> >Aahz: > >> > >> +1 on changing __dynamic__ or at least enabling some kind of class > >> variable mutability by default. > Guido van Rossum wrote: > > 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). [Aahz] > Yeah, you did, but I didn't see you directly address my point about the > necessary mutability of class variables. I agree that they are necessary. What else do you want me to say? > > 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? The problem is that the only kind of control that is easy to implement is to make *everything* immutable. Given that I strive for __dynamic__=1 as the default, I don't want to add more code that's only temporary. Maybe I'll just make __dynamic__=1 the default in 2.2a4, and work on the performance issues later. (But there are subtle semantics differences as well that make life more complicated than it should be with __dynamic__=1.) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4