[Python-3000] PEP Parade

[Guido van Rossum]

On 5/1/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 02:04 PM 5/1/2007 -0700, Guido van Rossum wrote:
> >On 5/1/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > > At 12:14 PM 5/1/2007 -0700, Guido van Rossum wrote:
> > > >Suppose you couldn't assign to __class__ of a function (that's too
> > > >messy to deal with in CPython) and you couldn't assign to its __code__
> > > >either. What proposed functionality would you lose?
> > >
> > > The ability to overload any function, without having to track down all the
> > > places it's already been imported or otherwise saved, and change them to
> > > point to a new function or a non-function object.
> >
> >Frankly, I'm not sure this is worth all the proposed contortions. I'd
> >be happy (especially as long as this is a pure-Python thing) to have
> >to flag the base implementation explicitly with a decorator to make it
> >overloadable. That seems KISS to me.
>
> I can see that perspective; in fact my earlier libraries didn't have this
> feature.  But later I realized that making only specially-marked functions
> amenable to overloading was rather like having classes that had to be
> specially marked in order to enable others to subclass them.

I admit I'm new to this game -- but most 3.0 users will be too. But I
would be rather fearful of someone else stomping on a function I
defined (and which I may be calling myself!) without my knowing it.
ISTM (again admittedly from the fairly inexperienced perspective) that
most functions and methods just *aren't* going to be useful as generic
functions. The most likely initial use cases are situations where
people sit down and specifically design an extensible framework with
some seedling GFs and instructions for extending them.

> It would mean that either you would obsessively mark every class in order
> to make sure that you or others would be able to extend it later, or you
> would have to sit and think on whether a given class would be meaningful
> for other users to subclass, since they wouldn't be able to change the
> status of a class without changing your source code.  Either way, after
> using classes for a bit, it would make you wonder why classes shouldn't
> just be subclassable by default, to save all the effort and/or worry.

Looking at it from a different way, you *do* have to mark APIs to be
subclasses explicitly -- using the "class" syntax. You can leave that
out, and then you end up with a bunch of functions in a module. Every
time I write some code I make a conscious decision whether to do it as
a class or as a method -- I don't create classes for everything by
default.

> Of course, I also understand that you aren't likely to consider overloads
> to be so ubiquitous as subclassing; however, in languages where merely
> static overloading exists, it tends to be used just that ubiquitously.  And
> even C++, which requires you to declare subclass-overrideable methods
> as  "virtual", does not require you to specifically declare which names
> will have overloads!

So this example can be interpreted both way -- sometimes you have to
declare an anticipated use, sometimes you don't. It still hasn't
convinced me that it's such a burden to have to declare GFs. I rather
like the idea that it warns readers who are new to GFs and more
familiar with how functions behave in Python 2. I can guarantee that
very few people are aware of being able to assign to func_code (hey,
*I* had to look it up! :-).

> But all that having been said, it appears that all of the current major
> Python implementations (CPython, Jython, IronPython, and PyPy) do in fact
> support assigning to func_code as long as the assigned value comes from
> another valid function object.  So at the moment it certainly seems
> practical (if perhaps not pure!) to make use of this.

I see your PBP and I raise you an EIBTI. :-)

> Unless, of course, your intention is to make functions immutable in
> 3.x.  But that would seem to put a damper on e.g. your recent "xreload"
> module, which makes use of __code__ assignment for exactly the purpose of
> redefining a function in-place.

No plans in that direction. Just general discomfort with depending on
the feature. Also noting that __code__ is an implementation detail --
it doesn't exist for other callables such as built-in functions.

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