I just tried to build pyindi-client with latest indi core commit on up-to-date Ubuntu 20.04. That compiles fine but the testindiclient.py script crashes when trying to iterate over a switch property:
```
elif p.getType()==PyIndi.INDI_SWITCH:
tpy=p.getSwitch()
for t in tpy:
TypeError: 'SwigPyObject' object is not iterable
pure virtual method called
```
It seems that Property get* methods are pure virtual. Will have a more precise look to that later.

Getting similar problems trying to use even basic basic PyIndi stuff - connection works but trying to update parameters I get the same subscriptable error.
None of the example scripts in the docs work except the basic "import, connect, and do nothing" one.

So yeah, PyIndi appears completely broken right now on 1.8.9. I've been trying to write a Rust INDI client which can provide a Python binding because the current state of PyIndi isn't great (and on other platforms like Windows it's a challenge), but it's a lot of effort to get that working.

First, go python3. Then, because there are changes in the structure of indi in progress, please be patient with the maintainer of pyindi, or offer to debug more deeply. Thanks!

-Eric

I'm using Python 3.

I am completely up for pitching in on pyindi if I can figure out how - I just wanted to confirm that the issue seen above was not isolated and was current.

My main gripe with pyindi is the documentation - if there are major changes underway that's okay, I know docs are often the last thing to get updated (being a maintainer for some OSS myself) but it doesn't help newbies (like me!) coming into an ecosystem if the basic examples explode with the "correct" config/setup/etc.

Edit: In the spirit of debugging "more deeply" - the issue appears that the attrs (value) referenced in the docs on the property returned by a device.getNumber() call (and from the looks of it, other similar calls) don't exist any more. The returned object is a INDI::PropertyView SWIG wrapper which has essentially no attributes or functions outside of the generic SWIG ones. This means you can't alter e.g. an exposure time value before returning it with sendNewNumber.

Without modifying the value, the sendNewNumber function additionally crashes with the following:
Traceback (most recent call last):
  File "allsky/allsky.py", line 91, in <module>
    asc.sendNewNumber(camera_exposure)
  File "/usr/local/lib/python3.7/dist-packages/PyIndi.py", line 1147, in sendNewNumber
    return _PyIndi.BaseClient_sendNewNumber(self, *args)
NotImplementedError: Wrong number or type of arguments for overloaded function 'BaseClient_sendNewNumber'.
  Possible C/C++ prototypes are:
    INDI::BaseClient::sendNewNumber(INumberVectorProperty *)
    INDI::BaseClient::sendNewNumber(char const *,char const *,char const *,double)

This happened a lot before, and it's definitely gonna happen again.
As much as I appreciate the pyindi-client project, it's essentially just a workaround for automatic API generation.

I have to wonder if it wouldn't just be easier to write a native python client for the XML protocol, or possibly a c++ python wrapper exposing a simplified version of the API...

I've been working on a Rust-native client that has no dependency on libindi, specifically because I want something portable; in theory it would be quite easy to provide a Python extension with the Rust backend.

Having said that, a pure Python client would be much easier to write (I'm struggling with INDI because of the poor state of XML parsers in Rust) and in theory to maintain given the wider Python userbase. For client authoring it'd certainly be easier to work with. I'm writing this purely to drive an all-sky camera and that'll be shipping images off to a neural net/CV stuff for image segmentation, and Python's a native of that sort of thing.

I would be afraid that the Rust-based python extension would have similar problem..
Not that I don't trust your work, but given that not many people know Rust, it would be difficult to find someone helping you maintain it :\

Ideally, the best solution would be a simplified JSON interface written in C++ directly into the INDI server. That way, writing a client for python, or indeed any other language, would be much much simpler

There seems to be already some work made in that direction:
github.com/geehalel/npindi
github.com/MMTObservatory/indiclient/tree/master/indiclient

I definitely agree that a full python solution would eventually be the best choice for long term support.
Cases where people will write exotic macros here and there that will probably continue break swig (without even considering the static binary dependency for the client)

That is good to know!
I was actually about to start my own implementation, but if I can find the time I might try to contribute to one of these.
geehalel implementation seems more mature, but also inactive in a couple of years.
@Jean-Luc do you have any insight on this?
is there a way to tag someone in this forum? 

The macro is not exotic and it was never a problem. The error was in using a macro without a proper include in pyindi-client.
Most of the problems with PyIndi are related to the work on the INDI Library to keep the interface in the future without rebuilding dependencies.
Also, high-level functions that facilitate the development process are implemented.

I am currently creating automatic builds for Linux / MacOS. If you like, I can add additional tests for pyindi-client.

Ok thank you for the feedback, and I apologize for mentionning the wrong problem. I was simply not able to determine what was the issue by myself.
I just realized that the macro I suspected to be the initial source of the problem was more or less an equivalent of Q_DECLARE_PRIVATE one can also find in QT source code that is apparently meant to bypass some compiler limitation with RTTI and dynamic_cast.

In my humble opinion it would be a good idea to have pyindi client tested at least as part of indi releases, as I think this project really makes indi extremely powerful, and some opensource projects with growing popularity are relying on it (hinking here at the fantastic work done by Gulinux). However it is definitely not my call, as I am not doing any significant maintenance of either indi or pyindi-client.

Thank you pawel-soja for your work on the project !

Thanks, I think I can support pyindi, monitor the status, and suggest an easier way to write in python (using INDI Library).
All upgrades are backwards compatible for C++, but I can see there are problems with swig - to be taken care of.