Transition from boostc to pure-python

[ddemidov]

I think we are now feature complete w.r.t. boostc version (pinging @ensonic). We can push this to PyPI and advertise on ev3dev.org.

Now, python-ev3dev package name on PyPI is taken by boostc version. The latest version published there was 0.2.2. I suggest we tag the pure-python bindings with something like 0.3 and just keep pushing to the same package on PyPI. This way users may still download older (boosts-based) versions. And I am going to put deprecation warning with a link to this repo in boostc version README.

[ddemidov]

We also may want to wait for @EricPobot's changes before version tagging. I've seen some nice work done already in his fork.

[ddemidov]

Also see #15

[rhempel]

@ddemidov, I will follow your lead on this - the Python packaging is something you are much more familiar with.
I think I can start making this into a Debian package.

[ddemidov]

@ensonic did some work on debian package for boosc version here. Can we use it?

[rhempel]

Yes, but now we need to add python-pil, beep, aplay, and espeak to the dependencies, fortunately we're not making changes to upstream sources so there's no patches necessary.

[dlech]

debhelper should take care of all of the python dependencies automatically. That is what ${python:Depends} is for in the debian/control file.

[ddemidov]

The 0.4.0 version of the bindings is uploaded to pypi: https://pypi.python.org/pypi?:action=display&name=python-ev3dev&version=0.4.0.

So the library may now be installed with easy_install -U python-ev3dev. We can put this into README, or we can wait until debian package is ready and use apt-get install python-ev3dev.

[ericpascual]

@ddemidov I'm far from home currently, and thus have no access to my machine. However as you could notice, I've pushed the latest version of my fork. Since I'm not sure to be able to isssue a pull request very soon, feel free to pick what is ok for you already.

One of the main points of my version (demoed in the small motors.py demo) is that the user of the lib does not make an import ev3dev, but a from ev3dev import <my_platform>, which in turn includes an from ev3dev import *, thus exposing transparently the base layer in addition to the extensions or overrides specific to that platform.

WRT autogen I've tried to backport my Python code to the templates, but have not tested if they reallly work. BTW I've also done minor fixes to some of the templates so that the code is more PEP compliant WRTcode formatting (PyCharm was underlining to much of it for code issues of this nature ;).

[EricPobot]

I'm happy my work has been retained :)
However, I could notice that only a part of the EV3 Leds stuff has been kept, and that the feature I've added to address the LEDs by side is not here. The public version does not allow to light the left one in red and the right one in green for instance, which my version can do.
Since this is a specificity of the EV3, it can be placed outside the autogen area.

[ddemidov]

I've seen the led-grouping code in your fork, and I agree it could be useful. The reason I did not pull it yet is that I could not come up with a way to do this through spec.json/autogen. Also, I am not sure mix_all is a good name for the function; may be mix_sides would be better?

[ddemidov]

I think we can introduce groups like left and right into spec.json. The idea is that each group has closely located leds, and each group has same set of colors. For example, ev3 has left and right groups of green/red leds, PiStorms has two groups of Red/Green/Blue leds. Then we could say 'set this group to this color', where color is a tuple of percentages. We could also add some predefined mixes/colors into spec.json as well. Then Leds.set(LEFT, AMBER) would work on ev3. May be can also add scale parameter to dim the color. Or maybe [c * 0.5 for c in AMBER] would be enough.

[EricPobot]

Just to be sure I have understood correctly the autogen stuff, its purpose is to generate the bindings for all the supported languages. Is this right ?

The idea is brilliant, but your previous comment makes me wonder if it is not starting to show to limitations, by adding a layer of additional burdens caused by the tool and not by the problems it is expected to solve.

As you could see, the involved code is pretty basic and straightforward, and IMHO writing it is simpler than finding a way to encode its logic into the autogen specs.

In addition I find that the Python code which is produced is sometimes not really Pythonic. For instance, you could notice that I've rewritten the EV3 buttons definitions using named tuples, which is a bit more readable than embedded dictionaries (even if I agree that at the end of the day objects are dictionary in Python)

Said differently, is the autogen strategy part of the solution, or part of the problem ?

[rhempel]

Well, there are always going to be stylistic differences :-) autogen will shine when we do more bindings, and although each individual class for motors, or LEDs may be simple, altogether there is 1.8K of code - what happens when we add a feature or attribute and need to update 6 bindings?

I will always suggest that we at least attempt to describe things like LED groups in the spec.json file, and if it does not work then we manually write some of the binding.

I will also always suggest that we take a break from writing the binding and actually attempt to program a robot so that we understand the actual problems our users will face.

As more advanced programmers, we tend to overthink the "right" solution and the result is that the binding never gets released.

At this point, it's not autogen or spec.json that is holding us back, it's adding better button and LED and screen support and changing the API for users. We will soon be at a good release point, I am still waiting for feedback from @ensonic to approve the Python API we have now so we can issue the 0.5.0 tag.

[ddemidov]

@EricPobot, I don't know why you keep saying the generated code is not pythonic. An autogen template is just a program that generates code, so if you don't like the code that is generated, you should blame the program author :). Hint: these blames usually go better with pull requests.

I agree with @rhempel that autogen is crucial for keeping sanity of all involved in developing all the language bindings (not only python). The README of the main repo says: 'Each binding complies with our universal language binding specification, which also serves as high-level documentation for our wrappers'. Keeping that true is much easier with autogen. Before the system was introduced, when @dlech pushed new kernel with updated drivers (that means: changed attributes), each binding developer had to update his bindings manually. That usually meant that some languages did not work for several weeks after kernel release. With autogen you just need to rerun the script (usually) to bring all the bindings up to date.