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 `_`.

But the discrepancy here is not the match statement, it's that "_" in REPLs doesn't behave like "_" in a script, if you are copying and pasting REPL code to a script this is something you already need to take into account. Also because REPLs have this feature only when the user doesn't bind to the name "_":

...

...

5 * 2 10 _ 10 _ = 5 5 * 2 10 _ 5

If the match statement didn't treat "_" as slightly special and bound the match to "_" then it would break this feature of REPLs. (apologies for mucking up the email addresses previously) On Wed, Jun 2, 2021 at 11:35 AM Alexis Masson <a.masson555@ntymail.com> wrote:

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.masson555@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:

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 To unsubscribe send an email to python-ideas-leave@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/F2XIFA... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/2ETC53... Code of Conduct: http://python.org/psf/codeofconduct/

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 `_`.

But the discrepancy here is not the match statement, it's that "_" in REPLs doesn't behave like "_" in a script, if you are copying and pasting REPL code to a script this is something you already need to take into account. Also because REPLs have this feature only when the user doesn't bind to the name "_":

...

...

5 * 2 10 _ 10 _ = 5 5 * 2 10 _ 5

If the match statement didn't treat "_" as slightly special and bound the match to "_" then it would break this feature of REPLs. (apologies for mucking up the email addresses previously) On Wed, Jun 2, 2021 at 11:35 AM Alexis Masson <a.masson555@ntymail.com> wrote:

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.masson555@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:

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 To unsubscribe send an email to python-ideas-leave@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/F2XIFA... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/2ETC53... Code of Conduct: http://python.org/psf/codeofconduct/