On 29 August 2016 at 11:44, Ken Kundert <python-id...@shalmirane.com> wrote:
> When working with a general purpose programming language, the above numbers
> become:
>
> 780kpc -> 7.8e+05
> 108MPa -> 1.08e+08
> 600TW -> 6e+14
> 3.2Gb -> 3.2e+09
> 53pm -> 5.3e-11
> $8G -> 8e+09
A better comparison here would be to engineering notation with
comments stating the units, since Python doesn't restrict the mantissa
to a single integer digit (unlike strict scientific notation):
780kpc -> 780e3 # parsecs
108MPa -> 108e6 # pascals
600TW -> 600e12 # watts
3.2Gb -> 3.2e9 # base pairs
53pm -> 53e-12 # meters
$8G -> 8e9 # dollars
The fundamental requirements for readable code are:
- code authors want their code to be readable
- the language makes readable code possible
So this starts to look like a style guide recommendation:
1. use engineering notation rather than scientific notation
2. annotate your literals with units if they're not implied by context
I find the pressure example a particularly interesting one, as I don't
know any meteorologists that work with Pascals directly - they work
with hectopascals or kilopascals instead. That would make the second
example more likely to be one of:
108e3 # kilopascals
1.08e6 # hectopascals
Similarly, depending on what you're doing (and this gets into the
"natural unit of work" concept David Mertz raised), your base unit of
mass may be micrograms, milligrams, grams, kilograms, or tonnes, and
engineering notation lets you freely shift those scaling factors
between your literals and your (implied or explicit) units, while
native SI scaling would be very confusing if you're working with
anything other than the base SI unit.
Accordingly, I'm starting to wonder if a better way for us to go here
might be to finally introduce the
occasionally-discussed-but-never-written Informational PEP that spells
out "reserved syntax for Python supersets", where we carve out certain
things we plan *NOT* to do with the base language, so folks writing
Python supersets (e.g. for electronics design, data analysis or code
generation) can use that syntax without needing to worry about future
versions of Python potentially treading on their toes.
Specifically, in addition to this SI scaling idea, I'm thinking we
could document:
- the Cython extensions for C code generation in .pyx files (cdef,
ctypedef, cimport, nogil, NULL)
- the IPython extensions for cell magics and shell invocation (unary
'%', unary '!'), and maybe their help syntax (postfix '?')
The reason I think this may be worth doing is that some of these ideas
are ones that only make sense *given a suitably constrained domain*.
Python supersets like Cython and IPython get to constrain their target
domain in a way that makes these extensions appropriate there in a way
that wouldn't be appropriate at the level of the base language, but we
can still be explicit at the base language level that we're not doing
certain things because we're delegating them to a tool with a more
focused target audience.
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/
