Target Python Version? about pyecore HOT 7 CLOSED

Indeed, PyEcore is built to work with Python >= 3.3, that's why I used a custom enum implementation. Few days ago, I change it on this branch: https://github.com/aranega/pyecore/tree/feature/python-3.4_min so it uses the basic 3.4 built-in enum instead. The only thing is that there is a project that uses PyEcore: PyGeppetto and I don't know which Python version they are using. I will ask them so perhaps we could target newer Python versions.

Currently, Travis-ci tests PyEcore against Python from 3.3 to 3.6, so it is Python 3.6 compatible. I know that Python 3.6 have a lot of improvement and new stuffs (f-strings are so great), but at the moment, I would prefer to keep a Python 3.x compatibility. As the library is quite new, I think that the fact to have less constraint regarding the Python version could help people to easily try/test/experiment without being forced to install at least Python 3.6. What do you think?

Anyway, I'm going to ask the people from the Geppetto project which Python version they are using so we could at least target Python >= 3.4, I really don't like the custom implementation for the enum. I hope I will have a quick answer.

from pyecore.

The project homepage says 3.3. Regarding the enum: as I said there is a back port that can be easily used on demand via setup.py.

In general I would not restrict the interpreter version at this time, but use the best modern Python available. I heard similar suggestions from famous podcaster Michael Kennedy.

But of course this is your decision.

from pyecore.

Oups, I was trying to link this file from the branch.

Oh, I wasn't aware that the backport could be handled by the setup.py regarding the Python version... And now I'm saying it, I forgot I had a condition upon the Python version used in the setup.py...

I'm really sorry, I totally missed that. Obviously, I agree with your proposition, we should target an higher Python version as long as the Python 3.x version is not restricted.

from pyecore.

After short discussion with the people involved in PyGeppetto, it seems that the Python version used is Python 3.4, so we could directly jump to this one as lower version. For the exercice, I wil try to keep the Python 3.3 compatibility anyway and improve the setup.py as you suggested.

from pyecore.

Thanks a lot!

Still, I have this really strong desire to use modern Python as much as possible. So after I'll get the initializers from the other ticket done (and maybe other stuff that I'd like to have to ease actually using pyecore), I would probably go through the exercise and reproduce the MTL generator with a pure Python version. We can still talk later whether to do this in pyecore or externally. Once this works I can create another generator, using possibly newer or other features (I like the attrs library). In the very end, I could even generate my own ecore classes with this and possibly get a custom version of the framework.

Don't worry, I am not talking about splitting off. We'll talk about the details and how and where to extend. But from my point of view this would be a route allowing any kind of Python version support at some point.

Just sharing some slightly incoherent thoughts here...

from pyecore.

I pushed on develop the new setup.py and refactoring on the notification system to use the built-in enum.

I'm really open to a pure Python generator for static metamodels and I think it is relevant to add it in PyEcore as it will install the generator as a standalone application and the runtime library at the same time. I would still try to maintain the Acceleo version in order to keep a link with the MDE/Eclipse/EMF-Java community (always better for discussion/proposition and stuffs).

Regarding the other points, I'm open to any proposals as long as they keep the features of the dynamic layer, the direct static access to meta-attribute for static metamodel, the ability to have reflection and meta-reflection as well as the same names/concepts than EMF-Java ;). I know this is a long list (there is probably points I forgot), but to my mind, these points are crutial to avoid a big 'split' from the Eclipse/EMF-Java community which is, obviously, very active in MDE.

from pyecore.

Thanks for the enums and version/target clarification.

from pyecore.