On 29 August 2016 at 13:40, 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.
Octal literals were on the Python 3 chopping block, with only two things saving them: - *nix file permissions (i.e. the existing sysadmin user base) - the proposal to switch to "0o" as the prefix The addition of "0b" was to make bitwise operators easier to work with, rather than requiring folks to mentally convert between binary and hexadecimal just to figure out how to set a particular bit flag, with the requirement to understand binary math being seen as an essential requirement for working with computers at the software development level (since it impacts so many things, directly and indirectly). Hexadecimal then sticks around as a way of more concisely writing binary literals However, the readability-as-a-general-purpose-language argument in the case of SI scaling factors goes as follows: - exponential notation (both the scientific and engineering variants) falls into the same "required to understand computers" category as binary and hexadecimal notation - for folks that have memorised the SI scaling factors, the engineering notation equivalents should be just as readable - for folks that have not memorised the SI scaling factors, the engineering notation equivalents are *more* readable - therefore, at the language level, this is a style guide recommendation to use engineering notation for quantitative literals over scientific notation (since engineering notation is easier to mentally convert to SI prefixes) However, once we're talking domain specific languages (like circuit design), rather than a general purpose programming language, then knowledge of the SI prefixes can be included in the assumed set of user knowledge, and made a language level feature. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
