This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Arfrever, brett.cannon, eric.araujo, eric.smith, eric.snow, lemburg, ncoghlan, pitrou, python-dev
Date 2012-05-06.07:28:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1336289200.3336.4.camel@localhost.localdomain>
In-reply-to <1336279812.3.0.555803193885.issue14657@psf.upfronthosting.co.za>
Content
> Here's my take.  No one will care about _frozen_importlib vs.
> importlib._bootstrap normally, right?  If __module__/__file__ says
> _frozen_importlib, it's no big deal.

The reason I'd prefer __file__ to point to the actual Python file is so
that people reading a traceback can find the source code. Of course
that's a bit minor.
(and, incidentally, the traceback itself will display the source code
lines)

> The only time you care about the distiction for importlib._bootstrap
> is when you're hacking on _bootstrap.py.  So let's keep the common
> case in sight and go from there.

Agreed.

> For the first part, let's simply ignore the pure Python
> importlib._bootstrap by default?  Then we stick a context manager in
> importlib.test.util that enables it.  When you're hacking on
> _bootstrap.py, you switch it over.  The common path stays pretty
> clean.

Looks good to me.

> I've attached a patch for the first part which has similarities to
> Antoine's.  (I didn't apply the context manager to the importlib test
> cases though.)

I think set_bootstrap() looks a bit fragile, since we have to manually
add any importlib attributes that are exported in importlib/__init__.py.
Perhaps we could detect them automatically?
History
Date User Action Args
2012-05-06 07:28:34pitrousetrecipients: + pitrou, lemburg, brett.cannon, ncoghlan, eric.smith, eric.araujo, Arfrever, python-dev, eric.snow
2012-05-06 07:28:33pitroulinkissue14657 messages
2012-05-06 07:28:33pitroucreate