On Wed, 26 Aug 2020 at 15:12, Ricky Teachey <ri...@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 _______________________________________________ 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/X342S76IP2AGIK3DPKSK6BI2XJE5KV74/ Code of Conduct: http://python.org/psf/codeofconduct/
