On 30 August 2016 at 13:48, Ken Kundert <python-id...@shalmirane.com> wrote:
>     >>> d_sun = 93e6*u.imperial.mile
>     >>> print(d_sun.to(u.parsec))
>     4.850441695494146e-06 pc

The "imperial.mile" example here highlights one key benefit that
expression based approaches enjoy over dedicated syntax: easy access
to Python's existing namespace features.

As a quick implementation sketch, consider something like:

>>> si_scaling = dict(k=1000, m=0.001)
>>> class SIScale:
...     def __getattr__(self, key):
...         return SIUnit(si_scaling[key])
...
>>> class SIUnit:
...     def __init__(self, value):
...         self.value = value
...     def __getattr__(self, ignored):
...         return self.value
...
>>> si = SIScale()
>>> 500 * si.k.m
500000
>>> 500 * si.k.parsec
500000
>>> 500 * si.m.m
0.5
>>> 500 * si.m.N
0.5

You could also relatively easily adapt that such that there there was
only one level of lookup, and you could write the examples without the
second dot (you'd just need to do some parsing of the key value in
__getattr__ to separate the SI prefix from the nominal units)

One particular benefit of this kind of approach is that you
automatically avoid the "E" ambiguity problem, since there's nothing
wrong with "si.E" from Python's perspective. You also gain an easy
hook to attach interactive help: "help(si)" (or si? in IPython terms)

Expanding out to full dimensional analysis with something like
astropy.units also becomes relatively straightforward, just by
changing the kind of value that __getattr__ returns.

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/

Reply via email to