On Sat, 14 Nov 2020 at 01:59, Baptiste Carvello <devel2...@baptiste-carvello.net> wrote: > > Hi, > > Le 12/11/2020 à 18:55, Guido van Rossum a écrit : > > The position of PEP 622/634/535/636 authors is clear: > > well, let me first emphasize that I did *not* mean to reopen the > discussion on those PEPs, which explain and discuss their design choices > thoroughly (even better since the rewrite, thanks for that). And I > definitely did not mean to spawn another "mark capture or value" > subthread… I thought "PEP 642 v2" in the thread title was explicit > enough, should have been more cautious :-) > > PEP 642 states as a design principle that parallelism between patterns > and assignments should be kept as much as possible (let's not discuss > this principle here). Thus, introducing different semantics for dotted > names deserves a discussion in that PEP (by contrast, literal > constraints need little discussion, because they have no semantics in > assignments).
You're right, I had missed that I didn't mention attribute syntax specifically in https://www.python.org/dev/peps/pep-0642/#keeping-inferred-equality-constraints The rationale is the same as it is in PEP 635: comparing against enum values is likely to be super common, and requiring the extra "==" sigils in that case at least arguably hinders readability rather than helping it. I actually find most of the predictions of likely usage patterns in PEP 635 entirely plausible - where I differ with the authors of that PEP is in whether or not we need to offer explicit override syntax for the cases where those predictions turn out to be wrong, rather than in our opinions of what the most common use cases are actually going to be. > > we see this as a > > necessary feature to support using enums (e.g. Color.RED) or constants > > defined in other modules (e.g. re.I) when simple switch functionality is > > being migrated from literals (e.g. case 404) to named constants (e.g. > > case HTTPStatus.NOT_FOUND). Bothering users with the technicality of > > needing to use '==' here is a big usability hit. > > Indeed, enums and other dotted constants are the heart of the matter. > And I get your point about not making useful refactoring more difficult. > Still it could make sense (in the philosophy of PEP 642, again) to defer > the choice and see how strong the need is. What PEP 642 ends up > proposing will be Nick Coghlan's call. I opted to include the inferred equality constraints for attributes specifically to make the revised PEP 642 almost purely additive over PEP 634 - while v1 removed a lot of things (which raised several legitimate readability and usability concerns), the only things v2 outright removes are the inferred constraints for True and False (on grounds of ambiguity). The rest of the changes are now either new additions (explicit identity and equality constraints), changes in spelling (double-underscore vs single-underscore for wildcards), or slight changes in how constructs are defined (the inferred constraints for literals and attribute lookups get redefined as syntactic sugar for their explicit counterparts, rather than being first class constructs in their own right). 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/ZFKXSL4E7AF5WVAQICNZQHTGRVMKCXJW/ Code of Conduct: http://python.org/psf/codeofconduct/
