Attention is currently required from: fixeria, laforge.
1 comment:
Commit Message:
Neels: please explain this change. […]
This tiny detail is just not worth even considering to spend time on. All time I spend ranting on this is another layer of ridiculous folly. We are discussing a class attribute.
But here goes, again:
I set a custom class attribute 'name' in each child class, and the code in `__new__()` overrides that. So this turns on its head the principle that a child class has the last say.
instead, here, the parent class overrides what the child class has determined to be its initial state. This prevents me from using a class attribute called 'name' in child classes.
The `__new__` operator should not be doing these things at all, the code before this patch is just plain and completely wrong.
Nowhere in pysim do we need to or should we ever ever, EVER, override `__new__()`.
I welcome you to experiment with it to find a way that works well with this super weird code in place. But I will always disagree because I am right and `__new__` is wrong.
This here is an instance of very annoying code review, because it is relentlessly asking me why i remove obscure things that are obviously and logically getting in my way, and stopping me from replacing them with the most normal trivial python that there is.
(This edit has initially been in another patch that also got similar discussions. To this day there has been no sound argument against this change.)
I should not have to explain in detail, but so far, when I do, this gets ignored, and comes back again and again. I have more layers of explanations why a class name should not be 1:1 taken as a name attribute in a UI merging naming scopes that belong separate etc etc, but it is just wasted time.
The fix is re-instating normal python that we know and love.
And, things actually break without this fix.
To view, visit change 41918. To unsubscribe, or for help writing mail filters, visit settings.