[issue45323] unexpected behavior on first match case _
Joël Bourgault added the comment: Complement: the Python tutorial presents the "magic _" in the following section, close to its end: https://docs.python.org/3/tutorial/introduction.html#numbers > In interactive mode, the last printed expression is assigned to the variable > _. -- ___ Python tracker <https://bugs.python.org/issue45323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45323] unexpected behavior on first match case _
Change by Joël Bourgault : -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker <https://bugs.python.org/issue45323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45323] unexpected behavior on first match case _
Joël Bourgault added the comment: I obtain the reported behaviour using `python -m doctests .md` in a Gitlab pipeline, so it is likely that the execution is similar to the Python interpreter. Therefore, I am satisfied by your answer, so I close this 'bug'; thanks a lot! Now, about the fact that `x` is assigned when matched even if "guarded-out" afterwards: this is exposed in the tutorial, so I consider this to be the expected behavior; see last sentence of https://www.python.org/dev/peps/pep-0636/#adding-conditions-to-patterns. Note: I discovered the observed behavior while writing a presentation, sourced in a markdown file and then rendered as a RevealJS presentation, visible here (French): https://poles.pages.forge.kaizen-solutions.net/pole-python/pr-sentations/python-structural-pattern-matching. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45323] unexpected behavior on first match case _
New submission from Joël Bourgault :
While testing the `match...case` construction, I get the following behavior
with Docker image Python 3.10 rc2-slim:
```python
>>> match "robert":
... case x if len(x) > 10:
... print("long nom")
... case [0, y]:
... print("point à x nul")
... case _:
... print("nothing interesting")
...
nothing interesting
>>> x # assigned, since matched, even if 'guarded-out'
'robert'
>>> y # not assigned, because not matched
Traceback (most recent call last):
...
NameError: name 'y' is not defined
>>> _ # normally not assigned, but we get a value??
'robert'
>>> del _ # but the variable does not even exist!?!?!?
Traceback (most recent call last):
...
NameError: name '_' is not defined
```
Moreover, if we continue working in the same session by assigning `_`
explicitly and playing with `case _`, we don't get any weird behavior anymore,
and `_` behaves as a normal variable.
So it seems to me that there is some weird corner case here, that should be
adressed.
--
messages: 402884
nosy: ojob
priority: normal
severity: normal
status: open
title: unexpected behavior on first match case _
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue45323>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
