My personal preference for adding units to python would be to make
instances of all numeric classes subscriptable, with the implementation
being roughly equivalent to:
def __getitem__(self, unit_cls: type[T]) -> T:
return unit_cls(self)
We could then discuss the possibility of adding some implementation of
units to the stdlib. For example:
from units.si import km, m, N, Pa
3[km] + 4[m] == 3004[m] # True
5[N]/1[m**2] == 5[Pa] # True
'Casual' users could also use a star import (despite its pitfalls) and not
have to worry about going back and updating the import statement, so I
don't think requiring that import would be much of a barrier to beginners.
They'd just learn they need that star import at the top of the file as a
sort of 'magic spell'.
Third-party libraries could provide their own unit classes with additional
features and characteristics that you could substitute in by simply
changing the import statement and nothing else. To write a custom unit
class you would just have to implement an __init__ that accepts a single
numeric argument. To enable units like m², the __pow__ magic method would
have to be implemented in the unit class' metaclass.
The advantages of this seem to me like:
1) no new syntax, just an extra magic method for numeric types
2) batteries included,
3) Won't clutter up the builtins, you have to opt in by using imports
3) simple for third-party libraries to support and extend
I can't really see much in the way of disadvantages aside from:
1) aesthetic objections to the use of subscription for this purpose. I
personally quite like it because in a way a unit at the end of a number *is*
a subscript anyway, so it seems quite fitting to use python's subscription
syntax for it.
2) the opposite of advantage 3) above: people actually *wanting* the units
to be part of the builtins so that you don't have to use any imports.
Depending on your opinion this can be a good or bad thing
And if no reasonable implementation of the batteries can be agreed upon,
that's fine, that part can be delayed or rejected.
On Fri, Apr 8, 2022 at 12:21 PM Ricky Teachey <ri...@teachey.org> wrote:
> On Fri, Apr 8, 2022, 2:40 AM Stephen J. Turnbull <
> stephenjturnb...@gmail.com> wrote:
>
>> Brian McCall writes:
>> >>>> Steven d'Aprano writes:
>>
>> > > you have shown nothing to justify why unit support must be built
>> > > into the language itself.
>> >
>> > I did what I could, but I'm not going to try and justify any more.
>>
>> That makes me sad, because everybody in the thread acknowledges that
>> improving the Python distribution's support for units is a good idea,
>> but nobody is as enthusiastic about getting it done as you.
>>
>> Chris Barker's comments about multiple attractive library
>> implementations are well-taken, I think, but I also think that with
>> more focus on getting a satisfactory module into the stdlib, it would
>> be quite possible to pick one that doesn't rely on non-stdlib types
>> (so I guess astropy.units would be out).
>>
>> That doesn't directly get you the literal syntax for units you focus
>> on, but if units are easier to use, more applications will use them,
>> and perhaps build up momentum for a syntax change. And the syntax
>> change is useless without the library.
>>
>
> I'll try to provide examples of my struggles with units in python but I'm
> not an accomplished coder at all and don't have much to look at in the way
> of examples. I sometimes go weeks without writing any code at all, followed
> by days of nothing but writing code.
>
> Python is so painful to use for units I've actually avoided it, so there
> won't be many examples I can give anyway. Hence my silence in this thread
> the past few days.
>
> I just get really excited at the idea of it being native to the language
> and am dreaming of being able to use it more often for my every day
> calculations. Right now I just don't feel confident I can.
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LSQQKL72J5AWCCZFHVY2M4RJFU7Y6OGH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/E6TWNUNIABVADBLRHY6LQXFRCH4UE74Z/
Code of Conduct: http://python.org/psf/codeofconduct/
