Jeremy Hylton wrote: > BAW> Think about my proposal this way: it actually removes a > BAW> restriction. > > I think this is really the crux of the matter! The proposal removes > a useful restriction. Not sure... I wouldn't mind having the ability to add attributes to all Python objects at my own liking. Ok, maybe a bit far fetched, but the idea would certainly be useful in some cases, e.g. to add new methods to built-in types or to add encoding name information to strings... > The alternatives /F suggested seem clearer to me that sticking new > attributes on functions and methods. Three things I like about the > approach: It affords an opportunity to be very clear about how the > attributes are intended to be used. I suspect it would be easier to > describe with a static type system. It prevents confusion and errors > that might result from unprincipled use of function attributes. The nice side-effect of having these function/method instance dictionaries is that they follow class inheritance. Something which is hard to do right with Fredrik's approach. I suspect that in Py3K we'll only have one type of class system: everything inherits from one global base class -- seen in that light, method attributes are really nothing unusual, since all instances would have instance dictionaries anyway (well maybe only on demand, but that's another story). Anyway, more power to you Barry :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: 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