[Python-Dev] Drop support for ones' complement machines?

["Martin v. Löwis"]

>>>> I'd rather prefer to explicitly list what CPython assumes about the
>>>> outcome of specific operations. If this is just about &, |, ^, and ~,
>>>> then its fine with me.
>>> I'm not even interested in going this far:
>> I still am: with your list of assumptions, it is unclear (to me, at
>> least) what the consequences are. So I'd rather see an explicit list
>> of consequences, instead of buying a pig in a poke.
> 
> Okay;  though I think that my list of assumptions is easier to check
> directly for any given implementation:  it corresponds
> exactly to items 2 and 4 in C99 J.3.5, and any conforming
> C implementation is required to explicitly document how it
> behaves with regard to these items.

I'm in favor stating the assumptions the way you do (*), I just
want to have an additional explicit statement what consequences
you assume out of these assumptions.

> I'm not sure how to decide which particular consequences
> should be listed, but those for &, |, ^ and ~ could certainly
> be included.

It should give the CPython contributors an indication what kind
of code would be ok, and which would not. Perhaps it should include
both a black list and a white list: some may assume that two's
complement already provides guarantees on left-shift, when it
actually does not (**).

Regards,
Martin

(*) I wonder why you are not talking about padding bits
(6.2.6.2p1)
(**) I also wonder why C fails to make left-shift
implementation-defined, perhaps with an even stronger binding
to the options for the integer representation.