Yeah, that's it exactly.
I see these two features - `_` as a joker in `match` statements and
`_`as the last value produced by a shell - as incompatible, because you
have to account for interferences between them, or face unexpected
behaviors in code you run.
I expect people to code like I do : first experiment a feature in a
shell, then write a clean script that implements it cleanly. To debug
that script, go back to the shell to run the script bit by bit, etc, etc.
You'd expect code that runs in a shell to behave the same in a script,
and vice-versa. But, if `_` is both a variable (shell) and a keyword
(`match`), that 's not the case. You have to work around the problem,
e.g. by reaffecting `_`.
My fear is that most people (me included) will most likely forget this
step when switching between a shell and a script.
Le 02/06/2021 à 15:48, Damian Shaw a écrit :
> The question is even more pressing in REPL, since there /is/
necessarily such a variable !
To clarify, your concern is that someone wants to use the match
statement in the REPL and use "_" to match against the last return
without needing to workaround with something like "last = _" and then
matching against "last"?
On Wed, Jun 2, 2021 at 9:30 AM Alexis Masson <a.masson...@ntymail.com
<mailto:a.masson...@ntymail.com>> wrote:
Hey everyone,
I meant to say, I agree with the two of you, actually. `_` as a
variable name is terrible, but it /can/ be used all the same ; on
the other hand, wildcards should not be legitimate variable names,
to prevent misunderstandings / accidents / bugs.
Had I taken part in the discussion aroud pattern matching, I would
have liked the `else` syntax better : having a special syntax for
special cases seems clearer, cleaner, and safer.
Another option that comes to mind is using `*` as the wildcard.
There is already a precedent for using `*` alone, e.g. in `import`
statements. In this case, it means "import everything from this
module", as opposed to listing the items you need. I can easily
see the parallel with `match` statements, thus making it intuitive
to learn and use this new syntax.
Anyway, yes, `_` as joker has flaws, the biggest one being to be a
resolvable variable name ; what is the expected behaviour when
running a script that has (even accidentally) a viariable named
`_` ? The question is even more pressing in REPL, since there /is/
necessarily such a variable !
I guess it's too late to change anything, though, so we'll have to
get used to it...
From https://docs.python.org/3.10/whatsnew/3.10.html
<https://docs.python.org/3.10/whatsnew/3.10.html>:
def http_error(status):
match status:
case 400:
return "Bad request"
case 404:
return "Not found"
case 418:
return "I'm a teapot"
case _:
return "Something's wrong with the Internet"
The wildcard idea looks just wrong and confusing. What if I want
to use it as a variable and match against it like _ = 504? This
is how it should be done:
def http_error(status):
_ = 504
match status:
case 400:
return "Bad request"
case 404:
return "Not found"
case 418:
return "I'm a teapot"
case _:
return "Gateway Timeout"
else:
return "Something's wrong with the Internet"
Don't do that.
There is a very strong convention in Python that a single underscore is
to be used for two purposes (and a third in the interactive interpreter
only):
(1) For "don't care" variables; anything that you don't care about and
aren't intending to use should be named `_`.
first, *_, last = sequence
This tells me that I am only using the first and last items, everything
else is ignored.
(2) For internationalisation. This is a convention that comes from other
languages, but it is so widespread that we're kinda stuck with it.
print(_("Try again."))
By convention, the underscore function is used to translate messages
into the current location's language.
(3) And in the interactive interpreter, underscore is a special variable
which captures the previous result. This doesn't work in scripts.
>>> 5 + 4
9
>>> _*10
90
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
<mailto:python-ideas@python.org>
To unsubscribe send an email to python-ideas-le...@python.org
<mailto:python-ideas-le...@python.org>
https://mail.python.org/mailman3/lists/python-ideas.python.org/
<https://mail.python.org/mailman3/lists/python-ideas.python.org/>
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/F2XIFAHOS56EIPFVGUDOSJDGXRC6LG3B/
<https://mail.python.org/archives/list/python-ideas@python.org/message/F2XIFAHOS56EIPFVGUDOSJDGXRC6LG3B/>
Code of Conduct: http://python.org/psf/codeofconduct/
<http://python.org/psf/codeofconduct/>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2ETC53YTKUOJKLA5GGXQDFH7UGX35ANJ/
Code of Conduct: http://python.org/psf/codeofconduct/
