On Thu, 16 Jun 2022 at 08:25, Steven D'Aprano <steve@pearwood.info> wrote:
On Thu, Jun 16, 2022 at 12:02:04AM +1000, Chris Angelico wrote:
On Wed, 15 Jun 2022 at 22:38, Steven D'Aprano <steve@pearwood.info> wrote:
There's no consensus that this feature is worth the added complexity, or even what the semantics are. The PEP punts on the semantics, saying that the behaviour may vary across implementations.
Excuse me? I left one or two things open-ended, where they're bad code and I'm not going to lock the language into supporting them just because the reference implementation happens to be able to, but "punts"? That's a bit much. The semantics are QUITE specific.
Under the Specification section, the PEP explicitly refers to behaviour which "may fail, may succeed", and different behaviour which is "Highly likely to give an error", and states "Using names of later arguments should not be relied upon, and while this MAY work in some Python implementations, it should be considered dubious".
So, yes, the PEP *punts* on the semantics of the feature, explicitly leaving the specification implementation-dependent.
One very very specific aspect of it is left undefined. Are you really bothered by that? I don't understand how you can dare to write a single line of code, given how many other things are actually not specified. Have you ever written a __del__ method? Python *does not guarantee* when it will be called. Wow! Python is hopelessly implementation-dependent, there's no WAY this should ever be used! And then you take this tiny point where I left it open to implementers to choose, and you say that the PEP "punts on the semantics" as if the entire specification is in doubt. I'm trying as hard as I can to believe that you're arguing in good faith, but it's getting less and less plausible. ChrisA