[Python-Dev] Access to bits for a PyLongObject

["Martin v. Löwis"]

Eric V. Smith schrieb:
> Also, it would either mean duplicating lots of code from the int
> formatter, or having a formatter library that both can call.  This is
> because __format__ must implement all formats, including padding,
> parenthesis for negatives, etc., not just the "missing" binary format.
> Not that that's necessarily bad, either. But see the next point.

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")

>> OTOH, also look at _PyString_FormatLong.
> 
> I think a solution would be to add 'b' to _PyString_FormatLong, which 
> I'm already calling for hex, octal, and decimal formatting.  Does that 
> sound reasonable?  It seems to me that if binary is useful enough for 
> PEP 3101, it should generally be available in _PyString_FormatLong.

That sounds fine.

> The obvious implementation of this would require adding a nb_binary to
> PyNumberMethods.  I'm not sure what the impact of that change would be,
> but it sounds really big and probably a show-stopper.  Maybe a direct 
> call to a binary formatter would be better.

Sure, introducing _PyLong_Dual (or _PyLong_AsDualString) would be 
appropriate, that can then forward to long_format.

> OTOH, this approach isn't as efficient as I'd like (for all formatting
> outputs, not just binary), because it has to build a string object and
> then copy data out of it.

Ah, but that's a proof-of-concept implementation only, right? A "true"
implementation should use __format__ (or whatever it's called). If
*that* then isn't efficient, you should be worried (and consider
introduction of a slot in the type object).

> 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.

> Maybe I'm over-emphasizing performance, given the early status of the
> implementation. 

Most definitely.

> 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 :-?)

Regards,
Martin