Thanks you for taking up this issue Pierre! I just want to make one
comment. You say classes without inheritance is pointless. I use them
constantly, where my usecase was already explained.
On Tue, Nov 27, 2018 at 10:35 AM Pierre Augier <
pierre.augier@xxxxxxxxxxxxxxxxxxxxxx> wrote:
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> wrote:
On Tue, Nov 27, 2018 at 07:52:34AM -0500, Neal Becker wrote:https://bitbucket.org/fluiddyn/fluidsim
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
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
