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/2002-December/030983.html below:

[Python-Dev] zipimport, round 3 (or would that be that 37?)

[Python-Dev] zipimport, round 3 (or would that be that 37?)Just van Rossum just@letterror.com
Mon, 9 Dec 2002 09:54:45 +0100
Skip Montanaro wrote:

>     Just> It prefers byte code over source, but ignores the time stamp. That
>     Just> *could* be confusing.
> 
> Not to mention a change of semantics.

Hm, questionable, as we don't currently *have* zip import ;-)

> If the .py file is newer than the
> ..pyc or .pyo files, why not just force compilation but don't save the result
> (maybe also toss a Warning)?  Isn't that what importing from a read-only
> directory or filesystem does today? 

Yes, this is what it should do. However, I'd be *very* grateful for a recipe
that translates a dos time/date (it's two shorts, zipfile.py contains code that
translates it to a time tuple) to something compatible with st.st_mtime. And it
can't use the time module ;-)

> Sure, it would slow things down, but it
> would better match the semantics of importing from the filesystem.
> Presumably testing before delivery of the zip archive would identify any
> time order problems.

Agreed.

Just



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