[Python-ideas] Float range class

Guido van Rossum guido at python.org
Sat Jan 10 20:50:09 CET 2015


I suppose the briefest of recipes could go in the range() docs, in a
section "what do do for floats". More extended recipes should probably go
on the activestate recipes site.

On Sat, Jan 10, 2015 at 11:30 AM, Andrew Barnert <
abarnert at yahoo.com.dmarc.invalid> wrote:

> On Saturday, January 10, 2015 9:59 AM, Guido van Rossum <guido at python.org>
> wrote:
>
> >On Fri, Jan 9, 2015 at 11:03 PM, Andrew Barnert
> <abarnert at yahoo.com.dmarc.invalid> wrote:
> >
> >>On Fri, Jan 9, 2015 at 7:29 PM, Andrew Barnert
> <abarnert at yahoo.com.dmarc.invalid> wrote:
> >>That gives a closed range of num+1 values. I think you want a closed
> range of num values (or maybe a half-open range of the first num of num+1
> values). So you want to replace every num with num-1.
> >
> >Not really. I think of this as splitting the range into `num` equal
> subranges and returning all the points including the endpoints. I think it
> would look really weird if you wanted to split [0, 1] into 10 equal
> sections (or 0.1 each) and you had to say 11.
>
>
> Maybe I'm just expecting it to work the same way as NumPy, and have lost
> whatever original intuition I might have had on this, and I suspect the
> NumPy designers likewise just copied from MATLAB rather than rethinking it
> from first principles, so I'll accept that your way seems more intuitive.
> But that just means we have to choose between more intuitive vs. more
> NumPy-like, which seems like yet another opportunity for a bikeshedding
> argument (and without the NumPy-equivalent API, it reopens the question of
> whether to use the same name as NumPy, too), so I think you're right in the
> end; there are too many questions without obvious answers, so maybe it's
> better off as a recipe.
>
> >>If you don't need O(1) __contains__ and friends (and I don't think you
> do) that's maybe 5 lines of code with the ABC.
> >
> >If it's in the stdlib it should be modeled after range(), which is
> significantly more sophisticated.
> >
> >OTOH if it's just a one-liner recipe in the docs returning a list is fine.
> >
> >OT3H __contains__ seems a really bad idea, due to general issues with
> float equality.
>
>
> Exactly, and the same for index and count. If you don't have those, you're
> not a Sequence. If you have those but they just rely on the linear fallback
> from the ABC it may not look quite as bad (e.g., they don't show up in the
> "defined here" part of help), but I'm not sure how good an argument that is
> for doing it that way when we could do it in O(1) time, and range does so.
> Of course it could also just be a sequence-like view, not an actual
> Sequence view, which has its own pros and cons. More bikeshedding...
>
> >>In fact, rather than just say how easy it is, give me 10 minutes to code
> it...
> >>
> >>https://github.com/abarnert/linspace
> >
> >I just see more opportunity for bikeshedding. :-(
>
>
> >Honestly, I think this is better off as a set of recipies (starting with
> the most naive of all and then discussing various refinements for better
> accuracy or speed or support of e.g. datetime), with a hefty section on
> the off-by-one issue, rather than a stdlib function.
>
>
> Yeah, you've convinced me.
>
>
>
> Forgive me for further bikeshedding questions, but… should these recipes
> go in the library docs? (If so, where?) In a HOWTO? Outside the official
> docs (ActiveState, the wiki, …?) with a reference to them somewhere?
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150110/9c5643ac/attachment.html>


More information about the Python-ideas mailing list