Martin v. Löwis wrote: > robert wrote: > > codecs are in python24.dll, mscvr71, mfc71 and all are not. > However, they are not in core - the operating system demand-pages code, > loading into core memory only what is being used. So if you don't use > the codecs, they are not loaded into core. > > While mscvr71 is likely loaded into core (even though it is not in > python24.dll), mfc71.dll does not play a role at all in Python 2.4. > Python is written entire in C, not in C++.
yes, yet as a consequence win32xx is forced to be linked against MFC71.dll (no other functional reason): another MegaByte which I'd need to package most times - while mfc42 from VC6 is pre-installed on each Windows. > >>* Is there a fundamental reason that the C-RTL of VC6 (which is >>pre-installed on on all Windows today) is not sufficient for current >>Python and extensions? instable? > > > The compiler that is used (VS 2003) won't ship it, and links with > msvcr71.dll. That's why that library version is used. hmm, yet msvcrt4 is obviously preinstalled on each Windows - and its in Windows Update Process. Its tagged: "4.20 - OS use only. DO NOT DISTRIBUTE") Think, in principle its possible to compile against that with VS2003/2005... ? ( think msvcrt4 is not delivered extra even in the python2.3 installer ) >>In case not: As the short living VS 2003 compiler is now more rare than >>the good old VC6, wouldn't it be better to switch back to VC6 for Py2.5 >>or at least to VC6 libs (which are maybe "free" of dev-license as they >>sit on each Windows). > > Better in what respect? Predictability of software development? > Certainly not: the development will be more predictable if a decision > that was once taken is implemented as promised. 2.4 and 2.5 compiled stuff is anyway not interchangeable - thus at alpha-stage a (down) step to a common system lib would probably have no countable negative effects at all. > Making more users happy? Certainly not, either. Some users request that > VS2005 is being used, not that VC6 is being used. Other users request > that Python 2.5 continues to be built with VS 2003. You can't please > everybody. Yet if the C runtime lib (distribution) problem is solved, the question of the compiler becomes irrelevant. Everybody could use his compiler without worry - a soft recommendation could be in the Python2.5 doc's to link extensions also against the same common basic ctrl in order to keep the numer of libs small. >>Maybe a suitable policy: the default crtl for Python should better be >>the default library of the OS and not that of a random compiler which is >>currently hip? > > That would make a good policy if the OS had a system C library. Windows > doesn't. Windows NT does have a CRT, namely crtdll.dll - but you weren't > suggesting to use that one, were you? msvcrt4 is probably a reliable system C lib and still used by most apps. Think it doesn't lack Pythons needs. there is also a "msvcrt.dll" - also updated by the Windows system. maybe its on each Windows ? On XP it has version 7. What is this? >>* can't the Mingw/gcc be used together with Windows default crt/mfc libs >>for Python2.5 ? - Python getting away the from this MS studio (lib) >>harassment? > > Sure, you can use gcc/mingw to build extensions for Python 2.4 and > Python 2.5. yes, the lib is 90% the object of concern. > >>* how many (serious) python users require to build distributable >>installers (which have carry the python-rtls and non-default crtl's)? > > > Apparently not many. I repeatedly asked for contribution of a That would be very intersting for me - number about where (project type, LOC, #-of-users) and how (system, distribution, ..) python is used. Is there already something. Maybe a research/poll in this NG would be feasible. > specification how pythonxy.dll should be modularized, and never > received one. Maybe most a most simple cutoff criteria with "costs" does it magically. Basic proposal: cost = (C1 * module-size - C2 * frequency-of-module-usage) I'd suggest: cutoff cost = 0 C1 = 1/200kB C2 = 1/80% Example CJK codecs: cost = 500k/200k - 30%/80% = 2.13 => too expensive by far Example zlib: cost = 70k/200k - 95%/80% = -0.84 => go in -robert -- http://mail.python.org/mailman/listinfo/python-list
