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.

> 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/F2XIFAHOS56EIPFVGUDOSJDGXRC6LG3B/
Code of Conduct: http://python.org/psf/codeofconduct/