Zip format (was: Questions about distutils strategy )

Is it possible nowadays to have two files with the same name but different paths (i.e. foo/bar.py and foo/spam/bar.py) in the same archive? That's the one thing that always struck me as very very silly about zipfiles. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

Jack Jansen asks:
Depends on how you do it. If the user imports foo.spam.bar, an importer will be asked for: foo (return foo.__init__) foo.spam (return foo.bar.__init__) foo.spam.bar (return foo.spam.bar) But the API allows lots of variations. This is another possible interaction: foo (return None) foo.__init__ (return foo.__init__) foo.spam (return None) foo.bar.__init__ (return foo.bar.__init__) foo.spam.bar (return foo.spam.bar) Or, by looking at different args to get_code, you could look at the requests as: foo in context of None spam in context of foo bar in context of foo.spam With another variation where the request for __init__ becomes explicit. The first way seems the natural way for archives, and makes it easy to keep foo.bar.spam distinct from foo.spam.
That's the one thing that always struck me as very very silly about zipfiles.
Huh? - Gordon

On Fri, 10 Dec 1999, Gordon McMillan wrote:
^^^ foo.spam.__init__
foo.spam.bar (return foo.spam.bar)
The above sequence is what currently happens.
The core of imputil has no knowledge of the __init__ thingy. That is specific to the filesystem-based stuff. So in this sense, "possible" means "imputil could be changed to do this". I would argue against the change, however :-)
Bing! Cheers, -g -- Greg Stein, http://www.lyra.org/

Zip files contain the full path, there's no problem with that. Was there ever? --Guido van Rossum (home page: http://www.python.org/~guido/)

Jack Jansen asks:
Depends on how you do it. If the user imports foo.spam.bar, an importer will be asked for: foo (return foo.__init__) foo.spam (return foo.bar.__init__) foo.spam.bar (return foo.spam.bar) But the API allows lots of variations. This is another possible interaction: foo (return None) foo.__init__ (return foo.__init__) foo.spam (return None) foo.bar.__init__ (return foo.bar.__init__) foo.spam.bar (return foo.spam.bar) Or, by looking at different args to get_code, you could look at the requests as: foo in context of None spam in context of foo bar in context of foo.spam With another variation where the request for __init__ becomes explicit. The first way seems the natural way for archives, and makes it easy to keep foo.bar.spam distinct from foo.spam.
That's the one thing that always struck me as very very silly about zipfiles.
Huh? - Gordon

On Fri, 10 Dec 1999, Gordon McMillan wrote:
^^^ foo.spam.__init__
foo.spam.bar (return foo.spam.bar)
The above sequence is what currently happens.
The core of imputil has no knowledge of the __init__ thingy. That is specific to the filesystem-based stuff. So in this sense, "possible" means "imputil could be changed to do this". I would argue against the change, however :-)
Bing! Cheers, -g -- Greg Stein, http://www.lyra.org/

Zip files contain the full path, there's no problem with that. Was there ever? --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
Gordon McMillan
-
Greg Stein
-
Guido van Rossum
-
Jack Jansen
-
James C. Ahlstrom