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

Wed Mar 18 02:36:08 CET 2015

I only 1/2 understand your problem, and I only half understand what this
does,.
and I half think I saw this at a PyOhio lightning talk that I can't find
now.

https://readthedocs.org/projects/python-measurement/

Maybe some of this is useful.

On Tue, Mar 17, 2015 at 8:35 AM, Jeremy McMillan <jeremy.mcmillan at gmail.com>
wrote:

> Not really. I'm concerned about accumulated rounding errors. It's
> something I haven't completely thought through yet.
>
> Also I remember vaguely that I had trouble using string format with
> decimals, but that may have been a long time ago. It seems more correct
> than floats, but I'll need to think hard about a test case.
>
> On Mon, Mar 16, 2015 at 8:51 PM, Brian Ray <brianhray at gmail.com> wrote:
>
>> 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
>>
>> _______________________________________________
>> 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
>
>

-- 
Carl K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20150317/cc8e08ed/attachment.html>