Nick Coghlan wrote:

On Thu, 2 Jul 2020 at 00:50, Guido van Rossum guido@python.org wrote:

...

As to allowing object destructuring syntax like Point(x, y) = p

...

that definitely has merit, but it is a complex subject that should be a separate PEP.

This is the main point I'm actually interested in, and I agree it should be a separate PEP.

I also like it, but I don't see a way to actually do it usefully without changing how Python works. The glitch is for cases like: Point(?x, 15) = p If constraints like (y=15) are not allowed, then it doesn't really offer much advantage over a regular constructor like: Point(*p) But if they are allowed, then what does it mean? Point(p[0], 15) would be logical, but still not very valuable. At the very least, it should be able to reject: Point(x, y) = ("Hello", "World") but it isn't clear how much of the constructor (let alone some other arbitrary callable) to run before saying "yeah, it meets the contract", unless type annotations and their "correct" meaning become even more constrained, so that: Point(x:int, y:int) = ("Hello", "World") could fail, because "Hello" is not an int. But that is just a very weak Design By Contract that both constrains the meaning of annotations and still leaves out most interesting contracts. -jJ