Mailman 3 December 2002 - Python-Dev

RE: [Python-Dev] New and Improved Import Hooks
by Moore, Paul Dec. 5, 2002

Dec. 5, 2002

From: Guido van Rossum [mailto:guido@python.org] > I still think I'd like sys.path to be a real list of real strings > (not necessarily representing files or directories though), with > a configurable set of handlers that are given a chance to deal > with each string in turn. That's exactly what I am arguing for. Jim Ahlstrom's existing patch makes this happen, for the extremely specific case of zip files only. Gordon McMillan's iu.py code offers this in a general way, but in … [View More]

2 1

Re: [Python-Dev] New Import Hook & New Zip Importer
by Moore, Paul Dec. 5, 2002

Dec. 5, 2002

On Thu, 5 Dec 2002 02:00:23 +0100, in you wrote: >Phew, it works. > >The attached tgz file contains: > zipper.patch: patches setup.py, Python/import.c, Python/importdl.h > zipimport.c: zipimport module, move to Modules/ > >Do I need to mention it's a rough patch <wink>? How do I build on Windows? I don't know what's needed to build the zipimport module... (Sorry, I'm not being awkward here, I have no idea how to set up the necessary Visual Studio stuff so … [View More]

2 1

New Import Hook & New Zip Importer
by Just van Rossum Dec. 5, 2002

Dec. 5, 2002

Phew, it works. The attached tgz file contains: zipper.patch: patches setup.py, Python/import.c, Python/importdl.h zipimport.c: zipimport module, move to Modules/ Do I need to mention it's a rough patch <wink>? import.c changes: - Allow arbitrary objects on sys.path. - If a path entry ends in ".zip", replace that entry with a zipimporter instance. (obviously, the zipimport module must be available for this to work.) - The search algo is: [handle … [View More]

2 3

Mac OSX issues
by Guido van Rossum Dec. 5, 2002

Dec. 5, 2002

I have temporary access to a Mac OSX box. I find the following problems: - test_re crashes unless I do ulimit -s 2000 -- haven't tried other values, but the default of 512 (KB) is insufficient. I know the README file explains this, but now that I've experienced this myself, I wonder if we shouldn't hack main() to increase the stack size to 2 MB, inside an #ifdef darwin or something like that. - test_socket fails with errno 3, 'Unknown server error' on a socket.gethostbyaddr() call.… [View More]

10 18

Can someone look at dummy_thread (#622537)?
by Brett Cannon Dec. 5, 2002

Dec. 5, 2002

There is a slight chance some of you remember the discussion that Zack Weinberg brought up here back in September about his experiences in rewriting ``tempfile``. One of the things he brought up was having to write his own fake lock so that the code would work when ``thread`` was not available. Guido suggested writing a module called ``dummy_thread`` that was API compatible with ``thread`` but was available on all platforms; he said he would check it in if it was written. Well, I wrote it. … [View More]But Guido has told me that he is too busy to check it in and so I am emailing you guys to see if someone can look at it and check it in. I would like to get it in before 2.3a so as to get the extra testing the alpha will get. The patch is #622537 ( http://www.python.org/sf/622537 ). It is complete to the best of my abilities. I have docs and the module and the tests and such. Should be pretty straight-forward to apply assuming I didn't muck up the docs (first attempt at doing any docs from scratch). The only thing beyond quality of code and documentation that might have to be dealt with is how far to integrate ``dummy_thread`` into the stdlib. I have a patch to have ``Queue``, ``threading``, and ``tempfile`` all use ``dummy_thread`` when ``thread`` is not available. Now I tested all of them with and without ``thread`` available and they all pass. But of course I wonder if this will break any code. The problem is that since ``dummy_thread`` basically just executes thread calls serially there is a problem when sommething like blocking I/O is used that blocks waiting for another thread (test_asynchat and test_socket do that, but they require ``thread`` so there is no issue there outright). So there is a chance that some code, when trying to run using ``threading`` will lock up. But I don't think this is an issue. I say in the docs that if you want to guarantee true threading to run ``import thread; del thread`` before importing ``threading``. But the main reason I don't think it will be an issue is that all other code that runs fine (but slowly) using ``dummy_thread`` now can be run where threads are not available. And those programs where deadlock would occur do not lose or gain anything since they couldn't run on a platform without ``thread`` anyway. The only issue is that if they don't check for ``thread`` someone trying to run the program will have a deadlocked program (although they shouldn't have been trying to run it in the first place). This is the only real questionable thing. Obviously the module can be checked in with no problem without touching the other modules (although ``Queue`` and ``tempfile`` should be patched regardless) if this seems to dicey to do. -Brett [View Less]

5 17

PEP 301: Package Index and Metadata for Distutils
by Richard Jones Dec. 4, 2002

Dec. 4, 2002

I've implemented all I believe is necessary for the package index to be pronounced accepted or not. This includes the last few missing pieces: - library reference patch against latest CVS - distutils/dist.py patch against latest CVS - use of distutils.version.LooseVersion sorting in the index database Where to now? Is there more to do? Should I stop now because it's not worth continuing? Richard

2 2

extension module .o files wind up in the wrong place
by Skip Montanaro Dec. 4, 2002

Dec. 4, 2002

I notice that when building Python in a subdirectory of the src dir that the .o files for extension modules are written in the wrong directory. Graphically, if my source tree looks like head/dist/src Makefile.pre.in /Modules /Python ... build Makefile /Modules /Python ... If I run cd build ../configure --prefix=/Users/skip/local make extension module .o files wind up in .../src/Modules … [View More]

5 7

Make universal newlines non-optional
by martin＠v.loewis.de Dec. 4, 2002

Dec. 4, 2002

At the time the universal newline code was committed, there was discussion whether or not it should be optional. I'd like to propose that it doesn't need to be optional: having a configuration option for it complicates the build documentation, and the space savings that one may gain from disabling it are minimal. So I volunteer to remove the #ifdef machinery around it. Any objections? Regards, Martin

3 4

RE: [Python-Dev] New and Improved Import Hooks
by Moore, Paul Dec. 4, 2002

Dec. 4, 2002

From: Just van Rossum [mailto:just@letterror.com] > I think this is more or less the same as iu.py, > except that there's no need for a "shadowpath" Thinking further, what is the advantage of your code over iu.py, if this is true? Performance? Do you have figures? Paul. PS I attach a small test script I used to get a feel for the performance of Jim's patch. Unzip this file, then do cd test zip -0r ../test0 * zip -9r ../test9 * Create a copy of the standard … [View More]

2 1

RE: [Python-Dev] New and Improved Import Hooks
by Moore, Paul Dec. 4, 2002

Dec. 4, 2002

From: Just van Rossum [mailto:just@letterror.com] > In the meantime things have changed: death to sys.import_hooks, > and yay to arbitrary objects on sys.path. I think this is more > or less the same as iu.py, except that there's no need for a > "shadowpath" (if not a string, the sys.path item _is_ the > "owner"). How do I put a zipfile on my PYTHONPATH environment variable? Paul.

2 1