Before we all get a little too excited here, I think that allowing ``` 1 = x ``` as a sneaky way of writing ``` assert x == 1 ``` would be a terrible mistake.
We already have a static way to assert that something is a string: ``` self.name: str = value ``` I don't think that we'll need another way to express the same thing at runtime, so I'm not excited about ``` self.name = str() = value ```
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.
On Wed, Jul 1, 2020 at 7:19 AM Nick Coghlan email@example.com wrote:
On Thu, 2 Jul 2020 at 00:04, Elliott Chen firstname.lastname@example.org wrote:
I saw in the PEP that "Allow more flexible assignment targets instead"
was rejected, but I actually think it's a good idea. The current PEP means there will be two different, subtly incompatible ways to destructure objects (match statement and iterable unpacking). The reasoning given was that most cases involve an if-statement, but there's no reason we can't have both flexible assignment targets and a match statement. I think unifying the concepts will make the language more consistent and easy to learn.
I also think destructuring an object with only one possible pattern can
be very useful, without the boilerplate to set up an entire match suite and manually raise an exception. This will make the variable assignment statement much more powerful. I don't see a good reason to arbitrarily restrict variable assignment to only allow sequence patterns. This might not be a good idea, but it can even potentially be used as an assert statement, like this:
def __init__(self, version, name, point): self.version = 1 | 2 | 3 = type # assert that "version" is
between 1 and 3
self.name = str() = string # assert that "name" is the correct
Point(0, self.y) = point # assert that "point" is on the y-axis
The constant value pattern would have to be changed to something else,
like "@constant", and even though that's also rejected, I think the benefits outweigh the costs here. The special treatment of "_" would have to go too, but there's no reason it can't be used as a wildcard by convention anyway, similar to how it can already be used in for loops. I don't see any benefit in treating it specially. Or the question mark can be the wildcard instead.
The wildcard spelling idea I suggested in the other thread was that "?" could become a general constraint prefix used to introduce non-literal and non-keyword constraints.
I was thinking purely in terms of destructuring and not in terms of data validation, but you're right that multiple assignments would allow for "multi-capture" (albeit with the usual caveats on iterable consumption).
(I think match/case is fine as the spelling for the multi-target dispatch case, though)
-- Nick Coghlan | email@example.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/LOLDPPKH... Code of Conduct: http://python.org/psf/codeofconduct/