> Because I'd like to avoid an inflation of functions. Instead, I'd
> prefer codecs.lookup to return an object that has the needed fields,
> but behaves like a tuple for backwards compatibility.
Here's how you can do that in 2.2a3 (I wrote this incomplete example
for another situation :-):
class Stat(tuple):
def __new__(cls, t):
assert len(t) == 9
self = tuple.__new__(cls, t[:7])
self.st_seven = t[7]
self.st_eight = t[8]
return self
st_zero = property(lambda x: x[0])
st_one = property(lambda x: x[1])
# etc.
t = (0,1,2,3,4,5,6,7,8)
s = Stat(t)
a,b,c,d,e,f,g = s
assert (a, b, c, d, e, f, g) == t[:7]
assert t == s + (s.st_seven, s.st_eight)
> > Note that the tuple interface was chosen for sake of speed and
> > better handling at C level (tuples can be cached and are easily
> > parseable in C).
Alas, a tuple subclass loses some of the speed and size advantage --
the additional instance variables require allocation of a dictionary.
(And no, you cannot use __slots__ here -- the slot access mechanism
doesn't jive well with the variable length tuple structure. If we
were to subclass a list, we could add
__slots__ = ["st_seven", "st_eight"]
to the class. But that's not fully tuple-compatible.)
--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