> ! -b : read files in binary mode (default)
> ! -t : read files in text mode (you almost certainly don't want
> When is -t useful?
I don't know that it ever is. md5sum.py before 2.3 didn't have such an
option, and always used binary mode. md5sum.py in 2.3 suddenly grew this
option, and *defaulted* to text mode, which is a disaster for normal usage
on Windows. On the CVS head I switched the default back to binary mode, but
left -t in since we had released a version supporting a -t option (and as
the default, no less).
I can invent a use case for -t (a text file checksum independent of platform
line-end convention), but it's strained (it's never been a real use case in
my protracted life <wink>).
The file PC/python_nt.rc defines the version information which will be
embedded as resource in pythonXX.dll.
Because of limitations in MS resource compiler, the info cannot be
constructed from patchlevel.h at compile time, instead it must be
changed manually. There is a python script PC/field3.py which helps, but
it cannot be used by the build process because python is then not
I'm working on a way to automate this:
A new project is inserted into the MSVC project file, and the pythoncore
project (which builds the python dll) will depend on it, so this new
project is built first.
This new project builds a small exe which will create (as custom build
step) an include file for python_nt.rc, so no manual step is needed any
Does this sound like a sensible approach, or are there any objections?
Last chance for feedback on python2.3.1 ... :)
Draft of announce message at www.python.org/2.3.1/announce.txt
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
>backup kept screwing up until FileStorage's
> if fsync is not None: fsync(file.fileno())
>actually did something on Windows.
I suspect making the change where you obtain fsync, rather than where
you call it
makes the code clearer. Just after import os, you can do the
appropriate bit of
the following code:
fsync = os.fsync
fsync = lambda filenumber: None # Unfortunately nothing to
-------- or --------
fsync = os.fsync or lambda filenumber: None # if we cannot sync,
This (at least to me) emphasizes the lack of a system facility. The
code emphasizes local solutions on a case-by-case basis. If the
always to skip the call, I'd find this method clearer.
-Scott Daid Daniels
When I checked in the HAVE_SYNC -> HAVE_FSYNC change I thought briefly about
including a test to test_os.py. I eventually decided against it because it
was clear that a simpleminded test for os.fsync's existence was useless.
Jason seems to have been bitten badly by it. I doubt that fsync() is
available everywhere (otherwise why test for it in the configure script?),
so it seems that Jason should have been testing for its presence (though see
below) and worming around its abscence if he wanted TMDA to run on as many
platforms as possible.
This suggests the following questions:
* Is there a reasonable way to write tests which will detect this sort of
* Should there be special documentation about os-dependent functions which
are not universally available? The fsync() doc says nothing about it not
always being available (thus Jason can be forgiven for not calling
Ok, here's my plans for 2.3.2.
Cut a release candidate on Tuesday (AU time, so Monday for merkins)
Cut a release Thursday (AU time).
I don't think the additional two days will hurt that badly, and I'd
strongly prefer to have a release candidate before the final build.
I don't know if the RC needs a windows installer built, as the problems
are in non-windows platforms.
"Fred L. Drake" <fdrake(a)acm.org> writes:
> The development version of the documentation has been updated:
> The new glossary in the tutorial is really nice!
Sure, but the hyperlinks don't work ;-)