[pythran] Re: Future plans?

  • From: Pierre Augier <pierre.augier@xxxxxxxxxxxxxxxxxxxxxx>
  • To: pythran@xxxxxxxxxxxxx
  • Date: Tue, 27 Nov 2018 16:35:43 +0100

Le 27/11/2018 à 14:33, Neal Becker a écrit :

Great to hear!
My usual use case does NOT have any inheritance (inheritance is overrated).  Classes are just used as containers to maintain state (data).  This matches a paradigm where a system is composed of objects that have some internal state (e.g., parameter settings).

On Tue, Nov 27, 2018 at 8:28 AM serge guelton <serge.guelton@xxxxxxxxxxxxxxxxxxx <mailto:serge.guelton@xxxxxxxxxxxxxxxxxxx>> wrote:

    On Tue, Nov 27, 2018 at 07:52:34AM -0500, Neal Becker wrote:
    > Dare I ask, is there a plan to support classes in the future?

    Not in the very near future, but it's a mid-term goal to support,
    say, data classes or « class without inheritance », or some
    simplified version of a class. The typing system used by Pythran
    needs to be enhanced, and when that task pops up, making the
    system extendable would pave the way for basic class support.
    Until then, collecting use cases would be a great idea: can you
    open an Issue where you, and eventually other pople, would provide
    examples of minimal class support requirements?

I use a lot classes with Pythran, in particular in https://bitbucket.org/fluiddyn/fluidsim

Support for proper data classes (https://docs.python.org/3/library/dataclasses.html) by Pythran would really be nice but I guess it is very difficult and not for tomorrow...  Wolf Vollprecht wrote that he "feel[s] like it could work out of the box, at least for single inheritance." (https://twitter.com/wuoulf/status/1062282912714973184) I have to say that I don't understand how it could work. I think if we have classes in Pythran we **need** simple inheritance (like this https://gist.github.com/paugier/7f9db3a3690758483108788d124e441a). Otherwise, I don't really see the point of having Python classes in Pythran... And without this, it would be very error prone: the same code leading to very different behaviors in Python and in Pythran.

That said, I think there is the same problem with cdef Cython classes ("built-in type"). But Pythran (supporting a subset of Python) is not Cython (a superset of the Python language). Since it is not possible to define "built-in types" in pure python (tell me if I'm wrong), it would be strange to be able to do it with Pythran, especially with the same Python syntax used to defined Python classes. At least we would need a special API to define such classes in the Pythran file (something like `class MyType(pythran.buildin_type):`). Note that it should be possible today to define in Cython built-in types with code using Pythran.

Sorry to insist with fluidpythran but there is already an API to use Pythran in Python classes by defining blocks of code compiled by Pythran:


Moreover we could easily implement this (pythran_def and cachedjit decorators for methods):


I'm pretty sure I'm going to implement it (for the simple case without method calls) because it would simplify a lot of code in FluidDyn packages.  I just don't know when :-) Now I think I need to slow down with fluidpythran until I get at least a first feedback on this project :-)

Note that it seems to me that @pythran_def / @cachedjit for methods of Python classes is MUCH simpler to implement than classes in Pythran. I think for most cases, @pythran_def / @cachedjit for methods would really be sufficient.

Python is bad for numerical kernels and for these parts Pythran is really useful. For the pythonic soup around the numerical kernels, Python is usually fast and good enough (especially with PyPy).

To summarize,

- I think we should be able to define Python classes using Pythran in Python with a nice Python API (for example with fluidpythran)

- I guess we can already define build-in types using Pythran with Cython

- I'm a little bit skeptical about defining build-in types with Pythran (we have Cython for that + it would break the "Pythran supports a subset of Python" assertion, except if we have a Pythran runtime API to be able to execute with the Python interpreter code in not-compiled Pythran files (pythran.buildin_type), but it is against Pythran principles)

- Proper Python classes in Pythran files seem very complicated. Pythran should be able to go back in the Python world and it is also against Pythran philosophy.


Other related posts: