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 <ncogh...@gmail.com> wrote: > On Thu, 2 Jul 2020 at 00:04, Elliott Chen <elliottchen2...@gmail.com> > 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 > type > > 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. > > Exactly! > > 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) > > Cheers, > Nick. > > > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > 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/LOLDPPKHE6L75WW2FNEQHONNZK2LM6NI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/WQCHP4A23CF7HSZTOMJUEFNC2MJPRIST/ Code of Conduct: http://python.org/psf/codeofconduct/
