[Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2
On Dec 28, 2004, at 4:30 PM, [EMAIL PROTECTED] wrote: Update of /cvsroot/python/python/dist/src/Mac/OSX In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9229 Modified Files: fixapplepython23.py Log Message: Just passing -undefined dynamic_lookup isn't enough: we also need to set the MACOSX_DEPLOYMENT_TARGET environment variable to 10.3 when calling the loader. And we do this with "env" because distutils apparently doesn't understand environment variable assignments before command names. This is the wrong fix. Distutils is dumber than you think. This patch just breaks C++ compilation in a different way. The correct solution is a patch to distutils of some kind. from distutils/unixccompiler.py:174 if target_lang == "c++" and self.compiler_cxx: linker[0] = self.compiler_cxx[0] self.spawn(linker + ld_args) "linker" is the variable expanded LDSHARED (or whatever comes out of sysconfig.customize_compiler). -bob ___ 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
Re: [Python-Dev] Zipfile needs?
Scott David Daniels wrote: I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? I thought I'd collect input here and make a PEP. Encryption/decryption support. Will most likely require a C extension since the algorithm relies on ints (or longs, don't remember) wrapping around when the value becomes too large. -Brett ___ 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
Re: [Python-Dev] Zipfile needs?
Scott David Daniels wrote: I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? I thought I'd collect input here and make a PEP. AFAIR, compression mechanisms are defined by numbers in the zip file. So you should not bother with such a change unless there is some "official" specification that explains how bzip2 is used in zipfiles. IOW, looking at http://www.pkware.com/company/standards/appnote/ you'll see that PKWARE has assigned algorithm 12 for bzip2. You might want to take a look at the spec to see what else the Python implementation lacks, and either document these features as deliberately missing, TODO, or just implement them right away. Regards, Martin ___ 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
Re: [Python-Dev] Re: [Pythonmac-SIG] The versioning question...
Chris Barker wrote: This really doesn't work well for complex packages. I was quite involved with the debate about versioning for wxPython (and helped drive it happening) and that was what I originally proposed. The problem is that you have a whole pile of modules and libs and user code that all imports the package. There are a LOT of "import wx" lines in the wxPython library, and a whole bunch more in a sizable wxPython app. As you upgrade, every one of those would have to be changed to import wx_x_y_z as wx Not at all. Import wx_x_y_z could do sys.modules["wx"] = wx_x_y_z and then all references to import wx would automatically resolve to the version that was imported first (or last, depending on your implementation strategy). This was not considered a reasonable solution. Among other things, it's really nice to be able to make a small change in just one file, and be able to test your app against a new version. Even if the package is not prepared to register itself under a different name also, this one file could modify sys.modules. Or you can have a wx.py that reads from wx_x_y_z import * Then, wx.py would be that single file. The versioning system that wxPython now has is quite nice, and seems to fit most people's needs well. Very good! Then I don't see a need to change anything in Python. This is quite true, and why I haven't bothered with a PEP, but maybe I've got the thinking backwards, we need the PEP to get the "important" people thinking about it. I don't think a PEP is needed - Python already appears to have everything you need to come up with your own versioning rules. Regards, Martin ___ 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
Re: [Python-Dev] Re: [Pythonmac-SIG] The versioning question...
Eric> Unless you are doing comparison tests, where it would be nice to Eric> be able to state in a generic way that the new implementation Eric> should not change answers. May be something like: Eric> import spam[1] as spamnext# next version Eric> import spam[0]as spamnow # current version Eric> assert spamnow.Ni() == spamnext.Ni() >From the Zen of Python I quote: Namespaces are one honking great idea -- let's do more of those! import spam.v1 as spamnext import spam.v0 as spamnow assert spamnow.Ni() == spamnext.Ni() Skip ___ 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
Re: [Python-Dev] Re: [Pythonmac-SIG] The versioning question...
Martin v. Löwis wrote: Eric Nieuwland wrote: Would it be an idea to submit a PEP for extending the 'import' keyword? No. Normally, packages should aim for backwards compatibility, so that applications would only want to specify a minimum version, such as import xml assert xml.version_info > (0,8,2) If you really want side-by-side installation of different versions, and a mechanism to select between them, the package could support import xml_0_8_2 as xml IOW, "import-as" should be sufficient for what you want to achieve. Unless you are doing comparison tests, where it would be nice to be able to state in a generic way that the new implementation should not change answers. May be something like: import spam[1] as spamnext # next version import spam[0] as spamnow # current version assert spamnow.Ni() == spamnext.Ni() --eric ___ 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
