{"version":"https:\/\/jsonfeed.org\/version\/1","title":"mathspp.com feed","home_page_url":"https:\/\/mathspp.com\/blog\/tags\/repl","feed_url":"https:\/\/mathspp.com\/blog\/tags\/repl.json","description":"Stay up-to-date with the articles on mathematics and programming that get published to mathspp.com.","author":{"name":"Rodrigo Gir\u00e3o Serr\u00e3o"},"items":[{"title":"TIL #139 \u2013 Multiline input in the REPL","date_published":"2026-03-02T15:15:00+01:00","id":"https:\/\/mathspp.com\/blog\/til\/multiline-input-in-the-repl","url":"https:\/\/mathspp.com\/blog\/til\/multiline-input-in-the-repl","content_html":"

Today I learned how to do multiline input in the REPL using an uncommon combination of arguments for the built-in open<\/code>.<\/p>\n\n

A while ago I learned I could use open(0)<\/code> to open standard input<\/a>.\nThis unlocks a neat trick that allows you to do multiline input in the REPL:<\/p>\n

>>> msg = open(0).read()\nHello,\nworld!\n^D\n>>> msg\n'Hello,\\nworld!\\n'<\/code><\/pre>\n
The cryptic ^D<\/code> is Ctrl<\/kbd>+D<\/kbd>, which means EOF on Unix systems.\nIf you're on Windows, use Ctrl<\/kbd>+Z<\/kbd>.<\/p>\n
The problem is that if you try to use open(0).read()<\/code> again to read more multiline input, you get an exception:<\/p>\n
OSError: [Errno 9] Bad file descriptor<\/code><\/pre>\n
That's because, when you finished reading the first time around, Python closed the file descriptor 0<\/code>, so you can no longer use it.<\/p>\n
The fix is to set closefd=False<\/code> when you use the built-in open<\/code>.\nWith the parameter closefd<\/code> set to False<\/code>, the underlying file descriptor isn't closed and you can reuse it:<\/p>\n
>>> msg1 = open(0, closefd=False).read()\nHello,\nworld!\n^D\n>>> msg1\n'Hello,\\nworld!\\n'\n\n>>> msg2 = open(0, closefd=False).read()\nGoodbye,\nworld!\n^D\n>>> msg2\n'Goodbye,\\nworld!\\n'<\/code><\/pre>\n
By using open(0, closefd=False)<\/code>, you can read multiline input in the REPL repeatedly<\/em>.<\/p>","summary":"Today I learned how to do multiline input in the REPL using an uncommon combination of arguments for the built-in open.","date_modified":"2026-03-02T16:21:46+01:00","tags":["repl","programming","python"],"image":"\/user\/pages\/02.blog\/04.til\/139.multiline-input-in-the-repl\/thumbnail.webp"},{"title":"TIL #123 \u2013 The appearing built-in","date_published":"2025-05-06T22:45:00+02:00","id":"https:\/\/mathspp.com\/blog\/til\/the-appearing-builtin","url":"https:\/\/mathspp.com\/blog\/til\/the-appearing-builtin","content_html":"
Today I learned that the module builtins<\/code> grows dynamically in the REPL.<\/p>\n\n
The appearing built-in<\/a><\/h2>\n
After some back and forth on BlueSky<\/a>, I tripped on some funky behaviour in the REPL:<\/p>\n
## Fresh new REPL, Python 3.13:\n>>> import builtins\n>>> len(dir(builtins))\n159\n>>> len(dir(builtins))\n160\n>>> len(dir(builtins))\n160<\/code><\/pre>\n
What the heck is going on?\nWhy did the module builtins<\/code> grow in size between the two calculations?!<\/p>\n
I restarted the REPL and tried something else:<\/p>\n
## Fresh new REPL, Python 3.13:\n>>> import builtins\n>>> print(dir(builtins))\n[ ... ]\n>>> print(dir(builtins))\n[ ... ]<\/code><\/pre>\n
I printed the contents of the module builtins<\/code> twice in a row and they were exactly the same...\nThen, I checked, and the length of the module builtins<\/code> was still 159:<\/p>\n
>>> len(dir(builtins))\n159<\/code><\/pre>\n
But then I checked again, and it grew again:<\/p>\n
>>> len(dir(builtins))\n160<\/code><\/pre>\n
For a second I was left wondering what sort of magic trick the built-in len<\/code> must be playing, since it looks like it's making the module builtins<\/code> grow another member...\nBut then I printed the contents of the module again and I found the culprit after using a text diff tool online:<\/p>\n
A screenshot of a text diff comparison where the text on the right shows that the name \"_\" is new.
The name `_` appears magically.<\/figcaption><\/figure>\n
That's when it hit me: the REPL has a special name _<\/code> that refers to the result of the last operation<\/a>.<\/p>\n
Importing the module isn't enough to make it show up because it's a statement and statements don't produce a value.\nSimilarly, the code print(dir(builtins))<\/code> also isn't enough because printing \u201cdoesn't return a result\u201d, but when I run len(dir(builtins))<\/code>, the length is saved in _<\/code>.<\/p>\n
But why is this variable in the module builtins<\/code> if other variables aren't..?<\/p>\n
I am not entirely sure, but my guess is that this special _<\/code> isn't a regular variable!\nYou can assign to _<\/code> and it will \u201coverwrite\u201d the other value:<\/p>\n
## Fresh new REPL:\n>>> 1 + 2\n3\n>>> _\n3\n>>> _ = 73\n>>> print(_)\n73<\/code><\/pre>\n
But it's not really overwriting the previous value...\nIt's actually shadowing the other one!\nHere's proof:<\/p>\n
## Fresh new REPL:\n>>> 1 + 2\n3\n>>> _\n3\n>>> _ = 73\n>>> print(_)\n73\n>>> import builtins\n>>> builtins._\n3\n>>> globals()[\"_\"]\n73<\/code><\/pre>\n
Fun, right?<\/p>","summary":"Today I learned that the module `builtins` grows dynamically in the REPL.","date_modified":"2025-10-20T22:34:56+02:00","tags":["programming","python","repl"],"image":"\/user\/pages\/02.blog\/04.til\/123.the-appearing-builtin\/thumbnail.webp"},{"title":"TIL #103 \u2013 debugging the new Python REPL with trace and PYREPL_TRACE.","date_published":"2024-07-13T19:00:00+02:00","id":"https:\/\/mathspp.com\/blog\/til\/debugging-the-new-python-repl-with-trace-and-pyrepl-trace","url":"https:\/\/mathspp.com\/blog\/til\/debugging-the-new-python-repl-with-trace-and-pyrepl-trace","content_html":"
Today I learned how to debug the new Python REPL with _pyrepl.trace<\/code> and the environment variable PYREPL_TRACE<\/code>.<\/p>\n\n
Debugging the new Python REPL with trace<\/code> and PYREPL_TRACE<\/code>\n<\/a><\/h2>\n
As of Python 3.13, the Python REPL is written in Python<\/em>.\nThis means that if you are debugging the REPL and add a call to print<\/code> in the code for the REPL, and then run the REPL, the debugging prints will show up in the REPL, in the middle of the thing you are trying to debug.\nThis can get quite confusing.<\/p>\n
To help alleviate this issue, the REPL includes a short submodule trace<\/code> that implements the function trace<\/code>, which can be used for debugging.\nIt is similar to the function print<\/code>, but instead of writing to the console it will write to a file.<\/p>\n
The environment variable PYREPL_TRACE<\/code> can then be used to set the path to the file to where trace.trace<\/code> writes.\nIn practice, what I do (thanks, \u0141ukasz) is I have two terminals next to each other, run tail -f PATH_TO_FILE<\/code> in one, and run PYREPL_TRACE=PATH_TO_FILE python<\/code> in the other, and this opens the REPL and prints the tracing live to my second terminal window.<\/p>\n
If you have Python 3.13 installed, you can try this out for yourself:<\/p>\n
\"Demo
GIF demo of the tracing functionality.<\/figcaption><\/figure>","summary":"Today I learned how to debug the new Python REPL with `_pyrepl.trace` and the environment variable `PYREPL_TRACE`.","date_modified":"2025-10-20T22:34:56+02:00","tags":["programming","python","repl"],"image":"\/user\/pages\/02.blog\/04.til\/103.debugging-the-new-python-repl-with-trace-and-pyrepl-trace\/thumbnail.webp"},{"title":"TIL #102 \u2013 ctrl+left and ctrl+right not working in the Python REPL on MacOS","date_published":"2024-07-13T18:00:00+02:00","id":"https:\/\/mathspp.com\/blog\/til\/ctrl-left-and-ctrl-right-not-working-in-the-python-repl-on-macos","url":"https:\/\/mathspp.com\/blog\/til\/ctrl-left-and-ctrl-right-not-working-in-the-python-repl-on-macos","content_html":"
Today I learned how to fix an issue with Ctrl<\/kbd>+left<\/kbd> and Ctrl<\/kbd>+right<\/kbd> not working in the new Python REPL on MacOS.<\/p>\n\n
\nCtrl<\/kbd>+left<\/kbd> and Ctrl<\/kbd>+right<\/kbd> not working in the Python REPL on MacOS<\/a><\/h2>\n
The (new) Python REPL (3.13+) has many<\/em> useful keyboard shortcuts and two of them are Ctrl<\/kbd>+left<\/kbd> and Ctrl<\/kbd>+right<\/kbd>, which are used to navigate the cursor by skipping to the beginning\/end of words, as the GIT below shows:<\/p>\n
\"Animation
GIF showing the keybindings in action.<\/figcaption><\/figure>\n
On MacOS, the keybindings were not working at all.\nWith the help of the new REPL trace functionality, we found out they weren't even making it to Python!<\/p>\n
After lots of digging, we found out what the issue was: MacOS was hijacking the two keybindings Ctrl<\/kbd>+left<\/kbd> and Ctrl<\/kbd>+right<\/kbd> for spaces-related shortcuts.\nTo turn those off, go to Settings > Keyboard Shortcuts > Mission Control > Mission Control dropdown > Untick \u201cMove left a space\u201d and \u201cMove right a space\u201d.<\/p>\n
\"Turning<\/p>","summary":"Today I learned how to fix an issue with Ctrl+left and Ctrl+right not working in the new Python REPL on MacOS.","date_modified":"2025-10-20T22:34:56+02:00","tags":["programming","python","repl"],"image":"\/user\/pages\/02.blog\/04.til\/102.ctrl-left-and-ctrl-right-not-working-in-the-python-repl-on-macos\/thumbnail.webp"}]}