Nick Coghlan ncogh...@gmail.com added the comment:
ZipImporter.get_filename() made public in:
2.7: r69425
3.1: r69426
--
resolution: - accepted
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
Correction - added as _get_filename() in that revision.
Documenting it and making it public (i.e. removing the underscore) is
still to be done, and will only be done for 2.7/3.1
___
Python tracker
Nick Coghlan ncogh...@gmail.com added the comment:
Fixed for 2.7 in r67750.
Will be ported to 2.6, 3.0 and 3.1.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4512
___
Nick Coghlan ncogh...@gmail.com added the comment:
The spec get_filename is pretty simple:
Return whatever __file__ would be set to if load_module() was called for
this module.
(runpy's problem is that it never actually loads the module in question,
so it never gets the chance to interrogate
Changes by Nick Coghlan [EMAIL PROTECTED]:
--
assignee: - ncoghlan
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4512
___
___
Python-bugs-list mailing
New submission from Alexander Belopolsky [EMAIL PROTECTED]:
From issue4197:
runpy needs a non-standard PEP 302 extension to set __file__ correctly
in the modules it runs. The pkgutil stuff it uses to find pure Python
modules in the filesystem supports that extension, but zipimport doesn't
Changes by Alexander Belopolsky [EMAIL PROTECTED]:
--
keywords: +patch
Added file: http://bugs.python.org/file12214/zipimport.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4512
___
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
I have attached a rough patch implementing the get_filename. I
deliberately copied code from get_source method that finds the filename
inside the zip archive and simply prefixed that with the archive path.
I could not find any