__name__ becoming read-write?

[Anthony Baxter]

On Tue, 24 Aug 2004 13:09:56 GMT, Arthur <ajsiegel at optonline.com> wrote:
> All I think I am looking for is proportionality.  The solution should
> be proportional to the problem.  The current syntax is expressive in
> the way that, I thought, was always considered to be fundamental to
> the concept of Pythonic.

See, I think decorators _are_ proportional to the problem. I think one
thing is that decorators are a nice language feature that will allow
for a large number of new approaches - things that wouldn't
necessarily have been considered before now.

> 1) the placement of the transformative code under the function  -
> leading to a purely hypothetical problem - I am not aware of any
> reports of acutal issues arising - of a reader missing important
> information related to the function.

Aside from anything else, it's ugly and hard to read code - you have
to flick to the bottom of the function to see what transforms might,
or might not, have been done.

> 2) burdensome amounts of typing when dealing with long function names.

It's not just a matter of typing, it's a matter of elegance. The
current syntax was always a placeholder until we figured out what, if
anything, needed to be added.

> If Python needs to apologize for being itself in the limited
> circumstances that give rise to these conditions, perhaps it can be
> done with a bit more - I don't know - dignity.  Which would involve
> recognizing the issues as minor annoyances, and providing some limited
> relief.

Again, I think you're misunderstanding the point of decorators.
They're a more generally useful feature, and I think people will be
far more likely to use them once they're a little more prominent. Not
everyone, sure, but those who can use it will find them incredibly
useful. The classic "synchronized()" decorator is one obvious example.
I think I've mentioned descriptors before in a similar context - 90+%
of Python programmers don't (knowingly) use them, but those who need
them find them incredibly powerful. And they can then write libraries
that use these, and other people can then use those libraries.

> And in those cases where the developer's editor's cut and paste
> facility are on the fritz and they are dealing with 70 letter function
> names, you have given them a writeable __name__ attribute as another
> weapon to solve their issue.

A couple of people have latched onto the writable __name__ thing, without
understanding some very basic problems with it - by itself, it's not
particularly useful. If you modify __name__, it does _nothing_ apart
from alter the name of the function that appears in tracebacks. It's
only when combined with decorators that it becomes useful, imho.