[Python-3000] pep 3124 plans

Guido van Rossum guido at python.org
Tue Jul 17 23:47:51 CEST 2007


On 7/13/07, Michele Simionato <michele.simionato at gmail.com> wrote:
> Phillip J. Eby <pje <at> telecommunity.com> writes:
> > For what it's worth, the pkgutil
> > module already contains an even simpler generic function
> > implementation than simplegeneric, and is already in the stdlib
> > albeit undocumented.
>
> Well, that is good to know. Personally I would be content with something
> at that level of sophistication (i.e. the absolute minimum). I think there
> is no much experience in the community with generic functions (except for
> you) and there is no danger in waiting and in acquiring more experience
> before including in the standard library a fully featured package. After
> all, RuleDispatch is already out there and there is no reason for putting
> everything in the stdlib. For the same reason, I am happy that Zope interfaces
> will stay out of the stdlib, and that we will have the much simpler ABC
> (of course one could argue that generic functions are better than ABC and
> actually I think so, but still ABC are a simpler entry point for most
> programmers, more in line with how Python has worked until now, and they
> will allows me to throw away an half-backed interface implementation I am
> using now, which is always a good thing ;)

Actually, I believe ABCs and GFs work well together, and I believe
Phillip has said so too.

Regarding the fate of PEP 3124, perhaps the right thing is to reject
the PEP, and be content with having GFs as a third party add-on? There
seems to be nothing particular about Python 3.0 as the point of
introduction of GFs anyway -- they can be introduced just as easily in
3.1 or 4.0 or any time later (or earlier, as Phillip's existing
implementation show).

I have one remaining question for Phillip: why is your design
"absolutely dependent on being able to modify functions in-place"?
That dependency would appear to make it harder to port the design to
other Python implementations whose function objects don't behave the
same way. I can see it as a philosophical desirable feature; but I
don't understand the technical need for it.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list