Re: [Python-Dev] clarification on PEP 3124 status
Hi Martin, On Sun, Sep 13, 2009 at 2:29 AM, "Martin v. Löwis" wrote: >> Could somebody please clarify the status of PEP 3124? At >> http://ftp.python.org/dev/peps/ , it is listed as "under >> consideration", but http://ftp.python.org/dev/peps/pep-3124/ says it >> has been deferred. > > This isn't really contradictory. "under consideration" means "in > progress": it has neither been accepted or rejected. > > 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. Darren ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] clarification on PEP 3124 status
2009/9/13 Darren Dale : >> 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. 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. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] clarification on PEP 3124 status
Hi Paul, On Sun, Sep 13, 2009 at 10:54 AM, Paul Moore wrote: > 2009/9/13 Darren Dale : >>> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] clarification on PEP 3124 status
At 08:29 AM 9/13/2009 +0200, Martin v. Löwis wrote: > Could somebody please clarify the status of PEP 3124? At > http://ftp.python.org/dev/peps/ , it is listed as "under > consideration", but http://ftp.python.org/dev/peps/pep-3124/ says it > has been deferred. This isn't really contradictory. "under consideration" means "in progress": it has neither been accepted or rejected. 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 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's deferred because the PEP needs a rewrite, and it isn't high on my priorities at the moment. It's also unlikely the rewrite will happen before PEAK-Rules reaches a non-alpha release status. (See http://ftp.python.org/dev/peps/pep-3124/#implementation-notes .) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
