On Wed, Aug 26, 2020 at 12:38 PM Alex Hall <alex.moj...@gmail.com> wrote:
> > This is why we have ABCs in the first place (and static checking). So that > you can't add it to Sequence is already a smell. If it's in the Mapping > protocol, why isn't it in the Sequence protocol? > > This is all just a general feature of ABCs. They were written once and > frozen in place and no new methods can be added to them because it would > break compatibility. It's not specific to this proposal. | and |= operators > were added to dict but not to Mapping/MutableMapping for the same reason, > even though the same operators exist with a similar meaning in the > Set/MutableSet protocols. So there's a clear precedent for this. > and the Set ABC doesn't have the set methods, like .union, .intersection ... (though I still don't get why that is ...) > > It's a little unfortunate that we can't put this in the Sequence ABC, but > it's not a big deal. The vast majority of the time I'm interfacing with my > own code and so I know that I'm working with a list, not some mysterious > Sequence. I don't think people are going to change their public facing > function signatures from `def foo(x: Sequence)` to `(x: list)` just so that > they can use `x.get`. Even if they do, it suggests that they think `.get` > is really useful, and callers can just convert their argument to a list > first. Similarly adding the union operator to dict is fine because people > usually use dicts, not generic Mappings. > This is something to be thinking about, however -- having the builtins extend the ABCs hasn't been a big deal, what with dynamic typing and all -- but as folks start using type hints, and static type checking more, it could be an issue. Honestly, I haven't delved into type checking much, so maybe I'm making this up, but what if you write a function that is type hinted to take a Mapping, and uses | or |=, and all the test code uses a built in dict, and all seems to be well. Then this code starts being more widely used, and someone runs it with a different Mapping object, and it passes the static type checking pass, and then, oops, a run-time failure. It makes me wonder of the utility of the ABCs is the builtins are extending them. Maybe we need a set of (at least for testing) builtins that are fully ABC conformant ? -CHB > > Besides, list already defines a bunch of stuff not found in Sequence or > MutableSequence: copy, sort, `<`, `+`, and `*`. What's one more? > > >> There's also the slippery-slope argument brought up earlier -- should it >> be added to tuple? To range? >> > > I think Steven D'Aprano asked this. I don't see it as an argument against > or a concern about a slippery slope, just a question. I think it'd be nice > to have it on lots of sequences, but it's OK if it's not. Neither scenario > strikes me as problematic. > > The union operator was also added to defaultdict, OrderedDict, and > ChainMap. Was this a problem? > > >> What should it do for a negative index? >> > > I think most people expect that if `lst[i]` returns a value then > `lst.get(i)` should return the same value, therefore it should return a > default only when `lst[i]` fails. Sometimes you specifically want > `lst.get(-1)` - there's a couple examples of that in [my earlier post]( > https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/) > and Daniel recently presented a case when he wanted that. > > This isn't the ideal behaviour for all use cases, but only as much as > normal indexing isn't the ideal behaviour for all use cases. Sometimes I've > had bugs because I forgot to account for negative indices, but I'm still > very grateful to you that negative indices work. We can't make something > equally convenient for all use cases, but that doesn't diminish the value > of this method. > > You said yourself that the generic alternative for all sequences is to > "check for IndexError", a sign that doing the equivalent of that is more > intuitive. > > >> I also think it negatively affects readability. Today when I see >> `foo.get(bar)` I assume that (unless the code is full of tricks) foo is a >> dict or Mapping >> > > That's already a poor assumption to make. `get` is an extremely generic > method name that has lots of meanings in different classes. > > >> But if list also grows a .get() method I have to assume in my head that >> foo is a list and then bar an int, and I basically have to read the rest of >> the code twice, once assuming foo is a Mapping, and once assuming it's a >> list. >> > > The purpose of `foo.get(bar)` is to get a value, not to tell you that foo > is a dict. If the rest of the code isn't able to tell you whether `foo` is > a dict or a list, then either the code is poorly written (and .get is not > to blame) or it doesn't matter because you're just getting individual > values. `foo[bar]` doesn't differentiate between lists and dicts and this > is generally considered a good thing, not a problem. > > >> The generalization I am talking about here is the assumption that because >> list and dict both support x[y], and dict also has x.get(y) which returns a >> default instead of raising, then it would be a good idea to add the latter >> also to list. >> > > I'm not assuming that list should have .get because dict has it. I'm > claiming list should have it because it would often be useful, based on > [empirical evidence]( > https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/ > ). > > Anyway, thank you for this. I'm enjoying the discussion and I'm glad to > hear actual reasons that can be argued about rather than the proposal just > fizzling away. > _______________________________________________ > 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/K2PMSIJQ27TS2JJUKPV3ASLJJ4HTVTBP/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/WRL2JABUYQUKLZ4DHD45K4CMZU64EDNE/ Code of Conduct: http://python.org/psf/codeofconduct/
