On 2022-04-05 12:17 a.m., Chris Angelico wrote:
On Tue, 5 Apr 2022 at 13:00, Steven D'Aprano <st...@pearwood.info> wrote:
Sure, we can demand that every application that needs to deal with US
survey miles and imperial miles and international miles give them all
distinct names. That's one solution, but not the only solution.
My solution is to allow the very very few applications that need both
to do some sort of disambiguation.
Of course, this is only significant if you need *literals* of all of
them. The units themselves can be distinct, even if each one would
want to register itself with the name "mile".
But even if you do that, having one interpreter-wide database that any
random library can write to is asking for trouble. If this becomes
widespread, expecting libraries to "just don't overwrite existing units"
is not good enough.
What's your proposal?
from units.SI import *
? This pollutes your main namespace *and* still has all the same problems.
from units.survey import mile as s_mile
from units.imperial import mile as i_mile
from units.roman import mile as r_mile
We could bikeshed endlessly on how exactly to tell the interpreter to
use an imported name as a literal suffix (it could just be that it calls
a new dunder), but it seems to me that the way to disambiguate a name
conflict in imported modules is very much already a solved problem. I
don't quite understand why you want to add a different system that
introduces a name conflict issue
AlexB
_______________________________________________
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/TY3JVBGUFQNFYGMUJ3MGJGEK4F5Q7UIE/
Code of Conduct: http://python.org/psf/codeofconduct/
