[Python-ideas] Float range class

[Andrew Barnert]

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?