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