Martin v. Löwis wrote: > Ah, I had missed the point that it's just binary formatting that > you are concerned with (and then I missed that binary is "base 2", > rather than "sequence of bits")
Apologies for not being clear. It's easy to forget that others don't share the context of something you've been immersed in. >> Having written all of this, I'm now thinking that Nick's suggestion of >> _PyLong_AsByteArray might be the way to go. I would use that for all of >> my formatting for longs. > > How would you do negative numbers, then? AsByteArray gives you two's > complement. _PyLong_Sign >> But I'd like PEP 3101 to be as efficient as possible, >> because once it's available I'll replace all of the '%' string >> formatting in my code with it. > > That is fine. However, don't trade efficiency for maintainability. > Keep encapsulation of types, this is what OO is for. Modularize > along with type boundaries. If that loses efficiency, come up with > interfaces that still modularize in that way but are efficient. > Don't "hack" to achieve performance. (Any other way I can formulate > the same objective :-?) Point taken. I currently have it using PyLong internals, just to get our tests to pass and so Pat can work on his part. As we still want to be a standalone module for a while, I'm going to modify the code to use AsByteArray and Sign to do the binary formatting only. When/if we integrate this into 3.0 (and 2.6, I hope), I'll look at adding __format__ to long, and possibly the other built in types. To do so we'll need to factor some code out to a library, because it doesn't make sense for all the built-in types to understand how to parse and operate on the format specifiers (the [[fill]align][sign][width][.precision][type] stuff). Thanks for your comments! Eric. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
