On 29 December 2014 at 21:50, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Dec 29, 2014 at 10:43 PM, Nathaniel Smith <njs@pobox.com> wrote:
> I just set up a PYTHONSTARTUP script to pre-import the obvious things and
> that fixed this problem for me. You'd still have to make a startup script to
> set up the hook, and it's not like 'import os, sys' will appreciably affect
> startup time.

Maybe those two won't, but I work with a number of Python students who
are using heavier libraries like psycopg2 and numpy, so I'd really
rather not auto-import those into everything. On the other hand, the
course is currently written for Python 2.7, so I can't actually make
use of this there... yet. Another reason to nudge the course writers
about updating to 3.x!

FWIW, making it easier to create CPython variants that pre-populate __main__ differently (ala pyp or the --pylab option to ipython) is one of the reasons I'd like to eventually implement the interpreter initialisation changes proposed in PEP 432 (or see it implemented).

However, even today, it's not particularly difficult to create custom launch scripts that initialise __main__ with a few different modules based on what you plan to work on and then set os.environ["PYTHONINSPECT"] = "1" to drop into the interactive interpreter:

$ python3 -c "import sys, os; os.environ['PYTHONINSPECT'] = '1'"
>>> sys, os
(<module 'sys' (built-in)>, <module 'os' from '/usr/lib64/python3.4/os.py'>)
>>>

Making existing pre-initialisation mechanisms easier to discover and/or use seems like a better path forward than adding yet more tools that are even more cryptic and hard to follow.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia