On 3/19/07, Patrick Maupin <[EMAIL PROTECTED]> wrote: > It was pointed out to me that, since I suggested > upper/lowercase was an issue for another PEP, > removal of uppercase octal/binary belonged in that same PEP
Removal of uppercase from other formats would affect backwards compatibility. For binary and octal, it is simply a matter of not adding additional alternative ways to do it. Consistency with hex and floats is worth something, but I don't think it is important enough to justify adding new support for the confusing O0. (Remember, the choice was 0t when uppercase support was still expected.) Also note that the case distinction can matter in output, because other systems might already assume a certain case for hex or floating point; I haven't heard of any external systems that already recognize O0 but not O0, or 0B but not 0b. If we don't support it on output, then the symmetry is already broken, and there is no reason to support it on input. > ... int(token) and int(token, 2-36) > are not modified by this proposal. int(token, 16) accepts (but does not require) a leading 0x. I assume that the code for 2 and 8 will also begin to allow a leading prefix. -jJ _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
