[Chicago] hark! datasize.data_size class for understanding data_size('2TiB') > data_size('2TB')
Jeremy McMillan
jeremy.mcmillan at gmail.com
Mon Mar 16 23:08:22 CET 2015
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20150316/90c0f10b/attachment.html>
More information about the Chicago
mailing list