[Python-Dev] Re: Problems with dict subclassing performance
"Pretendere" in Italian means "to demand", it's a false friend with the English "pretend". I don't know whether Marco is Italian (the false friend might also be there between Spanish or whatever other romance language he speaks and English, for all I know). From a native Italian speaker's perspective, what he meant was very clear to me, but it's also clear that an English speaker with no experience of Italian would not be expected to understand the meaning necessarily. Either way, from an outsider's perspective this whole bickering over such a small thing seems unfit for a list where adults talk about technical details. It seems to me that someone should swallow their pride and let this thread drop once and for all, it's not bringing anything useful or relevant. ___ 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/I4MMDDKQRK5ZW4MJRHUMYNLTLJ5AQLMW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 647 Accepted
I vaguely remember reading some discussion about Annotated and, for what
little it's worth, I disagree with the consensus.
For now all that comes to mind is either stuffing the information in
docstrings (which would be kind of an involution, seeing as that was the
way for annotating type before type annotations), or changing the name
of the type to something more obvious at a glance. Something like
Typeguards["param", T], if arbitrary strings could be included, which
would have to correspond to parameter names. This would give a few extra
advantages:
- Multiple parameters could be annotated per function if needed (e.g.
def my_function(param1, param2) -> Typeguards["param1", T, "param2",
U]). An alternative syntax could be Typeguards[["param1", T], ["param2", U]]
- Functions with additional parameters that the function uses but which
are not typeguarded could be used, and there would be no ambiguity as to
which parameter is affected by the typeguard: def my_function(param1:
Any, param2: bool) -> Typeguards["param1", T]
Personally, I like the idea of functions that /happen/ to restrict the
type of a variable without it necessarily being their only or primary
goal; this would enable those.
Possible alternative names: Ensures["param1", T], Ensure["param1", T],
IsType["param1", T]. It's important to remember that jargon creates a
potential hurdle to comprehension, so simpler language should, in my
opinion, always be preferred.
Side-note: | is being introduced for union types in type annotations.
Could it be an idea to add a & as well, to signal side-effects of the
function that do not interfere with the return value? A function could
then have a signature like:
- def my_function(param1, param2) -> bool & Typeguards["param1", T]
- def my_function(param1) -> int & Typeguards[T] # Only one param, so
"param1" is optional
I realise it would make signatures (optionally!) longer and arguably
uglier, but the latter is mostly a matter of personal taster and of
getting used to, which is always there when new features are introduced.
I remember := being controversial, but it grew on me over time.
I hope there's at least something worth considering in the above ideas.
On 07/04/2021 21:59, gu...@python.org wrote:
But it isn't a "side effect". It is a distinct concept that is
important to the type checker.
Note that in TypeScript this also doesn't look like a boolean -- it
uses a unique syntax that has to be learned:
function isCustomer(partner: any): partner is Customer {
. . .
}
Arguably the TS syntax is more easily intuited without looking it up,
but TS has a certain freedom in its syntactic design that we don't
have for Python: new *syntax* has to be added to the Python parser and
can't be backported, whereas new *types* (like `TypeGuard[T]`) can
easily be backported via typing_extensions.py.
We have really tried, but we did not come up with anything better than
the current PEP.
FWIW you might be interested in Annotated (PEP 593), which can be used
to indicate various attributes of a type annotation. Before you
suggest that we adopt that instead of PEP 647, we considered that, and
the consensus is that that's not what Annotated is for (it's intended
for conveying information to tools *other* than the type checker, for
example schema checkers etc.).
--
--Guido van Rossum (python.org/~guido )
/Pronouns: he/him //(why is my pronoun here?)/
[Python-Dev] Re: PEP 647 Accepted
I don't have any decent proposal at the moment but I think coming up with a way to annotate side-effects of functions (including typeguard-ness) could come in handy. If we anticipate needing that, perhaps it would be beneficial to come up with that feature before implementing this PEP, lest we end up with something that could have benefitted from it but was released just before it. Though personally I like the PEP and have no qualms about having to learn that TypeGuard is "a bool with a side-effect"; I don't think it's a problem in the first place, there are less obvious, more complicated things in Python that I couldn't just intuit at a glance. On 06/04/2021 22:31, Barry Warsaw wrote: [...] but this also isn’t quite accurate, and we were concerned that this might be highly inconvenient in practice. In a sense, the type guard-ness of the function is an attribute about the function, not about the parameters or return type, but there is no way to currently express that using Python or type checking syntax. [...] Cheers, -Barry (on behalf of the Python Steering Council) ___ 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/DUIPWYVKP5KWXHQVN5ODPQPFCMOXGWFW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Yet another idea for pattern matching syntax
I'm sorry, I've been skipping around the discussion a bit, but I'm fairly certain this suggestion hasn't been proposed yet. It's perhaps a bit too different from what has been proposed thus far but maybe that's exactly what's needed to convince the minds, since as far as I see it most of the parties who have an opinion on marking either assignments or lookups would at this point have changed their mind, if they were going to at all. What about declaring the identifiers that are going to be lookups in advance? Something like: match obj with some_var, something: case x, some_var: # here x binds, but some_var is a lookup I'm just throwing it out there because it occurred to me that this may solve the aesthetic issues while being clear on what identifier has what role. I'm sorry if this ends up just being more noise. ___ 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/QPZYIHDRIBTLEFWFGE3P7D5Y5EUU467Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Who is target reader of tutorial?
I think it's important to remember that many novice programmers today learn python as their first language. While i don't think the python tutorial is the right place for teaching how to program, i also think it would be best if it didn't make too many assumptions on the reader's knowledge. When it comes to the basics, assuming one already knows another language isn't very beneficial anyway, in my opinion. If all one is looking for is a table comparing a known thing with its python equivalent, there are many of those on the internet already and in much more compact form. ___ 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/AGYLMJQOWV6SQVBVT7VGEII77V4ALVT6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
Re: symbol for lookup Whatever happened to the proposal of using . as prefix? If memory serves, the main objection was about it being hard to see, but is it really? We use fixed width fonts for a reason, and there are other places a dot is quite critical (has any php programmer ever mistaken a .= for a = ?) without it's size ever causing issues. I think . is visible enough while being aesthetically inoffensive. Am i missing some problem or important past objection to it? ___ 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/CQH465FPZP3IIN2TNAZRXQKUG5XYCANI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 idea: "match case object" to represent match patterns
On 18/07/2020 11:09, Steven D'Aprano wrote: On Sat, Jul 18, 2020 at 10:58:17AM +0200, Federico Salerno wrote: We don't, after all, confuse function calls for references to a function, or vice-versa. Beginners do. Frequently. Sometimes it is quite a hurdle for them to learn to write `function()` instead of `function`. And even experienced developers sometimes forget to put parentheses after file.close, or at least we used to before context managers. (I know I did. I don't think I'm alone.) I consider myself far from being an experienced developer, but I cannot in all honesty say I'm likely to forget parens after file.close any more than after any function call. Perhaps it comes down to being used to some other language I have never worked with. I can see why beginners would find the distinction between func and func() to be challenging at first, but that is something that subsides relatively often. Most likely way before one needs to be aware of the intricacies of a complex feature such as pattern matching, considering Python, contrary to e.g. Rust or functional languages, is not built around that concept and has survived without it thus far. Pattern matching would be useful and nice, but not essential to the point that a beginner would have to learn it before getting a solid grasp on how functions are called or referenced. ___ 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/HMYPBWO2NK4GXFWMSDAFW2JBWJ3HHG2K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 idea: "match case object" to represent match patterns
On 18/07/2020 02:10, Guido van Rossum wrote:
[...] it was quickly pointed out by my co-authors that this doesn't
fly, because when the parser sees `case other_3d_point:` it doesn't
know whether you meant this as a capture pattern (binding the variable
`other_3d_point`) or as a pattern object.
This could be solved. One option would be to make pattern objects
callable, such that when you write:
my_pattern = MatchCase("something")
match stuff:
case my_pattern():
...
my_pattern() is used as a pattern object, and a single identifier like
my_pattern is interpreted, as expected by the current version of the
PEP, as a capture. I believe this is not subtle enough to be confusing
to anyone who learns the feature as a whole. We don't, after all,
confuse function calls for references to a function, or vice-versa.
Also with your proposal the compiler would not be able to tell that x,
y and z are local variables, because they are only mentioned inside
string literals.
I was hoping the implementation of MatchCase could take care of this. I
suppose it would require MatchCase to have access to locals() everywhere
it's called; would this be a problem?
___
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/4WURK7EVXC5SPZKIRACEAM32RRK2HTY5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 16/07/2020 19:00, Rhodri James wrote: On 16/07/2020 17:37, Steve Holden wrote: While I understand the point of view that says that match ... : should encapsulate a sequence of indented suites, it seems to me that match/case/case/.../else has a natural affinity with try/except/except/.../finally/else, and nobody seems to think that the excepts should be indented. Or the finally. And naturally the match/else case are at the same indentation level, just as for/else, while/else and try/finally. So why, exactly, should case be indented? [...] If we did: match: case : then having an indented section which must be a single expression would be unique in Python syntax. [...] match : case : would be the one place in Python where you end a line with a colon and **don't** indent the following line. It seems relevant to mention that before Python's unique syntax for a ternary operator (x = something if something else default_value), you would never find an if or else without a colon and an indented block, and the order (value, condition, default) is different than what is usually found in other languages (condition, value, default). That hasn't stopped Python from implementing the feature in its own way and I don't see why this PEP should be different, since Python is not other languages and match suites are not other suites. I could easily see people being confused when the slew of statements they would inevitably decide they must be able to put there, and soon we'd have cats and dogs living together and the downfall of civilisation as we know it. [...] Writers of simple formatters and the like (such as Python-mode in Emacs) would curse your name, etc, etc. Tools should adapt to the language, not the other way around. If things had to be done the way they had always been done, without any change, for fear of people not being used to it, we wouldn't even have Python at all. People learn and adapt. It seems like a small price to pay in exchange for consistency and removal of ambiguity, considering people will still have to learn the new feature one way or another. ___ 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/6KUIVENOCYIZSGXCLX6O5V3OJDIXO235/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 622 idea: "match case object" to represent match patterns
Recent discussion on the store vs. load syntax issues of PEP 622
prompted a (yet unripe) idea that could hopefully spur some progress.
What if cases required some sort of MatchCase (name pending) object
which could be preconstructed by the user if needed, but also inferred
on the fly if absent? I think an example would clarify what I mean.
Consider the following block (with & to mark "load" just for
demonstration purposes):
match some_point:
case Point(x, y, _) if x > y:
print(f"Tridimensional point with x > y")
case Point(_, _, _):
print("Some other 3D point.")
case Point(_, _y) as pt:
print(f"{pt} has y=={my_y}.")
case Point(10, _):
print("Some bidimensional point with x==10.")
case Point(_, y):
print(f"Bidimensional point with {y=}.")
case _:
print("Something else.")
This is admittedly simple enough that it wouldn't require what I'm about
to show, but it does require marking my_y in some way to prevent it from
being interpreted as a "store" identifier, or to namespace it for the
same reason. Now consider the following refactor:
3d_point = MatchCase("Point(x, y, z)")
other_3d_point = MatchCase("Point(_, _, _)")
point_with_my_y = MatchCase("Point(_, {})", my_y) # syntax with {} is
debatable.
other_2d_point = MatchCase("Point(_, y)")
match some_point:
case 3d_point if 3d_point[0] > 3d_point[1]:
# 3d_point exposes x, y, and zwith the names given
# in the declaration, as well as numerically,
# through __getitem__ or perhaps also through attributes
# like .args and .kwargs.
...
case other_3d_point:
# other_3d_point[0] through [2] are available, while
# other_3d_point["_"] == other_3d_point[2] because it's the last
# one that was given. Presumably the programmer wouldn't care
about it.
...
case point_with_my_y as pt:
# pt still exposes positional arguments like pt[0], pt[1] or
pt.args
# as well as pt["_"] (== pt[0] in this case), but pt[1] has no
# equivalent in pt.kwargs because no name was given.
...
case Point(10, _):
# Python would construct its own MatchCase here and behave as
expected.
...
case other_2d_point:
print(f"Bidimensional point with y={other_2d_point['y']}.")
case _:
...
Every case above could be constructed in the same way as in the example
without MatchCase, except for point_with_my_y, which contains a lookup:
every identifier inside the match is interpreted as "store" unless it's
namespaced; the others are included for demonstration purposes.
As seen in case Point(10, _), patterns that contain no "load"
identifiers can be written without using MatchCase instances. In effect,
its usage would be a sort of "plug-in" for when complex or verbose
functionality is needed, allowing to load identifiers or encode patterns
for readability and/or reuse through the match block.
The value of the identifiers to load would be read at MatchCase
instantiation and internally converted to a constant value.
Guard clauses could optionally be included in the MatchCase
instantiation. If both it and the case: provide guards, they are anded
together.
If deemed appropriate, a special meaning could be given to MatchCase()
(no arguments, or with "" or even any falsy value as argument) to
represent the default case to appease those who don't like _.
Note that the above examples assume at least _ (and possibly any
identifier) can be repeated. My proposed MatchCase idea is compatible
with the possibility of disallowing repeated identifiers, while still
allowing them in MatchCase()'s first argument with the behaviour seen in
the other_3d_point case.
The constructor MatchCase could be either provided as a builtin or in a
stdlib module that must be imported. I think the latter would be more
reasonable.
Any specific syntax or name presented above (MatchCase, the {}s in its
first argument, the names of the MatchCase.args and MatchCase.kwargs
attributes) is debatable.
I hope I haven't missed any important point that would make the above
demonstration invalid. Any thoughts?
___
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/DDYISJOZPJOD2C2RY4HH2XS3YMHBVYWX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 13/07/2020 19:17, Guido van Rossum wrote: I find it debatable that we should have this at all, since there are other interpretations possible, and honestly I doubt that it’s a common use case. That’s why we’re holding off. Fair enough. All it would do would be save code in a guard condition after all. Thanks for offering, but we’ve got that under control. I wasn't trying to imply otherwise. :) ___ 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/UABDA4IMDLUT63VHDUM5XGEAAZPI7EOC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 13/07/2020 12:28, Henk-Jaap Wagenaar wrote: No, that would not be impossible but fraught with problems. This is discussed in the PEP: https://www.python.org/dev/peps/pep-0622/#algebraic-matching-of-repeated-names The PEP goes into no detail of what these problems (or "number of subtleties") are, but it does mention how we decided to make repeated use of names within the same pattern an error; we can always relax this restriction later without affecting backwards compatibility which does hint at the fact that the problems are not insurmountable hurdles. All in all not an urgent feature, but it would be nice to have from the get-go if there is agreement and it is doable. @PEP authors: Incidentally, I am eager to start contributing and see this PEP advance—if there's anything I can do, including possibly non-code "dirty work" please let me know. I was thinking of collecting all the objections and points of contention of the PEP and the current progress on each in one place so that the pros and cons can be evaluated more clearly. Would that be useful? ___ 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/74CJSU6RP7OJUIN5ERMT3I3HNPQQKCWM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 13/07/2020 00:20, Guido van Rossum wrote: The need for a wildcard pattern has already been explained -- we really want to disallow `Point(x, y, y)` but we really need to allow `Point(z, _, _)`. Generating code to assign the value to `_` seems odd given the clear intent to *ignore* the value. Would it be impossible for the parser to interpret Point(x, y, y) as "the second and third arguments of Point must have the same value in order to match. Bind that value to y"? Since the value has to be the same, it doesn't matter whether y binds to the first or the second (or the nth) instance of it. That said, in time and with all the arguments brought to the table, I personally came to accept special-casing _, although I don't especially like it. From my point of view, the biggest issue to solve is the load vs. store decision and its syntax. ___ 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/WE5CQOFDLKYN7WUNBFJ5LMQ5P7X2SF5M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 12/07/2020 11:38, Larry Hastings wrote: In that case, I'd like to make a specific pitch for "don't make '_' special". (I'm going to spell it '_' as it seems to be easier to read this way; ignore the quotes.) IIUC '_' is special in two ways: 1) we permit it to be used more than once in a single pattern, and 2) if it matches, it isn't bound. If we forego these two exceptions, '_' can go back to behaving like any other identifier. It becomes an idiom rather than a special case. Drilling down on what we'd need to change: To address 1), allow using a name multiple times in a single pattern. 622 v2 already says: [...] If we relax it now, then we don't need '_' to be special in this way. All in all this part seems surprisingly uncontentious. To address 2), bind '_' when it's used as a name in a pattern. This adds an extra reference and an extra store. That by itself seems harmless. The existing implementation has optimizations here. If that's important, we could achieve the same result with a little dataflow analysis to optimize away the dead store. We could even special-case optimizing away dead stores /only/ to '_' and /only/ in match/case statements and all would be forgiven. Folks point out that I18N code frequently uses a global function named '_'. The collision of these two uses is unfortunate, but I think it's survivable. I certainly don't think this collision means we should special-case this one identifier in this one context in the /language/ specification. Consider: * There's no installed base of I18N code using pattern matching, because it's a new (proposed!) syntax. Therefore, any I18N code that wants to use match/case statements will be new code, and so can be written with this (admittedly likely!) collision in mind. I18N code could address this in several ways, for example: o Mandate use of an alternate name for "don't care" match patterns in I18N code, perhaps '__' (two underscores). This approach seems best. In keeping with this change, I additionally propose removing '*_' as a special token. '*_' would behave like any other '*identifier', binding the value to the unpacked sequence. Alternately, we could keep the special token but change it to '*' so it mirrors Python function declaration syntax. I don't have a strong opinion about this second alternative. +1 to everything One consideration: if you /do/ use '_' multiple times in a single pattern, and you /do/ refer to its value afterwards, what value should it get? Consider that Python already permits multiple assignments in a single expression: (x:="first", x:="middle", x:="last") After this expression is evaluated, x has been bound to the value "last". I could live with "it keeps the rightmost". I could also live with "the result is implementation-defined". I suspect it doesn't matter much, because the point of the idiom is that people don't care about the value. I'd expect it to bind to the last one. If that's in any way problematic, in order to prevent oblivious misuse, referencing an identifier that was bound more than once should raise an exception. But as you say, it doesn't really matter. ___ 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/ZKW6AOZIYPTCTIQLFZ6L37JXTZKTAYVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python-Dev Digest, Vol 204, Issue 75
On 11/07/2020 19:29, Jim J. Jewett wrote: To me, "else:" has a slightly different meaning than "case _:" case _: essentially a default, ensuring that the match logic is complete. else: OK, the subject of this match failed, here is our fallback logic. Whether this distinction is important enough to express in code is another question, as is whether or not anyone but me would follow this "obvious" convention. So I'm not convinced the difference justifies the existence a second syntax. But I'm also not sure it doesn't, particularly if that distinction were given in the PEP and in documentation for the match statement. -jJ Could you construct two examples to prove behaviour would be different between the two? To me the two meanings seem too similar to make a difference in code. On 12/07/2020 00:31, Guido van Rossum wrote: Hm... Just the fact that people have been arguing both sides so convincingly makes me worry that something bigger is amiss. I think we're either better off without `else` (since the indentation of `case _` cannot be disputed :-), or we have to revisit the reasons for indenting `case` relative to `match`. As MRAB said, it's a case of picking the least inelegant one. Let me add that the parser can easily deal with whatever we pick -- this is purely about human factors. That is a good point. I don't think there would be any particular objection to allowing one case to catch anything that wasn't caught before—the issue is with making _ (or any other particular symbol) special for the occasion, or at the very least none of those proposed thus far has been universally accepted. Was anything beside _ and ... proposed? What if case object(): or case any: did that instead? The former is already used to a similar meaning in the context of a match block, the latter would be very obvious to any reader and, since it's already a builtin, few would think shadowing it for use as a store-identifier would be a good idea. On 11/07/2020 21:13, Eric Nieuwland wrote: This could also resolve the discussion on indentation of the ‘case’ parts and the placement of the default matching: match [as ]: case []: … [else: ] within the preparation statements it would then be allowed to use undefined variables as receivers of matched parts. This is intriguing, but I do share Greg Ewing's doubt: what happens if you need no preparation? Personally I'd accept if the line could be omitted altogether, but I understand many others are opposed to having the line following a colon be indented at the same level, and likewise I don't think the idea of having to write pass (or ...) explicitly when no preparation is needed will be well received. ___ 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/MMDXSHHLM6CI3S6TFTCI3VLES3N2RLAS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 11/07/2020 00:57, Paul Sokolovsky wrote:
The PEP itself in "rejected" ideas makes an argument against it:
indented stuff after a line ending with ":" must be a *statement*. It
would be totally nuts for that to be something else, e.g. an expression:
Good point.
That of course leads us to the obvious idea:
match a: case 1: ... case 2: ... else: ... Of course, PEP
smartly has an argument against that too, in the vein of "after line
ending with ':', there should be an indent suite (list of
statements)". But that's where it goes sideways.
Exactly. I think not identing what comes after match a: comes with far
more advantages than disadvantages. In fact, if the only "real" issue is
that anything after : must be indented, I'd say it is vastly outweighed
by the issues not doing it would solve.
Would the parser allow us to write the above without the colon, thus
avoiding the aforementioned objection?
And if the above snippet looks weird to anybody, it's only because of
all the "case" business. There wouldn't be such a problem if it was
instead: match a: | 1: ... | 2: ... |: ... The above
ML-like syntax should be perfect for almost everyone, ... except the
PEP authors, because they have it in "rejected ideas" either.
I don't know, that doesn't look very pythonic based on the preference
Python makes for words over symbols. I don't think there's any problem
with using case, it's the expectations many have for what should come
around it that creates issues.
On 11/07/2020 12:49, Greg Ewing wrote:
I can't think of one at the moment, but I don't think you
should dismiss tradition so easily.
I don't mean to dismiss it, but I wouldn't want it to get in the way of
a change if there are good reasons to go against tradition. This seems
like one of these cases to me.
One of the arguments used
to justify significant indentation in Python is that "you're
going to indent it for readability anyway, so the compiler
might as well take notice of it".
For the most part, Python indentation follows what people
would naturally do even if they didn't have to. So I think it's
worth looking at what people typically do in other languages
that don't have mandatory indentation.
[...]
or like this:
switch (x) {
case 1:
...
case 2:
...
default:
...
}
This suggests to me that most people think of the cases as being
subordinate to the switch, and the default being on the same level
as the other cases.
I think that last one would be perceived as ok if it weren't for the
brackets: everyone naturally indents any set of brackets' contents. I
wouldn't normally mind cases being indented extra relative to "match" if
not for two points:
1. Python relies heavily on indentation. It's likely for a match block
to appear in a place that is already well indented, *and* it is also
likely to often include further levels of indentation. It would be
preferable not to require two levels at a minimum every time a match
block is needed.
2. Unless the default case is signalled with an ad-hoc keyword like
default (which I personally would like), it seems a wildcard symbol like
the controversial _ is needed to pair with case. Going against tradition
and setting only one indentation level would solve this issue, while
still allowing (I think) any programmer to indent the default case extra
if they so wish.
If none of this is convincing, I do believe the matter is easier than it
appears, because few would be confused by else being at the same level
as each other case.
Alternatively, what if (gasp!) both were allowed as synonyms? I'm sure
one of the two would eventually settle as conventional, and there is no
possible ambiguity. I know it goes against the "one obvious way to do
it" precept but it's clear that there is no obvious way here at all, so,
¿porque no los dos?
___
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/2U3DRD7R244V7SQ24WRUM34SENA3P5US/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 10/07/2020 12:33, Greg Ewing wrote: A thought about the indentation level of a speculated "else" clause... Some people have argued that "else" should be at the outer level, because that's the way it is in all the existing compound statements. However, in those statements, all the actual code belonging to the statement is indented to the same level: if a: elif b: else: ^ | Code all indented to this level But if we were to indent "else" to the same level as "match", the code under it would be at a different level from the rest. match a: case 1: case 2: else: ^ ^ | | Code indented to two different levels This doesn't seem right to me, because all of the cases, including the else, are on the same footing semantically, just as they are in an "if" statement. I feel all those who aren't directly arguing against it are working off the assumption that it is needed for match and case to have different levels of indentation, but is this really true? Is there anything (bar tradition or other subjective arguments) that speaks in favour of this, especially in light of the fact that having the same indentation level would also solve other problems? A few emails ago I proposed something like this (and I'm probably only the last one to do so amongst many), but if anyone made an argument against it I must have missed it: match: a case 1: ... case 2: ... else: ... (The a on a separate line being arguable.) I think it would look neater, be reminiscent of the if/elif/else syntax we're all familiar with, and solve the issue of where to indent the else. ___ 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/6B45E57SNMHDH4EYOAXCBPJRNIE6SAVR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 09/07/2020 01:27, Ethan Furman wrote: On 07/08/2020 10:44 AM, Ethan Furman wrote: So namespaced variables only... is there a recommendation on handling global() and local() type variables? Okay, some off-list discussion clarified that for me: - easiest way is to use a guard ``` def foo(x, spam): match x: case Point(p, q, context=c) if c == spam: # Match ``` I like this one. Doesn't it also solve the issue of store vs. load? Everything is stored but the guard clause can look-up. ___ 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/NSO2QZ7DSLREPJL5OJCSZTUWWXREM76S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 08/07/2020 12:30, Rhodri James wrote: Any name used as a pattern is a catch-all. The only difference between "case dummy:" and "case _:" is that "_" doesn't bind to the thing being matched, but "dummy" does bind to it. I meant catch-all as in "case _:" (or "else:"). I apologise for the lack of clarity. On 08/07/2020 17:02, Guido van Rossum wrote: There’s one other issue where in the end we could be convinced to compromise: whether to add an `else` clause in addition to `case _`. In fact, we probably would already have added it, except for one detail: it’s unclear whether the `else` should be aligned with `case` or `match`. If we are to add this we would have to ask the Steering Council to decide for us, as the authors deadlocked on this question. Thanks for the write-up. What were the arguments in support of aligning else with case? I expect it has to be with aesthetics, but for what concerns semantics, it seems to me that "match...else", interpreted as "no match was found" would make the most sense; aligning it with case would look like the else has to do with whatever case was last. Unless both match and all cases are on the same indentation level. Here an example: match: variable case "some constant": # ... case x if x == guard_clause: # ... else: # ... I know at least Elm indents the match variable on a separate line. On 08/07/2020 19:44, Tim Peters wrote: One microscopic point: [Guido] ... (if `.x` is unacceptable, it’s unclear why `^x` would be any better), As Python's self-appointed spokesperson for the elderly, there's one very clear difference: a leading "." is - literally - one microscopic point, all but invisible. A leading caret is far easier to see, on a variety of devices and using a variety of fonts. Indeed, I missed the leading dot in ".x" in your email the first two times I read that sentence. But a caret is harder to type. So here's an off-the-wall idea: use an ellipsis. If you're still using a maximal-munch lexer, ellipsis followed by an identifier is currently a syntax error. "...x" is far easier to see than ".x', easier to type than "^x", and retains the mnemonic connection that "something is a named load pattern if and only if it has dots". +1 on a simple dot being hard to see. Alternative idea: if we really ought to have a mark for references¹, why not use the & symbol, which already signifies something like "reference" in C(++) and Rust? ¹: I know marking "store" instead of "load" has been suggested before; I'm still on the fence on which I prefer but I would even accept marking both (with = and == respectively, for example). ___ 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/YH3SXITYAAPEVD4RKH6OPSWWJZEHGGC3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup
On 07/07/2020 16:31, Henk-Jaap Wagenaar wrote: I used to be in this "camp", however, a (I think valid) point was raised that "else:" is not a (full) alternative. Due to the restriction on repeated names (e.g. Point(x, x) is illegal), if you want to "throw away" intermediate matches, you will have to either have to come up with new names (Point(unused_1, unused_2)) or use the "_" as currently instituted (Point(_, _)) and "else:" does not cover that insofar as I can tell. Personally I think using _ as throwaway name is perfectly fine, as it is in the rest of Python. The only exception would then be that _ is allowed to be repeated, whereas other identifiers aren't. I'd be ok with that. What I don't like is the use of _ as catch-all, which is different and not interdependent with its use as throwaway. On 08/07/2020 07:26, Steven Barker wrote: To sum up, I feel like using constructor and keyword-argument syntax to access attributes is an abuse of notation. I'd much prefer a new syntax for matching classes and their attributes that was not so likely to be confusing due to imperfect parallels with class construction. +1 Ideally something like Datetime.year=x would be in my opinion clear at a glance (and reference vs. assignment could be accomplished simply by having == for reference and = for assignment), but it's problematic when it comes to mentioning multiple attributes. A couple ideas: 1. Datetime[year=x, months==3, days==SOME_CONST] 2. (Datetime.year=x, months==3, days==SOME_CONST) 3. Datetime.year=x .months==3 .days==SOME_CONST 4. Datetime.year=x, .months==3, .days==SOME_CONST With no class, this would perhaps favour usage of = and/or == before names to resolve the reference vs. assignment dispute. ___ 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/NGETVO36VD2ECR7Z7F5LYDUP62RRFKVU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622
On 03/07/2020 21:55, Rob Cliffe wrote:
I don't like the .name syntax (grit on Tim's monitor; does not
suggest the meaning). Nor am I keen on "expressions" being
interpreted differently after 'case' than elsewhere in Python. But I
don't know what syntax (where necessary) to suggest.
I'm not keen on special treatment of the '_' variable, and would
prefer to be able to use 'else:' after 'match'.
+1
I think using else would be sensible since it has similar behaviour in
the rest of Python and it would immediately make sense to anyone seeing
the syntax for the first time (provided they understood what the rest of
the match block does).
If objections were moved against it I seem to have missed them (in my
defence, the discussion on PEP622 has been quite fragmented and I
haven't been on this list for very long).
I also don't like the .name syntax and for what little it's worth, I
personally would have a hard time getting used to it if it were adopted.
Has anyone proposed introducing ` ` quotes for this purpose? They could
enclose references without ambiguity and could even be used elsewhere in
Python to enclose identifiers, for example to allow spaces and symbols
in them (which I wouldn't regard as particularly good style, but it may
still come in handy). They are used in MySQL, bash and Markdown to
enclose expressions or identifiers, so I feel no experienced programmer
would have a hard time wrapping their head around it. Though I'd
understand if it were problematic for Python's parser.
Another option would be to wrap references in {} in a similar way to
what happens in fstrings.
Another option still could be to wrap references in quotes, like
strings, and require use of str("some string") to catch literal strings,
but I don't know if I like this myself.
Either way, I seem to prefer symmetric marks to signal references; I
don't know if anyone else shares this sentiment.
___
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/QJ7ET7V4YLLUL7YVZZWVRFHPP4L3WZPH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 (match statement) playground
+1
Is there a reason, after all, why we should mark constant patterns as
special, and not the opposite?
On 02/07/2020 19:10, Walter Dörwald wrote:
On 1 Jul 2020, at 18:54, Brandt Bucher wrote:
Walter Dörwald wrote:
This looks strange to me. In all other cases of variable lookup the
global variable z would be found.
The next case assigns to z, making z local to whereis. This is
consistent with python's existing scoping rules (for example, try
rewriting this as the equivalent if-elif chain and you'll get the
same error). It sounds like you want to add "global z" to the top of
the function definition.
whereis(23) however works.
This branch is hit before the unbound local lookup is attempted.
OK, understood.
However I still find the rule "dotted names are looked up" and
"undotted names are matched" surprising and "case .constant" ugly.
A way to solve this would be to use "names at the top level are always
looked up".
With this the constant value pattern:
case .name:
could be written as:
case name:
The capture pattern (of which there can only be one anyway) could then
be written as:
case object(name):
instead of
case name:
Or we could use "matches are always done against a match object", i.e.
the code from the example would look like this:
from dataclasses import dataclass
@dataclass
class Point:
x: int
y: int
z = 42
def whereis(point):
w = 23
match point as m:
case Point(0, 0):
print("Origin")
case Point(0, m.y):
print(f"Y={m.y}")
case Point(m.x, 0):
print(f"X={m.x}")
case Point():
print("Somewhere else")
case w:
print("Not the answer")
case z:
print("The answer")
case object(z):
print(f"{z!r} is not a point")
Servus,
Walter
___
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/BEKMYROEF4E3LXONFU37TDKNWGI6NO4S/
Code of Conduct: http://python.org/psf/codeofconduct/
