Nick Coghlan wrote:
> On Thu, 2 Jul 2020 at 00:50, Guido van Rossum gu...@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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ZCDCBE3U3WUZZTKOXYA6ZFXUH3MV6SUK/
Code of Conduct: http://python.org/psf/codeofconduct/
