Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/11/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Nick Coghlan has reviewed the patch and seems to think it's a good idea. Thomas Wouters also said he likes it, and I ran it by Guido earlier and he seemed to think the idea is good, although I don't think he has seen the implementation. See my comment: I must be missing the point of the patch, since I can do the same thing (make a single executable zip file on Linux) through a /bin/sh header just fine. Right, but it's supposed to be cross platform, as mentioned in the patch. This will work on Windows. The main problem I see is that a shell script in front of a zip file seems like a relatively common idiom that people use and have different variants on, each of which have their own idiosyncrasies. So it would nice to consolidate them and make it standard and robust. For example, it looks like eggs have an executable format that is similar to this. And see the bug I mentioned where those executable eggs can't be invoked through a symlink (which to me is a relatively severe problem). I think this has to do with some introspection on $0, but you won't run into that with this implementation. Also, I mentioned the program called autopar we use at Google that does the same thing, and it also have a significant number of weird hacks in the shell header. I think Thomas Wouters has also worked on another program to make an executable zip file. Another example is that the behavior of the zip in your example depends on what else is in the current directory [1], which isn't desirable. Nick pointed out this issue and I addressed it in the patch by removing from sys.path, since the -c flag adds that. If lots of people reinvent this wheel (and they have), there are going to be other subtleties like this that will be missed. The -z flag also eliminates starting an extra process -- you invoke the Python interpreter directly instead of starting a shell which in turn invokes the Python interpreter. As mentioned, it's also a very tiny amount of code, and I don't see much potential for bad interactions with other things, the way I've written it. Andy 1) andychu test2$ ./foo_exe.zip Traceback (most recent call last): File string, line 1, in ? File foo.py, line 16, in ? import outside ImportError: No module named outside andychu test2$ touch outside.py andychu test2$ ./foo_exe.zip main andychu test2$ ___ 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] Add a -z interpreter flag to execute a zip file
Right, but it's supposed to be cross platform, as mentioned in the patch. This will work on Windows. But in the description, you said that you do the same on Windows by making a file that is both a zip file and a batch file. So my approach is also cross-platform, no? How do you get the -z option to work on Windows? What extension do you use, and how is the zipfile created? The main problem I see is that a shell script in front of a zip file seems like a relatively common idiom that people use and have different variants on, each of which have their own idiosyncrasies. So it would nice to consolidate them and make it standard and robust. Couldn't that also be achieved by documenting best practice in the documentation? Why is the shell script not robust? For example, it looks like eggs have an executable format that is similar to this. And see the bug I mentioned where those executable eggs can't be invoked through a symlink (which to me is a relatively severe problem). I think this has to do with some introspection on $0, but you won't run into that with this implementation. Why that? Why do eggs fail to process $0 correctly, whereas the -z option gets it correct? That just sounds like a bug in eggs to me, that could be fixed - or, if not, I'd expect that -z cannot fix it, either. My understanding of this note is that pkg_resources uses sys.argv[0] to determine the version number of the egg; IIUC, -z won't help at all here because sys.argv[0] will still be the name of the symlink. Also, I mentioned the program called autopar we use at Google that does the same thing, and it also have a significant number of weird hacks in the shell header. I think Thomas Wouters has also worked on another program to make an executable zip file. What are those weird hacks, why are they necessary, and how does the -z option overcome the need for these hacks? That people fail to make it work with /bin/sh doesn't automatically mean they succeed with -z. Either they are too unexperienced to make the shell header correct (in which case documenting best practice would help), or they have deeper problems with that approach, in which case it isn't at all obvious that the proposed change improves anything. Another example is that the behavior of the zip in your example depends on what else is in the current directory [1], which isn't desirable. Nick pointed out this issue and I addressed it in the patch by removing from sys.path, since the -c flag adds that. should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. The -z flag also eliminates starting an extra process -- you invoke the Python interpreter directly instead of starting a shell which in turn invokes the Python interpreter. See my script. It does not start (fork) another process. Instead, the existing process gets reused. It execs another program, true. As mentioned, it's also a very tiny amount of code, and I don't see much potential for bad interactions with other things, the way I've written it. It's baggage that is rarely needed, and the feature can be readily implemented in a different way for people who need it. 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] Add a -z interpreter flag to execute a zip file
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Right, but it's supposed to be cross platform, as mentioned in the patch. This will work on Windows. But in the description, you said that you do the same on Windows by making a file that is both a zip file and a batch file. So my approach is also cross-platform, no? The approach is cross-platform, in that you can use the approach on different platforms. The result of the approach, however, is not cross-platform. You can't distribute your single zip-as-executable to both Windows and bourne-shell-using platforms. The -z argument does allow that. Why is the shell script not robust? There are a lot of subtleties in figuring out which python to execute, environment variables that you may or may not want to tweak (admittedly Google's solution that Andy referenced is more vulnerable to that, but it's not unique to Google by any means.) If you want any kind of flexibility in the packaged-up program, you need a bunch of logic in the shell script, and environment-tricks to pass information to the python process, start the python process and provide a bunch more logic in Python to boot. For instance, you need to set PYTHONPATH to include the zipfile before you can import from it, but you don't want that PYTHONPATH to be passed to subprocesses by accident. The -z argument makes it extremely simple: the user decides which python to run, and the program is run directly just like it would if it was unpacked and run that way. It makes it extremely easy to create 'single executables' out of multiple Python files, in the form that single .py files already are. It leaves building a more complex system (such as eggs) ontop of it entirely open. The change is a good thing, IMHO. And I say this not because we use a similar solution at Google -- we already solved it, and we won't be using the -z argument anytime soon anyway. I say this because I've had many requests from non-googlers for something exactly like this :) should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. Yes. should either be interpreted as the zipfile, or be replaced by the zipfile. In the case of executing the zipfile, the main script lives *in the zipfile*. It's baggage that is rarely needed, and the feature can be readily implemented in a different way for people who need it. I disagree with both statements. The bagage is much less than zipimport itself, which has proven to be quite useful. Nevertheless, zipimport built into the interpreter was by no means necessary; current users of it could have readily implemented it themselves, with no changes to Python. (In fact, Google's 'autopar' tool does exactly that to support Python 2.2, which lacks zipimport.) This is a very small, logical and useful extension to zipimport, and I believe you will find more uses for it than you expect (although I do believe you yourself don't have a need for it. I just don't think you're a typical Python programmer in this case :) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Add a -z interpreter flag to execute a zip file
On 7/12/07, Thomas Wouters [EMAIL PROTECTED] wrote: On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Right, but it's supposed to be cross platform, as mentioned in the patch. This will work on Windows. But in the description, you said that you do the same on Windows by making a file that is both a zip file and a batch file. So my approach is also cross-platform, no? The approach is cross-platform, in that you can use the approach on different platforms. The result of the approach, however, is not cross-platform. You can't distribute your single zip-as-executable to both Windows and bourne-shell-using platforms. The -z argument does allow that. Why is the shell script not robust? There are a lot of subtleties in figuring out which python to execute, environment variables that you may or may not want to tweak (admittedly Google's solution that Andy referenced is more vulnerable to that, but it's not unique to Google by any means.) If you want any kind of flexibility in the packaged-up program, you need a bunch of logic in the shell script, and environment-tricks to pass information to the python process, start the python process and provide a bunch more logic in Python to boot. For instance, you need to set PYTHONPATH to include the zipfile before you can import from it, but you don't want that PYTHONPATH to be passed to subprocesses by accident. The -z argument makes it extremely simple: the user decides which python to run, and the program is run directly just like it would if it was unpacked and run that way. It makes it extremely easy to create 'single executables' out of multiple Python files, in the form that single .py files already are. It leaves building a more complex system (such as eggs) ontop of it entirely open. The change is a good thing, IMHO. And I say this not because we use a similar solution at Google -- we already solved it, and we won't be using the -z argument anytime soon anyway. I say this because I've had many requests from non-googlers for something exactly like this :) should not be removed from sys.path . It is *not* meant to be the current directory, but the directory where the main script lives. Yes. should either be interpreted as the zipfile, or be replaced by the zipfile. In the case of executing the zipfile, the main script lives *in the zipfile*. It's baggage that is rarely needed, and the feature can be readily implemented in a different way for people who need it. I disagree with both statements. The bagage is much less than zipimport itself, which has proven to be quite useful. Nevertheless, zipimport built into the interpreter was by no means necessary; current users of it could have readily implemented it themselves, with no changes to Python. (In fact, Google's 'autopar' tool does exactly that to support Python 2.2, which lacks zipimport.) This is a very small, logical and useful extension to zipimport, and I believe you will find more uses for it than you expect (although I do believe you yourself don't have a need for it. I just don't think you're a typical Python programmer in this case :) +1. (Hi Andy! :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 366 - Relative imports from main modules
I'm in general in favor of this. I will accept it once there is a
working implementation that is satisfactory.
Are we planning on supporting this in 2.6? It might break some 2.5
code that messes with modules and packages?
--Guido
On 7/10/07, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
On 7/9/07, Nick Coghlan [EMAIL PROTECTED] wrote:
Given the above limitations, I propose that we document the new
attribute as follows:
If the module global __package__ exists when executing an import
statement, it is used to determine the base for relative imports,
instead of the __name__ and __path__ attributes.
That's fine. __path__ actually isn't used to resolve relative imports
into absolute ones anyway; it's used only as a substitute to sys.path
when importing within a package.
I was referring to the fact that if __path__ is present (indicating a
package), then the relative import is based directly on __name__,
otherwise it is based on __name__.rpartition('.')[0].
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Add a -z interpreter flag to execute a zip file
On 08:41 am, [EMAIL PROTECTED] wrote: On 7/12/07, Thomas Wouters [EMAIL PROTECTED] wrote: I disagree with both statements. The bagage is much less than zipimport itself, which has proven to be quite useful. Nevertheless, zipimport built into the interpreter was by no means necessary; current users of it could have readily implemented it themselves, with no changes to Python. I wonder, is it even necessary to say anything, after: +1. ? But, since I so often object to new features, and there is a heavy Google bias in the existing survey sample, I would like to say that I had a problem several months ago in a _radically_ different environment (Twisted running on an embedded system, Zipfile of PYCs used to shave off as much disk space and startup time as possible) where having the subtleties of a -z flag figured out already would have saved me a _ton_ of work. I was already aware of the shell-header trick, but discovering all the environment-setup details was tedious and distracting enough to make me give up and switch to writing a bunch of hard-to-test /bin/sh code. It wasn't a bad project by any means, and Python worked out even better than expected (we weren't even sure if it would be able to load into the memory available, but it turns out that being able to do everything in a single process helped a lot) but a -z option would have been that much more impressive :). In fact, I distinctly remember thinking You know, if Python had an equivalent to Java's '-jar' option, this would be a whole lot easier. (Even better, on this _particular_ project, would have been a generic run this thing-which-looks-like-a-sys.path-entry standard format, which could have been switched for different deployments to a directory, a zipfile, or the result of freezing. Perhaps that's starting to get too obscure, though.) ___ 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] Add a -z interpreter flag to execute a zip file
On 12/07/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I wonder, is it even necessary to say anything, after: +1. [...] In fact, I distinctly remember thinking You know, if Python had an equivalent to Java's '-jar' option, this would be a whole lot easier. I'm also +1 on this, for exactly the same reason - I've often thought that an equivalent of -jar would be useful, but whenever I've had a go at implementing it myself, the fiddly bits needed have meant that it ended up not being cost effective to bother... Paul. ___ 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] Add a -z interpreter flag to execute a zip file
On 12/07/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Right, but it's supposed to be cross platform, as mentioned in the patch. This will work on Windows. But in the description, you said that you do the same on Windows by making a file that is both a zip file and a batch file. So my approach is also cross-platform, no? Getting the details of such a batch file header right on Windows is not easy, not least because there is no exec equivalent on Windows. The following works, but (a) uses 2 processes, and (b) doesn't preserve the exit code. The first issue is minor, but the second is a big problem (and one I don't know how to fix). Also, on Windows, zip-packaged GUI programs could be useful - these would be executed using pythonw -z How do you get the -z option to work on Windows? What extension do you use, and how is the zipfile created? The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). It also offers a script for building the zipfiles - either as sample code, or to be included with Python (it's not clear to me). It's arguable that .pyz files should use pythonw -z, not python -z, as file extensions are more often useful for clickable programs in the GUI. You could have two extensions (.pyz and .pzw, maybe) but I'm not sure it's worth it. The point here is that the fiddly part (setting sys.path, locating the main module, etc) is covered by the -z option, deployment considerations are easier to handle (and hence the exact defaults supplied are less crucial) once -z is available. Paul. ___ 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] Add a -z interpreter flag to execute a zip file
At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote: should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. Right; it should be replaced with the zipfile path instead. I would personally rather see this option defined as simply placing a directory at the front of sys.path, and perhaps defining a default -m value of __main__, unless overrridden. Being able to use the option more than once would be nice, too. On Windows, you can't set an environment variable on the same line as a command, so this would give you a one-liner way of setting sys.path and running an application. I do not see a reason to make this option zipfile-specific in any way, though; it's just as useful (and sometimes more so) to be able to distribute an application as a directory, since that lets you use .pyd, .so, .dll etc. without needing the egg cache system for using those. Why that? Why do eggs fail to process $0 correctly, whereas the -z option gets it correct? That just sounds like a bug in eggs to me, that could be fixed - or, if not, I'd expect that -z cannot fix it, either. My understanding of this note is that pkg_resources uses sys.argv[0] to determine the version number of the egg; IIUC, -z won't help at all here because sys.argv[0] will still be the name of the symlink. That's correct; it will not help. A change in the zipped .egg format is required, but could be done. If the option is added (again, without being zipfile-specific!) then there is a reason for me to make the change. ___ 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] Add a -z interpreter flag to execute a zip file
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: But in the description, you said that you do the same on Windows by making a file that is both a zip file and a batch file. So my approach is also cross-platform, no? How do you get the -z option to work on Windows? What extension do you use, and how is the zipfile created? Nick suggested using .pyz, and others seem to like that solution (possibly using pythonw) and that seems logical enough to me. If it's agreed that that's the right solution on Windows, I can put in the work for that. Couldn't that also be achieved by documenting best practice in the documentation? Why is the shell script not robust? I think it's pretty clear that it's not robust, and there have been even more anecdotal examples on this thread. Everyone does it slightly differently -- not for any particular reason, but just because the right thing isn't trivial. As I pointed out, the example you came up with (which many others would come up with too) has a fairly serious problem, in that it will import things from outside the .zip file. I could build my .zip file on my system, test it out, and then deploy it to another machine and it will break. Ironically, this happened to *me* while developing the patch! Why that? Why do eggs fail to process $0 correctly, whereas the -z option gets it correct? That just sounds like a bug in eggs to me, that could be fixed - or, if not, I'd expect that -z cannot fix it, either. My understanding of this note is that pkg_resources uses sys.argv[0] to determine the version number of the egg; IIUC, -z won't help at all here because sys.argv[0] will still be the name of the symlink. OK, I could be mistaken here, I haven't actually repro'd this bug. What are those weird hacks, why are they necessary, and how does the -z option overcome the need for these hacks? That people fail to make it work with /bin/sh doesn't automatically mean they succeed with -z. Either they are too unexperienced to make the shell header correct (in which case documenting best practice would help), or they have deeper problems with that approach, in which case it isn't at all obvious that the proposed change improves anything. I don't think this is true at all. I have provided the sample code to make one of these files, and so you basically have to run a command line, rather than write a shell header -- and the shell header is currently not documented anywhere. As mentioned, this approach also prevents you from having to start the shell, and makes it more portable, since people might use #!/bin/myfavoriteshell or use #!/bin/sh and not realize they are using system-specific features of the shell. Another example is that the behavior of the zip in your example depends on what else is in the current directory [1], which isn't desirable. Nick pointed out this issue and I addressed it in the patch by removing from sys.path, since the -c flag adds that. should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. Regardless of what *should* be interpretreted as, the example you gave has the problem mentioned (with current versions of Python) -- that *is* the current directory and thus things get imported outside of the zip file when they are not found in the zip file. Right now is replaced with the zip file. If there's a better implementation I'm willing to change it. As mentioned, it's also a very tiny amount of code, and I don't see much potential for bad interactions with other things, the way I've written it. It's baggage that is rarely needed, and the feature can be readily implemented in a different way for people who need it. I also disagree with both statements. : ) I think others have said basically the exact same thing as I am saying: that it is *commonly* needed, it's not a lot of baggage in Python since it's so little code, and it's easy to get wrong. Andy ___ 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] Add a -z interpreter flag to execute a zip file
On 7/12/07, Phillip J. Eby [EMAIL PROTECTED] wrote: At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote: should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. Right; it should be replaced with the zipfile path instead. That's indeed what the current implementation does, replacing with the zip file. I would personally rather see this option defined as simply placing a directory at the front of sys.path, and perhaps defining a default -m value of __main__, unless overrridden. Being able to use the option Actually, that's a good idea, and it does work with my current implementation [1], although we'd have to change the name __zipmain__. Is __main__ a good idea considering that is used for something similar but implemented completely differently (the module name)? I thought about using __main__, but decided on __zipmain__ since seemed to be more explicit and reduce potential conflicts. To be clear to other readers, the convention would be that if a __main__.py file exists at the root of a directory, then the whole directory is considered an executable python program. more than once would be nice, too. On Windows, you can't set an environment variable on the same line as a command, so this would give you a one-liner way of setting sys.path and running an application. I do not see a reason to make this option zipfile-specific in any way, though; it's just as useful (and sometimes more so) to be able to distribute an application as a directory, since that lets you use .pyd, .so, .dll etc. without needing the egg cache system for using those. Yes, the dynamic library importing is nice. thanks, Andy 1) andychu testprog$ find . ./__init__.py ./package1 ./package1/__init__.py ./package1/foo.py ./package1/lib.py ./__zipmain__.py andychu testprog$ ../python -z . lib module here argv: ['.'] andychu testprog$ ___ 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] Add a -z interpreter flag to execute a zip file
Phillip J. Eby wrote: At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote: should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. Right; it should be replaced with the zipfile path instead. I would personally rather see this option defined as simply placing a directory at the front of sys.path, and perhaps defining a default -m value of __main__, unless overrridden. Being able to use the option more than once would be nice, too. On Windows, you can't set an environment variable on the same line as a command, so this would give you a one-liner way of setting sys.path and running an application. I do not see a reason to make this option zipfile-specific in any way, though; it's just as useful (and sometimes more so) to be able to distribute an application as a directory, since that lets you use .pyd, .so, .dll etc. without needing the egg cache system for using those. I've thought about this a little further since my last comment on SF, and I think it may be a better idea to handle this as a runpy module parameter rather than as a parameter for the main interpreter. For those that aren't aware, the two commands: python -m module python -m runpy module actually have the same effect - both run the specified module. The second version is just a little indirect, as it first executes the runpy module, which then makes its a second call to run_module(). It was done this way so that -m style functionality was readily available for Python versions prior to 2.4. The current version of runpy doesn't accept any options, but it would be pretty easy to make the following changes: 1. Accept a -p option that prepends path entries. These path entries would be combined into a single list from left to right on the command line, then the whole list prepended to sys.path. If at least one -p option is given, the default '' entry would be removed from sys.path (the current directory could be added back in explicitly via -p '.'). 2. Attempt to run the module __main__ if no module is otherwise specified Startup would be fractionally slower than it would be with the C-level option, but the code would be much simpler, and the new feature would be readily available on any Python implementation which can execute the runpy module. The relevant shebang line to be prepended to a zip file would then look something like: #!/usr/bin/env python -m runpy -p Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
[Python-Dev] Python developers at Google (was Re: Add a -z interpreter flag to execute a zip file)
On 7/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] 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 ___ 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] Add a -z interpreter flag to execute a zip file
At 01:46 AM 7/13/2007 +1000, Nick Coghlan wrote: The current version of runpy doesn't accept any options, but it would be pretty easy to make the following changes: 1. Accept a -p option that prepends path entries. These path entries would be combined into a single list from left to right on the command line, then the whole list prepended to sys.path. If at least one -p option is given, the default '' entry would be removed from sys.path (the current directory could be added back in explicitly via -p '.'). 2. Attempt to run the module __main__ if no module is otherwise specified Startup would be fractionally slower than it would be with the C-level option, but the code would be much simpler, and the new feature would be readily available on any Python implementation which can execute the runpy module. The relevant shebang line to be prepended to a zip file would then look something like: #!/usr/bin/env python -m runpy -p I don't have any particular objection to using runpy for this, but I believe that this shebang line won't actually work on certain non-BSD OSes, such as most Linux versions, which allow you to have at most *one* argument to a #! line, and will combine anything after the executable portion into a single argument. This means that the only workable form of this line for cross-platform use is: #!/usr/bin/python2.6 -z And of course that won't work if Python is somewhere else. You can't both use env to invoke Python, *and* expect arguments to work. env will receive a single argument of python -m runpy -p, which it will then try to invoke. On Mac OS and various other BSDs, your example will work correctly, but it won't work most anywhere else, as few OSes actually support passing individual arguments from a #! line. See: http://www.in-ulm.de/~mascheck/various/shebang/ ___ 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] Add a -z interpreter flag to execute a zip file
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__. ;-) ___ 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
[Python-Dev] Typo in itertools.dropwhile()
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 ___ 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] Python developers at Google (was Re: Add a -z interpreter flag to execute a zip file)
Neal We need to hear more from people outside of Google to ensure we Neal are doing the best possible job. It would also be great to have Neal more active committers that don't work at Google. Are you worried that Google might get hit by a bus? wink 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] Add a -z interpreter flag to execute a zip file
The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). Ok. It would be good if the patch actually added that extension, rather than merely suggesting that it should be added. 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] Add a -z interpreter flag to execute a zip file
The relevant shebang line to be prepended to a zip file would then look something like: #!/usr/bin/env python -m runpy -p I might be confusing things, but I think some systems only allow a single argument in the shebang line. 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
[Python-Dev] Subversion branch merging
I'm tasked with performing a number of merge operations across various Python branches. Can somebody please share a command line that I should use to continue with the merge tracking that has been used? Is that documented somewhere? 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] Subversion branch merging
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: I'm tasked with performing a number of merge operations across various Python branches. Can somebody please share a command line that I should use to continue with the merge tracking that has been used? Is that documented somewhere? You mean using svnmerge? If so, see the dev FAQ: http://www.python.org/dev/faq/#how-do-i-merge-branches . If you are after something else then I don't know. =) I do know, though, that Thomas kept talking about moving us over to Bazaar (or some distributed VCS) and instead of having a ton of svn branches we have distributed VCS branch for each feature in Py3K. That way the VCS's strong merge system would work in our favour for pulling in from the various Py3K branches and for eventual mainline merging. -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] Add a -z interpreter flag to execute a zip file
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). Ok. It would be good if the patch actually added that extension, rather than merely suggesting that it should be added. So does everyone agree that there should be a new extension called .pyz? And that the definition of this is a .zip file with a __zipmain__.py module at its root? If so, I can make the change... I haven't looked around the codebase yet but it sounds easy enough. This makes it seem like a bigger change than it is, but I think it's the right thing to do to support Windows properly. Other points: * I think it's true that the shebang line should only have one argument. * Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case. 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. * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. thanks, Andy ___ 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] Add a -z interpreter flag to execute a zip file
At 10:53 PM 7/12/2007 +0200, Martin v. Löwis wrote: The approach is cross-platform, in that you can use the approach on different platforms. The result of the approach, however, is not cross-platform. You can't distribute your single zip-as-executable to both Windows and bourne-shell-using platforms. The -z argument does allow that. I still don't understand how so. How will this work on Windows? Via the .pyz extension on Windows, and a shebang header everywhere else... although the path and possibly Python version will have to be hardcoded in the shebang line. The -z argument makes it extremely simple: the user decides which python to run, and the program is run directly just like it would if it was unpacked and run that way. Really? I think there a still a number of subtleties, like what sys.argv[0] will be, and how sys.path will look like. It's definitely *not* the same as if you unzipped it, and ran the unzipped one. IMO, sys.argv[0] should equal the -z argument, as should the script directory entry on sys.path. Actually, the more I think about this, the more I'm leaning towards getting rid of the option and just having the startup code check whether sys.argv[0] can be mapped to an importer object, and if so, importing __main__ from it. A special python script file importer type could be implemented for file objects, so that importing __main__ from it will execute the contents of the file in a __main__ module. This approach would provide uniform argv[0] handling (in that python argv[0] will always rerun the same program) and allow zipfile shebangs to use 'env' to invoke Python, since no command-line option is then required. There is one slight complication: the python script file importer must adjust sys.path[0] to the directory of the script, instead of the script itself. ___ 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] Add a -z interpreter flag to execute a zip file
#!/usr/bin/env python -m runpy -p Martin I might be confusing things, but I think some systems only allow Martin a single argument in the shebang line. It's always been my impression that all Unix or Linux systems have that constraint. I've never heard of that restriction being relaxed. 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] Add a -z interpreter flag to execute a zip file
At 03:52 PM 7/12/2007 -0700, Andy C wrote: On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). Ok. It would be good if the patch actually added that extension, rather than merely suggesting that it should be added. So does everyone agree that there should be a new extension called .pyz? And that the definition of this is a .zip file with a __zipmain__.py module at its root? If so, I can make the change... I haven't looked around the codebase yet but it sounds easy enough. Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes SenseTM. * Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case. 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). 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. * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. I personally don't see any benefit to making up an extra name, when we already have one that describes the functionality perfectly. There is absolutely nothing about -z that needs or should care about zipfile-ness, so why add an unnecessary limitation while creating yet another __special__ name to remember? ___ 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
[Python-Dev] Registry keys written by x64 installer
After installing the x64 version of Python 2.5.1 via the MSI file on python.org, I noticed most of the registry keys are missing. Further investigation shows they aren't actually missing, but have simply been virtualized, so they actually appear under the Wow6432Node key. This Wow6432Node key is used by 32bit programs running on a 64bit OS. Ironically, this means that a 32 bit Python can open HKLM\Software\Python - the OS virtualizes that request to the Wow3264Node tree. However, a 64 bit Python (ie, the very Python that was installed by the MSI) fails to open that key - no vistualization occurs and as the key specified does not exist, we fail. For example: This is the Python 2.5 installed by the MSI installer: Python 2.5.1 (r251:54863, Apr 18 2007, 09:02:36) [MSC v.1400 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import _winreg _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, Software\\Python\\PythonCore) Traceback (most recent call last): File stdin, line 1, in module WindowsError: [Error 2] The system cannot find the file specified But if I use a 32bit version of Python: Python 2.5.1 (release25-maint, Jun 4 2007, 23:00:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import _winreg _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, Software\\Python\\PythonCore) PyHKEY at 004790B0 (0098) It works. I'm afraid my knowledge of MSI is very limited, so I'm not sure where to start. One thing I did notice is that msilib\__init__.py has a variable 'Win64' set, hard-coded to 0 - but I've no idea if it is relevant. Presumably it is relevant to *something*, otherwise it would not have been created - but its unclear when and how this should be set to 1, and if this should concern people trying to use bdist_msi to create x64 extension packages - but for now, let's just stick with the topic at hand - the registry keys set by the installer. Any clues? Thanks, Mark ___ 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] Registry keys written by x64 installer
On 7/12/07, Mark Hammond [EMAIL PROTECTED] wrote: I'm afraid my knowledge of MSI is very limited, so I'm not sure where to start. One thing I did notice is that msilib\__init__.py has a variable 'Win64' set, hard-coded to 0 - but I've no idea if it is relevant. Presumably it is relevant to *something*, otherwise it would not have been created - but its unclear when and how this should be set to 1, and if this should concern people trying to use bdist_msi to create x64 extension packages - but for now, let's just stick with the topic at hand - the registry keys set by the installer. Per the requirements documented at http://msdn2.microsoft.com/En-US/library/aa372396.aspx, the behavior you describe is expected for a 32-bit installer. (To install files and registry to 64-bit locations, the Template Summary must include Intel64 or x64 depending on which architecture, and the component must be marked as 64-bit). I'm not familiar with how msilib is invoked to create the MSI files in question, but it does look like setting Win64 to 1 at an early enough time would cause an Intel64 installer to be built, along with entirely 64-bit components. This wouldn't work for x64 machines, and all components being 64-bit may be incorrect: potentially the 64-bit installer should have some 32-bit components. -- Michael Urman ___ 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] Add a -z interpreter flag to execute a zip file
At 03:52 PM 7/12/2007 -0700, Andy C wrote: So does everyone agree that there should be a new extension called .pyz? And that the definition of this is a .zip file with a __zipmain__.py module at its root? If so, I can make the change... I haven't looked around the codebase yet but it sounds easy enough. I'm not a Windows user, so don't have a good feel for the state of the extension mess on that platform these days. PYZ isn't listed on filext.com, but I don't know if that means much. On Thursday 12 July 2007, Phillip J. Eby wrote: Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes SenseTM. Indeed. Let's not do something so specific it's a pain to use. Andy C: * Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case. Yes. A use case for using directories, or for *not* supporting them? These cases should be as similar as possible; like Phillip suggested, we should be thinking sys.path entry rather than zip file. Phillip Eby: 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). What happens if multiple entries contain __main__.py entries? I don't like this one so much. I don't know what Java does if you specify -jar more than once; that might suggest something. 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. Agreed. Andy: * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. Identifying ZIP files is straightforward; there's nothing weird about this one. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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] Add a -z interpreter flag to execute a zip file
On 7/12/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: Phillip Eby: 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). What happens if multiple entries contain __main__.py entries? I don't like this one so much. I don't know what Java does if you specify -jar more than once; that might suggest something. You can't with: java version 1.5.0_11 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode) -help says: or java [-options] -jar jarfile [args...] (to execute a jar file) args are passed to the jarfile being run. $ java -jar xalan2.jar -jar xalan2.jar Invalid option: -jar Invalid option: xalan2.jar n ___ 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] Typo in itertools.dropwhile()
[Matthieu on itertools.dropwhile() docs] 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 ? It is correct as written. Given a sequence where predicate is true 1000 times and then alternately false and true, it returns the part that is alternately false and true. So, it did DROP (omit, not return, skip-over, etc) the first 1000 true items and it did return EVERY element from the first false to the end. It did not produce any output for the first 1000 inputs so it took a while to get to the first output (the first false). Hope that clears it up for you. Raymond ___ 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] Subversion branch merging
Brett Cannon wrote: On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: I'm tasked with performing a number of merge operations across various Python branches. Can somebody please share a command line that I should use to continue with the merge tracking that has been used? Is that documented somewhere? You mean using svnmerge? If so, see the dev FAQ: http://www.python.org/dev/faq/#how-do-i-merge-branches . If you are after something else then I don't know. =) I do know, though, that Thomas kept talking about moving us over to Bazaar (or some distributed VCS) and instead of having a ton of svn branches we have distributed VCS branch for each feature in Py3K. That way the VCS's strong merge system would work in our favour for pulling in from the various Py3K branches and for eventual mainline merging. -Brett Hi all, While I'm generally just a silent listener to this list, I thought I'd share my experiences with distributed SCM - primarily because I think it's a great step in the right direction. So far I've used DARCS, Hg, and Git. And at this point Git is far and away the winner. While I can't claim to have spent alot of time with DARCS, my experience was that it took a fair whack of unintuitive pain to work out how to extract a patch that I could send upstream to be submitted to a project. I believe it also has a reputation for being rather slow. I've also noticed that repositories sometimes become broken and need to be re-checked out - but that I'm willing to put down to some other factor I'm not aware of. With Hg I went in fast and hard, and nearly got burned before I could bail out in time :-) It's very friendly to use, but we run a number of OpenBSD hosts for our core architecture, and it turns out Hg wraps calls to patch, and parses the text output from the call (assuming the version of patch is GnuPatch). The problem here is that under OpenBSD the output assumptions get violated, as reflected by the failure of lots of tests - including repository sanity checks. That meant Hg just wasn't going to be an option for us. I also found that having a new directory tree of files for each branch was rather onerous. Having bailed on Hg I found git to be fast, cross platform, and user-friendly (provided you understand the basic concepts of distributed SCM, and you're using git 1.5+ ;-) ). It also has some really cool features like rebasing for letting your branch actively track the trunk from which you branched it. I can't speak to how easily any of these cross over to the windows platform, although none of them seem to be overly windows friendly (YMMV). But I presume this would be one of the key problems facing a distributed versioning system by the python community. Cheers Dave ___ 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] Add a -z interpreter flag to execute a zip file
On 7/12/07, Phillip J. Eby [EMAIL PROTECTED] wrote: At 03:52 PM 7/12/2007 -0700, Andy C wrote: On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). Ok. It would be good if the patch actually added that extension, rather than merely suggesting that it should be added. So does everyone agree that there should be a new extension called .pyz? And that the definition of this is a .zip file with a __zipmain__.py module at its root? If so, I can make the change... I haven't looked around the codebase yet but it sounds easy enough. Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes SenseTM. 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? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop? There aren't any restrictions on what can be in __main__ (it's just another module), and while I think it would be a bad practice to import __main__, I could see people being tripped up by this in practice. People might start storing silly things like the program version there, for convenience. 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. * Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case. 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? Just curious, I have never felt a need to do that. I use Python on Windows frequently. 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. But I don't have a clear enough picture from all the comments of what exactly to implement. -z is not the same as prepend an item to sys.path, because we replace with the -z argument. And we also munge sys.argv[0] (which is what you said should happen). So it's not clear to me at all what multiple -z's should do, exactly. Can you write out the pseudo code? Or modify my patch. I think it would be fine to have both a -z and -p flag, if the functionality is needed. -z accepts a zip file or a directory and does the right thing to run it as an executable. -p could accept multiple arguments and literally prepends them to sys.path. These seem like different things to me. I'll look at adding the file association for .pyz (is there an expert on that for questions?), and in that time hopefully the list can decide on the rest of the issues. Or we can just make Guido decide, which is fine by me. : ) Andy ___ 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] Registry keys written by x64 installer
Per the requirements documented at http://msdn2.microsoft.com/En-US/library/aa372396.aspx, the behavior you describe is expected for a 32-bit installer. Agreed - but unless I'm missing something, this release is not expected to be a 32bit installer. (To install files and registry to 64-bit locations, the Template Summary must include Intel64 or x64 depending on which architecture, and the component must be marked as 64-bit). I'm not familiar with how msilib is invoked to create the MSI files in question, but it does look like setting Win64 to 1 at an early enough time would cause an Intel64 installer to be built, along with entirely 64-bit components. This wouldn't work for x64 machines, Why wouldn't it work for x64 machines? Is it simply because msilib only handles Intel64 when that flag is set? and all components being 64-bit may be incorrect: potentially the 64-bit installer should have some 32-bit components. What 32bit components should a 64bit build of Python include? Perhaps you mean *could* - but IIUC, there is no intention to release 32bit and 64bit versions of Python in a single package (and further, IIUC, no intent on supporting a 32bit and 64bit installation on the same machine, regardless of packaging) I'm afraid its not clear to me if you are agreeing with me (ie, that the registry keys are incorrect), or disagreeing with me (the keys are what you would expect a correct x64 install to create)? I think you are agreeing, but sounding a caution that it might not be trivial to fix, but I would like to be sure... Cheers, Mark ___ 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] Add a -z interpreter flag to execute a zip file
Another issue I see is that -m and -c have command line parsing semantics, and -z follows those now. python -z foo.zip -z bar As implemented, this would pass sys.argv[0:3] == ['foo.zip', '-z', 'bar'] If you allow multiple -z flags to be meaningful, this gets confusing. The foo.zip program could have a legitimate -z flag. If you overload -z to mean prepend things to sys.path, then you might also want to do python -z /dir1 -z /foo.zip -c 'import foo; print foo'. Should this execute dir1/__main__.py, foo.zip/__main__.py or print foo? I could be missing what you intend. But I think the patch as implemented doesn't have any of these potentially unconsidered cases and unintended consequences. Andy ___ 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] Typo in itertools.dropwhile()
2007/7/13, Raymond Hettinger [EMAIL PROTECTED]: [Matthieu on itertools.dropwhile() docs] 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 ? It is correct as written. Given a sequence where predicate is true 1000 times and then alternately false and true, it returns the part that is alternately false and true. So, it did DROP (omit, not return, skip-over, etc) the first 1000 true items and it did return EVERY element from the first false to the end. It did not produce any output for the first 1000 inputs so it took a while to get to the first output (the first false). Hope that clears it up for you. Hi, Thanks for the answer. I agree with you, but this explains the first sentence. The second says that nothing is output until the predicate is true. It should say while the predicate is true or until the predicate is false. But I could be misunderstand 'until' as well (English is not my mother tongue, but still...) Matthieu ___ 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] Subversion branch merging
Dave Harrison writes: While I can't claim to have spent alot of time with DARCS, my experience was that it took a fair whack of unintuitive pain to work out how to extract a patch that I could send upstream to be submitted to a project. This doesn't seem to be a common issue with Darcs, but obviously your mileage varies. I believe it also has a reputation for being rather slow. I've also noticed that repositories sometimes become broken and need to be re-checked out - but that I'm willing to put down to some other factor I'm not aware of. Both of these are acknowledged by the core Darcs developers. Recently several users posted their regrets to the Darcs mailing lists, and the developers only said something like we're working on it, so please come back and check. IMO Darcs is a non-starter for a large project at this point. It also has some really cool features like rebasing for letting your branch actively track the trunk from which you branched it. Unfortunately, rebasing doesn't seem to be stable yet. Sometimes it works for me, sometimes not. I don't know whether its because I don't know what I'm doing, bugs in git, or changes in the calling syntax. (NB, git rebase is basically just what the Arch people call tla update, and darcs's claim to fame is that you don't need to distinguish between a rebase and a simple pull, darcs calculates it for you.) ___ 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] Typo in itertools.dropwhile()
Raymond Hettinger writes: [Matthieu on itertools.dropwhile() docs] Note, the iterator does not produce any output until the predicate is true it did return EVERY element from the first false Shouldn't the until in the doc be while? Alternatively, true could be changed to false. ___ 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
