[Python-ideas] Making the stdlib consistent again

[Brett Cannon]

On Mon, Aug 1, 2016, 08:36 Matthias welp <boekewurm at gmail.com> wrote:

> On 1 August 2016 at 16:23, Chris Angelico <rosuav at gmail.com> wrote:
> >On Mon, Aug 1, 2016 at 11:31 PM, Matthias welp <boekewurm at gmail.com>
> wrote:
> >>> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160801/2bd53712/attachment.html>