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