On Oct 13, 2019, at 12:02, Steve Jorgensen <ste...@stevej.name> wrote: > > There are many cases in which it is awkward that testing whether an object is > a sequence returns `True` for instances of of `str`, `bytes`, etc. > > This proposal is a serious breakage of backward compatibility, so would be > something for Python 4.x, not 3.x.
I’m pretty sure almost nobody wants a 3.0-like break again, so this will probably never happen. > > Instead of those objects _being_ sequences, have them provide views that are > sequences using a method named something like `members` or `items`. Nothing else in Python works like this. Dicts do have an `items` method, but that provides an iterable (but not indexable) view of key-value pairs, while the dict itself is an iterable if its keys. So I think this would be pretty confusing. Also, would you want them to not be iterable either? If so, that would break even more code; if not, I don’t think it would actually solve that much in the first place. The main problem is that a str is a sequence of single-character str, each of which is a one-element sequence of itself, etc. forever. If you wanted to change this, I think it would make more sense to go the opposite way: leave str a sequence, but make it a sequence of char objects. (And likewise, bytes and bytearray could be sequences of byte objects—or just go all the way to making them sequences of ints.) And then maybe add a c prefix for defining char constants, and you’ve solved all the problems without having to add new confusing methods or properties. Meanwhile, the most common places you run into this problem are in functions that take a single str argument or a single iterable-of-str argument. Most such cases have already been solved by taking a str or tuple-of-str, which is clunky, even it’s worked since Python 0.9. But a better solution for almost all such cases is to just change the function to take a *args parameter for 0 or more string arguments. While we’re at it, if you really wanted to make a radical breaking change to Python involving view objects, I’d prefer one that expanded on dict views, to make all kinds of lazy view objects that are sequences or sets (e.g., calling map on a sequence gives you a sequence that’s computed on the fly; filtering a set gives you a set; reversing a sequence gives you a sequence; etc.), rather than making something else that’s kind of similar but doesn’t work the same way. And finally, if you want to break strings, it’s probably worth at least considering making UTF-8 strings first-class objects. They can’t be randomly accessed, but with an iterable-plus API like files, with seek/tell, or a new more powerful iterable API like Swift or C++, a lot of languages have found that to be a useful trade off anyway. But again, I doubt any of this is likely to happen, as nobody wants to go through another decade-long painful transition unless the benefits are a whole lot bigger than fixing a couple of minor things people have already learned how to deal with. _______________________________________________ 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/T2TLCUVKZHEZBTY3IUH34MU2XH7VNE4T/ Code of Conduct: http://python.org/psf/codeofconduct/
