cases, plus even tougher tests of that. This implementation follows
the correctness proof very closely, and should also be quicker (yes,
I wrote the proof before the code, and the code proves the proof <wink>).
Lesson learned: kids should not be allowed to use API's starting
with an underscore :-/
zipimport in 2.3a1 is even more broken than I thought: I attemped
to _PyString_Resize a string created by PyString_FromStringAndSize,
which fails for strings with length 0 or 1 since the latter returns
an interned string in those cases. This would cause a SystemError
with empty source files (and no matching pyc) in the zip archive.
I rewrote the offending code to simply allocate a new buffer and
avoid _PyString_Resize altogether.
Added a test that would've caught the problem.
(or None) now. In 2.3a1 they could also return an int or long, but that
was an unhelpfully redundant leftover from an earlier version wherein
they couldn't return a timedelta. TOOWTDI.
the test set as it only tested with a zip archive in the current directory,
but it doesn't work at all for packages when the zip archive was specified
as an absolute path. It's a real embarrassing bug: a strchr call should
have been strrchr; fever apparently implies dyslexia.
Second stupid bug: the zipimport test failed with a name error
__importer__ (which I had renamed to __loader__ everywhere but here).
I would've sworn I ran the test after that change but that can't be true.
What I don't understand that noone reported a failing test_zipimport.py
before the release of 2.3a1.
suggestion from Guido, along with a formal correctness proof of the
trickiest bit. The intricacy of the proof reveals how delicate this
is, but also how robust the conclusion: correctness doesn't rely on
dst() returning +- one hour (not all real time zones do!), it only
relies on:
1. That dst() returns a (any) non-zero value if and only if daylight
time is in effect.
and
2. That the tzinfo subclass implements a consistent notion of time zone.
The meaning of "consistent" was a hidden assumption, which is now an
explicit requirement in the docs. Alas, it's an unverifiable (by the
datetime implementation) requirement, but so it goes.
understood now: it can't work. Added comments explaining why (it's "the
usual"-- unrepresentable hours in local time --but in a slightly different
guise).
an idea from Guido. This restores that the datetime implementation
never passes a datetime d to a tzinfo method unless d.tzinfo is the
tzinfo instance whose method is being called. That in turn allows
enormous simplifications in user-written tzinfo classes (see the Python
sandbox US.py and EU.py for fully fleshed-out examples).
d.astimezone(tz) also raises ValueError now if d lands in the one hour
of the year that can't be expressed in tz (this can happen iff tz models
both standard and daylight time). That it used to return a nonsense
result always ate at me, and it turned out that it seemed impossible to
force a consistent nonsense result under the new implementation (which
doesn't know anything about how tzinfo classes implement their methods --
it can only infer properties indirectly). Guido doesn't like this --
expect it to change.
New tests of conversion between adjacent DST-aware timezones don't pass
yet, and are commented out.
Running the datetime tests in a loop under a debug build leaks 9
references per test run, but I don't believe the datetime code is the
cause (it didn't leak the last time I changed the C code, and the leak
is the same if I disable all the tests that invoke the only function
that changed here). I'll pursue that next.
- new import hooks in import.c, exposed in the sys module
- new module called 'zipimport'
- various changes to allow bootstrapping from zip files
I hope I didn't break the Windows build (or anything else for that
matter), but then again, it's been sitting on sf long enough...
Regarding the latest discussions on python-dev: zipimport sets
pkg.__path__ as specified in PEP 273, and likewise, sys.path item such as
/path/to/Archive.zip/subdir/ are supported again.
of the timetz case. A tzinfo method will always see a datetimetz arg,
or None, now. In the former case, it's still possible that it will get
a datetimetz argument belonging to a different timezone. That will get
fixed next.
ignore tuple.
The line, "from _random import Random as CoreGenerator", fools the test
code which expects CoreGenerator.__name__ to be "CoreGenerator" instead
of "Random".
Guido has in mind an easier way for users to code this stuff, but the
only tests we have now are for fixed-offset tzinfo classes, and this
stuff is extremely delicate in the endcases (read the new test code
for why: there are holes in time <wink>).
operands have identical tzinfo members (meaning object identity -- "is").
I misunderstood the intent here, reading wrong conclusion into
conflicting clues.
subtraction, work as documented. In the Python implementation,
they weren't calling utcoffset() if both operands had the same
tzinfo object. That's fine if it so happens that the shared
tzinfo object returns a fixed offset (independent of operand),
but can give wrong results if that's not so, and the latter
obtains in a tzinfo subclass instance trying to model both
standard and daylight times. The C implementation was already
doing this "correctly", so we're just adding tests to verify it.
