> Aahz: > > It's not particularly convenient for me to try out 2.2a1, so I'm just > > going by what's written. One little hole that I don't see an answer to > > is what happens when you do this: > > > > class C(object): > > x = 0 > > def foo(cls): > > cls.x += 1 > > foo = classmethod(foo) > > > > C.foo() > > Okay, after thinking about this a bit, I think that if the above code > requires __dynamic__=1 to work, then the default for __dynamic__ should > be changed. I don't find the arguments about changing __class__ to be > particularly persuasive, but I think the above code *is* closely related > to standard Python idioms that should work by default. > > +1 on changing __dynamic__ or at least enabling some kind of class > variable mutability by default. > -- My 2cts: I think this is also a matter of how much complex the language is perceived: Before 2.2: everything is dynamic and mutable (pretty general rule, a performance killer but that's another point ;) ) After: - this is mutable and that's not (a more complex picture) vs. - by default everything is mutable ... (advanced user) but you can tune that (for good reasons) A marginal note: I agree with James Althoff that some more granularity about dynamic behavior would be a good thing (but only if the newbie is protected from the burden) regards, Samuele Pedroni.
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