On Mon, 20 Mar 2000, Jeremy Hylton wrote: > I'm not sure what you mean by "fix." I mean any sane behaviour -- either failing on TypeError at the beginning, like "for" does, or executing without raising an exception. Raising an exception in the middle which is imminent is definitely (for the right values of definitely) a suprising behaviour (I know it suprised me!). >I think by fix you mean, "allow the broken code above to > execute without raising an exception." Yuck! I agree it is yucky -- it is all a weird echo of the yuckiness of the type/class dichotomy. What I suggested it a temporary patch... > As far as I can tell, the problem is caused by the special > way that a for loop uses the __getitem__ protocol. Well, my look is that it is caused by the fact __getitem__ is used both for the sequence protocol and the mapping protocol (well, I'm cheating through my teeth here, but you understand what I mean <wink>) Agreed though, that the whole iteration protocol should be revisited -- but that is a subject for another post. > The right solution, I think, is to allow a means for stating > explicitly whether a class with an __getitem__ method is a sequence or > a mapping (or both?). And this is the fix I wanted for Py3K (details to be debated, still). See? You read my mind perfectly. > I suspect that the right solution, circa > Py3K, is that classes must explicitly state what types they are > subtypes of or what interfaces they implement. Exactly. And have subclassable built-in classes in the same fell swoop. getting-all-excited-for-py3k-ly y'rs, Z. -- Moshe Zadka <mzadka@geocities.com>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com
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