Alex Hall wrote: > > Strings already have an exception in this area. Usually x in y means > any(x == elem for elem in y). It makes the two meanings of in > match
Actually, `in` means the same in strings, in sequences, in lists, etc. But, in Python's view, a string is composed of sub-strings, the smallest one being a character. So `in` looks for substrings and characters in strings. Looks strange to you? It is coherent with the nature of strings in Python. , and to me (I don't know if this is true) it's the reason that iterating over > dictionaries yields the keys, although personally I'd find it more convenient > if it > yielded the items. Oh, I think that dictionaries iterate over keys because you can get the associate item using the keys (not vice-versa). But, probably this is not the real reason. > Another somewhat related example: we usually accept that basically every > object can be > treated as a boolean, even more so of it has a __len__. But numpy and pandas > break this 'rule' by raising an exception if you try to treat an array as a > boolean, Well, I think that some objects (mainly implementing __bool__ and some related magic methods) can be evaluated as boolean. Of course, __bool__ and __len__ can be overridden and objects can refuse to be evaluated as boolean as you pointed out. I do not catch the analogy with str class... Every object, every class can be redefined in Python... > In a sense these libraries decided that while unambiguous behaviour could be > defined, > the intention of the user would always be ambiguous. The same could be said > for strings. > Needing to iterate over a string is simply not common unless you're writing > something like > a parser. So even though the behaviour is well defined and documented, when > someone tries > to iterate over a string, statistically we can say there's a good chance > that's not what > they actually want. Are you implying that developers are wrong when they iterate over strings? Seriously? Does it matter in any case? Strings must be defined in Python in some way. Immutable sequence strings was the choice. If they are sequences, they must behave as sequences. If they were foo objects, they must behave foo objects. The implementation, the syntax, and the semantics of strings are coherent in Python. If you want to change this, you must change the foundations of Python strings. We should not be wrong about this. Ultimately, it does matter how many people iterate on strings. That is not the question. > And in the face of ambiguity, refuse the temptation to guess. > I do think it would be a pity if strings broke the tradition of indexable > implies > iterable, but "A Foolish Consistency is the Hobgoblin of Little Minds". The > benefits in > helping users when debugging would outweigh the inconsistency and the minor > inconvenience > of adding a few characters. Users who are expecting iteration to work because > indexing > works will quickly get a helpful error message and fix their problem. At the > risk of > overusing classic Python sayings, Explicit is better than implicit. > However, we could get the benefit of making debugging easier without having > to actually > break any existing code if we just raised a warning whenever someone iterates > over a string. It doesn't have to be a deprecation warning and we don't need > to ever > actually make strings non-iterable. I do not agree at all. Every programming language makes a compromise. Languages are defined by what they do and what they do not. Python has chosen to be a immutable string sequence language and in my humble opinion it has been coherent with that choice. Other alternatives would be chosen, of course. But they were not. It is not a question of right or wrong, better or worse. It is a question of being consistent. And, I should say, Python is consistent in this particular point. > I'm out of time, so I'll just quickly say that I prefer .chars as a > property without the (). And jdveiga you asked what would be the advantage of > all this after I made my previous post about it biting beginners, I'm not > sure if you > missed that or you were just typing yours when I made mine. Yeah, I was typing and, yeah, I had answered you as soon as I saw your message. Sorry, but I do not agree with you once again ;-) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FX5SMGSP5KPKGZG646TB6UYOJZ7JRD4J/ Code of Conduct: http://python.org/psf/codeofconduct/
