This thread seems light on real use cases. I know there are people eager to have integer generics, since they are essential for typing numpy, pandas, tensorflow and friends. And so there are good proposals floating around for this on typing-sig; I expect implementations within a year.
But integer ranges? I guess they would be useful to catch array indexing mistakes, but I don’t believe IndexError is the bane of anyone’s existence. And float ranges? I wouldn’t want to touch those with a 10-foot pole. What am I missing? On Sat, Aug 8, 2020 at 15:28 Ricky Teachey <ri...@teachey.org> wrote: > On Sat, Aug 8, 2020 at 5:51 PM Michael Smith <mich...@smith-li.com> > wrote: > >> This kind of thing is so powerful, and I would love to see tooling >> capable of it in the python ecosystem. I believe folks who say it's very >> hard to implement correctly, but I don't know that that's a good reason not >> to make the proposed range syntax legal for some primitive types like int. >> Tools like mypy can choose not to handle int[A:B] until they are ready, or >> forever, but someone else can still work on it. >> > > I agree. > > A total, complete solution that successfully catches everything might well > be out of reach. But that doesn't seem like a reason to not catch what can > be caught. > > On Sat, Aug 8, 2020 at 5:51 PM Michael Smith <mich...@smith-li.com> > wrote: > >> Are we just talking about the language features here, or does this list >> include ideas for tooling like mypy? >> > > Others will surely know better than me but it seems like that in order to > add the ability to use the [ ] operator on the int (and perhaps float) > type, and to be able to "get at" the arguments that were provided to them, > the language would first have to change to support that,. > > But on the other hand there is no stopping someone from writing a library > that writes its own Int and Float type hints that supports all of this, and > putting it out in the universe to see what traction it gets. > > I know for a fact I am not skilled enough to do this, unfortunately, so > I'd have to leave it to someone else. > > On Sat, Aug 8, 2020 at 4:42 PM Dominik Vilsmeier <dominik.vilsme...@gmx.de> > wrote: > >> By the way, I would find it more intuitive if the `stop` boundary was >> included in the interval, i.e. `int[0:10]` means all the integer numbers >> from 0 to 10 (including 10). I don't think that conflicts with the current >> notion of slices since they always indicate a position in the sequence, not >> the values directly (then `int[0:10]` would mean "the first 10 integer >> numbers", but where do they even start?). >> > It's always interesting how people's intuitions can differ. Making the > stop value inclusive by default is a little jarring to me since it is so > inconsistent with sequence indexing elsewhere. But I do see your point that > in reality this is NOT slicing positions in a sequence (since it has no > beginning and end). I don't think it would be a terrible thing for both > start and stop to be inclusive by default. > > But regardless of whether the stop value is inclusive or not, there are > certainly going to be instances when someone will want inclusivity and > others when they want exclusivity, and this applies to both the start and > the stop value. > > In other words, any syntax that did not provide the ability to state all > of these number lines would seem pretty wanting: > > 0 < x < ∞ # all positive integers > -∞ < x < 0 # all negative integers > 0.0 < x < ∞ # all positive floats > -∞ < x < 0.0 # all negative floats > > 0 <= x < ∞ # all positive integers, zero included > -∞ < x <= 0 # all negative integers, zero included > 0.0 <= x < ∞ # all positive floats, zero included > -∞ < x <= 0.0 # all negative floats, zero included > 0 <= x <= 10 # some inclusive int interval > 0 < x < 10 # some exclusive int interval > 0 < x <= 10 # some int interval, combined boundaries > 0 <= x < 10 # some int interval, combined boundaries > 0.0 <= x <= 10.0 # some inclusive float interval > 0.0 < x < 10.0 # some exclusive float interval > 0.0 < x <= 10.0 # some float interval, combined boundaries > 0.0 <= x < 10.0 # some float interval, combined boundaries > > And versions of all of these with step arguments. > > A way around the inclusive vs exclusive problem might be to define some > sort of indicator, or function, to modify the boundaries. > > Here's several ideas of how to spell the number line 0 < x <=10: > > >>> x: int[excv(0):incv(10)] # where incv and excv stand for "inclusive" > and "exclusive" > >>> x: int[@0:10] # where the @ is read "almost" or "about" or "around" > -- the idea is all boundaries are inclusive by default and the @ makes a > boundary exclusive > >>> x: int[(0,"incv"):(10,"excv")] # here we just pass tuples to the > start and stop slice arguments, and the text indicates whether each > boundary is inclusive (incv) or exclusive (excv) > > I think the third is my favorite - it reads pretty nicely. Although it > would be nicer if it didn't need the parentheses. The second one is > interesting though. > > But of course regardless of which of these spellings (or some other) is > preferred, the default behavior would still need to be defined. > > > --- > Ricky. > > "I've never met a Kentucky man who wasn't either thinking about going home > or actually going home." - Happy Chandler > > _______________________________________________ > 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/WAIJ2OEFMVATEZFAQWAEHDJLIP7PHX56/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --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/COTOFYD7DIPXFMUZU5GXHBZBOIWJQ5G4/ Code of Conduct: http://python.org/psf/codeofconduct/
