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 followed). 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`__ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
