[Python-ideas] real numbers with SI scale factors

Nick Coghlan ncoghlan at gmail.com
Mon Aug 29 00:35:15 EDT 2016


On 29 August 2016 at 13:40, Brendan Barnwell <brenbarn at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list