__name__ becoming read-write?

[Anthony Baxter]

On Tue, 24 Aug 2004 14:00:35 GMT, Arthur <ajsiegel at optonline.com> wrote:
> But all at a cost.  I would be comforted to hear you say something
> about the costs you perceive.  If you present it is all just a win,
> it becomes too easy to challenge your assessment. So easy, that even
> someone like myself can pull it off, at least to an extent - and at
> least in my own judgement.

_Any_ new feature has a cost - whether it is in the additional
training needed, the potential for truly horrendous hacks, the
backwards-incompatibility, or whatever else.

The additional training issue:
    One of my internal measures for evaluating new decorator syntax
options is that it be *obvious* that "this is something new". The
various ideas of "doing something wacky with a list" or "a magic
'decorate()' function" fail this test, for me. They're not obviously
doing something new.
    Following on from that, the new feature should be explainable in
the context of existing knowledge. The before-def decorator syntax is
easily explainable in this context. It might be that new python
programmers might not realise that a function or a method is just an
object, like any other, and can be treated just like any other object
- passed as an argument to a function, or whatever. If they've come
from a particularly limited language before Python, there might be a
bit of mental dissonance before they realise this, but they will
realise it eventually. And this is a good thing to realise - once you
"get" that everything's an object, you're on the path to understanding
Python well (I'd add as a footnote the understanding of what a
"variable name" actually means usually follows soon after this).

The potential for truly horrendous hacks:
    This is a given, and is the case for any new feature, particularly
one like decorators (or metaclasses, or descriptors, or ...). The
potential for nasty and clever hacks isn't a new thing - take, for
instance the "Don Beaudry hook" introduced for metaclasses way back in
Python 1.5. Jim Fulton took this small hole and drove a large truck
called ExtensionClass through it, leading to the brain-warping of
Acquisition. Or the current Zope3 Interfaces package, which uses a
truly nasty sys._getframe() hack. But in both those cases, end users
of the features don't have to care about the underlying nastiness,
they can just use the new features.
    Will people write unpleasant decorator functions? Sure. But the
same people probably write hideously complex __del__ methods on every
object, and don't understand why cyclic GC then doesn't work for them,
or why their destructors aren't being called reliably.  Hell, look at
the recent:
     class Argh(random.choice(dict,list)): 
         ....
thing posted by someone (mwh? I forget)

The backward incompatibility:
    I regard this as a non-issue. For starters, pretty much *every*
major release of Python has had some new feature that wasn't backwards
compatible. For example, generator expressions were also added to 2.4.
They will cause a SyntaxError in Python 2.3 and earlier. And I would
guess that genexprs will be used far far more often than decorators in
most codebases.
    If backwards compatibility *is* an issue, note that there's a
couple of solutions here. For starters, there's the maintenance
releases of the previous release. I'm being a complete
pain-in-the-arse with stopping any new features creeping into those
releases, for *damn* good reason. I'm trying to make sure that people
can get the benefits of bug fixes, without having their entire
codebase break. And once 2.4 final ships, I'll be cutting what I plan
to be the last of the 2.3 series, and moving on to 2.4.1. If you
really, really want to keep using 2.3, and this is a problem for you
(because you want the continuing stream of bugfixes), I'm happy to
help bring someone up to speed so that they can take on 2.3.6 and
onwards. (As should be obvious, I'm using "you" in the general sense
here).