A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-July/102587.html below:

[Python-Dev] unexpected import behaviour

[Python-Dev] unexpected import behaviourNick Coghlan ncoghlan at gmail.com
Sat Jul 31 17:07:40 CEST 2010
On Sat, Jul 31, 2010 at 3:57 PM, Daniel Waterworth
<da.waterworth at gmail.com> wrote:
> @Nick: I suppose the simplest way to detect re-importation in the
> general case, is to store a set of hashes of files that have been
> imported. When a user tries to import a file where it's hash is
> already in the set, a warning is generated. It's simpler than trying
> to figure out all the different ways that a file can be imported, and
> will also detect copied files. This is less infrastructure than you
> were suggesting, but it's not a perfect solution.

Hashing every file on import would definitely be more overhead than
just checking __file__ values (since we already calculate the latter,
and regardless of how a file is imported, it needs to end up in
sys.modules eventually). Besides, importing the same code under
different names happens in several places in our own test suite (we
use it to check that code behaviour doesn't change just because we
import it differently), so we can hardly disable that behaviour.

That said, I really don't think catching such a rare error is worth
*any* runtime overhead. Just making "__main__" and the real module
name refer to the same object in sys.modules is a different matter,
but I'm not confident enough that I fully grasp the implications to do
it without gathering feedback from a wider audience.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4