Alas, it is not fully packaged yet, because I know so little about how to do this packaging thing, or how to know if I've done it right. The code is here: https://github.com/rhinstaller/bytesize. The generated docs are here: http://python-bytesize.readthedocs.org/en/latest/. There is clearly a problem w/ the package documentation somehow going missing. It doesn't go missing in my private copy. The changes are as previously outlined below. This is a call for comments. I'ld like to move fast on the part where I adapt blivet, blivet-gui, anaconda to use the new library. - mulhern ----- Original Message ----- > From: "David Lehman" <dlehman@xxxxxxxxxx> > To: anaconda-devel-list@xxxxxxxxxx > Sent: Thursday, January 15, 2015 10:51:33 AM > Subject: Re: We should make blivet.size.py a separate package > > On 01/13/2015 11:54 AM, Anne Mulhern wrote: > > Hi all, > > > > It turns out that anaconda uses Size() objects for a number of things that > > are only tangentially related to storage. There's a bunch of stuff in > > packaging, for instance, which does not seem that nearly related to storage > > but which does use Size(). It seems cruel to make anaconda restrict its > > usage of this handy Size class to only storage related stuff, but > > inconsistent, > > if it is a storage package, not to. > > I don't see this as being cruel or limiting given that anaconda is > already using blivet, but I also don't have any objections if you want > to take on the additional work of maintaining another package for it. I > agree with all of the proposed changes below, noting that none of them > depend upon size being a separate package. > > David > > > > > Clearly, a separate package is the solution and might prove to be generally > > useful. > > > > Other changes that should be made at the same time are: > > > > 1) Disentangle parsing user input from Size() construction. This would > > change the > > interface, so that: > > > > * Size("10 MiB") would have to be changed to Size(10, size.MiB) > > * Size("%d KiB" % int(val[i])) would have to be changed to > > Size(int(val[i]), size.KiB) > > > > Note: All other things being equal, the above changes would result in a > > speed up of about 4x, > > when the argument is changed from a string to a tuple. > > > > * Size(user_input) would have to be changed to Size(parseSpec(user_input)) > > > > 2) Use int instead of Decimal for underlying representation and use > > delegation, not extension. > > int is unbounded, and appropriate > > as Size() stores exact number of bytes. The implementation will still use > > Decimal within > > humanReadable() and convertTo(), where Decimal proves its worth. This would > > make (1) a bit > > easier, for it would be possible to override object.__init__() instead of > > overriding Decimal.__new__() > > which is awkward because of the context parameter which Decimal.__new__ > > requires. > > > > Benefits to the change would be a 5 to 10x reduction in size of Size() > > objects and a 10 to 15x > > speedup in constructing Size() objects and in arithmetic operations. The > > only arithmetic operation > > I profiled was addition; I'm generalizing here. > > > > There would be no change to the interface, and the changes in the class are > > actually very simple. > > > > 3) Make arithmetic operations more type-sensible. > > > > Currently, our code does a bunch of not so good things, like: > > > >>>> divmod(Size("3 MiB"), Size("2 MiB")) > > (Decimal('1'), Decimal('1048576')) > > > > The semantics of divmod should agree with the, in this situation, correct > > semantics of mod, > > which gives the type of the remainder as a Size. > > > >>>> Size("3 MiB") % Size("2 MiB") > > Size('1 MiB') > > > > 2 multiplied by itself 3 bytes times should raise an exception or > > something, but it doesn't: > >>>> 2 ** Size("3 B") > > Decimal('8') > > > > The number of times 2 MiB can be subtracted from 3 MiB is not 1 bytes > > times, it's 1 times, but: > >>>> Size("3 MiB") / Size("2 MiB") > > Size('1 B') > > > > and so forth. > > > > In theory, our code should not be asking for really nonsensical operations > > like 2 ** Size("1 MiB"), > > and I think it is not. > > > > It can be made configurable how extreme the reaction is to a requested > > operation that makes no sense. > > > > There are certain operations that are mathematically sensible, but which > > the implementation > > would not, because it could not, support. One such operation is 2 MiB * 2 > > KiB which yields > > 4096 KiB^^2. We have no ability to represent that, so it would be better to > > raise a TypeError when > > called upon to calculate it rather than return, as now, Size('4 GiB'). > > I believe that computations in this category are not ones that we > > actually do in Blivet or Anaconda or should expect to. The context in which > > they could arise is > > in, e.g., statistics, where in order to calculate the standard deviation, > > one has to square > > the values. But if we start doing statistics on some MiB's we should not be > > using Size > > class at all, we can use pint, which is good for that, but bad for our > > regular purposes. > > > > NOTE: Most of the _implementation_ is already done, leaving just packaging > > and a few places > > in anaconda where it will require a little thought to decide if parseSpec > > is called for. > > > > Please give me your opinions. Maybe we can discuss this in installer > > meeting. > > > > - mulhern > > > > > > > > > > > > > > > > > > _______________________________________________ > > Anaconda-devel-list mailing list > > Anaconda-devel-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > > > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
