On Wed, 26 Aug 2020 at 15:12, Ricky Teachey <ricky@teachey.org> wrote:

> Objection 1: Slowing Things Down
>
> The INTENDED EFFECT of the changes to internals will be as Jonathan Fine described: every time a subscript operation occurs, this new dunder attribute gets investigated on the class, and if it is not present then the default key translation function is executed.
>
> If things were implemented in exactly that way, obviously it would slow everything down a lot. Every subscripting operation gets slowed down everywhere and that's probably not an option.
>
> However, for actual implementation, there's no reason to do that. Instead we could wrap the existing item dunder methods automatically at class creation time only when the new dunder attribute is present. If it is not present, nothing happens. In other words, what has been described as the "default key or index translation function" already exists. Let's not change that at all for classes that do not choose to use it.

That would mean the effect was to disallow runtime monkeypatching -
the new dunder is *only* effective if added at class creation time,
not if it's added later. You may not care about this, but it is a very
different behaviour than any other dunder method Python supports - so
quite apart from the problems people would have learning and
remembering that this is a special case, you have to document *in your
proposal* that you intend to allow this. And other people *do* care
about disallowing dynamic features like monkeypatching.

I do understand that Python's extreme dynamism is both disconcerting
and frustrating when it makes proposals like this harder to implement.
But conversely, that same dynamism is what makes tools like pytest
possible, so we all benefit from it, even if we don't directly go
around monkeypatching classes at runtime.

If you think you can implement this proposal without blocking Python's
dynamic features, and without introducing a performance impact, I'd
say go for it - provide an example implementation, and that would
clearly show people concerned about performance that it's not an
issue. But personally, I'm not convinced that's possible without
adding constraints that *aren't* currently included in the proposal.

> Objection 3: Doesn't add anything useful/helpful
>
> This objection seems obviously false.

Hardly. What are the use cases? It's "obviously false" to state that
the proposal doesn't add anything at all, true. But the question is
whether the addition is *useful* or *helpful*. And not just to one
individual who thinks "this would be cool", but to *enough* people,
whose code would be improved, to justify the cost of adding the
feature. You yourself conceded that the feature adds complexity, this
is where you get to explain why that cost is justified. "It's
obviously helpful" isn't much of a justification.

Paul