On Jul 26, 2010, at 10:53 PM, Ralf Schmitt wrote: >Some of the things that need to be adapted are e.g. Makefiles >(basically anything that assumes modules have a certain name), all of >the freezers (cxFreeze, py2exe, ...). The biggest problem probably >will be that an import will load the wrong module or no module at all. >I'm just speculating here...
I took a look at cx_freeze - it doesn't support Python 3.2 yet afaict (the build fails but it may be shallow). I'm going to look at py2exe as soon as I can get a Windows VM up and running. Since import is (usually) handled by the built-in dynload_shlib.c code it should generally Just Work I think, unless some application installs custom import hooks. In any case, I think this will be a fairly standard and probably simple, porting effort, which goes along with supporting any new major release. >> "Change is bad" isn't a constructive argument. ;) > >Did I make that argument? Apologies. >> That's fine, but it's not the way Debian/Ubuntu works today. PEP >> 3149 adoption will definitely remove significant complication for >> deploying multiple Python versions at the same time on those systems. > >You're just moving that complication into python. It's a much different level and scope of complexity though. For Python, it's pretty simple: look for an additional .so file name pattern which gets baked into Python at compile time. For that, you're able to remove a huge amount of complexity on Debian/Ubuntu by removing the need to manage multiple directory trees and symlinks between files in those trees. The tools that manage them (i.e. handle package installs and removals) also get much simpler. I think it's a worthwhile trade-off. Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ 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
