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 lemburg
Recipients Arfrever, brett.cannon, eric.araujo, eric.snow, lemburg, ncoghlan, python-dev
Date 2012-04-24.17:55:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Brett Cannon wrote:
> That initial comment is out-of-date. If you look that the commit I made I  documented importlib.machinery._SourcelessFileLoader. I am continuing the discouragement of using bytecode files as an obfuscation technique (because it's a bad one), but I decided to at least document the class so people can use it at their own peril and know about it if they happen to come across the object during execution.

It's not a perfect obfuscation technique, but a pretty simple and
(legally) effective one to use.

FWIW, I don't think the comment in the check-in is appropriate:

   1.127 +   It is **strongly** suggested you do not rely on this loader (hence the
   1.128 +   leading underscore of the class). Direct use of bytecode files (and thus not
   1.129 +   source code files) inhibits your modules from being usable by all Python
   1.130 +   implementations. It also runs the risk of your bytecode files not being
   1.131 +   usable by new versions of Python which change the bytecode format. This
   1.132 +   class is only documented as it is directly used by import and thus can
   1.133 +   potentially have instances show up as a module's ``__loader__`` attribute.

The "risks" you mention there are really up to the application developers
to decide how to handle, not the Python developers. Python has a long
tradition of being friendly to commercial applications and I don't see
any reason why we should stop that.

If you do want this to change, please write a PEP. This may appear
to be a small change in direction, but it does in fact have quite
some impact on the usefulness of CPython in commercial settings.

I also think that the SourcelessFileLoader loader should be first class
citizen without the leading underscore if the importlib is to completely
replace the current import mechanism. Why force developers to write their
own loader instead of using the standard one just because of the leading
underscore, when it's only 20 lines of code ?

Marc-Andre Lemburg

2012-04-28: PythonCamp 2012, Cologne, Germany               4 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! :::: Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
Date User Action Args
2012-04-24 17:55:06lemburgsetrecipients: + lemburg, brett.cannon, ncoghlan, eric.araujo, Arfrever, python-dev, eric.snow
2012-04-24 17:55:05lemburglinkissue14605 messages
2012-04-24 17:55:05lemburgcreate