On Fri, 8 Apr 2022 at 13:09, Matt del Valle <matthew...@gmail.com> wrote: > > 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
Thanks. That's extremely useful, and I can see it as a reasonable language feature request. BUT (and it's a big "but"!) someone would have to write, support and maintain that units library. Obviously in the first instance, it couldn't use the dedicated syntax, but unit_cls(number) doesn't seem like a horribly bad compromise for a 3rd party library right now. So here's my proposal. 1. Somebody (or a group of people) who wants to see this happen, write (or adopt) a library and publish it on PyPI. It should provide *all* of the functionality that the proposed stdlib support would offer, with the sole exception that units get attached to values using unit_cls(number) rather than special syntax. It's possible that the "units" library that's already on PyPI is (nearly) that library - but from what I've heard in this thread, the community hasn't reached consensus on what "best of breed" looks like yet. 2. Once that library has demonstrated its popularity, someone writes a PEP suggesting that the language adds support for the syntax `number[annotation]` that can be customised by user code. This would be very similar in principle to the PEP for the matrix multiplication @ operator - a popular 3rd party library demonstrates that a well-focused language change, designed to be generally useful, can significantly improve the UI of the library in a way which would be natural for that library's users (while still being general enough to allow others to experiment with the feature as well). 3. Once the new language feature is accepted, and the library authors are willing, propose that the library gets added to the stdlib. We're currently at step 1 - we need someone to come up with a library that demonstrates how to provide this functionality in a way that matches users' requirements, and which has unified community support. That step doesn't need anything much from the Python core devs or even this list, beyond maybe a general feeling that the overall plan "isn't a totally dumb idea"... Step 2 is where a PEP and proper core dev support would be needed. But the library would be useful even if this doesn't happen (and conversely, if the library proves *not* to be useful, it demonstrates that the language change wouldn't actually be as valuable as people had hoped). Step 3 is optional. With language support that can be used by external libraries, "being part of the stdlib" isn't needed. This is true of pretty much everything in the stdlib, though - stdlib modules don't have any special benefits that external libraries don't. As a supporter of a large stdlib, I'd be OK with moving the units library into the stdlib (on the assumption that the library maintainers commit to supporting it in the stdlib, and don't run away and dump the problem on the core devs). Others who prefer a smaller stdlib would argue it's fine on PyPI. But that's an argument about principles which frankly end users and 3rd party library authors can't influence much (and can probably ignore in practice). So honestly, I'd encourage interested users to get on with implementing the library of their dreams. By all means look ahead to how language syntax improvements might help you, but don't let that stop you getting something useful working right now. Paul _______________________________________________ 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/5NYDJZSQK7ZEE5UDCWHAAU5ZK5FKCLVE/ Code of Conduct: http://python.org/psf/codeofconduct/
