[Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14[draft]

Tony Meyer ta-meyer at ihug.co.nz
Mon Mar 7 03:07:44 CET 2005

Somewhat slower, but here are two more threads from me (email is mostly a
weekday thing for me, and the last few days were full of sun, wine, food and
jazz.  Well, and work.  But working with sun, wine, food and jazz, so it's
hard to complain too much).  Feedback will not be ignored :)

More licensing issues - redistribution

As most people know, one of the major changes between the Windows builds of
Python 2.3 and 2.4 is that 2.4 is built with VC7, rather than VC6.  One of
the consequences of this change is that 2.4 links with the Microsoft DLL
msvcr71.dll, which only some people have, rather than msvcr.dll, which
pretty much all Windows users have.

The Windows Python 2.4 distribution installs msvcr71.dll, so it's there when
needed.  However, those building frozen applications (e.g. with py2exe) need
to ensure that their users have msvcr71.dll.

After going through the EULA's for both the commercial and free-to-use
Microsoft compilers, it seems that redistributing mscvr71.dll is acceptable,
if the re-distributor owns a copy of the commercial (not free) compiler,
includes an EULA agreement in one of various forms (e.g. 'click-wrap'), and
follows various other minor conditions (note that just about every message
in this thread contains "IANAL, but").

This leaves those without VC7 unable to redistribute msvcr71, unless, as
some suggested, distributing a frozen Python application can be considered
as redistributing Python (and the various other minor conditions are

In an interesting twist, it appears that the official Windows Python 2.4
distribution is in breach of the EULA, as a 'click-wrap' license is
required, and is not present.  This element of the thread died without
reaching a conclusion, however.

If you *are* a lawyer (with expertise in this area), and would like to
comment, then please do!

Contributing threads:
   - `Is msvcr71.dll re-redistributable?`__

Avoiding signs in memory addresses

Troels Walsted Hansen pointed out that builtin_id() can return a negative
number in Python 2.4 (and can generate a warning in 2.3).  Some 2.3 modules
(but no 2.4 ones) have code to work around this, but Troels suggested that a
better solution would be to simply have builtin_id() return an unsigned long
integer.  The consensus was that this would be a good idea, although nothing
has been checked in yet, and so this will probably stagnate without someone
submitting a patch (or at least a bug report).

Contributing threads: 
   - `builtin_id() returns negative numbers`__

More information about the Python-Dev mailing list