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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 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 Python-Dev@python.org 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
> 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. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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
On Sat, Sep 12, 2009 at 9:57 AM, Darren Dale wrote: > I would be very interested in seeing a framework for generic functions > in the numpy standard library. Sorry, I meant to say "python standard library" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] clarification on PEP 3124 status
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. I was reading through the discussion on the python-3000 mailing list archive, and at one point somebody asked for other examples where generic functions are used in the community. The numpy project has a basic generic function mechanism for numpy's ufuncs (regular functions that operate on arrays), where subclasses of numpy.ndarray can define __array_prepare__ (this method will be added in numpy-1.4) and __array_wrap__ methods, which are sort of analogous to @before and @after in PEP 3124 (ndarray subclasses define an __array_priority__ attribute to decide how to dispatch). The numpy approach is not a general solution and is not as flexible as what is described in the PEP, but it can be used by functions that operate on subclasses that implement matrices, masked arrays, arrays with physical units. I would be very interested in seeing a framework for generic functions in the numpy standard library. I think would be more simple and flexible than what we currently have. Is there still interest/motivation for supporting generic functions in the standard library? Darren ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
