[Python-ideas] Python hook just before NameError

Nick Coghlan ncoghlan at gmail.com
Mon Dec 29 15:11:20 CET 2014

On 29 December 2014 at 23:02, Chris Angelico <rosuav at gmail.com> wrote:

> On Mon, Dec 29, 2014 at 11:46 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > 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'>)
> >>>>
> Once again, that's fine for sys and os, which won't take long to
> import. For this to work with _every_ module on the system, you'd need
> to couple it with a lazy import mechanism. We had some proposals along
> those lines recently... what happened to them?

The infrastructure landed for 3.5 already, so the custom startup script can
also register a lazy loader if it wants to do so:

(Lazy loading is already possible, since it's just a particular way of
using the existing import customisation mechanisms that have been around
for over a decade, 3.5 just makes it easier by providing more of the
infrastructure to do it directly in the standard library)

You can also fairly easily have different startup scripts for different
scenarios, and then use explicit imports to bring in any extra pieces you
decide you want for a given session.

One trick I'll sometimes use myself is to do my playing around in IPython
Notebooks, where any common setup code can just go in the first cell. (I'm
not sure if IPython Notebook has a "clone existing notebook" feature yet,
but that would be a very nice way to have template environments with
different setup cells)

New language features, or even default interpreter features, are generally
an absolute last resort for solving problems - the vast majority of
problems can be better solved externally. Incurring the long term
maintenance costs of standardisation only makes sense when the perceived
pay-off is deemed likely to justify that investment.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141230/c10ffdcd/attachment-0001.html>

More information about the Python-ideas mailing list