On 26 August 2016 at 18:35, Steven D'Aprano <st...@pearwood.info> wrote:
> I think that units are orthogonal to types: I can have a float of unit
> "gram" and a Fraction of unit "gram", and they shouldn't necessarily be
> treated as the same type.
I think you are mixing here what I sometimes call classes (i.e. runtime
implementation)
and types (i.e., static "interface" declaration). In this terms I think
units are types.
But probably it is a more philosophical question and could be a matter of
taste.
On 27 August 2016 at 15:04, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> def power(potential, current):
> return WattType(float(Volt)*float(Ampere))
One don't need to call float on NewTypes derived from it, they will be cast
"automatically", so that:
def power(I, V):
return WattType(I*V)
should be sufficient. Concerning the speed vs. flexibility issue, one could
use stub files:
# content of units.py
def WattType(x): return x
#etc.
# contents of units.pyi
class WattType:
def __init__(self, x: float) -> None:
...
def __mul__(self, other: float) -> WattType:
# over 9000 of complicated overloads and stuff
In such way units will be very fast at runtime but will be thoroughly
checked by static type checkers.
As I understand there are two separate parts of the proposal:
1) suffixes like micro, kilo, etc. -- but Guido does not like this idea yet
2) physical units -- this part I think could be 99% percent solved by PEP
484 and PEP 526
(it is not 100% because this will require dependent types).
--
Ivan
On 27 August 2016 at 22:22, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Aug 28, 2016 at 4:25 AM, Steven D'Aprano <st...@pearwood.info>
> wrote:
> >
> > Sympy (apparently) doesn't warn you if your units are incompatible, it
> > just treats them as separate terms in an expression:
> >
> > py> 2*m + 3*K
> > 3*K + 2*m
> >
> > which probably makes sense from the point of view of a computer algebra
> > system (adding two metres and three degrees Kelvin is no weirder than
> > adding x and y). But from a unit conversion point of view, I think
> > sympy is the wrong solution.
>
> As a generic tool, I would say this is correct. It keeps things simple
> and straight-forward. Worst case, you see a strange result at the end,
> rather than getting an instant exception; in fact, it's very similar
> to NaN, in that some operations might cancel out the "error" status.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
