> On 10 Jul 2020, at 18:28, Jim Baker <jim.ba...@python.org> wrote: > > On Fri, Jul 10, 2020, 9:16 AM Eric Nieuwland <eric.nieuwl...@gmail.com> wrote: > >> On 10 Jul 2020, at 01:51, Jim Baker <jim.ba...@python.org> wrote: >> ... >> Explicit namespacing (if a constant) or using a guard (if a variable) seems >> to be the right solution, as Ethan demonstrated earlier. No need for . or ^ >> or \ or ... to disambiguate. Also it seems to me that structural pattern >> matching will build on two common usages of namespaces for constants: >> >> 1. Constants used from other modules are almost always used in the module >> namespace. Eg, socket.AF_UNIX or signal.SIGTERM. >> 2. New code often tends to use constants defined within an Enum namespace. >> Hopefully we will see more of this convention in usage. >> >> (Very much an aside: Interestingly with the socket module we see both used - >> it defines its constants with IntEnum and exports them traditionally. The >> namespace specifics it uses with IntEnum._convert_ to make this happen -- >> strictly speaking EnumMeta._convert, not documented, and a bit hard to >> follow -- might be possibly debatable, but it works out quite well in >> practice in providing backwards compatibility while continuing to work with >> a C source of these constants.) >> >> This would also mean >> case Point(x=\x, y=\y): >> should be used to obtain x and y from the Point instance. > > This approach makes deeper nesting of the structure much more cumbersome, I > think. > > How to match Polygon(Point(x0,y0), Point(x1, y1), Point(x2, y2)) based on its > structure? > And Polygon(Point(x0,y0), p1, Point(x2, y2))? > > > I'm just trying to describe what v2 of the PEP is trying to do and how it > then corresponds to a reasonable usage model. Sorry for any confusion.
Yes, I understood. Thank you for that. No apology needed. > So in your scenario above, Polygon and Point are used as class patterns > (https://www.python.org/dev/peps/pep-0622/#class-patterns). Consequently they > are treated accordingly and have that nice structural pattern matching > quality! What I meant to say is that as I read the current PEP text there would be a confusing difference between match poly: case Polygon(Point(x0, y0), Point(x1, y1), Point(x2, y2)): ... and p0 = Point(x0, y0) p1 = Point(x1, y1) p2 = Point(x2, y2) match poly: case Polygon(p0, p1, p2): ... This would be especially clumsy if I need to match parts in a deep structure. It would require me to either write the whole construction as part of the ‘match’ or use ‘match’ nested to drill down to the parts I need. > Earlier I was discussing constant patterns > (https://www.python.org/dev/peps/pep-0622/#constant-value-patterns), which > require they be namespaced in some way (a qualified name as it is described > in the PEP). Indeed. My point is this would be - as far as I know - the first time you need to create a namespace to use the value of an already known variable. This only to allow assignment to variables which I find counterintuitive and which IMHO leads to clumsy constructions, as shown above. So I hope the new and special thing here (i.e. assign matched parts of the structure to variables) will not interfere with how we read expressions in Python. A special indicator for the special use case to me seems far easier to understand and to teach. —eric _______________________________________________ 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/ZXYKO57S6U5UNQG6Y5IUXIXI54RBV2QD/ Code of Conduct: http://python.org/psf/codeofconduct/
