>>> Now, suppose that the "external function" switches to use the name
>>> collections.DefaultDict. The above code will break, unless the two
>>> names defaultdict and DefaultDict are updated in parallel somehow to
>>> both point to MyMockClass. How do you propose we support that?
>>
>> This would be fixed with the 'aliasing variable names'-solution.
>>
>
> Not sure I follow; are you proposing that module attributes be able to
> say "I'm the same as that guy over there"? That could be done with
> descriptor protocol (think @property, where you can write a
> getter/setter that has the actual value in a differently-named public
> attribute), but normally, modules don't allow that, as you need to
> mess with the class not the instance. But there have been numerous
> proposals to make that easier for module authors, one way or another.
> That would make at least some things easier - the mocking example
> would work that way - but it'd still mean people have to grok more
> than one name when reading code, and it'd most likely mess with
> people's expectations in tracebacks etc (the function isn't called
> what I thought it was called). Or is that not what you mean by
> aliasing?
By aliasing I meant that the names of the fuctions/variables/
classes (variables) are all using the same value pointer/location.
That could mean that in debugging the name of the variable
is used as the name of the function. e.g. debugging get_int
results in 'in get_int(), line 5' but it's original getint results in
'in getint(), line 5'. Another option is 'in get_int(), line 5 of getint()'
if you want to retain the source location and name.
And all of that requires work beyond simple aliasing by assignment. That means writing code to make this work as well as tests to make sure nothing breaks (on top of the documentation).
Multiple core devs have now said why this isn't a technical problem. Nick has pointed out that unless someone does a study showing the new names would be worth the effort then the situation will not change. At this point the core devs have either muted this thread and thus you're not reaching them anymore or we are going to continue to give the same answer and we feel like we're repeating ourselves and this is a drain on our time.
I know everyone involved on this thread means well (including you, Matthias), but do realize that not letting this topic go is a drain on people's time. Every email you write is taking the time of hundreds of people, so it's not just taking 10 minutes of my spare time to read and respond to this email while I'm on vacation (happy BC Day), but it's a minute for everyone else who is on this mailing list to simply decide what to do with it (you can't assume people can mute threads thanks to the variety of email clients out there). So every email sent to this list literally takes an accumulative time of hours from people to deal with. So when multiple core devs have given an answer and what it will take to change the situation then please accept that answer. Otherwise you run the risk of frustrating the core devs by making us feel like we're are not being listened to or trusted. And that is part of what leads to burnout for the core devs.
-brett
It could be descriptors for Python library implementations, but in C
it could be implemented as a pointer to <VariableContents> instead of
a struct containing <VariableContents>, or it could compile(?) to use
the same reference.
I am not familiar enough with the structure of CPython and
how it's variable lookups are built, but these are just a few ideas.
-Matthias
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/