On 26 August 2016 at 08:34, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 26 August 2016 at 13:46, Ken Kundert <python-id...@shalmirane.com>
> wrote:
> > On Fri, Aug 26, 2016 at 10:14:53AM +1000, Steven D'Aprano wrote:
> >> On Thu, Aug 25, 2016 at 11:02:11AM -0700, Ken Kundert wrote:
> >>
> >> > Even if the language completely ignores the units, we have still
> gained by
> >> > allowing the units to be there, just like we gain when we allow user
> to add
> >> > comments to their code even though the compiler ignores them.
> >>
> >> This part of your proposal would be *worse*: you would fool the casual
> or
> >> naive user into believing that Python did dimensional analysis, while
> in fact
> >> not doing so. You would give them a false sense of security.
> >
> > This idea is new to general purpose languages, but it has been used for
> over 40
> > years in the circuit design community. Specifically, SPICE, an extremely
> heavily
> > used circuit simulation package, introduced this concept in 1974. In
> SPICE the
> > scale factor is honored but any thing after the scale factor is
> ignored. Being
> > both a heavy user and developer of SPICE, I can tell you that in all
> that time
> > this issue has never come up. In fact, the users never expected there to
> be any
> > support for dimensional analysis, nor did they request it.
>
> [snip]
>
> > And it has little to do with my proposal, which is basically this:
> >
> > Numbers with SI scale factor and units have become very popular. Using
> them is
> > a very common way of expressing either large or small numbers. And that
> is true
> > in the scientific and engineering communities, in the programming
> community
> > (even the linux sort command supports sorting on numbers with SI scale
> factors:
> > --human-numeric-sort), and even in popular culture.
> >
> > Python should support them. And I mean support with a capital S. I can
> come up
> > with many different hacks to support these ideas in Python today, and I
> have.
> > But this should not be a hack. This should be built into the language
> front and
> > center. It should be the preferred way that we specify and output real
> numbers.
>
> Thanks for the additional background Ken - that does start to build a
> much more compelling case.
>
> I now think there's another analogy you'll be able to draw on to make
> it even more compelling at a language design level: just because the
> *runtime* doesn't do dimensional analysis on static unit annotations
> doesn't mean that sufficiently clever static analysers couldn't do so
> at some point in the future. That then puts this proposal squarely in
> the same category as function annotations and gradual typing: semantic
> annotations that more clearly expressed developer intent, and aren't
> checked at runtime, but can be checked by a human during code review,
> and (optionally) by static analysers as a quality gate.
>
Unfortunately, I didn't read the whole thread, but it seems to me that
this would be just a more sophisticated version of NewType.
mypy type checker already supports NewType (not sure about pytype).
So that one can write (assuming PEP 526):
USD = NewType('USD', float)
EUR = NewType('EUR', float)
amount = EUR(100)
# later in code
new_amount: USD = amount # flagged as error by type checker
The same idea applies to physical units.
Of course type checkers do not know that e.g. 1m / 1s is 1 m/s, but
it is something they could be taught (for example by adding @overload
for division operator).
--
Ivan
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
