_ should be reassigned after command execution

[ngudbhav]

Bug report

Bug description:

This is a snippet from the python REPL.

>>> "abc"
'abc'
>>> _
'abc'
>>> _ = "bcf"
>>> _
'bcf'
>>> "abc"
'abc'
>>> _
'bcf'
>>> ››

Python allows overriding _ as a variable. If this is overridden, there seems to be no way to return to the previous default behaviour. If there is, please correct and suggest.

CPython versions tested on:

3.12

Operating systems tested on:

macOS

[donBarbos]

I think this looks like expected behavior.

If _ cannot be redefined then it will not be possible to use as a variable, and this is a common usage scenario for example when unpacking.
People often use this as a variable, and if we can't use it as a variable then the user code will not work correctly

[picnixz]

If this is overridden, there seems to be no way to return to the previous default behaviour. If there is, please correct and suggest

I think this is the expected behavior because if you explicitly define _, then the REPL doesn't know whether this was intended or not so it cannot use it as its output variable. Have you tried del _ just to see if this helps? (I haven't tested it).

[ngudbhav]

@picnixz, Thanks. del seems to work correctly in Python REPL but throws an error in the IPython kernel. Maybe I should raise an issue with them. There, it says that the variable is not defined.

@donBarbos, I am aligned. So, the same operator _ serves 2 purposes. One as a variable in the code, and the other to denote the last output in the REPL environment.

1. Is there any way to point to the built-in _ instead of the variable _ (apart from the del)?
2. I am trying to compare this with Ruby's behaviour, which may not be correct as every language is unique. In the Ruby REPL, even if you define _, printing _ will give you the last output. In other words, it is not possible to use _ as a variable.
3. Some linters also suggest using _ would essentially mean that you do not want to use the output.

[picnixz]

Some linters also suggest using _ would essentially mean that you do not want to use the output.

_ can also be used when using gettext

throws an error in the IPython kernel

I think this should be reported to IPython.

Is there any way to point to the built-in _ instead of the variable _ (apart from the del)?

AFAIK, no; and I don't think we should do it on our side.

[ngudbhav]

Thanks for the reply, @picnixz. My concern is that _ loses its significance in REPL when it is used as a variable. Feel free to close this issue if you think this is not something planned or ideal.

[picnixz]

I actually digged into the code and it's not a REPL stuff actually. On Python 3.6 (which has the old REPL) we have:

Python 3.6.15 (default, Sep 23 2021, 15:41:43) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> __builtins__._
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'builtins' has no attribute '_'
>>> 1
1
>>> __builtins__._
1

In particular, the "last" value is actually stored at the builtins level and not just at the REPL level. I'm afraid changing this would be much more complex =/

Note: this has probably something to do with sys.displayhook:

$ python3 -c 'import sys; import builtins; sys.__displayhook__(3); print(builtins._)'
3
3

This is tested here:

cpython/Lib/test/test_sys.py

Lines 45 to 60 in 844596c

	def test_original_displayhook(self):
	dh = sys.__displayhook__
	with support.captured_stdout() as out:
	dh(42)
	self.assertEqual(out.getvalue(), "42\n")
	self.assertEqual(builtins._, 42)
	del builtins._
	with support.captured_stdout() as out:
	dh(None)
	self.assertEqual(out.getvalue(), "")
	self.assertTrue(not hasattr(builtins, "_"))

[picnixz]

cc @pablogsal for confirmation that we wouldn't change this in Python

I have also a question: one could say that _ = ... should assign _ to the global namespace but not to the builtins namespace itself. Namely, it should accessible as a global variable but not as a builtin one. IOW, _ should first be looked up in the global namespace before being looked up on __builtins__, so that the "last" value can still be accessed through __builtins__._ instead. But I think it's a bit of an overcomplication and I don't know if this wouldn't break stuff.

[pablogsal]

cc @pablogsal for confirmation that we wouldn't change this in Python

From the REPL maintainance point of view I don't see any reason why we would. IF we were to change this it needs to be treated like a new feature (which is / may be)a breaking change and therefore my opinion would be one among many (in the sense that no matter what I particulary think, this needs to be decided colletively).