[Chicago] hark! datasize.data_size class for understanding data_size('2TiB') > data_size('2TB')

[Brian Ray]

Are you talking about the complexity
<http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html> of floating
point <https://docs.python.org/2/tutorial/floatingpoint.html> numbers?

I am guessing for consistency you might want is:

    int(round(some_float))

and

    float(some_int)

However, I am not entirely sure this solves all problems. You may want to
do decimal <https://docs.python.org/2/library/decimal.html>math instead of
floating point.





On Mon, Mar 16, 2015 at 5:08 PM, Jeremy McMillan <jeremy.mcmillan at gmail.com>
wrote:

> That's pretty much it, except subclassing immutable base types requires
> splitting the constructor work between __init__() and __new__().
>
> Yeah, unit tests are good. I should add some coverage. Aside from
> asserting some deterministic values, I'm uneasy about converting back and
> forth between int and float values. What's the best way to cover that?
> On Mar 16, 2015 4:49 PM, "Brian Ray" <brianhray at gmail.com> wrote:
>
>> Very cool, so you subclass int and overwrite __format__ if i read
>> correctly? I would recommend writing some unit tests.
>>
>>
>>
>> On Sunday, March 15, 2015, Jeremy McMillan <jeremy.mcmillan at gmail.com>
>> wrote:
>>
>>> I am doing some SaltStack states at work, and I decided I will not write
>>> any more data size string parsing or formatting human readable memory or
>>> storage footprint demand/capacity. I'm tired of reinventing the wheel.
>>>
>>> I'm done.
>>>
>>> Well, I'm done with the first draft anyway.
>>>
>>> https://github.com/aphor/data_size
>>>
>>> There's a better than fair chance I will get to open source the
>>> SaltStack formula work too, which means I need to be kind about the
>>> dependency on this little data_size utility class, and that means
>>> publishing it on PyPI. Before it gets there, I sadly don't work in a Python
>>> shop, so I need to ask for help from you, the Python community, to review
>>> the code. For your effort, maybe you will be able to scratch your own itch
>>> with this wee snippet.
>>>
>>> If you've ever needed to compare two data allocations, or report on even
>>> one, I hope you will try it. Criticism, issues on GitHub, kudos, and
>>> especially pull requests are appreciated with gratitude.
>>>
>>> From the README.md:
>>>
>>> There is support for metric and IEC units in both bits and bytes and
>>> nonstandard abbreviated IEC units (for legacy Java -Xmx). There is support
>>> for variable word-lengths, but because I thought it would get confusing,
>>> converting between two different word lengths is not supported. The word
>>> length constructor keyword argument will allow converting counts of weird
>>> (actually non-byte) word or symbol bit lengths to bit rates, which can then
>>> be explicitly converted to standard 8-bit bytes.
>>>
>>> The really sweet feature that everyone (now everybody's me!) should love
>>> is the Python 3 string.format() support!
>>>
>>> Help on method __format__ in module datasize.data_size:
>>>
>>> __format__(self, code) unbound datasize.__data_size__.data_size method
>>>     formats as a decimal number, but recognizes data units as type format codes.
>>>     Precision is ignored for integer multiples of the unit specified in the format code.
>>>     format codes:
>>>     a    autoformat will choose a unit defaulting to the largest
>>>           size with a quantity >= 1 (default)
>>>     A    abbreviated number of bytes (implied IEC units, and implied 'B' bytes suffix omitted)
>>>     B    bytes      (1)
>>>     kiB  kibibytes  (1024)
>>>     kB   kilobytes  (1000)
>>>     ...
>>>     GiB  Gibibytes  (1024**3)
>>>     GB   Gigabytes  (10**9)
>>>     ...
>>>     YiB  Yobibytes  (1024**8)
>>>     YB   Yottabytes (10**24)
>>>
>>> >>> from datasize import data_size
>>> >>> 'My new {0:GB} SSD really only stores {1:.2GiB} of data.'.format(data_size('750GB'),data_size(data_size('750GB') * 0.8))
>>> 'My new 750GB SSD really only stores 558.79GiB of data.'
>>> >>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Brian Ray
>> @brianray
>> (773) 669-7717
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago
>
>


-- 
Brian Ray
@brianray
(773) 669-7717
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20150316/c281a2c1/attachment.html>