Mailman 3 July 2007 - Python-Dev

Alternative to -z option
by Phillip J. Eby July 13, 2007

July 13, 2007

After thinking about it some more, I suggest that instead of using a special option to execute a zipfile, we simply always get an importer for the script filename. If the importer is imp.NullImporter, then we do normal script processing. Otherwise, we set set sys.path[0] = sys.argv[0] = script, and import __main__. This will support zipfiles and directories, Windows and Unix, even using "env" (since no option to the interpreter is required). Thoughts?

2 1

Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
by Phillip J. Eby July 13, 2007

July 13, 2007

At 09:13 PM 7/12/2007 -0700, Andy C wrote: >I can definitely see why it "just makes sense", and my first thought >was indeed to name it __main__. But then you lose the ability to make >a distinction: What does "if __name__ == '__main__" mean in >__main__.py? : ) The same as anywhere else; it'll just always be true. :) > If someone tries does import __main__ from another >module in the program, won't that result in an infinite loop? No, for two reasons. First, importing __main__ always returns whatever the start script is using as a __main__ module. Second, even if you're in the middle of __main__ itself, the module is already in sys.modules. So this is a non-issue. >At Google some people do "import sitecustomize" and get values that >were computed earlier by the sitecustomize. I could see the same kind >of thing happen with __main__.py. Yes, but it won't work unless the overall program was launched via *that particular* __main__.py -- running from the interpreter prompt for example, those values won't be there. So, people will learn quickly why that doesn't work. > > Testing your package before you zip it, would be one. :) My > > personal main interest was in being able to add an item to sys.path > > without having to set $PYTHONPATH on Windows. That's why I'd like it > > to be possible to use -z more than once (or whatever the option > ends up as). > >Where would you do that? Just typing it literally on the command >line? Yes. > > > I think it's sufficient to treat it as a documented "trick" > > >that you can substitute a whole directory for a zip file with the -z > > >flag. If there is a concrete suggestion, I'd like to discuss it, but > > >otherwise it seems like we'll get bogged down in expanding use cases. > > > > Eh? First you say there aren't any use cases, now you say there'll be > > too many? I'm confused. The only competing proposal besides what > > I've suggested was the one to add an option to "runpy", and IMO > > that's dead in the water due to shebang argument limits. > >As implemented the patch is fairly simple, and shouldn't have any >unintended consequences. I'm not necessarily opposed to making it >more general and thinking about sys.path vs. a zip file specifically. I think it can be replaced with using standard importer detection of sys.argv[0], to decide whether it is an importable location (dir/zip), and then importing __main__, with fallback to the old script behavior. This is forward-compatible with other import mechanisms, and supports #! lines better for zipfiles, since no -z option is needed.

1 0

Typo in itertools.dropwhile()
by Matthieu Brucher July 13, 2007

July 13, 2007

Hi, There seems to be a typo in the doc of itertools.dropwhile() : Make an iterator that drops elements from the iterable as long as the predicate is true; afterwards, returns every element. Note, the iterator does not produce *any* output until the predicate is true, so it may have a lengthy start-up time. It says something and then the opposite, so which one is true ? Matthieu

5 7

Python developers at Google (was Re: Add a -z interpreter flag to execute a zip file)
by Neal Norwitz July 12, 2007

July 12, 2007

On 7/12/07, glyph(a)divmod.com <glyph(a)divmod.com> wrote: > > ... there is a heavy Google bias in the existing survey sample ... Not just this survey... There are many python developers at Google and that is not likely to change anytime soon. This means that it's even more important to hear differing points of view. We need to hear more from people outside of Google to ensure we are doing the best possible job. It would also be great to have more active committers that don't work at Google. n

2 1

Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
by Phillip J. Eby July 12, 2007

July 12, 2007

At 08:11 AM 7/12/2007 -0700, Andy C wrote: >Is __main__ a good idea considering that is used for something >similar but implemented completely differently (the module name)? That would be why it *is* a good idea; it's the One Obvious Way To Do It. :) Now we just need an option abbreviation that's less obscure than '-z', given that this isn't just for zipfiles. Either that, or we can pretend it stands for "zoom in on this path and run its __main__". ;-)

1 0

Re: [Python-Dev] PEP 366 - Relative imports from main modules
by Phillip J. Eby July 12, 2007

July 12, 2007

At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote: >I see no big problems with this, except I wonder if in the end it >wouldn't be better to *always* define __package_name__ instead of only >when it's in main? And then perhaps rename it to __package__? Done >properly it could always be used for relative imports, rather than >parsing __module__ to find the package. Then you won't even need the >error handler. +1 for __package__, and putting it everywhere. Relative import should use it first if present, falling back to use of __name__.

