[Python-ideas] real numbers with SI scale factors

[Paul Moore]

On 30 August 2016 at 04:19, Ken Kundert <python-ideas at shalmirane.com> wrote:
> Do you think there is no value to be able to naturally read and write numbers
> with SI scale factors from Python? Or is your issue with something about my
> proposal?

Ken,
Answering these questions from my perspective (and thanks for taking
note of the comments and toning down your delivery, by the way)

I have an issue with the way your proposal is vague about the
relationship between SI scales and units - it's been mentioned a
couple of times, but never adequately addressed, that scales are
tightly linked to units (we routinely talk about kilometers and
milligrams, but almost never about kilos or millis). There have been
some strong (and justified, IMO) objections to adding units without
giving them proper semantic meaning, and your response to that seems
to be to talk for a while about scale factors in isolation, but then
go straight back to examples using scaled units. It's hard to
understand exactly what you're proposing when your examples don't
match your suggestions.

If we assume you *are* simply talking about pure scales (k=1000,
M=1000000 etc), then you haven't addressed the many suggestions of
alternatives, with anything more substantive than "well, I (and
colleagues I know) prefer scale factors", plus some examples with
scaled *units* again. Your comparisons tend to show your preferred
approach in the best light, while using the least attractive
alternative options. And there's almost no proper discussions of pros
and cons. In short, you offer almost nothing in the way of objective
arguments for your proposals.

You mention "reading and writing numbers with scale factors from
Python". It's easy enough to do external IO with scale factors, you
just read strings and parse them as you wish. A language syntax only
affects internal constants - and it's not clear to me that the benefit
is significant even then, as I'd expect (as a matter of good style)
that any constant needing this type of syntax should be named anyway.
Again, this isn't something you address.

You've offered no examples of real-world code in existing public
projects that would be improved by your proposal. While that's not
always necessary to a successful proposal, it certainly makes it more
compelling, and helps to confirm that a proposal isn't limited to
"niche" areas.

So to summarise, I don't think you've made objective arguments for
your proposal (your *subjective* enthusiasm for the proposal has never
been in doubt), or addressed many of the comments that have already
been made.

To be honest, I don't think there's much chance of your proposal being
accepted at this point in time. As Steven noted, Python tends not to
be a leader in matters like this, and so the lack of mainstream prior
art is probably sufficient to kill this proposal. But for your own
benefit (and the benefit of any future proposals you may make in this
or other areas - please don't feel put off by the fact that this
specific proposal has met with a lot of resistance) you might want to
review the thread and consider what a PEP might look like for this
discussion, and how you would have incorporated and responded to the
objections raised here -
https://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep
is a good summary of the sort of things you should be looking at.
There's no need to actually complete a PEP or post it, the proposal
here hasn't reached a stage where a PEP is useful, but thinking about
the PEP structure might help you understand the context a bit better.

I hope this helps,
Paul