From: "Guido van Rossum" <guido@python.org> > > Do you intend to have a test for "is this an iterator" at all? > > Not right now, see the rest of my email. The best you can do is check > for a next method and hope for the best. I only asked because the rest of your email seemed to imply that you didn't believe in such checks at this time, while the sentence above my question seemed to imply there is/should be such a test. Thanks for clarifying. > > If LBYL is bad, what is introspection good for? > > Ask Alex. OK. Alex, what's introspection good for? > > I understand that that's always been "the Python way". However, > > isn't there also some implication that some of the special functions > > are more than just a way to provide implementations of Python's > > syntax? > > Like what? > > > Notes in the docs like those on __getitem__ tend to argue > > for that, at least by convention. Unless I'm misinterpreting > > things, "the Python way" isn't quite so one-sided where protocols > > are concerned. > > Can you quote specific places in the docs you read this way? Just for example: __getitem__: "For sequence types, the accepted keys should be integers and slice objects. .... If key is of an inappropriate type, TypeError may be raised; if of a value outside the set of indexes for the sequence (after any special interpretation of negative values), IndexError should be raised. Note: for loops expect that an IndexError will be raised for illegal indexes to allow proper detection of the end of the sequence. " __delitem__: "Same note as for __getitem__(). This should only be implemented for mappings if the objects support removal of keys, or for sequences if elements can be removed from the sequence. The same exceptions should be raised for improper key values as for the __getitem__() method." __iter__: "This method should return a new iterator object that can iterate over all the objects in the container. For mappings, it should iterate over the keys of the container, and should also be made available as the method iterkeys()." The way I read these, the behavior of an implementation of these functions isn't really open-ended. It ought to follow certain conventions, if you want your type to behave sensibly. And that's about as strong as any legislation I've seen anywhere in the Python docs. > I don't > see it, but I've only scanned chapter 3 of the Language Reference > Manual. > > > Just for the record, I never meant to imply that it was broken, only > > that I'd like to get a little more from it than I currently can. > > Maybe I should read Ping's email. From the discussion I figured he > was arguing this way. I think you have to settle with what I proposed > at the top. Of course I do; I never expected otherwise. Like most of my other suggestions, this is a case of "OK, whatever you say Guido... but as long as people are interested in discussing the issues I'd like them to understand my reasons for bringing it up". -Dave
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