The "this" module doesn't import functions; instead, it prints directly to stdout.  Accordingly, there is no reason to cache this module in sys.modules.

Ideally, a learner should be able to type "import this" more than once in  a Python session.

"Special cases aren't special enough to break the rules." ;-)

You could add the following to the bottom of this.py:

import sys
del sys.modules['this']

FWIW, a question about "this" has come up on multiple occasions when I teach Python classes.

I'd take their question as an educational opportunity.

reload(this)

Whatever we decide to do here, it **must** also be done for antigravity.py.

It seems to me that having import this work more than once would teach a beginner the *wrong* lesson about how python import works.  So I agree that it should be a teaching moment, not a bug to be fixed.

If it ain't broke don't fix it.

+0 to just doing a reload.  At the point you show someone "import this", it may be premature to be explaining reloading to them.  Python is great because you usually don't have to hand-wave through some concepts in order to explain others. [1]

Also, under Python 3 you have to import reload() separately:

from imp import reload
reload(this)


[1] http://www.boredomandlaziness.org/2011/08/scripting-languages-and-suitable.html

IMO the fact that importing happens only once is also a very important one, so much the better this helps in learning it early.

The bad thing is that opening this.py to see what's happening will not really enlighten the beginner :)

The current ugly, implicit, complex ROT13? + custom decoder version of this.py violates the initial tenets that it prints. I suppose that is an intentional joke. If it were explicit and simple:

text = '''<title>
<text lines>
...'''
print(text)

then people could follow up
  import this
with
  this.text
and learn something about accessing module attributes.

Terry is right here. The "this" module doesn't seem to have been thought as an educational tool in the first place.

I think this should be closed as won't fix.

Having "import this" behave differently from any other import is counter-intuitive (students will start asking "why if I reimport 'this' the code gets executed every time but it doesn't work with my module?").

If they want to read the Zen over and over again they can check PEP 20.

> Having "import this" behave differently from any other import is counter-intuitive

I agree. My proposal (by design) does not change the property of executing only when first imported. I merely proposed that the text either start as cleartext or that the decrypted text be saved as a module attribute. *This* would make 'this' *more* like normal modules.

Having side-effect code executed on import, as opposed to when running as main, is unusual. (Idlelib.idle is another intentional example, and one which currently has the same problem.) But I agree that this unusual behavior should remain for both.

Having module code that is intentionally obfuscated and as about as inefficient as possible without being totally ridiculous is, I hope, unique, and not at all like other modules.

Even if Tim wants to keep the literal encrypted, and the rot13 codec is not available in Py3 (?), the decoding would, I believe, be much more efficient using str.translate. Or the text could be encoded and decoded with one of the pairs in the binascii or base64 modules.

Reassigned to Barry, since he wrote this module ;-)  FWIW, I wouldn't change it.  It wasn't intended to be educational, but a newbie could learn quite a bit by figuring out how it works.

I completely agree with Tim.  The 'this' module was a *joke* and a stealthy one at that.

http://www.wefearchange.org/2010/06/import-this-and-zen-of-python.html

About the only thing I'd support is adding some comments to the code to either explain what's going on a little better, or provide some history to what this module is and why it's there.  Then again, if you want to do that, please be sure to also add some documentation, but you better make it *funny*. :)