> On 10 Apr 2022, at 11:20, Chris Angelico <ros...@gmail.com> wrote: > > On Sun, 10 Apr 2022 at 18:44, Ronald Oussoren via Python-ideas > <python-ideas@python.org <mailto:python-ideas@python.org>> wrote: >> >> >> >> On 8 Apr 2022, at 16:33, Steven D'Aprano <st...@pearwood.info> wrote: >> >> On Tue, Apr 05, 2022 at 02:17:00PM +1000, Chris Angelico wrote: >> >> Do you ever have one module that's using statute miles and >> another that's using nautical miles, but *not both in the same >> module*? The only reason to have them namespaced to modules is to >> allow different modules to use them independently. If your application >> needs to use both statute and nautical miles in the same module (most >> likely the main module), then it's going to have an issue, and your >> proposal adds a ton of complexity (that's a real unit, by the way, I >> totally didn't make it up) for no benefit whatsoever. >> >> >> That's not the real problem. >> >> The real problem is that my program may: >> >> * import ham, which registers mile as 1609.3412 m >> * import spam, which registers mile as 1609.344 m >> * import cheese, which registers mile as 1609.3472 m >> * import aardvark, which registers mile as 1609.3426 m >> * import hovercraft, which registers mile as 1853.181 m >> >> >> I’ve only scanned this thread and may have missed an explanation for this, >> but why must there be a global registry? >> >> Explicit imports, possibly with a new dunder protocol for literal convertors >> feels like a better fit to the language to me. This also avoids the problem >> with a global registry you mention earlier. >> > > That's precisely what Steven is arguing for, and I'm arguing against. > Primarily because YAGNI, but also for a more fundamental reason: the > registry of units is not simply a definition of name -> value, which a > namespace is capable of (but I think is wrong for this situation), but > it's also a definition of which units can be converted into which.
The registry is a mapping from names to objects implementing some kind of interface, and modules are a good solution for that. > That would affect how two objects interact with each other - can you > add meters and miles? Can you treat the electron-volt as a unit of > mass? All these sorts of questions belong to the application, and > there's no useful way to divide them on module boundaries, much less > other scopes. Why not, that’s what we do for all other types and interfaces? Compatibility and interaction should IMHO be part of the implementation of a set of cooperating types, and that’s orthogonal to how you get access to those types. > > There's no point trying to make this scoped, just as we don't have > lots of other things scoped (like sys.modules). Shared state across > the application is a *good* thing, not a bad one. I’m pretty sure singletons are considered to be a code smell in general ;-) But as I wrote earlier, I don’t have a use case for using this feature myself. The closest I get are tuples with the same shape but different interpretation, such as various color representations. For those using regular class syntax is obviously a better choice than using tuples (e.g. RBG(1,2,3)). The few times I need to deal with units I can either ignore them, or use a normal type (e.g. meters(1)). Ronald > > ChrisA > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > <mailto:python-ideas@python.org> > To unsubscribe send an email to python-ideas-le...@python.org > <mailto:python-ideas-le...@python.org> > https://mail.python.org/mailman3/lists/python-ideas.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/IH2VPKRYBKXLJCVNRZL7PB5WKCWYAK2Z/ > > <https://mail.python.org/archives/list/python-ideas@python.org/message/IH2VPKRYBKXLJCVNRZL7PB5WKCWYAK2Z/> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/> — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
_______________________________________________ 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/SRM72OSDWQWX7RNKZMHUNTIGAP7SWKKD/ Code of Conduct: http://python.org/psf/codeofconduct/
