[Python-Dev] Re: 2.2a1: classmethod() and class attributes

[Aahz Maruch]

[okay, so I'm following up on old stuff -- sue me]

[there's also excessive quoting to maintain context]

Guido van Rossum wrote:
>Aahz:
>> 
>> +1 on changing __dynamic__ or at least enabling some kind of class
>> variable mutability by default.
> 
> After converting the Tools/compiler package to the new class system, I
> tend to agree (I already said so on c.l.py in my last post there).

Yeah, you did, but I didn't see you directly address my point about the
necessary mutability of class variables.

> For dynamic classes, I must assume that at any time someone can add a
> special method (like __iter__) to a class.  It's hard to set up things
> so that the dispatch function is set in the type object at the moment
> C.__iter__ is assigned: it would require a class to keep track of all
> its subclasses, without keeping those subclasses alive.  While I know
> I can do that using weak references, I don't like having to maintain
> all that administration.  So at the moment, when a class is dynamic, I
> just stick all dispatch functions in the type object -- the dispatch
> functions will raise AttributeError when their corresponding method is
> not found.  (This is the same approach used for classic classes, BTW.)
> 
> This is slower than it should be -- the fully dynamic Tools/compiler
> package compiles itself about 25% slower this way.  If I tweak it to
> use all static classes (not very hard), it runs at about the same
> speed as it does with classic classes.  I imagine I could make it
> faster by using __slots__, but I don't know enough about the internals
> yet to be able to do that.
> 
> My goal (before I'm happy with making __dynamic__=1 the default) is
> that dynamic classes should be at least as fast as classic classes.  I
> haven't profiled it yet -- it's possible that there's a cheap hack
> possible by making more conservative assumptions about __getattr__
> alone -- classic classes special-case __getattr__ too.)

Okay, keeping in mind that I don't actually understand what I'm talking
about, what is the problem involved in permitting existing attributes to
be mutable?  

That is, as I think James Althoff has pointed out, there are at least
two levels of mutability, one of which is the ability to mutate existing
attributes, and another of which is the ability to add attributes.
Would making this all finer-grained help?  Do we actually need to
control whether existing attributes are mutable?
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6       <*>       http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista

We must not let the evil of a few trample the freedoms of the many.