[M.-A. Lemburg]
> I'd suggest that Guido marks those features he considers stable
> as such and clearly states which other features should still
> be condsidered experimental and not for production use.
>
> I intend to make some of the mx-datatypes subclassable but would
> want to have to support n different ways of implementing the details
> (I'll already have to support two different ways: classic and
> new style... wouldn't want to do classic, new style version 2.2,
> new style version 2.3, etc.)
The clearest statement to date is probably here:
http://aspn.activestate.com/ASPN/Mail/Message/827383
Note that it ends with:
We should document this more clearly and in more detail.
And we should.
The internal details are pretty stable now; *perhaps* they'll need to be
rearranged to cater to things that can't be done at all now, but that's true
of every part of the language (albeit especially true of large new
features).
__slots__ et alia are shallow spelling details, where "shallow" doesn't mean
unimportant but that changing the spelling has scant effect on the
internals -- note how Michael bragged about how short and unintrusive his
__slot__-respelling patch was <0.9 wink>. Adding new ways to spell things
shouldn't have any effect on how you need to implement your extension types.
Note that we've already gone thru the exercise of making all the basic
builtin types subclassable, so have some confidence that the subclassing
APIs are both usable and solid. They've also been stable (e.g., I can't
think of any change to them between the last alpha and current CVS).
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