Chris Angelico writes: > A proposal that breaks existing code, and which introduces a new way > to do things, will usually require multiple versions of deprecation > time in order to be accepted. Nothing is preventing us from doing that here. I already intend to have the adoption syntax come first, since it doesn't break anything pre existing, it can be added, and a few version later, the breaking change can happen, you've got your deprecation time.
> That usually means either a compatibility > period, or a means of continuing to use the older syntax. A compatibility period is probably the only way for the entire proposal, but for most parts of it, i'm pretty sure it could be possible to have the older syntax still apply. > In the case of > the "except Exception, e:" syntax, the justification is that it is > confusingly similar to "except (Exception1, Exception2):" in a way > that causes hard-to-debug problems. I've already been over how MRO causes hard to debug problems, since it makes it possible for one class to ignore one of its parent attribute, while using the other parents attribute instead, without any warning / errors. Actually i got another exemple recently (at work, i wasn't really looking for it), on django doc : https://docs.djangoproject.com/fr/4.0/topics/auth/default/#django.contrib.auth.mixins.UserPassesTestMixin.get_test_func some classes dedicated to test some users all inherit from the same UserPassesTestMixin class. This class has some NotImplemented errors, in the method it provides to it's childrens. If we were to make multiple TestMixins, like described in the link i shared, calls to super aren't possible, and would lead to the mixins needing to be inherited all together. So there's no point writing down multiple of them, might aswell write down just one, and why would you, when you have multiple tests that have nothing to do with one another. The doc concludes it's impossible to use multiple TestMixins, and doesn't mention at all the class.method syntax that all of you seem to find so obvious. Given the popularity of django, it speaks volume to what i've been telling you for so long now. class.method syntax is *not* a solution, since it's very unlikely someone in need will find it. So there's very much a need to be covered here. > Don't simply dismiss the concern; > answer it by showing the need that justifies it. Hope it answers that remark. I'll still be working on that survey... it's taking me forever Will you have a read at the question before i run it, so you can agree before hand the questions are fair to you? --- Eric V. Smith writes: > I'm trying to > save you some time here, but if you're committed to continuing this, > then you can't say you weren't warned when it's ultimately rejected I'm aware of this, thanks for the warning nonetheless. > My > suggestion is to rework your proposal to not break any existing code I've been doing that already, and i'll keep doing it, i'm very aware of this constraint. What are the biggest breaking change i haven't covered yet, in your opinion? If you can think of a few that seem way too bad please let me know. _______________________________________________ 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/KSH23FO6DLJJJV6DSNZBROS4C6RNQZII/ Code of Conduct: http://python.org/psf/codeofconduct/
