pydsfapi [v3.2.0] - Official Python Client Library for DSF

[wilriker]

@achrn I have noticed something similar but TBH I have no idea what is going on here. Nothing has changed in regards to this but still it is no longer working. I have to investigate that.

Which python version are you using?

[achrn]

@wilriker Wow that was quick!

It occurred to me I could check for myself when the change happens - it does change between 3.1.1 and 3.1.2 and if I roll back to 3.1.1 my scripts start working again - MachineModel is subscriptable in 3.1.1, but not in 3.1.2 and 3.1.3.

Having looked at the diff on GitHub 3.1.1 - 3.1.2 I can't see why the changes would change what gets returned (apart from let it be longer). As far as I can see teh changed def receive_json(self): was returning a str and is still returning a str.

My Python is 3.7.3

[wilriker]

@achrn Just as an idea, have you removed all .pyc files as well as __pycache__ directories? Just to make sure nothing is stuck in half-way pre-compiled voodoo black-magic bogus.

[achrn]

@wilriker I ahdan't, but I was doing pip3 uninstall pydsfapi before each new install.

I've tried again - unistall, hunt for any pydsfapi traces and obliterate them (including fo ~/.local/lib/python3.7 where I found a few). I'm not sure I want to remove all __pycache__ and *.pyc - plus it would take a while to hunt them all down. There are no *dsf*.pyc or pydsfapi* (except the .gz I'm installing from) files anywhere on the machine before I do a pip3 install

After that, still the same behaviour - MachineModel object is not subscriptable.

I have a relatively simple workaround, because if I don't transfer a full model, my first 'patch' gets a whole model. So I can easily change my scripts to start with an empty dict, and use get_machine_model_patch() to obtain a 'patch' containing the whole model (as a nice predictable string). Then I apply that patch to the empty dict, and that gives me a dict of the machine model, and the script proceeds from that point fine.

[wilriker]

@achrn I have a vague theory of what might be the cause for this. But I can probably only test next week.

[achrn]

@wilriker No problem - as I say, I've got an easy workaround, so there's not a rush on my account. Thanks.

[wilriker]

@achrn said in pydsfapi [v3.1.3] - Official Python Client Library for DSF:

My scripts that previously did that then e.g. for h in machine_model['heat']['heaters'] are suddenly reporting TypeError: 'MachineModel' object is not subscriptable.

I see the same problem with 3.1.1. It works for me (both versions) if I use

for h in machine_model.heat['heaters']

i.e. trying to access heat as a member rather than a dict key.

[achrn]

@wilriker said in pydsfapi [v3.1.3] - Official Python Client Library for DSF:

It works for me (both versions) if I use
for h in machine_model.heat['heaters']

Yes, that works for me too in 3.1.3.

However, it breaks my patch-applying routine, so I think it's more work for me than my other workaround (at least, for my existing scripts).

[wilriker]

@achrn I don't know why this works for you in 3.1.1 (as it does not for me) but I found a simple way of getting it to work. I would though hold that off for version 3.2.0 because you said you have a working alternative solution.

[achrn]

@wilriker said in pydsfapi [v3.1.3] - Official Python Client Library for DSF:

I would though hold that off for version 3.2.0 because you said you have a working alternative solution.

Yes, no problem for me - I have what I wanted working now, so don't rush on my account.

[wilriker]

Release v.3.2.0

I am pleased to announce the release of version 3.2.0 of pydsfapi that syncs all the changes introduced with DSF 3.2.x.

This release also contains some major contributions and cleanups from @resam, thanks for that!

The package can be downloaded as usual from GitHub Releases page but will probably be available to be installed via pip in the future.