Paul Moore wrote: > 2009/7/4 Brett Cannon <br...@python.org>: >>> (runpy is also a lot happier with >>> them when they expose get_filename(), a relatively recent addition to >>> the PEP 302 API). >> An addition I was not even aware of. Looks like importlib needs a little >> updating. > > Yes, I didn't notice that sneak into PEP 302, either :-)
I probably should have been noisier about that when I added it. I'm pretty sure it did come up on this list, but it would have been somewhere in the middle of a runpy discussion: runpy was stuck because it only uses PEP 302 to *find* the modules it needs, but not to actually load them. In the original version of PEP 302 the only way to get a loader to tell you the filename was to load the module and see what it set __file__ to, which wasn't useful in the runpy case. If I recall correctly, at the time when PJE was rationalising the code duplication between runpy and pkglib the comment was also made that runpy's get_filename() optional loader extension should be mentioned in PEP 302. runpy still works for loaders that don't provide it, it just can't set __file__ or sys.argv[0] correctly in those cases. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com