[Python-Dev] clarification on PEP 3124 status (original) (raw)
Darren Dale dsdale24 at gmail.com
Sun Sep 13 18:27:01 CEST 2009
- Previous message: [Python-Dev] clarification on PEP 3124 status
- Next message: [Python-Dev] clarification on PEP 3124 status
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Paul,
On Sun, Sep 13, 2009 at 10:54 AM, Paul Moore <p.f.moore at gmail.com> wrote:
2009/9/13 Darren Dale <dsdale24 at gmail.com>:
If Phillip doesn't respond here, you may want to ask him directly. My impression is that it is deferred because nobody is pursuing it actively (including Phillip Eby). It's common for a PEP to be in that state for several years, "deferred" then is an indication that readers shouldn't expect a resolution in short term.
That is why I asked, I wondered if it is being actively considered and pursued, or if it had been deferred or worse abandoned.
That said: my personal feeling is that this PEP is way too large, and should be broken into seperate pieces of functionality that can be considered independently. There is a lot of stuff in it that isn't strictly necessary to provide the feature listed in the rationale. It would be nice to have a suitable foundation upon which more elaborate third party dispatchers could build. The potential generic functions have in a project like numpy are pretty exciting. You may also be interested in http://bugs.python.org/issue5135 which is a (much) simpler attempt to introduce generic functions into the standard library.
Thanks for the pointer. I actually read through the discussion there yesterday. I don't think simplegeneric would be especially useful to numpy. For example, multiplying a numpy.array([1,2,3]) with a quantities.Quantity([1,2,3], 'm/s') should produce a new Quantity regardless of the order in which they are provided to numpy.multiply(). Numpy can handle this particular example now, but the mechanisms are a bit convoluted.
Generally, these things get stalled because the core developers don't have sufficient interest in the topic to do anything directly, and the arguments in favour aren't compelling enough to make a difference. Maybe the benefits numpy would get would help the case.
I am a relatively new contributor to the numpy project, contributing bug fixes and features (most of which have been related to -- or could benefit from -- generic functions) to better support subclasses like Quantity. Numpy has different kinds of arrays (ndarrays, array scalars, masked arrays, matrices) and supports many different data types (int8, float32, complex64, etc). The ability to dispatch based on the object type (or combinations thereof), or on combinations of data types, or perhaps on the units of quantities, seem like good examples where predicative dispatch would be useful.
I am primarily trying to get up to speed to help with the effort to transition numpy to python-3. Perhaps generic functions could help make the numpy source code more accessible and maintainable, so that maybe someday there would even be interest in including numpy or some subset thereof in the standard library. Anyway, it is helpful to me to see where generic functions stand and how they might develop in the standard library as we work on numpy support for python 3.
Regards, Darren
- Previous message: [Python-Dev] clarification on PEP 3124 status
- Next message: [Python-Dev] clarification on PEP 3124 status
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]