[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:
https://fluidpythran.readthedocs.io/en/latest/#command-pythran-block
Moreover we could easily implement this (pythran_def and cachedjit
decorators for methods):
https://fluidpythran.readthedocs.io/en/latest/#python-classes-pythran-def-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.
Pierre
Other related posts:
