[Python-ideas] Float range class

Andrew Barnert abarnert at yahoo.com
Thu Jan 8 18:41:00 CET 2015


On Jan 8, 2015, at 8:01, Todd <toddrjen at gmail.com> wrote:
> The current approaches for float ranges all have significant limitations.  numpy.arange pre-allocates the values and doesn't use python floats, both of which affect performance. 
> 
How does using numpy floats instead of python floats affect performance, unless "it's too fast" or "it uses too little memory" are problems?
> The third approach is to create a new module for various range classes.  For example there could be a float range, a datetime range, a decimal range, a duck-typed range, an abstract base class for making new range classes, etc.  However, this is a lot more work (although it wouldn't need to all be done at one time).
> 
I think what you'd really want is a full suite of interval/count/range APIs over various types. For example, a datetime range that doesn't even allow offsetting or comparing for overlap doesn't seem all that useful. I can think of lots of uses for all kinds of range-like things, but none of them are well satisfied by just a range view that acts like a sequence and has no other methods, short of iterating them (for which a generator expression is sufficient--or, if you're doing a lot of them in some app for some reason, a one-liner function that wraps up the genexpr).

More generally: if an frange that works exactly like range but with floats (and rounding errors) is all you want, that's so trivial to write that it doesn't seem worth putting in the stdlib, unless the use case is very common. If you want more than that, then whether it belongs in the stdlib probably depends on exactly what you want (and whether you or someone else has a good design and implementation, of course).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150108/20896974/attachment.html>


More information about the Python-ideas mailing list