On 29 December 2014 at 21:50, Chris Angelico <rosuav@gmail.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
On Mon, Dec 29, 2014 at 10:43 PM, Nathaniel Smith <njs@pobox.com> wrote: 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