5 8

Need help fixing failing Py3k Unittests in py3k-struni
by Guido van Rossum July 12, 2007

July 12, 2007

One of the most daunting tasks remaining for Python 3.0a1 (to be released by the end of August) is fixing the remaining failing unit tests in the py3k-struni branch (http://svn.python.org/view/python/branches/py3k-struni/). This is the branch where I have started the work on the string/unification branch. I want to promote this branch to become the "main" Py3k branch ASAP (by renaming it to py3k), but I don't want to do that until all unit tests pass. I've been working diligently on this task, and I've got it down to about 50 tests that are failing on at least one of OSX and Ubuntu (the platforms to which I have easy access). Now I need help. To facilitate distributing the task of getting the remaining tests to pass, I've created a wiki page: http://wiki.python.org/moin/Py3kStrUniTests . Please help! It's easy to help: (1) check out the py3k-struni branch; (2) build it; (3) pick a test and figure out why it's failing; (4) produce a fix; (5) submit the fix to SF (or check it in, if you have submit privileges and are confident enough). In order to avoid duplicate work, I've come up with a simple protocol: you mark a test in the wiki as "MINE" (with your name) when you start looking at it. You mark it as "FIXED [IN SF]" once you fix it, adding the patch# if the fix is in SF. If you give up, remove your lock, adding instead a note with what you've found (even just the names of the failing subtests is helpful). Please help! There are other tasks, see PEP 3100. Mail me if you're interested in anything specifically. (Please don't ask me "do you think I could do this" -- you know better than I whether you're capable of coding at a specific level. If you don't understand the task, you're probably not qualified.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

7 10

Subprocesses and SIGPIPE
by Matthew Woodcraft July 11, 2007

July 11, 2007

The documentation for the subprocess module says that it can be used as a replacement for shell pipelines, and gives an example. On *nix systems, cpython is set to ignore SIGPIPE, and this setting is inherited by child processes created by the subprocess module. This is nearly always not what you want when you're constructing a pipeline. In practice, I think most programs are not particularly designed (or tested) to run with SIGPIPE ignored, and I've had trouble caused by this a couple of times now. If you know about this, it's easy enough to avoid trouble using something like this as a preexec_fn for subprocess.Popen: def permit_sigpipe(): signal.signal(signal.SIGPIPE, signal.SIG_DFL) My question is: should subprocess.Popen do this by default? In any case, it would be good to see this issue mentioned near the pipeline example. -M-

1 0

SVN precommit hook
by Thomas Wouters July 11, 2007

July 11, 2007

I just got this traceback trying to do a rather large checkin: Transmitting file data ............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: file /python/branches/p3yk-noslice/Lib/test/string_tests.py is not whitespace-normalized file /python/branches/p3yk-noslice/Doc/tools/buildindex.py is not whitespace-normalized file /python/branches/p3yk-noslice/Lib/test/test_array.py is not whitespace-normalized Traceback (most recent call last): File "/data/repos/projects/hooks/checkwhitespace.py", line 50, in ? File "/var/lib/python-support/python2.4/svn/core.py", line 217, in run_app File "/data/repos/projects/hooks/checkwhitespace.py", line 32, in main File "/var/lib/python-support/python2.4/libsvn/fs.py", line 381, in svn_fs_node_prop libsvn._core.SubversionException: ("Can't open file '/data/repos/projects/db/transactions/56255-1.txn/props': Too many open files", 24) I'm not complaining about the whitespace-normalization issues, but rather the open files issue ;-P It sounds like a buglet somewhere, although it may be in libsvn. -- Thomas Wouters <thomas(a)python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 3

[PATCH] fixing 2.5.1 build with unicode and dynamic loading disabled
by Alexander Neundorf July 11, 2007

July 11, 2007

Hi, this is my first email to this list, I'm currently porting python to some platforms with limited capabilities and so I thought it would be a good idea to subscribe here. While doing the porting, I found two small problems in Python 2.5.1: If Py_USING_UNICODE is disabled, in Python/ast.c decode_unicode() still calls unicode-related functions, which leads to undefined references when linking. If HAVE_DYNAMIC_LOADING is disabled, in Python/import.c _PyImport_DynLoadFiletab is still initialized, which also leads to undefined references when linking, since then no source file which defines this variable is used. A patch against 2.5.1 is attached. Best regards Alex

2 2