Tim Peters wrote: > > [M.-A. Lemburg] > > ... > > True, but I'm also thinking about writing new code in Python > > which uses these features and there I don't see the stability > > of the API just yet (but would really like them to stabilize > > *before* 2.2 moves out the door and even if this means waiting > > until after Christmas ;-). > > I tried to explain before that time isn't linear <wink>: "after Christmas" > probably means "next spring at earliest", and we just aren't going to let > that happen. Why not ? Who's pushing us ? AFAIK, there's no marketing team with a hammer out there forcing us to publish on a fixed date :-) Hey, these new features were once proclaimed as the Grand Unification to be announced in Python 3k... this step is a very important one in Python's development. Self-imposed deadlines should not get in the way of the design process. Well, IMHO, at least. > I can only suggest you pretend we didn't release the new features, then, in > any aspect which appears unstable -- you're not required to use them. I know... but you know as well as I do that people will start using these features right away -- "experimental" features have a tradition in Python of not being experimental in the usual sense of being subject to change in future releases. People basically start experimenting and then assume that their results will remain valid for years to come and shout out loud if they don't. > While > new ways to spell __slots__ and property() and staticmethod() and > classmethod() and super may get invented later, the 2.2 ways won't go away. That's what meant with the above note about "experimental" features in Python. > So that's focusing on the wrong things. The set of things that *may* break > appears impossible to characterize. For example, exactly how conflicts in > multiple inheritance get resolved, or exactly when an override of > __getitem__ in a subclass of dict will get invoked (e.g., currently not for > .update()), or that referencing an uninitialized __slot__ attr currently > returns None instead of raising NameError, or that e.g. > > >>> class myint(int): > ... def __init__(self, val): > ... int.__init__(val * 2) > ... > >>> i = myint(3) > >>> i > 3 > >>> > > without warning, etc. I don't know how to characterize these: they have > nothing in common, apart from being arguable. But *all* language behavior > is arguable, so that's not a clue either -- what's different in this case is > that Guido is still open to arguing about the new stuff. That means it's > all experimental, to some degree. True, and that's why I would like to see a simple list of features which will be safe to use in Python 2.2 and which do expose a stable API. Something like: * you can subclass from types and extend them, but not override existing methods or attributes * __specialmethods__ except __init__ are not guaranteed to work the same way as they do for instances etc. Or add a disclaimer like this to the prominent announcements, web-pages, etc.: """ Extending types in Python 2.2 is possible to some extent, but currently only provided for experimentation purposes and to get more experience with the overall design. The design will become stable in Python 2.3. """ -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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