Re: [Python-Dev] Typo in itertools.dropwhile()
Stephen J. Turnbull [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | 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. As I understand the first sentence, yes. ___ 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
Andy C wrote: So does everyone agree that there should be a new extension called .pyz? How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. - Anders ___ 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
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. Sure. However, you *can* specify multiple jar files on the command line, in the class path. java -cp xerces.jar -jar xalan2.jar This runs xalan2.jar, but adds xerces.jar to the class path. It has all the advantages of a command line option compared to setting CLASSPATH: it won't be inherited to subprocesses, and you can use it on Windows, too, whereas you cannot set environment variables in the command line on Windows. So while -z strictly gives the equivalent -jar, it's actually -cp that is used much more often in Java (I think), and that doesn't have an equivalent in Python still. My typical usage of java goes like this java -cp endless list of jar files the.main.class The equivalent Python line would be python -p path -m main_module 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
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. Not to diverge py-dev too far into the depths of DRCS usage, but are you doing anything particularly complex ? While I wouldn't say I do it regularly, I certainly consider it part and parcel of general git usage, and I've always found it works well for me. Rebasing is one of the features that really convinced me git was a cut above the rest, obviously along with the ease of merging. For those that are interested the ultra brief explanation for git branching is that it stores all your branches in the one directory structure. You git checkout to switch between branches, which causes all the managed files in your directory to be changed to reflect the state branch you are changing to. ___ 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
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. There are several places where 64-bitness need to be considered: you need to set the architecture of the entire MSI file, and the installer sets it to x64 (Intel64 means Itanium). In addition, you can set the Win64 bit on components, and msilib sets it on all components, AFAIK. 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] Registry keys written by x64 installer
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? Please take a look at msilib.set_arch_from_file. This takes an executable file, determines the processor architecture, and then sets both MSI type (the PID_TEMPLATE SummaryInformation field), and the Win64 variable, which should cause all components to become Win64 components (i.e. flag 256 being set). 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] Registry keys written by x64 installer
On Friday, 13 July 2007, Michael Urman wrote: Furthermore only one architecture may be set in the template summary, so an installer may be only one of i386, x64, and Intel64 (although the latter are assumed to also be able to run i386 binaries). I suspect I'm still missing something here. The title of the page you referenced before is Using 64-Bit Windows Installer Packages - I suspect that is different than a 32-Bit installer package installing a 64bit program! Agreed. I was just making clear that I'm not familiar with what the MSI includes, and whether any of the components in a 64-bit install should be 32-bit or not. With the msilib code as is, it appears to be all or nothing, or rely on tweaking a global between calls to start_component. Yes - that is a bit of a shame, as having 32bit components would allow more flexibility (eg, allow a 64bit install of Python to work with an IIS configured for 32bit extensions), but that's something we can deal with later if necessary. If you just want to get to the keys it currently sets, there should be an override parameter that causes the registry API to read the 32-bit keys even in a 64-bit process, but I'm not familiar with using _winreg. using _winreg is (almost) like using the API directly. RegDisable[/Enable]ReflectionKey appears to let the 32bit process see the real keys - I'm not aware of how 64bit apps would enable that reflection, but it probably doesn't really matter for our purposes. In case anyone is interested, I just made a patch to _winreg.c adding these 2 functions (http://python.org/sf/1753245) in case anyone would like to review it. If there's interest and I can get pointers to where the MSI files are built, I can look into patching it. I don't have a convenient 64-bit Windows machine around to test any changes, though. I think Tools\msi is what you are looking for, but hopefully Martin will chime in. I'm more than happy to help test. 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] Subversion branch merging
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 think that's what I'm looking for. Thanks, 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] Registry keys written by x64 installer
Michael Urman schrieb: On 7/12/07, Mark Hammond [EMAIL PROTECTED] wrote: Why wouldn't it work for x64 machines? Is it simply because msilib only handles Intel64 when that flag is set? Right - it sets the template summary to include Intel64, not x64. You might be looking at the wrong version. In Python 2.5, it also sets it to x64, if the PE machine type is 0x8664. Furthermore only one architecture may be set in the template summary, so an installer may be only one of i386, x64, and Intel64 (although the latter are assumed to also be able to run i386 binaries). Right. That's why I provide three installers. Agreed. I was just making clear that I'm not familiar with what the MSI includes, and whether any of the components in a 64-bit install should be 32-bit or not. With the msilib code as is, it appears to be all or nothing, or rely on tweaking a global between calls to start_component. That's correct. I'm also uncertain what precisely the Win64 flag on a component means, according to http://msdn2.microsoft.com/EN-US/library/aa368007.aspx msidbComponentAttributes64bit means # Set this bit to mark this as a 64-bit component. This attribute # facilitates the installation of packages that include both 32-bit and # 64-bit components. If this bit is not set, the component is registered # as a 32-bit component. # # If this is a 64-bit component replacing a 32-bit component, set this # bit and assign a new GUID in the ComponentId column. When I started to work on this, I found that not setting the Win64 bit at all does not work, although I forgot the details what precisely failed. I found some articles in the net that suggest that this flag turns off redirection, e.g. http://blogs.msdn.com/heaths/archive/2006/04/14/avoid-overwriting-files-in-administrative-installations.aspx As we don't want any redirection, setting the flag on all components should be correct. The former, with hints of caution: it appears the unused 64-bit code paths of msilib were created to best serve under incorrect assumptions. With what the code would create (with or without Win64 set), it will not generate the 64-bit registry keys that the 64-bit program will access. Why do you say that? What registry keys do you think it creates, and what registry keys do you think it should create instead? There are no 64-bit registry keys on Windows; Win64 only has normal registry keys and 32-bit (i.e. redirected) registry keys. With Win64 set it will not even install except on an Itanium system. I always test whether the AMD 64 binary installs correctly before releasing it. If you just want to get to the keys it currently sets, there should be an override parameter that causes the registry API to read the 32-bit keys even in a 64-bit process, but I'm not familiar with using _winreg. If there's interest and I can get pointers to where the MSI files are built, I can look into patching it. I don't have a convenient 64-bit Windows machine around to test any changes, though. You don't need to provide patches - just tell me what's wrong with the MSI file. I.e. look at it in orca, correct it so that it works correctly, then report what changes you made. 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
Dave Harrison writes: Unfortunately, rebasing doesn't seem to be stable yet. Not to diverge py-dev too far into the depths of DRCS usage, but are you doing anything particularly complex ? As of git 1.5.0.something, git rebase --onto NEWBASE UPSTREAM just ignored the --onto flag AFAICT. As I say, I may have been abusing it to do something inappropriate. Basically I wanted to take the tip of BRANCH (which was experimental, but I'd accidentally done a bunch of generic typo fixing) and graft it onto the mainline. ___ 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 Friday 13 July 2007, Paul Moore wrote: Fair point. Doesn't it argue that there are valid uses for both -p and -z (in Python terms)? I'm not expert in Java usage, but on Windows, Indeed it does. I'd be happy for there to be a -p that allows both Windows and Unix users to prepend to sys.path. It should also be separate from the -z (or whatever that gets called). -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 Friday 13 July 2007, Anders J. Munch wrote: How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. I guess it would be pinheaded to call it .zippy. ;-) -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
Fred L. Drake, Jr. wrote: On Friday 13 July 2007, Anders J. Munch wrote: How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. I guess it would be pinheaded to call it .zippy. ;-) I believe .zpy would be most recognizable and lest subject to confusion. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - ___ 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/13/07, Mark Hammond [EMAIL PROTECTED] wrote: On Friday, 13 July 2007, Michael Urman wrote: I suspect I'm still missing something here. The title of the page you referenced before is Using 64-Bit Windows Installer Packages - I suspect that is different than a 32-Bit installer package installing a 64bit program! I haven't worked with it enough to know all the intracacies, but the short of what I know is if your template is i386, you can only install to 32-bit locations. If it is x64 or Intel64, then you can only install on machines of those architectures, and the 64-bit locations become available to components marked as 64-bit. using _winreg is (almost) like using the API directly. RegDisable[/Enable]ReflectionKey appears to let the 32bit process see the real keys - I'm not aware of how 64bit apps would enable that reflection, but it probably doesn't really matter for our purposes. In case anyone is interested, I just made a patch to _winreg.c adding these 2 functions (http://python.org/sf/1753245) in case anyone would like to review it. http://msdn2.microsoft.com/en-us/library/aa384129.aspx describes the KEY_WOW64_64KEY and KEY_WOW64_32KEY flags, allowing explicit access to either set from either type of application. I think Tools\msi is what you are looking for, but hopefully Martin will chime in. I'm more than happy to help test. Thanks, and I see he has, and perhaps I've been looking at an incorrect file... -- 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] Subversion branch merging
Dave Harrison wrote: [...] 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. We can probably assume that none of the Linux kernel team are developing on Windows. There is probably s a group with relevant experience somewhere. I'd Google for it, but I expect that the results would be dominated by British assertions that you have to be a stupid git to run Windows. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - ___ 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/13/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Michael Urman schrieb: Right - it sets the template summary to include Intel64, not x64. You might be looking at the wrong version. In Python 2.5, it also sets it to x64, if the PE machine type is 0x8664. I've looked most closely at http://svn.python.org/view/python/trunk/Lib/msilib/__init__.py?rev=47280view=auto, and from there not even full readings yet, just searching for Win64 to see what the flag did. No doubt I have missed several intracacies. As we don't want any redirection, setting the flag on all components should be correct. It may well be fine for the Python installers. Without the flag, locations such as the 64-bit folder destinations resolve to the 32-bit redirected locations, and the registry resolves to the 32-bit reflected registry. The former isn't particularly helpful in any case I can think of (as the non 64-bit locations are available anyway), but the latter could be important if an 64-bit install needs to set 32-bit registry keys. The former, with hints of caution: it appears the unused 64-bit code paths of msilib were created to best serve under incorrect assumptions. With what the code would create (with or without Win64 set), it will not generate the 64-bit registry keys that the 64-bit program will access. Why do you say that? What registry keys do you think it creates, and what registry keys do you think it should create instead? Perhaps it's my reading the wrong version (the one I linked above doesn't even have the string x64), or my assumption that msilib would target a more general use case than pure 64-bit / pure 32-bit installers. Or I missed the easy way to interleave 64 and 32-bit components. There are no 64-bit registry keys on Windows; Win64 only has normal registry keys and 32-bit (i.e. redirected) registry keys. I find that nomenclature distinction to be more confusing than referring to them incorrectly :) I always test whether the AMD 64 binary installs correctly before releasing it. And I ran no tests at all, so I defer to you here. You don't need to provide patches - just tell me what's wrong with the MSI file. I.e. look at it in orca, correct it so that it works correctly, then report what changes you made. That's even easier then, if anything's actually wrong. I'll find some time this weekend to look at it and report back. Would the one at the following URL be the correct one to verify? http://www.python.org/ftp/python/2.5.1/python-2.5.1.amd64.msi (linked from http://www.python.org/download/) -- 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] Typo in itertools.dropwhile()
Thank you very much ! Matthieu 2007/7/13, Raymond Hettinger [EMAIL PROTECTED]: [Stephen J. Turnbull] Shouldn't the until in the doc be while? Alternatively, true could be changed to false. Yes. I'll make the change. 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] Registry keys written by x64 installer
On 7/13/07, Michael Urman [EMAIL PROTECTED] wrote: That's even easier then, if anything's actually wrong. I'll find some time this weekend to look at it and report back. Would the one at the following URL be the correct one to verify? http://www.python.org/ftp/python/2.5.1/python-2.5.1.amd64.msi (linked from http://www.python.org/download/) Assuming this is the right file, the cause of the behavior Mark reported is pretty clear. While the template summary is indeed x64, the attributes on the registry components are all 4 instead of 256 | 4, so they are placed in the 32-bit reflected registry. I don't know if this is desirable for some other reason. -- 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
On Jul 12, 2007, at 1:58 PM, Phillip J. Eby wrote: 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/ Ah, but you *can* use some quite clever quoting to get that effect. E.g. this starts up python with /usr/bin/env and a -O argument: #!/bin/sh exec /usr/bin/env python -O $0 $@; Credit for this trick originally belong to someone else: I found this on some website, but I don't know where anymore. I'll leave it as a exercise to the reader to figure out how it works. :) James ___ 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 13/07/07, Martin v. Löwis [EMAIL PROTECTED] wrote: So while -z strictly gives the equivalent -jar, it's actually -cp that is used much more often in Java (I think), and that doesn't have an equivalent in Python still. My typical usage of java goes like this java -cp endless list of jar files the.main.class The equivalent Python line would be python -p path -m main_module Fair point. Doesn't it argue that there are valid uses for both -p and -z (in Python terms)? I'm not expert in Java usage, but on Windows, .jar files are associated with javaw -jar %1 %*, which would reinforce the suggestion that Python have a .pyz extension associated with pythonw -z %1 %*. Note the -w (GUI) form of both of these... 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] Registry keys written by x64 installer
I've looked most closely at http://svn.python.org/view/python/trunk/Lib/msilib/__init__.py?rev=47280view=auto, and from there not even full readings yet, just searching for Win64 to see what the flag did. No doubt I have missed several intracacies. Ah, ok. This should get fixed, but it isn't use to create the installer. Instead, look at http://svn.python.org/view/python/trunk/Tools/msi/msilib.py?rev=55245view=markup Perhaps it's my reading the wrong version (the one I linked above doesn't even have the string x64), or my assumption that msilib would target a more general use case than pure 64-bit / pure 32-bit installers. Why should it? I have yet to see a use case for that. That's even easier then, if anything's actually wrong. I'll find some time this weekend to look at it and report back. Would the one at the following URL be the correct one to verify? http://www.python.org/ftp/python/2.5.1/python-2.5.1.amd64.msi (linked from http://www.python.org/download/) Indeed. 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] Registry keys written by x64 installer
Assuming this is the right file, the cause of the behavior Mark reported is pretty clear. While the template summary is indeed x64, the attributes on the registry components are all 4 instead of 256 | 4, so they are placed in the 32-bit reflected registry. I don't know if this is desirable for some other reason. I found the same thing, and put a corrected installer at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.amd64.msi Mark, can you please report whether that fixes your problem? 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] Typo in itertools.dropwhile()
Actually, I think it *is* a typo: the last part should read that no output is produced until the predicate becomes *false*. - C On 7/13/07, Raymond Hettinger [EMAIL PROTECTED] wrote: [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/shiblon%40gmail.com ___ 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
(Sorry about top-posting: I'm using my blackberry while waiting for the bus and my gmail client doesn't do quoting :-( ) Certainly java won't let you specify -jar more than once, because that would be telling it to *run* two files. It *will*, however, let you specify more than one jar in the classpath. This is done all the time, making the contents of those jars available for importing. These aren't typically combined, since the whole point of running a jar file is to have a single distributed package, but IIRC it is not prohibited. - C On 7/12/07, Neal Norwitz [EMAIL PROTECTED] wrote: 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/shiblon%40gmail.com ___ 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()
[Stephen J. Turnbull] Shouldn't the until in the doc be while? Alternatively, true could be changed to false. Yes. I'll make the change. 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 12, 2007, at 5:54 PM, Brett Cannon wrote: 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. Mailman switch to Bazaar on June 22. The transition went pretty smoothly (the hardest part of the process was shutting off write access to Subversion ;). I know some of us were talking about it at Pycon, but I've now been using it for 4 or 5 more months. It's really a top-notch dvcs and I think it would bring a lot of benefit to the Python community. I'll see if I can set up some public bzr mirrors of our svn repository for people to try it out. Or you could just use the bzr- svn plugin to get a local repository. There are lots of key benefits to using a dvcs, but IMO the most important is that it helps democratize the development process, and makes it much easier for the core to review and accept contributions. diffs are so 20th century. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRpeZYnEjvBPtnXfVAQL0ugQArei77bNsmv1hdrfs6RGinNiBdhNvSet8 vprjc3JgdV0iBltSX2KvHj+xOEd49ImDtKSws1uQNDLzIGMzv65/P03d3udwd2fy VrzBrO9Nlw+YdWtfJEcwCmRGT7Zj4HNUhYxQUB/V/3dytjLZoCp3m5xYAbfj44be FThPPbnCeDI= =CuEJ -END 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
Re: [Python-Dev] Subversion branch merging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 13, 2007, at 11:25 AM, Barry Warsaw wrote: I'll see if I can set up some public bzr mirrors of our svn repository for people to try it out. Or you could just use the bzr- svn plugin to get a local repository. Silly me, the trunk is already available: https://code.launchpad.net/~vcs-imports/python/trunk I could certainly request that other branches be mirrored if there's any interest. Should the community ever decide to make the switch, I believe the entire Subversion history could be imported, though we may not care about the majority of existing branches. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRpea3nEjvBPtnXfVAQLZZAP9GeBgNh3t8fr5sA+sDk8gxnzp9ORQEaob jqB5GfFYtthDPpwWElAYDbnBIO2jBWiidagVu40Rh1eLrIP74x+OFFkVdgK1yGP2 NJ1lJvk0jEMgDleMz2GTtEwULQDvKWM8jtw3qrdhQgIkM5H+DintF4BgkmpbmXKj ecxLeQcvuR0= =Z360 -END 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
Re: [Python-Dev] Subversion branch merging
Barry diffs are so 20th century. :) How do you compare two versions of something without some sort of diff? 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
On Fri, Jul 13, 2007, Chris Monson wrote: Certainly java won't let you specify -jar more than once, because that would be telling it to *run* two files. It *will*, however, let you specify more than one jar in the classpath. This is done all the time, making the contents of those jars available for importing. These aren't typically combined, since the whole point of running a jar file is to have a single distributed package, but IIRC it is not prohibited. Actually, I do regularly use both classpath and -jar with java because I'm running a .jar file that does not contain the world. OTOH, this is a development environment rather than a production environment, so theoretically I could just shove everything into the .jar file -- but I don't because that adds more time to the compile/link/jarjarjar cycle. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I support the RKAB ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 13, 2007, at 11:39 AM, [EMAIL PROTECTED] wrote: Barry diffs are so 20th century. :) How do you compare two versions of something without some sort of diff? Well okay, you caught me being flippant. :) Sure, you visually compare with diffs, but you apply those changes with merges. This means the end of posting patches because instead what you would do is post the url to a branch that you published some place. It means that branch can be kept up-to-date as its parent branch changes, so a new feature candidate need never get stale. It also means your new feature candidate is a first class revision control branch, just as usable as the trunk, say. So it's much more powerful than trading patch files around. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRpekD3EjvBPtnXfVAQLBqwP/RbJ3VhArWjijJ99/u3CzAy0xbcvnUIEv htlZ/2PBXGZ+ZZm0uQiQcnwlczVUVAiyopdPgTAUmerh9aYWZTP8rtC3SIG7gBDz 6QdNYMl2Rvh5AsvLNXo3HzTyVx74cKHEy91csUuoUWomBa1dR9DVRsT+CpbwM4U8 q11cm7kjXa4= =v4w0 -END 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
Re: [Python-Dev] Subversion branch merging
2007/7/13, Barry Warsaw [EMAIL PROTECTED]: with merges. This means the end of posting patches because instead what you would do is post the url to a branch that you published some place. It means that branch can be kept up-to-date as its parent branch changes, so a new feature candidate need never get stale. It also means your new feature candidate is a first class revision control branch, just as usable as the trunk, say. So it's much more powerful than trading patch files around. More powerful, maybe, but also more limitating. Do you still have the patch metodologie? How can you provide a patch if you don't have a place to publish the change? 3rd-world--ly yours, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
Sure, you visually compare with diffs, but you apply those changes with merges. This means the end of posting patches because instead what you would do is post the url to a branch that you published some place. But how do you publish stuff? Do you need to run your own web server on your dial-up machine? I simply cannot imagine that all contributors have access to some machine that is always online and willing to host bzr patches (which is necessary IIUC). 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] Add a -z interpreter flag to execute a zip file
Andy C wrote: ... a .zip file with a __zipmain__.py module at its root? Why not just an __init__.py, which you would normally execute if you tried to import/run a directory? * 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__. Treating zip files (and only zip files) as a special case equivalent to uncompressed files seems like a wart; I would prefer not to special-case zips any more than they already are. If anything, I would like to see the -m option enhanced so that if it gets a recognized collection file type (including a directory or zip), it does the right thing. Whether that actually makes sense, or defeats the purpose of the -m shortcut, I'm not sure. [on using __main__ instead of __init__ or __zipmain__] __main__.py? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop? It doesn't today; it does use circular imports, which can be a problem. while I think it would be a bad practice to import __main__, I have seen it recommended as the right place to store global (cross-module) settings. -jJ ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 13, 2007, at 12:54 PM, Martin v. Löwis wrote: Sure, you visually compare with diffs, but you apply those changes with merges. This means the end of posting patches because instead what you would do is post the url to a branch that you published some place. But how do you publish stuff? Do you need to run your own web server on your dial-up machine? You could, but you certainly don't need to. For example, Launchpad [1] hosts bzr code branches for anyone working on open source software. Sign in (for free of course) and start pushing your own branches immediately[2]. However, there's also no reason why other such services couldn't be deployed, perhaps even hosted by the PSF, just like we do with Subversion. The difference is that it doesn't matter because unlike running multiple Subversion repositories, dvcs's in general are designed to be distributed (duh :). I simply cannot imagine that all contributors have access to some machine that is always online and willing to host bzr patches (which is necessary IIUC). Having access is easy. Self-publishing might not be something people want to do (it's certainly not something I want to do), but that's not a requirement. - -Barry [1] http://www.launchpad.net which is a service provided by Canonical. Full disclosure: I work for them. But I'm not touting that as a company shill; I really do think that bzr and the Launchpad code hosting service provide a lot of benefit. Be your own judge. [2] E.g. https://code.launchpad.net/~barry/munepy/trunk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRpe24nEjvBPtnXfVAQITRQP/YNKJ8GSU/vvXrAyIi/EHhQhGLyXma1Xg rSzDWbQV/khXGhnsxOEwdKJUXKHskyGkJFr0x3ClCyiAKyLAgpM/pgbknAfuE5mU 9oAD+K/aGYFem+BxoLfwFeE0eBqDw/NYvnQH3FHSPaEpTJ2eCtu+M6N7AB0MUQQH 9pL7VYT3bEk= =Hio1 -END 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
Re: [Python-Dev] Subversion branch merging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 13, 2007, at 12:24 PM, Facundo Batista wrote: 2007/7/13, Barry Warsaw [EMAIL PROTECTED]: with merges. This means the end of posting patches because instead what you would do is post the url to a branch that you published some place. It means that branch can be kept up-to-date as its parent branch changes, so a new feature candidate need never get stale. It also means your new feature candidate is a first class revision control branch, just as usable as the trunk, say. So it's much more powerful than trading patch files around. More powerful, maybe, but also more limitating. Do you still have the patch metodologie? How can you provide a patch if you don't have a place to publish the change? You can still have a patch methodology if your internet connection really sucks. But if you have good enough access to the current Subversion repository, then you probably have good enough access to use a free branch hosting service like Launchpad. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRpe3aHEjvBPtnXfVAQL1swQAuXP/QX5c/isttwQ3Et/N7fp6mG9a+sA+ HX7G6rSWxaYGtmYOjXTqjeou/QEoNlEtOqvZQcAJQ4iObMVg0mVIVFxixPln3JPQ u4XNt37FklJh7q0tbvi6VQeBi82beqWuL6+MTE6dMD1ruRAkJ/zpM9/ruiCBSmSB XO84dNkv/dY= =sUf+ -END 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
Re: [Python-Dev] Subversion branch merging
Barry Silly me, the trunk is already available: Barry https://code.launchpad.net/~vcs-imports/python/trunk Bazaar keeps this in sync with svn.python.org? 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] Alternative to -z option
On 13/07/07, Phillip J. Eby [EMAIL PROTECTED] wrote: 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? Let me get this right: if I had a one-liner hello.py (containing the line print Hello, world) all I'd need to do is (1) rename hello.py to __main__.py (2) zip hello.zip __main__.py. Then, python hello.zip would work exactly as python hello.py did previously? Sounds plausible. I'm not entirely clear on the details of the code needed (long day!) - would you be willing to produce a patch? (One major point in favour of the -z patch is that it exists already!) 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] Subversion branch merging
Should the community ever decide to make the switch The last time, I was asked to write a PEP. I would demand the same thing the next time such a switch is suggested. I would be -1 on any proposed switch to a system that hasn't made its 1.0 release yet (myself, I've used subversion since 0.21, and I certainly don't want to go back to these times). 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] Alternative to -z option
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? ___ 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] Building Python with CMake
Hi, as I wrote in my previous email, I'm currently porting Python to some more unusual platforms, namely to a super computer (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system (http://ecos.sourceware.org), which have more or less surprisingly quite similar properties. To do this, I added CMake files to Python, in order to use CMake to cross compile Python to these platforms. CMake (http://www.cmake.org) is a buildsystem in scope similar to autotools, but it's just one tool (instead of a collection of tools) and it support Windows and the MS compilers as first class citizens, i.e. it can not only generate Makefiles, but also project files for the various versions of Visual Studio, and also for XCode. Attached you can find the files I had to add to get this working. With these CMake files I was able to build python for eCos, BlueGene, Linux and Windows (with Visual Studio 2003, but here I simply reused the existing pyconfig.h, because I didn't want to spend to much time with this). So for Linux the configure checks should be already quite good and almost complete, for eCos and BlueGene they also work (both are UNIX-like), for Windows there is probably some tweaking required. So if anybody is interested in trying to use CMake for Python, you can find the files attached. Version 2.4.5 of CMake or newer is required. I guess I should mention that I'm doing this currently with the released Python 2.5.1. Bye Alex Python-2.5.1-cmake.tar.bz2 Description: application/tbz ___ 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 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. ___ 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
Am Fri, 13 Jul 2007 12:58:24 -0500 schrieb [EMAIL PROTECTED]: Barry Silly me, the trunk is already available: Barry https://code.launchpad.net/~vcs-imports/python/trunk Bazaar keeps this in sync with svn.python.org? [...] Yes, the branch is update regularly. I think it's done nightly. The last checkin is from Georg Brandl for patch #1675424. Bye, Dennis Benzinger ___ 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] Building Python with CMake
2007/7/13, Alexander Neundorf [EMAIL PROTECTED]: as I wrote in my previous email, I'm currently porting Python to some more unusual platforms, namely to a super computer (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system (http://ecos.sourceware.org), which have more or less surprisingly quite similar properties. Sorry, missed the previous mail. Have two questions for you: - Why? - Do you know if there're plans for support this two platforms beyond this porting? Thank you!! Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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/13/07, Facundo Batista [EMAIL PROTECTED] wrote: 2007/7/13, Barry Warsaw [EMAIL PROTECTED]: with merges. This means the end of posting patches because instead what you would do is post the url to a branch that you published some place. It means that branch can be kept up-to-date as its parent branch changes, so a new feature candidate need never get stale. It also means your new feature candidate is a first class revision control branch, just as usable as the trunk, say. So it's much more powerful than trading patch files around. More powerful, maybe, but also more limitating. Do you still have the patch metodologie? How can you provide a patch if you don't have a place to publish the change? All DCVS's I looked at had a simple file export for 'changes'. It's diff + metadata, basically, which means it includes renames, directory mutation, changelogs, change-dependency information (which 'revision' it is based on, in effect) and whatever else the DCVS needs or wants. You can toss those around just like you can toss around diffs. -- 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] Building Python with CMake
On Friday 13 July 2007 14:53, you wrote: 2007/7/13, Alexander Neundorf [EMAIL PROTECTED]: as I wrote in my previous email, I'm currently porting Python to some more unusual platforms, namely to a super computer (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system (http://ecos.sourceware.org), which have more or less surprisingly quite similar properties. Sorry, missed the previous mail. Have two questions for you: - Why? Why porting or why using cmake ? Porting because of VTK (http://www.vtk.org), cmake because it has really good support for cross compiling (cvs version of cmake). And it has the nice side effect that the manually maintained MSVC project files would not be required anymore. - Do you know if there're plans for support this two platforms beyond this porting? BlueGene is for running VTK on it, and this will be supported for the coming years. eCos was for testing the cross compile, since this is easier to work with than with BlueGene. I don't know if there will be users for Python on eCos, but then again I didn't have to change anything to get it working on eCos, the configure checks did it all. Bye Alex ___ 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 13/07/2007 14.23, Steve Holden wrote: 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. We can probably assume that none of the Linux kernel team are developing on Windows. There is probably s a group with relevant experience somewhere. I'd Google for it, but I expect that the results would be dominated by British assertions that you have to be a stupid git to run Windows. git doesn't support Windows in a way that Windows users would find reasonable. In fact, the only ones saying it does already support Windows are non-Windows users. hg has a much more mature Windows support. In fact, I didn't face any major problems in using it under Windows (even in the details: eg, it supports case-insensitive filesystems). I can't speak of bzr. -- Giovanni Bajo ___ 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, Brett Cannon [EMAIL PROTECTED] wrote: 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. No. I never talked about moving us over. I do not believe and have never believed that to be feasible (in the foreseeable future.) It is certainly possible to host a project of Python's size, depth of history and number of committers in a DVCS (Monotone is my personal favourite, with Mercurial and Bazaar a shared second), and certain things would go a _lot_ better with proper branch tracking and merging, but switching over Python means an entirely new way of working, educating all the developers and working around the limitations of the chosen system. (I'm not saying they have more limitations than Subversion per se, but we are already used to working around Subversion's limitations.) What I talked about was converting the monolithic p3yk branch to a collection of separate feature-branches, which would then be merged together into the py3k branch, as well as the trunk (for backported changes.) The p3yk branch contains many changes that will never be backported, mixed in with change we want in Python 2.6. We currently do manual merging from the trunk into p3yk. When we start backporting features, those features in the trunk will end up conflicting with the p3yk changes. Worse, we will need to manually track bugfixes to those features in the p3yk branch in order to apply them to the trunk, and take extra care when merging in bugfixes from the trunk, too. Because Subversion don't keep track of which chunk was already merged, you get a lot of spurious conflicts. It gets extremely tedious to do those merges manually, and the error rate raises significantly. (I already have an uncomfortable feeling that I missed some of the merges in the p3yk branch, leaving bugs in p3yk that were fixed in the trunk. Fortunately, tests catch them fairly quickly -- but we still don't have 100% test coverage, not even for newly fixed bugs.) I have been working on converting the p3yk branch into separate Bazaar[*] branches, by first converting the whole branch (with 'tailor') and then applying each changeset to an appropriate feature branch, creating them as needed (using a little script based on tailor, because cherrypicking doesn't quite do what I want.) The last half year of changes, though, gets so incredibly intertwined that it's quite hard to pull them apart. Furthermore, I would still have to merge them back together to create the original py3k branch, and do merges with the trunk, too. I've been forced to decide it's not worth it, at this point. If we'd started with separate feature-branches earlier, it would have been. Now, it's easier and less error prone to just suck it up and deal with the numerous conflicts backported features will create. (Since I will be doing much backporting myself, I'm not just letting someone else deal with the mess :-) Some-branch-of-me'ly y'rs, [*] Bazaar was chosen for a number of unimportant reasons that are entirely moot at this point. It doesn't reflect my personal preference or constitute any form of official endorsement :-) -- 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] Building Python with CMake
On 13/07/2007 20.53, Facundo Batista wrote: as I wrote in my previous email, I'm currently porting Python to some more unusual platforms, namely to a super computer (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system (http://ecos.sourceware.org), which have more or less surprisingly quite similar properties. Sorry, missed the previous mail. Have two questions for you: - Why? Because it would be a single unified build system instead of having two build systems like we have one (UNIX and Windows). Also, it would be much easier to maintain because Visual Studio projects are generated from a simple description, while right now if you want to change something you need to go through the hassle of defining it within the Visual Studio GUI. Consider for instance if you want to change the Windows build so that a builtin module is compiled as an external .pyd instead. Right now, you need to go through the hassle of manually defining a new project, setting all the include/libraries dependencies correctly, ecc. ecc. With CMake or a similar tool, it would be a matter of a couple of textual line changes. [ I'll also remember that ease of maintanance for developers is the #1 reason for having a 2.1Mb python25.dll under Windows, which I would really love to reduce. ] -- Giovanni Bajo ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 13, 2007, at 4:04 PM, Giovanni Bajo wrote: I can't speak of bzr. I don't use or even have Windows, but this page says there are native Windows binaries available (yes Bazaar is pure Python): http://bazaar-vcs.org/BzrOnPureWindows There's also a Tortoise-like extension available: http://bazaar-vcs.org/TortoiseBzr - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRpfckHEjvBPtnXfVAQKArwP/aS20z5EcNT7GJSMepCORo34tE5SpF1g/ OMvRTervNDuUmjulgAHM9w9Chi3lOibM6eX0nJ8kHHzoaPrFDQkzh1/Gc+OZqfSA FAgctJtVkT956o+F1+xFe90KqtTtH8gmwHMFMhr/a7BZvV1S1kpCyu8ygI3YEe2u 5JParA9UcO0= =5HLR -END 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
Re: [Python-Dev] Subversion branch merging
On 7/12/07, Dave Harrison [EMAIL PROTECTED] wrote: So far I've used DARCS, Hg, and Git. And at this point Git is far and away the winner. Let's not start a discussion on which DVCS is better, or I'd burn your ears off about all the ways each of those (as well as Bazaar, Arch/tla/bzr1, Arx, CodeVille, SVK, Monotone and BitKeeper) suck, suck badly or are the work of the devil. The official Python source repository will be Subversion for now (although it isn't officially my decision :). I encourage anyone to use a mirror of it in their own favourite VCS, and do their own development in it. 'tailor' is a nice tool if you care about having the full history (as I do) and you don't happen to hit bugs in it or the VCS. Do realize that the full history may be a burden, especially in DVCS solutions. For what it's worth, rumour has it Subversion 1.5 or 2.0 will get actual branch tracking and full-history merging. If done properly (it's not done yet, so it's hard to say) it would reduce the advantage of the DVCS solutions by about half ;-P -- 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] Registry keys written by x64 installer
Martin quoting me: Yes - that is a bit of a shame, as having 32bit components would allow more flexibility (eg, allow a 64bit install of Python to work with an IIS configured for 32bit extensions), but that's something we can deal with later if necessary. Can you elaborate? As you mention, 64 and 32bit programs use different instruction sets. Therefore, trying to use a 64bit install of Python with IIS configured to work with 32bits is not going to work. In this case, switching the configuration of IIS will require the Python user to uninstall the previous version and install a different version - but some sites may end up in a dilemma here - they may be *forced* to use IIS in 32bit mode due to no 64bit port for a tool they need, but simultaneously desire a 64bit build of Python for other tasks on that same box. It's incorrect for a Win64 installer to make the executable components Win32. Right - I got the impression from Micheal that it was possible for 32bit components to be installed in a 64bit install, but I don't profess to know anything about this. A 64 bit pythonxy.dll cannot work in a 32-bit IIS - it's a different instruction set. That's not something that you can fix by just installing things differently. Exactly - which is why I'm suggesting that not allowing 64bit and 32bit versions of Python to be installed on the same box will cause inconvenience for some people. I agree such people will be in the minority, and their requirements are not clear, so I'm not pushing for a change of policy here. using _winreg is (almost) like using the API directly. RegDisable[/Enable]ReflectionKey appears to let the 32bit process see the real keys - I'm not aware of how 64bit apps would enable that reflection, but it probably doesn't really matter for our purposes. They can specify KEY_WOW64_32KEY. Ah - thanks. 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] Registry keys written by x64 installer
Martin: Assuming this is the right file, the cause of the behavior Mark reported is pretty clear. While the template summary is indeed x64, the attributes on the registry components are all 4 instead of 256 | 4, so they are placed in the 32-bit reflected registry. I don't know if this is desirable for some other reason. I found the same thing, and put a corrected installer at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.amd64.msi Mark, can you please report whether that fixes your problem? It does indeed - thank you guys! 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] Subversion branch merging
Thomas Wouters wrote: On 7/12/07, *Dave Harrison* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: So far I've used DARCS, Hg, and Git. And at this point Git is far and away the winner. Let's not start a discussion on which DVCS is better, or I'd burn your ears off about all the ways each of those (as well as Bazaar, Arch/tla/bzr1, Arx, CodeVille, SVK, Monotone and BitKeeper) suck, suck badly or are the work of the devil. The official Python source repository will be Subversion for now (although it isn't officially my decision :). I encourage anyone to use a mirror of it in their own favourite VCS, and do their own development in it. 'tailor' is a nice tool if you care about having the full history (as I do) and you don't happen to hit bugs in it or the VCS. Do realize that the full history may be a burden, especially in DVCS solutions. For what it's worth, rumour has it Subversion 1.5 or 2.0 will get actual branch tracking and full-history merging. If done properly (it's not done yet, so it's hard to say) it would reduce the advantage of the DVCS solutions by about half ;-P While I don't necessarily agree (and await for that burning feeling to start in my ears ;-) ), I think the lack of a decent windows port for some, and general lack of real maturity in most, are the killer arguments against DRCS for Python at this point. My own DRCS of preference (git) has a method for pulling from subversion anyway, and I can't really claim to even contribute much directly _to_ Python's core, so I'm wary of claiming to be too invested in this. That said, there are always strong arguments in favour of the distributed model encouraging and fostering community dev participation - and code always speaks louder than words heh. 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
Andy C wrote: 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? Is there a reason not to use __init__.py for this? -- Greg ___ 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
Anders J. Munch wrote: How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. Indeed. Is there any need to restrict extensions to 3 characters these days? Last time I experimented with this on Windows, it seemed to handle longer extensions okay. -- Greg ___ 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/13/07, Greg Ewing [EMAIL PROTECTED] wrote: Andy C wrote: 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? Is there a reason not to use __init__.py for this? Well, you might have multiple executable .py files in the same source tree. So then you would want to build multiple .pyz files, each of which has a different __zipmain__. I think of __zipmain__ as part of the format of the .pyz file, not part of the source tree. In particular, it specifies what module/function to run in the zipped source tree (and I imagine it will be adapted for other uses). In this model you're separating your development tree and the thing you deploy, which is not always the case in Python. 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
