On Mon, Aug 29, 2016 at 1:40 PM, Brendan Barnwell <brenb...@brenbarn.net> wrote:
> On 2016-08-28 20:29, Ken Kundert wrote:
>>
>> What is wrong with have two ways of doing things? We have many ways of
>> specifying the value of the integer 16: 0b10000, 0o20, 16, 0x10, 16L, ....
>
>
> Zen of Python: "There should be one-- and preferably only one
> --obvious way to do it."
>
> If Python didn't have binary or octal notation and someone came here
> proposing it, I would not support it, for the same reasons I don't support
> your proposal. If someone proposed eliminating binary or octal notation for
> Python 4 (or even maybe Python 3.8), I would probably support it for the
> same reason. Those notations are not useful enough to justify their
> existence. Hexadecimal is more justifiable as it is far more widely used,
> but I would be more open to removing hexadecimal than I would be to adding
> octal.
>
I agree with you on octal - there are very few places where it's the
one obvious way to do things, and you can always use int("755",8) if
you have data that's represented best octally. But hex is incredibly
helpful when you do any sort of bit manipulations, and decimal quickly
becomes unwieldy and error-prone. Here's some code from Lib/stat.py:
S_IFDIR = 0o040000 # directory
S_IFCHR = 0o020000 # character device
S_IFBLK = 0o060000 # block device
S_IFREG = 0o100000 # regular file
S_IFIFO = 0o010000 # fifo (named pipe)
S_IFLNK = 0o120000 # symbolic link
S_IFSOCK = 0o140000 # socket file
These are shown in octal, because Unix file modes are often written in
octal. If Python didn't support octal, the obvious alternative would
be hex:
S_IFDIR = 0x4000 # directory
S_IFCHR = 0x2000 # character device
S_IFBLK = 0x6000 # block device
S_IFREG = 0x8000 # regular file
S_IFIFO = 0x1000 # fifo (named pipe)
S_IFLNK = 0xA000 # symbolic link
S_IFSOCK = 0xC000 # socket file
About comparable for these; not as good for the actual permission
bits, since there are three blocks of three bits. Python could manage
without octal literals, as long as hex literals are available. (I
don't support their *removal*, because that's completely unnecessary
backward incompatibility; but if Python today didn't have octal
support, I wouldn't support its addition.) But the decimal
equivalents? No thank you.
S_IFDIR = 16384 # directory
S_IFCHR = 8192 # character device
S_IFBLK = 24756 # block device
S_IFREG = 32768 # regular file
S_IFIFO = 4096 # fifo (named pipe)
S_IFLNK = 40960 # symbolic link
S_IFSOCK = 49152 # socket file
One of these is wrong. Which one? You know for certain that each of
these values has at most two bits set. Can you read these? If you're
familiar with the powers of two, you should have no trouble eyeballing
the single-bit examples, but what about the others?
We need hex constants for anything that involves bitwise
manipulations. Having binary constants is nice, but (like with octal)
not strictly necessary; but we need at least one out of bin/oct/hex.
(Also, 16L doesn't actually mean the integer 16 - it means the *long*
integer 16, which is as different from 16 as 16.0 is.)
ChrisA
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
