On Monday, September 30, 2019 at 12:24:30 AM UTC-4, Andrew Barnert via Python-ideas wrote: > > On Sep 29, 2019, at 16:41, Steven D'Aprano <st...@pearwood.info > <javascript:>> wrote: > > > >> On Sun, Sep 29, 2019 at 11:27:32AM +0100, Oscar Benjamin wrote: > >> > >> That's the point that I would make as well. What can you do with an > >> object that is only known to be Subscriptable? > > > > I can subscript it. What did you expect the answer to be? > > I think the idea here is that your type follows the “old sequence > protocol”, where you can index it with 0, 1, … until you get an IndexError, > without having to check __len__ first. > > Since there are various bits of Python (including the iter function) that > support this protocol, it’s odd that there’s no ABC for it. And it’s not > just that it’s odd, it’s different from almost every other > collection-related protocol in Python. > > I think the only reasonable argument against this is that “old-style” > means “legacy”, as in you shouldn’t be creating new classes like this. But > I don’t think that argument is true. There are perfectly good use > cases—like your infinite sequences—that are perfectly good old-style > sequences and are not valid Sequences, and how else are you supposed to > implement them? (Iteration is great, but sometimes random access matters.) >
That's funny, I always thought of that as legacy. The iterator protocol has been a special case in so many proposals I've seen on this list. I think it's really ugly. Instead of collections.abc.OldStyleSequence, what do you think of adding something like InfiniteSequence to collections.abc instead? It's basically Sequence without __len__, __reversed__, or __count__. I don't see it getting much use though. > > If I’m right about what you’re asking for, I think it’s a useful addition. > > Of course the same protocol would accept all kinds of bizarre other things > that support __getitem__ for different reasons, like the “I want to spell > calling differently” thing, plus (somewhat less uselessly) > typing._GenericAlias subclasses like typing.List. But I don’t think that’s > a problem. Sure, it’s not ideal that your test would accept typing.List, > but who’s going to pass the List pseudo-type to a function that clearly > expects some kind of collection? If they get a different exception than > they expected (a TypeError a few lines down, most likely), who cares? That > seems like a consenting adults issue. > _______________________________________________ > Python-ideas mailing list -- python...@python.org <javascript:> > To unsubscribe send an email to python-id...@python.org <javascript:> > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/LPQXOMBHEKSPZZVRDB36U5WFTABBLMCK/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/ETY5PLWHCPIIC7BFUGLZ6CEN4CRL7MQF/ Code of Conduct: http://python.org/psf/codeofconduct/
