New environment variable PYTHON_HISTORY

[0xl3vi]

BPO	29779
Nosy	@warsaw, @berkerpeksag, @serhiy-storchaka, @yan12125, @0xl3vi, @ZackerySpytz
PRs	bpo-29779: new environment variable PYTHONHISTORY. #473 gh-73965: New environment variable PYTHON_HISTORY #13208

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2017-03-10.07:40:03.245>
labels = ['3.8', 'type-feature', 'library']
title = 'New environment variable PYTHONHISTORY'
updated_at = <Date 2019-05-24.11:34:21.544>
user = 'https://github.com/0xl3vi'

bugs.python.org fields:

activity = <Date 2019-05-24.11:34:21.544>
actor = 'ZackerySpytz'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2017-03-10.07:40:03.245>
creator = '0xl3vi'
dependencies = []
files = []
hgrepos = []
issue_num = 29779
keywords = ['patch']
message_count = 5.0
messages = ['289342', '289402', '289497', '289624', '343375']
nosy_count = 6.0
nosy_names = ['barry', 'berker.peksag', 'serhiy.storchaka', 'yan12125', '0xl3vi', 'ZackerySpytz']
pr_nums = ['473', '13208']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue29779'
versions = ['Python 3.8']

Linked PRs

• gh-73965: Move PYTHON_HISTORY into the correct usage section #113798

[serhiy-storchaka]

$HISTFILE is the name of the file in which Bash command history is saved. Shouldn't the name of similar environment variable for Python be PYTHONHISTFILE?

Bash uses several environment variables for control its command history: HISTCONTROL, HISTFILE, HISTFILESIZE, HISTIGNORE, HISTSIZE, HISTTIMEFORMAT. Does Python need corresponding environment variables?

Wouldn't be better to control all these details by Python code in .pythonrc.py rather than by environment variables? For example I have the following code in my .pythonrc.py:

if sys.version_info < (3,):
 try:
 import readline, os, atexit
 histfile = os.path.join(os.path.expanduser("~"), ".python2_history")
 try:
 readline.read_history_file(histfile)
 except IOError:
 pass
 atexit.register(readline.write_history_file, histfile)
 del os, histfile
 except ImportError:
 pass

[warsaw]

I don't think the Python envar has to follow the contraction from bash. $PYTHONHISTORY reads very nicely.

I have similar code in my $PYTHONSTARTUP, but it would be nice to be able to get rid of it and just let Python do the common thing.

[yan12125]

That's a great feature! Here's a question: what should be CPython's behavior when PYTHONHISTORY is explicitly set to empty? Currently there's an error:

$ PYTHONHISTORY= ./python
Python 3.7.0a0 (master:f6595983e08fe20cf06a2535d74d912c6dbb044f, Mar 12 2017, 19:22:29) 
[GCC 6.3.1 20170306] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
Error in atexit._run_exitfuncs:
FileNotFoundError: [Errno 2] No such file or directory

Maybe it's better to just disable the history functionality in this case?

By the way, seems comments starting from https://github.com/python/cpython/pull/473/files#diff-f34a16518c608b2ca946d3f5ca0a1942R419 should be updated too.

[warsaw]

On Mar 12, 2017, at 11:42 AM, Chi Hsuan Yen wrote:

That's a great feature! Here's a question: what should be CPython's behavior
when PYTHONHISTORY is explicitly set to empty? Currently there's an error:

$ PYTHONHISTORY= ./python
Python 3.7.0a0 (master:f6595983e08fe20cf06a2535d74d912c6dbb044f, Mar 12 2017, 19:22:29)
[GCC 6.3.1 20170306] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
Error in atexit._run_exitfuncs:
FileNotFoundError: [Errno 2] No such file or directory

Yeah, that's not good. I'll note that in the PR.

(But also note that you have to unset PYTHONSTARTUP if you, like me, use that
as the old school way of enabling history.)

Maybe it's better to just disable the history functionality in this case?

It should use the default, but it shouldn't cause an error.

[ZackerySpytz]

PR 473 was closed by its author. I have created a new pull request (PR 13208) that addresses all of Berker Peksag's comments on the old PR. Please have a look.