On Wed, Aug 26, 2020 at 10:40 AM Paul Moore <p.f.mo...@gmail.com> wrote:
> 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. > I agree with you. Let's preserve the dynamism. I abandon that implementation idea. > 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. > Yup. That is going to be a hard one. Hopefully others smarter than me can help think about how we could do it. But I for sure see the problem. > 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 > Well I did give a couple examples: language supported opt-in for pep-472-ification, and pep-472 opt-out. But Ok, more are needed. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
_______________________________________________ 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/BXTZRCFMFFDLXAW6O2SQACWCHHMYQ6E4/ Code of Conduct: http://python.org/psf/codeofconduct/
