I’m sorry, I just can’t teach you how static type checking works. Read the mypy docs, install it, and experiment.
On Wed, Aug 26, 2020 at 13:10 Christopher Barker <python...@gmail.com> wrote: > 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 > > > -- --Guido (mobile)
_______________________________________________ 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/HP3P3HSVQX4MONYLTDJ5A3H3IPPXONUG/ Code of Conduct: http://python.org/psf/codeofconduct/
