Re: [Python-Dev] Devguide: Can I make commits from machines other than the one I generated the keys on?
On Sun, 06 Mar 2011 04:54:06 +0100 Jesus Cea j...@jcea.es wrote: I would rather prefer to promote the -A parameter to SSH (to use the local SSH agent be used from the remote development machine) instead of uploading private keys. That's not a good answer to the question, since it cannot apply to machines where you log in locally (such as a laptop you use when travelling). Regards Antoine. ___ 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] Please sync your feature branches
Antoine Pitrou solip...@pitrou.net wrote: Is that really going to work? I.e. will Mercurial be able to merge from default to one of the feature branches? If so, what will be the procedure? What would be the exact steps to try this out on the PEP 382 branch (say)? I've sketched out the steps in http://potrou.net/hgdevguide/committing.html#long-term-development-of-features First, thanks everyone for converting the active feature branches! - I've a couple of questions: 1) The default branch in the repository features/py3k-cdecimal contains all cdecimal changesets. I assume that the recommendation from the devguide to create a new named branch inside the new repository does not apply here, so I'll use 'default' for future cdecimal changes. Is this correct? 2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but not in the web interface. Should these be closed to avoid confusion? Stefan Krah ___ 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-checkins] devguide: More miscellaneous review comments.
On Sun, Mar 6, 2011 at 7:37 PM, ned.deily python-check...@python.org wrote: http://hg.python.org/devguide/rev/ad3278cfc5f6 changeset: 376:ad3278cfc5f6 user: Ned Deily n...@acm.org date: Sun Mar 06 01:37:13 2011 -0800 summary: More miscellaneous review comments. files: committing.rst communication.rst coredev.rst faq.rst stdlibchanges.rst diff --git a/committing.rst b/committing.rst --- a/committing.rst +++ b/committing.rst @@ -3,6 +3,9 @@ Committing and Pushing Changes == +.. TODO: include a checklist of items to be included in a commit? + e.g updated Misc/NEWS entry, tests, doc For non-Windows, get people to run make patchcheck. Windows devs will need a manual checklist, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Please sync your feature branches
On 06.03.2011 12:56, Stefan Krah wrote: Antoine Pitrou solip...@pitrou.net wrote: Is that really going to work? I.e. will Mercurial be able to merge from default to one of the feature branches? If so, what will be the procedure? What would be the exact steps to try this out on the PEP 382 branch (say)? I've sketched out the steps in http://potrou.net/hgdevguide/committing.html#long-term-development-of-features First, thanks everyone for converting the active feature branches! - I've a couple of questions: 1) The default branch in the repository features/py3k-cdecimal contains all cdecimal changesets. I assume that the recommendation from the devguide to create a new named branch inside the new repository does not apply here, so I'll use 'default' for future cdecimal changes. Is this correct? You can also start working on a named branch for easier switching. Just do a hg branch cdecimal. This assumes that the branch history is not desired to be preserved when the branch is finished, and just a single patch is committed to the main repo. 2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but not in the web interface. Should these be closed to avoid confusion? No; inactive simply means that the branch currently has no real head, since all heads have been merged into another branch. If all developers merge their changes promptly, it will be the default state of the maintenance branches except for 2.7. Georg ___ 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] Please sync your feature branches
On 06.03.2011 12:56, Stefan Krah wrote: Antoine Pitrou solip...@pitrou.net wrote: Is that really going to work? I.e. will Mercurial be able to merge from default to one of the feature branches? If so, what will be the procedure? What would be the exact steps to try this out on the PEP 382 branch (say)? I've sketched out the steps in http://potrou.net/hgdevguide/committing.html#long-term-development-of-features First, thanks everyone for converting the active feature branches! - I've a couple of questions: 1) The default branch in the repository features/py3k-cdecimal contains all cdecimal changesets. I assume that the recommendation from the devguide to create a new named branch inside the new repository does not apply here, so I'll use 'default' for future cdecimal changes. Is this correct? 2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but not in the web interface. Should these be closed to avoid confusion? Hmm, and legacy-trunk should already be closed actually. It does not show up in hg branches for me. Georg ___ 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] hooks: Hopefully fix the issue where notification of merges to buildbot
On Sun, Mar 6, 2011 at 02:38, Antoine Pitrou solip...@pitrou.net wrote: For the record, the reason these emails look a bit strange (and appear to be pushed by Dirkjan (sorry)) is that they were done directly on the server with the settings of the local user hg. FWIW, I have a tiny extension at work that can set the user depending on the private key used to log in. I could show you the code if it's helpful (it'll probably need some refinements to be robust enough). Cheers, Dirkjan ___ 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] Please sync your feature branches
On Sun, Mar 6, 2011 at 10:17 PM, Georg Brandl g.bra...@gmx.net wrote: 2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but not in the web interface. Should these be closed to avoid confusion? Hmm, and legacy-trunk should already be closed actually. It does not show up in hg branches for me. I assume Stefan was referring to the features/py3k-cdecimal clone rather than the cpython one. This is going to happen with all the server-side clones - we really only want default in the clone, but the maintenance branches will come along for the ride. There are actually a few things related to server-side clone maintenance that I'm not entirely clear on: - is it OK to work on default, or does that cause problems with merging back later? - is there an easy way to close all the branches that aren't of any interest and avoid reopening them when merging from the cpython clone? - how do we track changes in cpython:default while continuing? By pulling from cpython into our local feature clone and pushing back to the server-side clone? Unrelated question: which is the practice area? Devguide says test, but we also have sandbox/cpython. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On Sat, Mar 5, 2011 at 9:33 PM, Mark Hammond skippy.hamm...@gmail.com wrote: IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. The fact this doesn't help users installing Python just for me is fine too from the POV of matching *nix systems - a user installing a private Python build on *nix also doesn't get the python2 and python3 conveniences, nor the automatic PATH convenience. But in practice I expect this would *not* be OK - which just highlights the risks of trying to generalize a specific observed problem on one OS to others. Why not modify the windows installers to install into C:\Python\X.Y and have the .bat files generated in C:\Python which is what I have been doing manually since py25. I just add C:\Python to the system Path then create/modify the bat files for new versions of python I install. C:\Python\python.bat - 3.2/python.exe C:\Python\python2.bat - 2.7/python.exe C:\Python\python3.bat - 3.2/python.exe C:\Python\python2.5.bat - 2.5/python.exe ... Something I have been thinking about recently though is outside the scope of the pep is writing a python.exe, to replace the python.bat, that would try to read the shebang line of the file to send it to the right version of python. Then I just associate py files with the dispatcher exe and everything should work as intended. ___ 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] Please sync your feature branches
Georg Brandl g.bra...@gmx.net wrote: 2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but not in the web interface. Should these be closed to avoid confusion? Hmm, and legacy-trunk should already be closed actually. It does not show up in hg branches for me. It does here after a fresh clone: $ hg clone http://hg.python.org/features/py3k-cdecimal/ ... $ hg branches default47990:6a1c8fcce229 3.247988:a0752d92d207 (inactive) 3.147987:9e9aa450a5f8 (inactive) legacy-trunk 33482:cde58cd07e7d (inactive) Stefan Krah ___ 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] Please sync your feature branches
Hi, I assume Stefan was referring to the features/py3k-cdecimal clone rather than the cpython one. This is going to happen with all the server-side clones - we really only want default in the clone, but the maintenance branches will come along for the ride. There are actually a few things related to server-side clone maintenance that I'm not entirely clear on: - is it OK to work on default, or does that cause problems with merging back later? It's ok. - is there an easy way to close all the branches that aren't of any interest and avoid reopening them when merging from the cpython clone? You could do that (see hg help commit for the --close-branch option), but it can create new heads if you pull further changes on these branches when pulling from the cpython clone. So it's more annoyance than needed IMO. - how do we track changes in cpython:default while continuing? By pulling from cpython into our local feature clone and pushing back to the server-side clone? Yes. Unrelated question: which is the practice area? Devguide says test, but we also have sandbox/cpython. The devguide should probably be updated to mention sandbox/cpython. (that's a good practice item) Regards Antoine. ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 6/03/2011 11:51 PM, Dj Gilcrease wrote: Why not modify the windows installers to install into C:\Python\X.Y and have the .bat files generated in C:\Python which is what I have been doing manually since py25. I just add C:\Python to the system Path then create/modify the bat files for new versions of python I install. That sounds like a reasonable scheme people may choose to use - however, it doesn't really address the basic issue - something still needs to add c:\Python to PATH, and the scheme itself doesn't really necessitate the common parent directory - ie, it is fundamentally the same (if less clean) as the existing c:\pythonx with a (eg) c:\python-cmd or c:\python-scripts directory with the .bat files - especially given the various installations can be located via the registry. ... Something I have been thinking about recently though is outside the scope of the pep is writing a python.exe, to replace the python.bat, that would try to read the shebang line of the file to send it to the right version of python. Then I just associate py files with the dispatcher exe and everything should work as intended. But where would such a python.exe live and how would that directory end up on the PATH? On the more general idea though, it could have legs as it would solve the file association issue for files which include the shebang and arrange for the status-quo (or better) for files which don't... But this sounds like a different PEP ;) 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] Please sync your feature branches
On Sun, Mar 6, 2011 at 7:52 AM, Stefan Krah stefan-use...@bytereef.org wrote: It does here after a fresh clone: Thats because it never got the revision that closed that branch, just merge http://hg.python.org/cpython/rev/b77918288f7d to http://hg.python.org/features/py3k-cdecimal/ ___ 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] devguide: More miscellaneous review comments.
On Sun, 6 Mar 2011 21:58:24 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Sun, Mar 6, 2011 at 7:37 PM, ned.deily python-check...@python.org wrote: http://hg.python.org/devguide/rev/ad3278cfc5f6 changeset: 376:ad3278cfc5f6 user: Ned Deily n...@acm.org date: Sun Mar 06 01:37:13 2011 -0800 summary: More miscellaneous review comments. files: committing.rst communication.rst coredev.rst faq.rst stdlibchanges.rst diff --git a/committing.rst b/committing.rst --- a/committing.rst +++ b/committing.rst @@ -3,6 +3,9 @@ Committing and Pushing Changes == +.. TODO: include a checklist of items to be included in a commit? + e.g updated Misc/NEWS entry, tests, doc For non-Windows, get people to run make patchcheck. Windows devs will need a manual checklist, though. I find make patchcheck to be a poor tool and I would rather see a manual checklist than a suggestion to use make patchcheck (which I never use). At least a manual checklist is able to explain you why the items are recommended. Regards Antoine. ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On Sun, Mar 6, 2011 at 8:10 AM, Mark Hammond mhamm...@skippinet.com.au wrote: That sounds like a reasonable scheme people may choose to use - however, it doesn't really address the basic issue - something still needs to add c:\Python to PATH, and the scheme itself doesn't really necessitate the common parent directory - ie, it is fundamentally the same (if less clean) as the existing c:\pythonx with a (eg) c:\python-cmd or c:\python-scripts directory with the .bat files - especially given the various installations can be located via the registry. True, and since System32 is already on the path, having the installer generate the bat files there is probably the best solution for this pep. ___ 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] small commit emails nit
I wonder if we couldn't kill the cpython repo name in the commit mails. I find it wastes space for the commit message in the subject line, and it's pretty obvious it's the cpython repo from the branch name. -- Regards, Benjamin ___ 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] small commit emails nit
On Sun, 6 Mar 2011 08:17:35 -0600 Benjamin Peterson benja...@python.org wrote: I wonder if we couldn't kill the cpython repo name in the commit mails. I find it wastes space for the commit message in the subject line, and it's pretty obvious it's the cpython repo from the branch name. Well, right now commits in the default branch don't get (default) displayed. Should we change that? ___ 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] small commit emails nit
On Mon, Mar 7, 2011 at 12:40 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 6 Mar 2011 08:17:35 -0600 Benjamin Peterson benja...@python.org wrote: I wonder if we couldn't kill the cpython repo name in the commit mails. I find it wastes space for the commit message in the subject line, and it's pretty obvious it's the cpython repo from the branch name. Well, right now commits in the default branch don't get (default) displayed. Should we change that? I'm actually OK with the status quo, but if we were going to change it, I would continue to leave (default) out. Completely unqualified = cpython default Only branch name = cpython branch Only repository name = other repository default repository name and branch name = other repository branch Such a change would get a +0 from me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 6 March 2011 02:33, Mark Hammond skippy.hamm...@gmail.com wrote: IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. No, no, no! Please no! Bat files are a lousy way of writing wrappers on Windows, as they don't nest. I've lost count of the number of times I've been tripped up by putting a series of commands into a batch file, only to have them fail because somewhere in the middle is a bat file wrapper which makes the outer bat file stop part way through :-( /rant 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] small commit emails nit
On Mon, 7 Mar 2011 00:52:08 +1000 Nick Coghlan ncogh...@gmail.com wrote: I'm actually OK with the status quo, but if we were going to change it, I would continue to leave (default) out. Completely unqualified = cpython default Only branch name = cpython branch Only repository name = other repository default repository name and branch name = other repository branch Well, I'm not sure, but the regularity of the cpython prefixes makes it easier to distinguish cpython commits from non-cpython ones IMO. Regards Antoine. ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
Using batch files is a poor idea, IMO, because you have to explicitly call a batch file from another, or the remainder of the caller will not execute. Installing to System32 s also questionable, but if it's just the launchers, it might be okay. From an installer's perspective, it would really help if those files kept consistent component GUIDs and had a Windows version block so it could upgrade consistently if it changes in the future I think Glenn Linderman hit the use cases on the head; I'm unclear why he was against the overhead of a helper executable. The things I would really want solutions for are these: * double click on a script, and have it launch the right python (2 or 3, w or not) * Probably scan for the final python[.\d]+ string and assume it's relevant. * be able to easily invoke python to interpret a script from the command prompt I'd be comfortable with setting associations to a set of thin executable wrappers which examined the #! line to extract a python version. It could fall back to the default version of python, which could be defined as the highest installed on the machine, or could be customizable by the machine's administrator. If this wrapper script passes on all command line parameters, it could also be a reasonable way to invoke python from the command line. Is there a good way for the wrapper to know what versions of python are available on Windows? Moving forward we could have a pythonx.y installer set a value in a known registry key, and document how to register an older python with this key. The default value of the key could be the mechanism for setting a default python version. I'm willing to clarify this and/or look into providing patches if it would help; the only potentially sticky point is the contribution agreement, but I wouldn't expect trouble with my employer. Michael ___ 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] small commit emails nit
On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 7 Mar 2011 00:52:08 +1000 Nick Coghlan ncogh...@gmail.com wrote: I'm actually OK with the status quo, but if we were going to change it, I would continue to leave (default) out. Completely unqualified = cpython default Only branch name = cpython branch Only repository name = other repository default repository name and branch name = other repository branch Well, I'm not sure, but the regularity of the cpython prefixes makes it easier to distinguish cpython commits from non-cpython ones IMO. It's a mental pattern matching thing - word layout is noticed before word content. So the suggested scheme: [python-checkins] Lorem ipsum dolor sit amet [python-checkins] (3.1): Lorem ipsum dolor sit amet [python-checkins] devguide: Lorem ipsum dolor sit amet [python-checkins] devguide (hg_migration): Lorem ipsum dolor sit amet provides more distinctive subject lines than the current: [python-checkins] cpython: Lorem ipsum dolor sit amet [python-checkins] cpython (3.1): Lorem ipsum dolor sit amet [python-checkins] devguide: Lorem ipsum dolor sit amet [python-checkins] devguide (hg_migration): Lorem ipsum dolor sit amet What we have isn't bad, but I agree with Benjamin that it could be better. Cheers, Nick -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] small commit emails nit
On Mon, 7 Mar 2011 01:11:24 +1000 Nick Coghlan ncogh...@gmail.com wrote: [python-checkins] Lorem ipsum dolor sit amet [python-checkins] (3.1): Lorem ipsum dolor sit amet [python-checkins] devguide: Lorem ipsum dolor sit amet [python-checkins] devguide (hg_migration): Lorem ipsum dolor sit amet If you read it through gmane, you wouldn't have the [python-checkins] header at least. Ok, so whoever commits next gets to test the new version of the hook (it will hopefully work). Regards Antoine. ___ 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] hg pull failed
Georg Yesterday's repository was still the test repository, now it's Georg the real one. You'll need to clone again. Thanks. I have a question about updates from cloned clones. Suppose I clone the central repo then clone locally to get the 2.7 and 3.2 release branches: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone cpython 2.7 If I want to later update my maintenance branches to get any updates will it suffice to just hg pull in my 2.7 and/or 3.2 directories or do I need to pull in cpython first? I guess my question is, are these clones transitive? 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] CPython hg transition complete
Antoine Martin v. Löwis mar...@v.loewis.de wrote: What is the recommended merge flow if I want to make this change to all branches? Antoine - on one hand: 2.5 - 2.6 - 2.7 (if you still want to maintain Antoine 2.5) Antoine - on the other hand: 3.1 - 3.2 - default Sorry, I don't understand. Can you spell that out in terms of hg commands for those of us with no working knowledge of the new system? Thx, 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] CPython hg transition complete
Le dimanche 06 mars 2011 à 09:50 -0600, s...@pobox.com a écrit : Antoine Martin v. Löwis mar...@v.loewis.de wrote: What is the recommended merge flow if I want to make this change to all branches? Antoine - on one hand: 2.5 - 2.6 - 2.7 (if you still want to maintain Antoine 2.5) Antoine - on the other hand: 3.1 - 3.2 - default Sorry, I don't understand. Can you spell that out in terms of hg commands for those of us with no working knowledge of the new system? This is sketched out in the devguide, I don't know if these instructions help you: http://docs.python.org/devguide/committing.html#forward-porting Regards Antoine. ___ 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] hg pull failed
On 06.03.2011 16:44, s...@pobox.com wrote: Georg Yesterday's repository was still the test repository, now it's Georg the real one. You'll need to clone again. Thanks. I have a question about updates from cloned clones. Suppose I clone the central repo then clone locally to get the 2.7 and 3.2 release branches: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone cpython 2.7 If I want to later update my maintenance branches to get any updates will it suffice to just hg pull in my 2.7 and/or 3.2 directories or do I need to pull in cpython first? I guess my question is, are these clones transitive? If you don't change repo configuration after these commands, hg pull in the 3.2 repo will pull from the local cpython repo. I'd advise to set the default entry in each of the clones' .hg/hgrc file to http://hg.python.org/cpython (as a committer you should be using ssh://h...@hg.python.org/cpython BTW). This way, hg push and hg pull communicate with the remote repo. You can still exchange commits with the other local clones by using, for example, hg push ../3.2. (You can also add another entry in the .hgrc's [paths] section if you want to give nicknames to these path names). Georg ___ 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] hg pull failed
On Mon, Mar 7, 2011 at 1:44 AM, s...@pobox.com wrote: Georg Yesterday's repository was still the test repository, now it's Georg the real one. You'll need to clone again. Thanks. I have a question about updates from cloned clones. Suppose I clone the central repo then clone locally to get the 2.7 and 3.2 release branches: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone cpython 2.7 If I want to later update my maintenance branches to get any updates will it suffice to just hg pull in my 2.7 and/or 3.2 directories or do I need to pull in cpython first? I guess my question is, are these clones transitive? Transitive. This is nice for the patch flow (fix in oldest, push, switch to next, merge, commit and push, etc, then only touch the central server for the final push of all branches), but it does you mean you need to follow the reverse order when grabbing changes from the central repository. Being slightly out of date is far less of a drama than it used to be, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] small commit emails nit
On Mon, 07 Mar 2011 01:11:24 +1000, Nick Coghlan ncogh...@gmail.com wrote: On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 7 Mar 2011 00:52:08 +1000 Nick Coghlan ncogh...@gmail.com wrote: I'm actually OK with the status quo, but if we were going to change it, I would continue to leave (default) out. Completely unqualified =3D cpython default Only branch name =3D cpython branch Only repository name =3D other repository default repository name and branch name =3D other repository branch Well, I'm not sure, but the regularity of the cpython prefixes makes it easier to distinguish cpython commits from non-cpython ones IMO. It's a mental pattern matching thing - word layout is noticed before word content. Um, yes, that's why having cpython in there makes it easier to recognize cpython commits when scanning a list of subjects. So the suggested scheme: [python-checkins] Lorem ipsum dolor sit amet [python-checkins] (3.1): Lorem ipsum dolor sit amet [python-checkins] devguide: Lorem ipsum dolor sit amet [python-checkins] devguide (hg_migration): Lorem ipsum dolor sit amet provides more distinctive subject lines than the current: [python-checkins] cpython: Lorem ipsum dolor sit amet [python-checkins] cpython (3.1): Lorem ipsum dolor sit amet [python-checkins] devguide: Lorem ipsum dolor sit amet [python-checkins] devguide (hg_migration): Lorem ipsum dolor sit amet What we have isn't bad, but I agree with Benjamin that it could be better. I don't feel strongly about it either way. -- R. David Murray www.bitdance.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] hg pull failed
On Mon, Mar 7, 2011 at 2:07 AM, Georg Brandl g.bra...@gmx.net wrote: If you don't change repo configuration after these commands, hg pull in the 3.2 repo will pull from the local cpython repo. I'd advise to set the default entry in each of the clones' .hg/hgrc file to http://hg.python.org/cpython (as a committer you should be using ssh://h...@hg.python.org/cpython BTW). This way, hg push and hg pull communicate with the remote repo. You can still exchange commits with the other local clones by using, for example, hg push ../3.2. (You can also add another entry in the .hgrc's [paths] section if you want to give nicknames to these path names). Given the recommended workflow in the devguide (i.e. when forward porting bug fixes, update all public branches in a single push), keeping the transitive connections between local clones is probably a good idea. It also means that we can do the full porting workflow even when offline. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] small commit emails nit
On 06.03.2011 17:10, R. David Murray wrote: On Mon, 07 Mar 2011 01:11:24 +1000, Nick Coghlan ncogh...@gmail.com wrote: On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 7 Mar 2011 00:52:08 +1000 Nick Coghlan ncogh...@gmail.com wrote: I'm actually OK with the status quo, but if we were going to change it, I would continue to leave (default) out. Completely unqualified =3D cpython default Only branch name =3D cpython branch Only repository name =3D other repository default repository name and branch name =3D other repository branch Well, I'm not sure, but the regularity of the cpython prefixes makes it easier to distinguish cpython commits from non-cpython ones IMO. It's a mental pattern matching thing - word layout is noticed before word content. Um, yes, that's why having cpython in there makes it easier to recognize cpython commits when scanning a list of subjects. +1 for keeping cpython. It's much shorter than rX - in python/branches/py3k anyway, so I don't see what's so bad about 7 helpful characters. Georg ___ 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] r88758 - tracker/instances/python-dev/scripts/addpatchsets
On Sun, 6 Mar 2011 17:32:40 +0100 (CET)
martin.v.loewis python-check...@python.org wrote:
-def find_bases(data, rev):
+def hg_splitpatch(data):
+patches = []
+filename = None
+for line in data.splitlines(True):
+if line.startswith('diff -r'):
Now I understand why you would like to discourage git diffs.
But, as I said back then, I don't think it's worthwhile to try and
compute the base rev. Most reviewable patches should apply cleanly
against the latest revision on default, otherwise we're gonna ask the
poster to regenerate the patch anyway.
Regards
Antoine.
___
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] hg pull failed
On 06.03.2011 17:15, Nick Coghlan wrote: On Mon, Mar 7, 2011 at 2:07 AM, Georg Brandl g.bra...@gmx.net wrote: If you don't change repo configuration after these commands, hg pull in the 3.2 repo will pull from the local cpython repo. I'd advise to set the default entry in each of the clones' .hg/hgrc file to http://hg.python.org/cpython (as a committer you should be using ssh://h...@hg.python.org/cpython BTW). This way, hg push and hg pull communicate with the remote repo. You can still exchange commits with the other local clones by using, for example, hg push ../3.2. (You can also add another entry in the .hgrc's [paths] section if you want to give nicknames to these path names). Given the recommended workflow in the devguide (i.e. when forward porting bug fixes, update all public branches in a single push), keeping the transitive connections between local clones is probably a good idea. It also means that we can do the full porting workflow even when offline. Sure, it's anyone's choice. I wouldn't go so far as to call this a connection. It is really important for everyone to understand that every clone is a standalone entity, and the *only* thing that makes up this connection is the single entry default = ... in the repo's .hg/hgrc. Georg ___ 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] devguide: More miscellaneous review comments.
On 06/03/2011 13:14, Antoine Pitrou wrote: On Sun, 6 Mar 2011 21:58:24 +1000 Nick Coghlanncogh...@gmail.com wrote: On Sun, Mar 6, 2011 at 7:37 PM, ned.deilypython-check...@python.org wrote: http://hg.python.org/devguide/rev/ad3278cfc5f6 changeset: 376:ad3278cfc5f6 user:Ned Deilyn...@acm.org date:Sun Mar 06 01:37:13 2011 -0800 summary: More miscellaneous review comments. files: committing.rst communication.rst coredev.rst faq.rst stdlibchanges.rst diff --git a/committing.rst b/committing.rst --- a/committing.rst +++ b/committing.rst @@ -3,6 +3,9 @@ Committing and Pushing Changes == +.. TODO: include a checklist of items to be included in a commit? + e.g updated Misc/NEWS entry, tests, doc For non-Windows, get people to run make patchcheck. Windows devs will need a manual checklist, though. I find make patchcheck to be a poor tool and I would rather see a manual checklist than a suggestion to use make patchcheck (which I never use). I find it helpful. Why do you say it is a poor tool? Michael At least a manual checklist is able to explain you why the items are recommended. Regards Antoine. ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] Finding buildbot failures
On 05/03/2011 22:18, Martin v. Löwis wrote: Am 05.03.2011 19:26, schrieb Michael Foord: On 28/02/2011 21:59, Martin v. Löwis wrote: That's one of the big advantages that Jenkins (nee Hudson) has over buildbot - drilling down into individual test failures through the web ui. Your test run needs to generate appropriate xml for that to work though. Buildbot can do this too. It can even do it without xml, although it does need *some* parseable format, which I think the Python test suite is a long way from. That would be a great improvement to the Python buildbot infrastructure. So would you be willing to contribute the necessary changes? To whom was this addressed? If to me I have the desire but lack the skill. I honestly believe that you do have the skill, but perhaps lack the knowledge (and yes, I meant to suggest that you work on this). Yes, that's what I meant. I'd be also willing to help you getting started, especially assuming you would want to sprint on that during PyCon. Sprints will be an ideal opportunity. All the best, Michael Regards, Martin -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] devguide: More miscellaneous review comments.
On Sun, 06 Mar 2011 16:52:54 + Michael Foord fuzzy...@voidspace.org.uk wrote: On 06/03/2011 13:14, Antoine Pitrou wrote: On Sun, 6 Mar 2011 21:58:24 +1000 Nick Coghlanncogh...@gmail.com wrote: On Sun, Mar 6, 2011 at 7:37 PM, ned.deilypython-check...@python.org wrote: http://hg.python.org/devguide/rev/ad3278cfc5f6 changeset: 376:ad3278cfc5f6 user:Ned Deilyn...@acm.org date:Sun Mar 06 01:37:13 2011 -0800 summary: More miscellaneous review comments. files: committing.rst communication.rst coredev.rst faq.rst stdlibchanges.rst diff --git a/committing.rst b/committing.rst --- a/committing.rst +++ b/committing.rst @@ -3,6 +3,9 @@ Committing and Pushing Changes == +.. TODO: include a checklist of items to be included in a commit? + e.g updated Misc/NEWS entry, tests, doc For non-Windows, get people to run make patchcheck. Windows devs will need a manual checklist, though. I find make patchcheck to be a poor tool and I would rather see a manual checklist than a suggestion to use make patchcheck (which I never use). I find it helpful. Why do you say it is a poor tool? Because of the following: At least a manual checklist is able to explain you why the items are recommended. ... which make patchcheck's very terse output doesn't provide. That said I admit it can be useful to newcomers. Regards Antoine. ___ 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] Support the /usr/bin/python2 symlink upstream
On 02.03.2011 16:54, Nick Coghlan wrote: /tangent Does this discussion remind anyone else of the bash/dash switch for /usr/bin/sh in Ubuntu? The distro itself coped fine, but 3rd party shell scripts that used bash extensions were a whole different story. (No, I'm not sure what lessons, if any, we can draw from that. It just struck me as an interesting parallel worth mentioning) I think that comparison is wrong. /bin/sh is defined to point to a Bourne compatible shell. If you use bash features, and you are not using /bin/bash, then you are calling for trouble. With /bin/sh, there is a standard what to expect, and you can write /bin/sh scripts which conform to all /bin/sh implementations. Compare that to /usr/bin/python and try to define how to write a script that works with reasonable new 2.x and 3.x python versions. Maybe there is a small subset of scripts (not using any third party python package), but how would such a standard be useful? Then even better point /usr/bin/python to /usr/bin/perl6, then at least all scripts break consistently ;) Matthias ___ 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] devguide: More miscellaneous review comments.
On 06/03/2011 17:05, Antoine Pitrou wrote: On Sun, 06 Mar 2011 16:52:54 + Michael Foordfuzzy...@voidspace.org.uk wrote: On 06/03/2011 13:14, Antoine Pitrou wrote: On Sun, 6 Mar 2011 21:58:24 +1000 Nick Coghlanncogh...@gmail.com wrote: On Sun, Mar 6, 2011 at 7:37 PM, ned.deilypython-check...@python.org wrote: http://hg.python.org/devguide/rev/ad3278cfc5f6 changeset: 376:ad3278cfc5f6 user:Ned Deilyn...@acm.org date:Sun Mar 06 01:37:13 2011 -0800 summary: More miscellaneous review comments. files: committing.rst communication.rst coredev.rst faq.rst stdlibchanges.rst diff --git a/committing.rst b/committing.rst --- a/committing.rst +++ b/committing.rst @@ -3,6 +3,9 @@ Committing and Pushing Changes == +.. TODO: include a checklist of items to be included in a commit? + e.g updated Misc/NEWS entry, tests, doc For non-Windows, get people to run make patchcheck. Windows devs will need a manual checklist, though. I find make patchcheck to be a poor tool and I would rather see a manual checklist than a suggestion to use make patchcheck (which I never use). I find it helpful. Why do you say it is a poor tool? Because of the following: At least a manual checklist is able to explain you why the items are recommended. ... which make patchcheck's very terse output doesn't provide. That said I admit it can be useful to newcomers. So both are useful. I find the automated one very handy. Michael Regards Antoine. ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On Sun, Mar 6, 2011 at 09:07, Michael Urman mur...@gmail.com wrote: I think Glenn Linderman hit the use cases on the head; I'm unclear why he was against the overhead of a helper executable. Interpreter startup time is increasing with every version IIRC**, so adding another slowdown means we have to step very carefully in this area. I'm +1 for much of the usability side of things, but we must remain mindful of performance. ** I've run some numbers but they're at work, so I'll have to grab them tomorrow. ___ 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] r88758 - tracker/instances/python-dev/scripts/addpatchsets
-def find_bases(data, rev):
+def hg_splitpatch(data):
+patches = []
+filename = None
+for line in data.splitlines(True):
+if line.startswith('diff -r'):
Now I understand why you would like to discourage git diffs.
But, as I said back then, I don't think it's worthwhile to try and
compute the base rev. Most reviewable patches should apply cleanly
against the latest revision on default, otherwise we're gonna ask the
poster to regenerate the patch anyway.
Would you like to contribute a patch to make that work? It's too tedious
to work without a base revision, so for the time being, this cannot be
supported.
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] CPython hg transition complete
Antoine This is sketched out in the devguide, I don't know if these Antoine instructions help you: Antoine http://docs.python.org/devguide/committing.html#forward-porting Thanks. There is one problem (for me, at least): Assuming you are doing all of your work in a single clone, do: hg update default hg merge 3.2 # Fix any conflicts; compile; run the test suite hg commit I normally have a sandbox for each branch (2.4 through head/default/trunk, whatever it's called now) to easy testing other packages I write against multiple versions of Python. Assume I have separate 3.1 and 3.2 sandboxes which are sibling directories of each other, and that I commit a change to my 3.1 sandbox, how do I merge the change from 3.1 to 3.2? Assume I don't understand the instructions later on in the section titled Using several working copies. It seems I would have to commit on 3.1, push to the main central repository, merge to 3.2 (how?), then go through the compile, test, repeat cycle again. Is there no way to merge from my 3.1 repo to my 3.2 repo before committing (sorry for the pun) to a central push? 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] small commit emails nit
On Mar 06, 2011, at 08:17 AM, Benjamin Peterson wrote: I wonder if we couldn't kill the cpython repo name in the commit mails. I find it wastes space for the commit message in the subject line, and it's pretty obvious it's the cpython repo from the branch name. I agree that the commit message Subject: lines consume a lot of horizontal space before they get to the meat of the matter. E.g. [Python-checkins] cpython (2.7): blah Removing 'cpython' doesn't lose much information since I suspect that repo will be the most common one. We could also shorten the Subject prefix that Mailman adds, or remove it entirely. I'm not so much in favor of total removal, but [PyCommit] or [PyHG] or some other suggestion might work. -Barry signature.asc Description: 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] hg pull failed
Nick Transitive. This is nice for the patch flow (fix in oldest, push, Nick switch to next, merge, commit and push, etc, then only touch the Nick central server for the final push of all branches), but it does Nick you mean you need to follow the reverse order when grabbing Nick changes from the central repository. Ummm, push from where to where? Are you assuming some relationship between my sandboxes? push sounds to me like pushing my changes to the central repository. That's not what I would want to do. I should also point out for those not familiar with my past experiences with Mercurial, I gave up on it once before (pylockfile) because I got things so totally f**ked up. I went back to Subversion on Google Code and have been happy ever since. I approach this new way of managing Python development with a great deal of trepidation. 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 06/03/2011 02:33, Mark Hammond wrote: On 6/03/2011 12:37 AM, Michael Foord wrote: On 05/03/2011 07:02, Nick Coghlan wrote: On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammondmhamm...@skippinet.com.au wrote: I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) I updated the draft PEP, explicitly bringing Mac OS X and Cygwin within the scope of the recommendation, and excluding PYTHON* environment variable considerations and Windows-related proposals. The Windows section does include a hit-list that may serve as a useful starting point if someone else felt like starting a Windows specific PEP, though. The issues are relevant to Windows (there are *other* issues as well but that doesn't mean that the same issue doesn't apply). Guido also said he would like to see Windows addressed. What issues specifically? If I look at the current PEP language, it refers to the default version of the Python interpreter and all new code that needs to invoke the Python interpreter. Neither of these apply in any meaningful way to Windows. People often invoke the Python interpreter from the command line to run code on Windows. It could be argued that the latter could include .bat files which use Python but that sounds like a theoretical problem (ie, I haven't heard much noise about that) where PEP394 is addressing an observed practical problem. I have my Python installs on my PATH (as do most Windows developers I know) and absent batch files I create myself I have no way of distinguishing between Python 2 and Python 3 (or other versions) because the Windows installer only creates python.exe. On Windows it seems to be just about 'python2' and 'python3' doing the correct thing in a default command prompt, which while desirable ignores the broader issues (eg, the file associations and anything else windowsy and not driven by the command-prompt) I'm glad it is desirable. Yes there are other issues, yes they should be addressed, but not as part of this PEP. I'll be happy to try and come to some consensus with Martin (and others) on what we *can* do for Windows (as similar to the other platforms as possible would be my goal) and provide appropriate text for the PEP. IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. The fact this doesn't help users installing Python just for me is fine too from the POV of matching *nix systems - a user installing a private Python build on *nix also doesn't get the python2 and python3 conveniences, nor the automatic PATH convenience. But in practice I expect this would *not* be OK - which just highlights the risks of trying to generalize a specific observed problem on one OS to others. bat files are far from ideal for the reasons that others have expressed. I would like to see us create version specific (i.e. python32.exe / python32w.exe) binaries (or links if we drop support for earlier versions of Windows or some filesystems - I'm agnostic on that issue) *plus* a python3.exe / python3w.exe with last install wins (as it is for currently for file associations). Whether we make those automatically available by installing into System32 or do that later by allowing the installer (optionally) to add a PATH entry I don't mind. Martin seems not to mind this idea and Paul Moore is +1 and Guido would like Windows at least addressed by the PEP, so I would *like* this added to the PEP unless there is substantial opposition to us doing this. All the best, Michael Foord Cheers, Mark -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] CPython hg transition complete
On Sat, Mar 5, 2011 at 11:39, Georg Brandl g.bra...@gmx.net wrote: Also please redirect praise to Antoine Pitrou and Dirkjan Ochtman who did most of the actual work. Georg Many thanks to you three and anyone else who put in effort on this project. It's excellent that this got completed in time for PyCon! ___ 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] hg pull failed
Georg If you don't change repo configuration after these commands, hg Georg pull in the 3.2 repo will pull from the local cpython repo. I'd Georg advise to set the default entry in each of the clones' .hg/hgrc Georg file to http://hg.python.org/cpython (as a committer you should Georg be using ssh://h...@hg.python.org/cpython BTW). Thanks. That's not what the dev guide says in its intro here: http://docs.python.org/devguide/setup.html#getting-the-source-code (That is, the dev guide has a new sub-audience other than just people new to Python core development. It also now has to cater a little to people like me with little Mercurial experience.) Georg This way, hg push and hg pull communicate with the remote Georg repo. I don't like that at all. Georg You can still exchange commits with the other local clones by Georg using, for example, hg push ../3.2. (You can also add another Georg entry in the .hgrc's [paths] section if you want to give Georg nicknames to these path names). That seems better. Thx, 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] CPython hg transition complete
Le dimanche 06 mars 2011 à 11:34 -0600, s...@pobox.com a écrit : Assume I have separate 3.1 and 3.2 sandboxes which are sibling directories of each other, and that I commit a change to my 3.1 sandbox, how do I merge the change from 3.1 to 3.2? Assume I don't understand the instructions later on in the section titled Using several working copies. It seems I would have to commit on 3.1, push to the main central repository, merge to 3.2 (how?), then go through the compile, test, repeat cycle again. Is there no way to merge from my 3.1 repo to my 3.2 repo before committing (sorry for the pun) to a central push? Yes, there is. You can simply push to your 3.2 repo instead: $ cd 3.1 $ hg up 3.1# just in case # hack, compile, test $ hg ci -m Issue #xxx: nasty bug now fixed $ hg push ../3.2 $ cd ../3.2 $ hg up 3.2# just in case $ hg merge 3.1 # compile, test, optionally resolve conflicts $ hg ci -m Merge fix for issue #xxx At this point you can push to the public repo from your 3.2 clone, or repeat the above push merge to your default clone (with the default branch checked out) and push from there. (by the way, the $ hg push ../3.2 $ cd ../3.2 sequence above is equivalent to $ cd ../3.2 $ hg pull ../3.1 ) Regards Antoine. ___ 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] hg pull failed
Nick Given the recommended workflow in the devguide (i.e. when forward Nick porting bug fixes, update all public branches in a single push), Nick keeping the transitive connections between local clones is Nick probably a good idea. It also means that we can do the full Nick porting workflow even when offline. So, when I cloned, I should have done something like this: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone 3.2 3.1 hg clone cpython 2.7 hg clone 2.7 2.6 hg clone 2.6 2.5 hg clone 2.5 2.4 instead of cloning everything from cpython, right? 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] hg pull failed
On 06.03.2011 18:39, s...@pobox.com wrote: Nick Transitive. This is nice for the patch flow (fix in oldest, push, Nick switch to next, merge, commit and push, etc, then only touch the Nick central server for the final push of all branches), but it does Nick you mean you need to follow the reverse order when grabbing Nick changes from the central repository. Ummm, push from where to where? Are you assuming some relationship between my sandboxes? push sounds to me like pushing my changes to the central repository. That's not what I would want to do. Any transfer of changesets between repositories is (depending on the direction) called a pull or push, and performed using the hg commands of the same name. The relationship between local clones is as symmetric as the one between a local and a remote clone. Georg ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On Sun, Mar 6, 2011 at 11:41, Michael Foord fuzzy...@voidspace.org.ukwrote: I would like to see us create version specific (i.e. python32.exe / python32w.exe) binaries (or links if we drop support for earlier versions of Windows or some filesystems - I'm agnostic on that issue) *plus* a python3.exe / python3w.exe with last install wins (as it is for currently for file associations). I don't have an ActiveState install on this machine, but I know they have been adding some form of version specific binaries for a while, so maybe they can comment on what they chose and how they chose it, and how people are using it. Are Sridhar or Trent on here? (sorry if this was already mentioned -- I joined late and only skimmed many of the posts) ___ 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] hg pull failed
On 06.03.2011 18:45, s...@pobox.com wrote: Nick Given the recommended workflow in the devguide (i.e. when forward Nick porting bug fixes, update all public branches in a single push), Nick keeping the transitive connections between local clones is Nick probably a good idea. It also means that we can do the full Nick porting workflow even when offline. So, when I cloned, I should have done something like this: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone 3.2 3.1 hg clone cpython 2.7 hg clone 2.7 2.6 hg clone 2.6 2.5 hg clone 2.5 2.4 instead of cloning everything from cpython, right? You can still change the default entries in .hg/hgrc to point to your desired default location. That's the *only* thing that changes depending on where you clone from. Georg ___ 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] Support the /usr/bin/python2 symlink upstream
On 04.03.2011 08:44, Kerrick Staley wrote: [looking at version 88755 of the draft] +1 on anything what is said about python2 (still remembering the unsuccessful proposal from one of the Chicago language summits). I do not like the vagueness about the python link. Sounds like It may point to this or that, but it might change, and it might break, maybe we'll change our position later, in some years. This recommendation is imo wrong: For the time being, it is recommended that python should refer to python2, except on distributions which include only python3 in their base install, or those that wish to push strongly for migration of user scripts to Python 3. Maybe some distributions already did decide on this, but it's definitely not something which will help compatibility across distributions. Further down in a note, It is suggested that even distribution-specific packages follow the python2/python3 convention [...] The note should be a recommendation, and the recommendation a note. Cross platform compatibility should be recommended. The rationale of the proposal only gives a rationale for the python2 link, not for the vagueness of the python link, and when to use it, e.g. to use the most recent interpreter interactively (as suggested by Martin v. Loewis), or to only use it for 2.x and 3.x compatible scripts. From a Debian/Ubuntu perspective I see python2.7 in the distribution for at least two more (LTS) releases (i.e. the next 4-5 years) to run old code or code abandoned by upstreams. I only see extra work with this code, when changing python to point to python3, while I do not see a disadvantage to use python3 (which was part of python3.x from the beginning) for the packaging inside a distribution. so -1 on the python link bits. Matthias ___ 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] r88758 - tracker/instances/python-dev/scripts/addpatchsets
On Sun, 06 Mar 2011 18:23:58 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
-def find_bases(data, rev):
+def hg_splitpatch(data):
+patches = []
+filename = None
+for line in data.splitlines(True):
+if line.startswith('diff -r'):
Now I understand why you would like to discourage git diffs.
But, as I said back then, I don't think it's worthwhile to try and
compute the base rev. Most reviewable patches should apply cleanly
against the latest revision on default, otherwise we're gonna ask the
poster to regenerate the patch anyway.
Would you like to contribute a patch to make that work? It's too tedious
to work without a base revision, so for the time being, this cannot be
supported.
Well, no. I was assuming that basing all patches on tip would make
things simpler.
Regards
Antoine.
___
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] hg pull failed
So, when I cloned, I should have done something like this: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone 3.2 3.1 hg clone cpython 2.7 hg clone 2.7 2.6 hg clone 2.6 2.5 hg clone 2.5 2.4 instead of cloning everything from cpython, right? You can still change the default entries in .hg/hgrc to point to your desired default location. That's the *only* thing that changes depending on where you clone from. What I often do is to add another line (below default=, or in ~/.hgrc), so I can do hg pull # pulls from my local copy hg push pydotorg # pushes directly into the remote directory 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] Support the /usr/bin/python2 symlink upstream
I do not like the vagueness about the python link. Sounds like It may point to this or that, but it might change, and it might break, maybe we'll change our position later, in some years. I can understand the uneasiness about that, however, the slightly sarcastic phrasing describes the intent precisely. It is deliberate that it may refer to any version. There are many precedents for that; /usr/bin/wish, /usr/bin/perl, or /usr/bin/ruby don't give any version guarantees either. They are still useful, primarily for interactive (REPL) use, or when you write scripts that are specific to a host and meant to be updated when the system gets updated. This recommendation is imo wrong: For the time being, it is recommended that python should refer to python2, except on distributions which include only python3 in their base install, or those that wish to push strongly for migration of user scripts to Python 3. I agree. Your wording is much better (it can be anything. If you don't like that, use a more specific file name). Maybe some distributions already did decide on this, but it's definitely not something which will help compatibility across distributions. The message from the PEP is clear: if you want something to work across systems, don't use /usr/bin/python, but either python2 or python3. So the very existence of the PEP helps compatibility across distributions. As the PEP points out, if some distribution doesn't conform, it's easy for the admin to work around that (i.e. add the missing symlink); this change will fix it for good (i.e. for all scripts to come). Notice that this not only works for Linux, but for all unixish systems. From a Debian/Ubuntu perspective I see python2.7 in the distribution for at least two more (LTS) releases (i.e. the next 4-5 years) to run old code or code abandoned by upstreams. I only see extra work with this code, when changing python to point to python3, while I do not see a disadvantage to use python3 (which was part of python3.x from the beginning) for the packaging inside a distribution. so -1 on the python link bits. It is conforming to the PEP to have /usr/bin/python as 2.x forever (i.e for at least two LTS releases - in Debian, that *is* forever). So Debian can make stronger guarantees than the PEP, and still conform to the PEP. 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] r88758 - tracker/instances/python-dev/scripts/addpatchsets
Would you like to contribute a patch to make that work? It's too tedious to work without a base revision, so for the time being, this cannot be supported. Well, no. I was assuming that basing all patches on tip would make things simpler. It's very easy to get the base code if you know the base revision, through http://hg.python.org/cpython/raw-file/rev/path I only now found out that hg.python.org also supports http://hg.python.org/cpython/raw-file/default/path http://hg.python.org/cpython/raw-file/tip/path So it would be possible to check for one of these if no revision number is given. However, that would require more changes to the patch parsing. As for basing changes on tip: IIUC, tip may be any branch. So if somebody develops a patch, there is a good chance that tip is not default when the patch is submitted to the tracker. Then the patch would not apply (to tip), and no review would be possible. 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] hg pull failed
On 2011-03-06 20:09, Martin v. Löwis wrote: So, when I cloned, I should have done something like this: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone 3.2 3.1 hg clone cpython 2.7 hg clone 2.7 2.6 hg clone 2.6 2.5 hg clone 2.5 2.4 instead of cloning everything from cpython, right? You can still change the default entries in .hg/hgrc to point to your desired default location. That's the *only* thing that changes depending on where you clone from. What I often do is to add another line (below default=, or in ~/.hgrc), so I can do hg pull # pulls from my local copy hg push pydotorg # pushes directly into the remote directory Not sure if it fits in your specific case you mention here, but Mercurial has a reserved path alias name default-push with special meaning: 'hg push' pushes to (1) the path defined as default-push under [paths] in .hg/hgrc (2) if default-push is not defined, to the default path (3) if neither is defined, the command aborts with an error message 'hg pull' always pulls from the default path (default-push doesn't matter for pull). (Same for the outgoing/incoming commands.) http://selenic.com/repo/hg/help/paths ___ 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] hg pull failed
Not sure if it fits in your specific case you mention here, but Mercurial has a reserved path alias name default-push with special meaning: Ah. I didn't know that, 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] [PEPs] Support the /usr/bin/python2 symlink upstream
Some nitpicks: 'The python command on Unix-Like Systems': This should be 'The python Command on Unix-Like Systems' python will refer to the same target as either python2 or python3, depending on the specific distribution and system: Nothing should break if python isn't the same as either python2 or python3 (sysadmins might want to set something like this up), so let's change it to python will refer to some version of either Python 2.x or Python 3.x. Similarly, the same version of Python as either python2 or python3 should be some version of either Python 2.x or Python 3.x. For the time being, it is recommended that python should refer to python2, except on distributions which include only python3 in their base install, or those that wish to push strongly for migration of user scripts to Python 3.: This bullet should be removed, since it unnecessarily lengthens the Recommendation (the same topic is addressed in the first bullet of the Notes) and is intended to be less strongly suggested than the other points in the Recommendation. ...all new code...: take out new; we would also like existing code to be modified when possible. the make install command and the Mac OS X installer in the 2.7 version of CPython will be adjusted to create the new python2 command in addition to the existing python and python2.7 commands: Are we going to specify which is the symbolic link and which is the actual executable? Per the 5th point in the Notes, I think that python should be a symlink (does the default installer do this already, placing the executable in pythonX.X?), since creating it as a link has advantages over an executable in certain situations, but the reverse is not true. directly rather than via sys.executable: This snippet is unneeded and confusing, because the or any code that invokes the Python 2 interpreter parenthetical note is intended to address code in other languages that execute the interpreter and not Python code. As an alternative to the recommendation presented above, some distributions may choose to leave the python command itself undefined, leaving sysadmins and users with the responsibility to choose their own preferred version to be made available as the python command.: The original version of this statement only addressed systems that have traditionally left python undefined (OpenBSD apparently does this). As it's worded now, it creates the possibility that distributions will suddenly start leaving python undefined as a result of this PEP, to the vexation of end-users. The Exclusions of MS Windows section should be shortened to This PEP deliberately excludes any proposals relating to Microsoft Windows, due to multiple issues in implementing a similar solution. This is because this PEP is about the solution on Unix-Like systems; the discussion of the issue on other platforms adds unnecessary length. The ideas in this section are preserved in this discussion thread (which is referenced in the PEP) and the verbatim text will still exist in the SVN, so anyone who needs this information can still get it easily if it is deleted. Although I am unfamiliar with Windows and am thus unaware of all the issues and possible solutions, I think that an excellent solution for the Python 2/3 issue on Windows was that suggested by Michael Foord: ...a stub python.exe that looks at the shebang line and then delegates to the appropriate pythonX.Y.exe would be a possibility... However, implementing this solution will take time and will slow the finalization of a solution for Unix-like systems if it is included in this PEP. -Kerrick Staley ___ 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] (Final?) release of Python 2.5 in April
According to our security fix policy, Python 2.5 releases can happen until September 2011. Since there are unreleased changes, I plan to make a release soon, which likely means April. I'll call this tentatively the final release of Python 2.5, even though security issues discovered after wards could require yet another release in September/October. So if you have any pending security fixes that you want to get into 2.5, please start committing them. Committing them into Mercurial is fine, even though I'm going to make the release from Subversion (copying all new changesets over as necessary). 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] [PEPs] Support the /usr/bin/python2 symlink upstream
Am 06.03.2011 21:12, schrieb Kerrick Staley: Some nitpicks: Heh, you are the author of the PEP :-) You'll find the source of your PEP in http://svn.python.org/projects/peps/trunk/ Please provide Nick with a patch/updated version; if you want to, you can also get write access to the PEP repository. 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] [PEPs] Support the /usr/bin/python2 symlink upstream
Sorry, I was unaware that Gmail splits threads that are longer than 100 messages, so I hadn't seen the last 26 messages when I wrote the above message. It seems that in the last 26 messages, there was lots of discussion toward the inclusion of provisions for Windows in this PEP. I didn't mean to silence those opinions, so I retract the part about Windows in my last message and instead defer the decision to the rest of you, since I don't care too strongly about it. I sometimes neglect to throw an I think into a sentence when I really should. However, I would still like to suggest in the softest of ways that, since it seems that the issues on Windows are complex and multiple possible solutions must be evaluated, it may be best to finalize this PEP and then start work on another one that addresses the issue on Windows. Also, there may not be enough commonality between the solutions on the two platforms to justify keeping the solutions in the same document. Kerrick Staley ___ 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] CPython hg transition complete
Antoine Yes, there is. You can simply push to your 3.2 repo instead: Antoine $ cd 3.1 Antoine $ hg up 3.1# just in case Antoine # hack, compile, test Antoine $ hg ci -m Issue #xxx: nasty bug now fixed Antoine $ hg push ../3.2 Antoine $ cd ../3.2 Antoine $ hg up 3.2# just in case Antoine $ hg merge 3.1 Antoine # compile, test, optionally resolve conflicts Antoine $ hg ci -m Merge fix for issue #xxx Thanks. I don't understand what the hg merge 3.1 does. You already pushed from 3.1 to ../3.2 then updated in 3.2. Didn't that make the changes available? 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] CPython hg transition complete
Am 06.03.2011 21:46, schrieb s...@pobox.com: Antoine Yes, there is. You can simply push to your 3.2 repo instead: Antoine $ cd 3.1 Antoine $ hg up 3.1# just in case Antoine # hack, compile, test Antoine $ hg ci -m Issue #xxx: nasty bug now fixed Antoine $ hg push ../3.2 Antoine $ cd ../3.2 Antoine $ hg up 3.2# just in case Antoine $ hg merge 3.1 Antoine # compile, test, optionally resolve conflicts Antoine $ hg ci -m Merge fix for issue #xxx Thanks. I don't understand what the hg merge 3.1 does. You already pushed from 3.1 to ../3.2 then updated in 3.2. Didn't that make the changes available? Included, but not available. The changes are in your 3.2 clone, but not in the 3.2 branch of the 3.2 clone. Each clone has all branches, even if you only update to one of them. So after hg push, the change is on the 3.1 branch of the 3.2 clone. The merge 3.1 tries to merge all changes on the 3.1 branch that are not already on the 3.2 branch to the 3.2 branch. HTH, 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] CPython hg transition complete
Beside Martin's answer, you might want to read: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html or perhaps: http://hginit.com/ Regards Antoine. Le dimanche 06 mars 2011 à 14:46 -0600, s...@pobox.com a écrit : Antoine Yes, there is. You can simply push to your 3.2 repo instead: Antoine $ cd 3.1 Antoine $ hg up 3.1# just in case Antoine # hack, compile, test Antoine $ hg ci -m Issue #xxx: nasty bug now fixed Antoine $ hg push ../3.2 Antoine $ cd ../3.2 Antoine $ hg up 3.2# just in case Antoine $ hg merge 3.1 Antoine # compile, test, optionally resolve conflicts Antoine $ hg ci -m Merge fix for issue #xxx Thanks. I don't understand what the hg merge 3.1 does. You already pushed from 3.1 to ../3.2 then updated in 3.2. Didn't that make the changes available? 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] CPython hg transition complete
Martin Included, but not available. The changes are in your 3.2 Martin clone, but not in the 3.2 branch of the 3.2 clone. Each Martin clone has all branches, even if you only update to one of Martin them. Martin So after hg push, the change is on the 3.1 branch of the Martin 3.2 clone. The merge 3.1 tries to merge all changes on the Martin 3.1 branch that are not already on the 3.2 branch to the 3.2 Martin branch. Thanks, that's helpful. 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] [PEPs] Support the /usr/bin/python2 symlink upstream
Heh, you are the author of the PEP :-) You'll find the source of your PEP in http://svn.python.org/projects/peps/trunk/ Please provide Nick with a patch/updated version; if you want to, you can also get write access to the PEP repository. I should've mentioned that I'd like a consensus (or a lack of protest) on the changes related to these snippets: -python will refer to the same target as either python2 or python3, depending on the specific distribution and system -the make install command and the Mac OS X installer in the 2.7 version of CPython will be adjusted to create the new python2 command in addition to the existing python and python2.7 commands -Exclusions of MS Windows The other changes are in the attached diff. The source needs to be reflown if line length is to be kept consistent. I don't feel I need write access to the repository at this point. -Kerrick Staley --- pep-0394.txt2011-03-05 01:06:50.0 -0600 +++ pep-0394-revised.txt2011-03-06 15:07:42.37338 -0600 @@ -1,5 +1,5 @@ PEP: 394 -Title: The python command on Unix-Like Systems +Title: The python Command on Unix-Like Systems Version: $Revision$ Last-Modified: $Date$ Author: Kerrick Staley m...@kerrickstaley.com, @@ -37,11 +37,7 @@ * Similarly, the more general ``python`` command should be installed whenever any version of Python is installed and should invoke the same version of Python as either ``python2`` or ``python3``. -* For the time being, it is recommended that ``python`` should refer to - ``python2``, except on distributions which include only ``python3`` in their - base install, or those that wish to push strongly for migration of user - scripts to Python 3. -* In order to tolerate differences across platforms, all new code that needs +* In order to tolerate differences across platforms, all code that needs to invoke the Python interpreter should not specify ``python``, but rather should specify either ``python2`` or ``python3`` (or the more specific ``python2.x`` and ``python3.x`` versions; see the Notes). @@ -68,7 +64,7 @@ ``python`` command to Python 2, some now alias it to Python 3. Some of the former also do not provide a ``python2`` command; hence, there is currently no way for Python 2 code (or any code that invokes the Python 2 -interpreter directly rather than via ``sys.executable``) to reliably run on +interpreter) to reliably run on all systems without modification, as the ``python`` command will invoke the wrong interpreter version on some systems, and the ``python2`` command will fail completely on others. The recommendations in this PEP provide a very @@ -113,9 +109,10 @@ ``python`` file, they can do so without inadvertently deleting the previously installed binary. * As an alternative to the recommendation presented above, some distributions - may choose to leave the ``python`` command itself undefined, leaving - sysadmins and users with the responsibility to choose their own preferred - version to be made available as the ``python`` command. + that have traditionally left the ``python`` command undefined may continue + to do so, leaving + sysadmins and users with the responsibility of making their own preferred + version available as the ``python`` command. * If the Python 2 interpreter becomes uncommon, scripts should nevertheless continue to use the ``python3`` convention rather that just ``python``. This will ease transition in the event that yet another major version of Python ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
I should've mentioned that I'd like a consensus (or a lack of protest) on the changes related to these snippets: [...] -Exclusions of MS Windows I think you won't get consensus on that: there are strong proponents and strong opponents (I think Mark being a strong proponent of such exclusion, and Michael being a strong opponent). I personally don't care either way much, but will only do with the Windows installer what the PEP tells me to do (if anything) (more precisely, I remain -0 on changing 2.7, and +0 on changing 3.3). So it comes back to you as the PEP author to take a stance, which you did. It's recommended tradition to record any opposing opinions in the PEP, along with rebuttals, so that the same arguments aren't brought up over and over again. If discussion then settles, it's up to the PEP dictator to approve or reject the whole text. 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] [PEPs] Support the /usr/bin/python2 symlink upstream
In article AANLkTimPEDWCsiOXfq=ppyypfkbmr-oja54m-cnaq...@mail.gmail.com, Kerrick Staley m...@kerrickstaley.com wrote: I should've mentioned that I'd like a consensus (or a lack of protest) on the changes related to these snippets: -python will refer to the same target as either python2 or python3, depending on the specific distribution and system -the make install command and the Mac OS X installer in the 2.7 version of CPython will be adjusted to create the new python2 command in addition to the existing python and python2.7 commands FYI - I will have some comments on the PEP, primarily with regard to OS X, in the next day. -- Ned Deily, n...@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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 06/03/2011 21:36, Martin v. Löwis wrote: I should've mentioned that I'd like a consensus (or a lack of protest) on the changes related to these snippets: [...] -Exclusions of MS Windows I think you won't get consensus on that: there are strong proponents and strong opponents (I think Mark being a strong proponent of such exclusion, and Michael being a strong opponent). Guido said he would like to see the PEP address Windows, although that requires *some* consensus. Paul Moore was +1 on Windows being included. Mark did accept that some of the changes were desirable, but was also concerned they didn't address all the issues on Windows. I *would* like to see all the issues addressed but I think that is outside the scope of this PEP. The solution I would like to see for Windows, with other issues to be addressed as issues in the bug tracker: Create version specific (i.e. python32.exe / python32w.exe) binaries *plus* a python3.exe / python3w.exe in the installer. Similar for Python 2.7 if we decide to modify 2.7 for the other platforms. (Presumably the same also applies to 3.1?) It would be fine for these to be binaries duplicating python.exe, or to be links (which will mean not supporting some filesystems and possibly not some versions of python). This means that Windows users who add their Python install to the path will have python, python3 and python3.2 on the path. (I believe this means *most* Windows developers.) Which binary python and python3 actually launch when invoked from the command line will depend which comes first in the path. If the installer is enhanced to (optionally) automatically add a python install to the path then this should follow the last installed wins rules as file associations do currently. An alternative solution, (perfectly acceptable to me) is that when python is installed on Windows for all users it could put python.exe *plus* the aforementioned version specific binaries into System32 which would automatically put them on the path. This also has the last installed wins behaviour for python.exe and python3.exe. (Would it require installing the appropriate msvcrt into System32 as well and is this desirable?) A generic Python launcher that could be used for the file association and honours the Unix style shebang line, delegating to the appropriate version of python, is an interesting idea but out of the scope of this PEP. It would be interesting to see if Mark, or others, are strongly opposed to these ideas or have strong preferences. If the biggest downside is really that it still leaves some issues unresolved then lets do this and tackle the other issues separately. All the best, Michael I personally don't care either way much, but will only do with the Windows installer what the PEP tells me to do (if anything) (more precisely, I remain -0 on changing 2.7, and +0 on changing 3.3). So it comes back to you as the PEP author to take a stance, which you did. It's recommended tradition to record any opposing opinions in the PEP, along with rebuttals, so that the same arguments aren't brought up over and over again. If discussion then settles, it's up to the PEP dictator to approve or reject the whole text. 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] CPython hg transition complete
On 3/6/2011 12:44 PM, Antoine Pitrou wrote: Le dimanche 06 mars 2011 à 11:34 -0600, s...@pobox.com a écrit : At this point you can push to the public repo from your 3.2 clone, or repeat the above push merge to your default clone (with the default branch checked out) and push from there. I presume 'push from there' means to the central repository. Is just one final central push needed, because all branches are in the 'default' clone (or three)? -- Terry Jan Reedy ___ 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] hg pull failed
On 3/6/2011 11:07 AM, Georg Brandl wrote: On 06.03.2011 16:44, s...@pobox.com wrote: Georg Yesterday's repository was still the test repository, now it's Georg the real one. You'll need to clone again. Thanks. I have a question about updates from cloned clones. Suppose I clone the central repo then clone locally to get the 2.7 and 3.2 release branches: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone cpython 2.7 If I want to later update my maintenance branches to get any updates will it suffice to just hg pull in my 2.7 and/or 3.2 directories or do I need to pull in cpython first? I guess my question is, are these clones transitive? If you don't change repo configuration after these commands, hg pull in the 3.2 repo will pull from the local cpython repo. I'd advise to set the default entry in each of the clones' .hg/hgrc file to http://hg.python.org/cpython (as a committer you should be using ssh://h...@hg.python.org/cpython BTW). But would it work to just pull once into default from the central repository (slow) and then pull from there (fast) into maintenance clones? I expect to nearly always be only working on issues that affect default. This way, hg push and hg pull communicate with the remote repo. You can still exchange commits with the other local clones by using, for example, hg push ../3.2. (You can also add another entry in the .hgrc's [paths] section if you want to give nicknames to these path names). Georg -- Terry Jan Reedy ___ 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] r88758 - tracker/instances/python-dev/scripts/addpatchsets
On 3/6/2011 11:43 AM, Antoine Pitrou wrote: compute the base rev. Most reviewable patches should apply cleanly against the latest revision on default, That was sensible when we ported patches back, but if they should be ported forward (3.1 = 3.2 = default), do we not want the patch to apply to the earlier branch? otherwise we're gonna ask the poster to regenerate the patch anyway. -- Terry Jan Reedy ___ 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] What does the m mean for the Mac OS X include folder?
There is a break with convention for the include folder name: /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/ What does the m mean? Barry ___ 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] devguide: More miscellaneous review comments.
On Mon, Mar 7, 2011 at 3:05 AM, Antoine Pitrou solip...@pitrou.net wrote: At least a manual checklist is able to explain you why the items are recommended. ... which make patchcheck's very terse output doesn't provide. That said I admit it can be useful to newcomers. I'd say the opposite - I personally find it useful because I already know what all the items refer to (and hence know when I can safely ignore them). It's a handy memory jogger to see if I completely forgot something (forgetting to check ACKS for names I'm not familiar with is one that often catches me out). Having a manual checklist listed in the devguide would be very useful, especially for new committers. It could mention make patchcheck as well. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?
I see that PyCObject_AsVoidPtr has been removed from python 3.2. The 3.2 docs do not seem to explain this has happened and what to replace it with. I searched the 3.2 docs and failed to find PyCObject_AsVoidPtr. I looked at the whats new page and the API PEP. Did I miss where this is documented? Because I have a contribution to PyCXX to use a new API that replaces PyCObject_AsVoidPtr I'm not stuck. But I'm sure I'm not the only python user that uses PyCObject_AsVoidPtr and will need a point to the replacement. Barry ___ 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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?
2011/3/6 Barry Scott ba...@barrys-emacs.org: I see that PyCObject_AsVoidPtr has been removed from python 3.2. The 3.2 docs do not seem to explain this has happened and what to replace it with. It's replaced with PyCapsule. -- Regards, Benjamin ___ 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] Support the /usr/bin/python2 symlink upstream
On Mon, Mar 7, 2011 at 4:12 AM, Matthias Klose d...@ubuntu.com wrote: so -1 on the python link bits. Some of the less mainstream distributions are starting to consider moving to python3 as the *only* version of Python that is installed by default, so I wanted to cover them in the suggestions (indeed, it was those experiments that reopened this discussion, since the python link could no longer always be trusted to mean Python 2.x, and the python2 link isn't available by default on most distros). Since allowing forward-looking experiments like that is one of the major advantages of the Linux distro model, I don't want to outright advise against such attempts, even if it would be an absolutely terrible idea for a mainstream distro targeted at widespread production usage to try it. By advocating use of the python2 link, and pointing out that the python link will likely start varying across platforms over the next few years, we also help make it *possible* for distros and individual sysadmins to eventually be able to change the target of the python link safely. That said, I'll look into rewording the main recommendations to more strongly suggest keeping python - python2 for any distro that cares about backwards compatibility, with a note somewhere about the option of making it point to python3 instead for distros that are more willing to break third party code. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] hg pull failed
On Mon, Mar 7, 2011 at 5:36 AM, Adrian Buehlmann adr...@cadifra.com wrote: Not sure if it fits in your specific case you mention here, but Mercurial has a reserved path alias name default-push with special meaning: 'hg push' pushes to (1) the path defined as default-push under [paths] in .hg/hgrc (2) if default-push is not defined, to the default path (3) if neither is defined, the command aborts with an error message 'hg pull' always pulls from the default path (default-push doesn't matter for pull). Oh, so I can split the lookup so a bare hg pull comes directly from pydotorg, while having a bare hg push follow the transitive links between my local clones? Very interesting! I'll try the fully transitive workflow for now, though and see how I like it. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?
On Mon, Mar 7, 2011 at 9:09 AM, Barry Scott ba...@barrys-emacs.org wrote: I see that PyCObject_AsVoidPtr has been removed from python 3.2. The 3.2 docs do not seem to explain this has happened and what to replace it with. I searched the 3.2 docs and failed to find PyCObject_AsVoidPtr. I looked at the whats new page and the API PEP. Did I miss where this is documented? The CObject API was deprecated in Python 3.1 before its complete removal in 3.2. Its deprecation and planned replacement with the Capsule API was mentioned briefly in the 3.1 What's New document and a deprecation warning and redirection were included in the 3.1 documentation: http://docs.python.org/release/3.1.3/c-api/cobject.html Details on the API replacement can be found here: http://bugs.python.org/issue5630 Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 7/03/2011 1:55 AM, Paul Moore wrote: On 6 March 2011 02:33, Mark Hammondskippy.hamm...@gmail.com wrote: IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. No, no, no! Please no! Bat files are a lousy way of writing wrappers on Windows, as they don't nest. I've lost count of the number of times I've been tripped up by putting a series of commands into a batch file, only to have them fail because somewhere in the middle is a bat file wrapper which makes the outer bat file stop part way through :-( To be clear, I was suggesting that using .bat files in system32 is a close analogy to the *nix situation - I didn't mean to advocate for it to actually happen :) Further, I see the creation of a python3.exe in the Python install directory as quite different than the *nix situation (where the 'python3' link is not in the install dir, but instead in a 'system' dir). IOW, I was trying to point out the solution to the problem on *nix doesn't translate that well to Windows, so Windows should not be considered as part of this PEP. That isn't to suggest Windows should not be considered at all. That said though, I'm only -0 on python2.exe/python3.exe - I don't think it will hurt, but also don't think it will help that much in practice. It may also turn out to be unnecessary should a complete solution be implemented - eg, a python launcher which (a) read the shebang lines and (b) allowed something like python -3 on the command-line would render both python3.exe and requests to have multiple installed Python versions on the PATH redundant. 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
[Python-Dev] hg diff
Martin v. Löwis writes: It seems that the dev guide recommends to use the --git option in hg diff. I'm working on the Rietveld integration, and found that this option makes things worse: the regular diff includes the base revision of the patch; hg diff --git doesn't. Does the regular diff work acceptably for the kinds of changes that diff --git was designed to be an improvement for? ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 7/03/2011 10:04 AM, Michael Foord wrote: Paul Moore was +1 on Windows being included. Mark did accept that some of the changes were desirable, but was also concerned they didn't address all the issues on Windows. I *would* like to see all the issues addressed but I think that is outside the scope of this PEP. I simply think Windows is outside the scope of this PEP - the title is The python command on Unix-Like Systems - IMO it should be kept short and focus on exactly what the title says. ... A generic Python launcher that could be used for the file association and honours the Unix style shebang line, delegating to the appropriate version of python, is an interesting idea but out of the scope of this PEP. As above - I think Windows should be kept out of scope. It would be interesting to see if Mark, or others, are strongly opposed to these ideas or have strong preferences. If the biggest downside is really that it still leaves some issues unresolved then lets do this and tackle the other issues separately. As mentioned in my other email, I'm -0 as I think they are slightly misguided. Why not leave the PEP with Unix-like in the title to Unix-like systems and create one with Windows in the title for Windows? :) 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] hg diff
Am 07.03.2011 02:24, schrieb Stephen J. Turnbull: Martin v. Löwis writes: It seems that the dev guide recommends to use the --git option in hg diff. I'm working on the Rietveld integration, and found that this option makes things worse: the regular diff includes the base revision of the patch; hg diff --git doesn't. Does the regular diff work acceptably for the kinds of changes that diff --git was designed to be an improvement for? I don't know. What are the kinds of changes that diff --git was designed for? 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] What does the m mean for the Mac OS X include folder?
In article 5ab965c9-7d5f-41b6-a5e9-2b881e92a...@barrys-emacs.org,
Barry Scott ba...@barrys-emacs.org wrote:
There is a break with convention for the include folder name:
/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/
What does the m mean?
The m means that the Python was configured and built with pymalloc.
This change was introduced by Issue9807 deriving configuration
information for different builds with the same prefix which is an
adjunct to PEP 3149 ABI version tagged .so files. As described in the
PEP, the idea is to allow the installation of multiple build variants on
one system, for instance, a set of debug shared libraries (with flag
d) alongside the normal optimized libraries. This was extended in
Issue9807 to cover the corresponding Include files. On current Debian
installs of python3.2, for instance, one sees:
$ ls -ld /usr/include/python3.2*
lrwxrwxrwx [...] /usr/include/python3.2 - python3.2mu
drwxr-xr-x [...] /usr/include/python3.2mu
(u means wide-unicode.)
For OS X framework builds, the unversioned convenience link is not
created:
$ cd /Library/Frameworks/Python.framework/Versions/3.2
$ ls -l
lrwxr-xr-x [...] Headers@ - include/python3.2m
-r-xrwxr-x [...] Python*
drwxrwxr-x [...] Resources/
drwxrwxr-x [...] bin/
drwxrwxr-x [...] include/
drwxrwxr-x [...] lib/
drwxrwxr-x [...] share/
$ ls -ld ./include/python3.2*
drwxrwxr-x [...] ./include/python3.2m/
Perhaps it should. And the implications of the multiple build variants
feature for OS X frameworks build have probably not yet been fully
considered. However, there are now multiple ways to find the proper
location of the include files and library files, both in
platform-independent and framework-specific (note the Headers link)
ways. And they all seem to produce the correct results.
$ bin/python3.2
import sysconfig
sysconfig.get_path('include')
'/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/p
ython3.2m'
^D
$ bin/python3-config --include
-I/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/
python3.2m
-I/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/
python3.2m
(So good you get it twice in the same line.)
In some ways, this issue falls into a bit of a black hole. For other
Unix-y platforms, the PSF (python.org) does not provide binaries or
installers so issues like installation locations are to some extent at
the discretion of the various distributors (Debian, Fedora, et al). For
Mac OS X and Windows, the PSF also plays the role of binaries/installer
distributor so some things specific to those installers may need to be
documented outside of the standard Python documentation set (or properly
noted).
Feel free to open an issue if you feel something should be changed (code
or documentation).
--
Ned Deily,
n...@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] hg diff
Martin v. Löwis writes: Am 07.03.2011 02:24, schrieb Stephen J. Turnbull: Martin v. Löwis writes: It seems that the dev guide recommends to use the --git option in hg diff. I'm working on the Rietveld integration, and found that this option makes things worse: the regular diff includes the base revision of the patch; hg diff --git doesn't. Does the regular diff work acceptably for the kinds of changes that diff --git was designed to be an improvement for? I don't know. What are the kinds of changes that diff --git was designed for? I don't know exactly how much of git diffcore has been implemented in hg diff --git. However, git's diff handles renames and copies correctly and pleasantly, including swapping file names (ie, renaming a to b and b to a simultaneously), and can change file modes. That kind of change is rather unpleasant to deal with in a traditional diff format. Eg, renames are represented as deleting all the lines from one file and re-adding them as a new file. ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 3/6/2011 8:18 PM, Mark Hammond wrote: To be clear, I was suggesting that using .bat files in system32 is a close analogy to the *nix situation - I didn't mean to advocate for it to actually happen :) Further, I see the creation of a python3.exe in the Python install directory as quite different than the *nix situation (where the 'python3' link is not in the install dir, but instead in a 'system' dir). IOW, I was trying to point out the solution to the problem on *nix doesn't translate that well to Windows, so Windows should not be considered as part of this PEP. That isn't to suggest Windows should not be considered at all. That said though, I'm only -0 on python2.exe/python3.exe - I don't think it will hurt, but also don't think it will help that much in practice. It may also turn out to be unnecessary should a complete solution be implemented - eg, a python launcher which (a) read the shebang lines and (b) allowed something like python -3 on the command-line would render both python3.exe and requests to have multiple installed Python versions on the PATH redundant. I completely support Mark's repeated request that Windows be left out of the PEP. I'm sure that Guido himself would say that 'include Windows' was meant to be qualified with 'if reasonable and sensible'. To summarize why not 'reasonable and sensible': 1. The solution in the PEP depends on the operating system respecting the shebang line. Windows does not, so the PEP is not appicable, unless we write a launcher that does. But that is outside the scope of the PEP. 2. There is something of a consensus on most of the PEP as is, but less for Windows. The Unix-like PEP should be finalized, approved, and implemented now. Windows can wait. 3. As a Windows user, I would like a *complete* solution that cannot all be part of PEP. It makes no sense to incorporate a partial solution that may be obsoleted by a real Windows install PEP. 4. I think a launcher may be the best idea. If so, other parts of a complete solution will flow from how that is written. 5. The PEP authors cannot write a Windows sub-PEP, so it would require different authors and effectively be a half-PEP in itself anyway. The implementations of the currently PEP and a Windows upgrade would mostly be disjoint also, both in terms of code and authors. -- Terry Jan Reedy ___ 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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?
On 3/6/2011 6:09 PM, Barry Scott wrote: I see that PyCObject_AsVoidPtr has been removed from python 3.2. The 3.2 docs do not seem to explain this has happened and what to replace it with. I searched the 3.2 docs and failed to find PyCObject_AsVoidPtr. I looked at the whats new page and the API PEP. Did I miss where this is documented? Georg recently reaffirmed on a tracker issue that when something is removed from the code, it is removed from the docs also. So the place to look for a deprecation notice and replacement suggestion is in the last release where present. -- Terry Jan Reedy ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 3/6/2011 7:07 AM, Michael Urman wrote: I think Glenn Linderman hit the use cases on the head; I'm unclear why he was against the overhead of a helper executable. The things I would really want solutions for are these: * double click on a script, and have it launch the right python (2 or 3, w or not) * Probably scan for the final python[.\d]+ string and assume it's relevant. * be able to easily invoke python to interpret a script from the command prompt I'd be comfortable with setting associations to a set of thin executable wrappers which examined the #! line to extract a python version. I'm only against the overhead of a helper written in Python, since it would have to launch Python (some explicit version) to run the helper script, and then launch the right version of Python to execute the real script. You mention a thin executable wrapper, and I have no problem with the overhead of that, probably. Seems that the PEP addresses two sub problems on Unix created by the coexistence of multiple incompatible major versions of Python: (1) how to invoke the right version of the interactive Python from the command line, and (2) how to specify the right version of Python inside Python scripts. One solution solves both problems on Unix... the declaration that /usr/bin/python (generally on the PATH and invocable from the shell as python) may be an installation dependent version, and the creation of appropriate version specific links and/or binaries for specific major and/or minor versions, to be used either from the command line or the #! line of scripts. For Windows, it is true at present that neither of the above problems has a solution: (1) a fully qualified installation path name must be used to invoke any version of Python, since it is not on the PATH (2) Only the last installed version of Python will be invoked by launching a Python script name something-or-another.py Hence, omitting Windows behaviors from the PEP leaves Windows without a solution for either problem, no worse off than it was before, but neither is it better off. If the PEP wants to address (1) interactive launching from the command line on Windows, that could be done by placing a batch file in System32; providing versioned symlinks in installed on a file system that supports them, or providing versioned binaries on a file system that doesn't support symlinks, either in System32, or by adding the Python installation directory to the PATH. For interactive use, most of these solutions are roughly equivalent in function. Since Windows does not use a #! line, then the solutions for (2) must be different. The ones that I can think of are: (A) declare the Python version in the name of the script file. By doing so in the extension, additional Windows associations could be created to launch different versions of Python. Switching versions would be as simple as renaming the file, changing the extension to include a different version. However, various tools would have to learn about additional extensions that mean Python (syntax directed editors, etc.) And it would be hard to have a script in a module, unless the importer recognized all those extensions too. So this solution has ripple effects that make it unattractive, although it is simple to implement the basic feature. (B) declare the Python version in the content of the script file. This cures most of the ripple effects of the above, but requires a launcher or wrapper program to be designed, implemented, and installed. There are a variety of subsolutions for different ways of declaring the version. (B1) Use the Unix #! line, and attempt to parse the version from it. This assumes there is a Unix #! line, note that Windows-only scripts wouldn't need them in the first place. Looking at and interpreting the Unix #! line, and translating it into an invocation of Python on Windows is clever and doable, but very tightly tied to Python. (B2) Use a second #! line, and attempt to parse a whole command from it, using Windows pathname syntax. This is attractive for cross-platform script, and builds on the Unix #! line which is well-understood by Unix and cross-platform developers. Again, Windows-only scripts wouldn't need a Unix #! line, but if this solution uses a second one, then the first must be created, possibly empty. Also, if there are parameters the script needs that only apply to one platform, they could be placed in the appropriate platform's #! line. (B3) Invent a variant syntax for #! -- perhaps #@. Since it is different than #!, it could be on the first line, if no Unix #! line is needed, but if not found on the first line, the second line would be examined, to allow #! on the first line for a cross-platform script. Same costs/benefits as (B2). (B4) As a variation on (B2) or (B3), the declaration of the version would not have to be a command line format... it could be #@ Version 3.2,
Re: [Python-Dev] hg diff
Am 07.03.2011 03:43, schrieb Stephen J. Turnbull: Martin v. Löwis writes: Am 07.03.2011 02:24, schrieb Stephen J. Turnbull: Martin v. Löwis writes: It seems that the dev guide recommends to use the --git option in hg diff. I'm working on the Rietveld integration, and found that this option makes things worse: the regular diff includes the base revision of the patch; hg diff --git doesn't. Does the regular diff work acceptably for the kinds of changes that diff --git was designed to be an improvement for? I don't know. What are the kinds of changes that diff --git was designed for? I don't know exactly how much of git diffcore has been implemented in hg diff --git. However, git's diff handles renames and copies correctly and pleasantly, including swapping file names (ie, renaming a to b and b to a simultaneously), and can change file modes. That kind of change is rather unpleasant to deal with in a traditional diff format. Eg, renames are represented as deleting all the lines from one file and re-adding them as a new file. Ok, so the next question is what constitutes an acceptable representation. I find the original approach to diff completely acceptable, also considering that people rarely rename files, and if they do, they typically don't put patches into a bug tracker. 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] [PEPs] Support the /usr/bin/python2 symlink upstream
I think that at this point there's been sufficient agreement that the technical issues on Windows are too complex to warrant addressing them in this PEP, and that a separate PEP will be written addressing Windows, so that is what will happen. A new email thread for the Windows topic should be started so that the discussions can be separated, and those uninterested in the Windows question can stop following that discussion without missing Unix-related comments buried in it. -Kerrick Staley ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 7/03/2011 3:30 PM, Glenn Linderman wrote: I'm only against the overhead of a helper written in Python, since it would have to launch Python (some explicit version) to run the helper script, and then launch the right version of Python to execute the real script. You mention a thin executable wrapper, and I have no problem with the overhead of that, probably. Yeah - I think any such wrapper could be a reasonably small C program - although I guess that depends on the decided functionality :) ... Since Windows does not use a #! line, then the solutions for (2) must be different. The ones that I can think of are: (A) declare the Python version in the name of the script file. By doing so in the extension, additional Windows associations could be created to launch different versions of Python. Switching versions would be as simple as renaming the file, changing the extension to include a different version. However, various tools would have to learn about additional extensions that mean Python (syntax directed editors, etc.) And it would be hard to have a script in a module, unless the importer recognized all those extensions too. So this solution has ripple effects that make it unattractive, although it is simple to implement the basic feature. Agreed - I find this unattractive. (B) declare the Python version in the content of the script file. This cures most of the ripple effects of the above, but requires a launcher or wrapper program to be designed, implemented, and installed. There are a variety of subsolutions for different ways of declaring the version. snip a few options Without putting too much thought into it, I think a simple scheme could work where the path must either be /usr/bin/python[23]? or a fully-qualified path to a Python executable. IIUC, this should allow most scripts to have a shebang line that does the right thing on *nix and Windows systems while still offering maximum flexibility on Windows. By default, for Python, the wrapper would get associated only with .py files. There would probably also need to be the same for .pyw, but it would be almost identical to the .py handling. 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On Mon, Mar 7, 2011 at 3:02 PM, Kerrick Staley m...@kerrickstaley.com wrote: I think that at this point there's been sufficient agreement that the technical issues on Windows are too complex to warrant addressing them in this PEP, and that a separate PEP will be written addressing Windows, so that is what will happen. A new email thread for the Windows topic should be started so that the discussions can be separated, and those uninterested in the Windows question can stop following that discussion without missing Unix-related comments buried in it. Indeed. Terry spelled out the reasons for a separate Windows specific PEP pretty well, so I'll add a reference to that in the next PEP update. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammond skippy.hamm...@gmail.com wrote: Without putting too much thought into it, I think a simple scheme could work where the path must either be /usr/bin/python[23]? or a fully-qualified path to a Python executable. IIUC, this should allow most scripts to have a shebang line that does the right thing on *nix and Windows systems while still offering maximum flexibility on Windows. Such a scheme should be able to handle /usr/bin/env python2 and variants as well. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 7/03/2011 4:34 PM, Nick Coghlan wrote: On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammondskippy.hamm...@gmail.com wrote: Without putting too much thought into it, I think a simple scheme could work where the path must either be /usr/bin/python[23]? or a fully-qualified path to a Python executable. IIUC, this should allow most scripts to have a shebang line that does the right thing on *nix and Windows systems while still offering maximum flexibility on Windows. Such a scheme should be able to handle /usr/bin/env python2 and variants as well. Agreed - that is just my ignorance showing through :) 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] hg pull failed
On 07.03.2011 00:16, Terry Reedy wrote: On 3/6/2011 11:07 AM, Georg Brandl wrote: On 06.03.2011 16:44, s...@pobox.com wrote: Georg Yesterday's repository was still the test repository, now it's Georg the real one. You'll need to clone again. Thanks. I have a question about updates from cloned clones. Suppose I clone the central repo then clone locally to get the 2.7 and 3.2 release branches: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone cpython 2.7 If I want to later update my maintenance branches to get any updates will it suffice to just hg pull in my 2.7 and/or 3.2 directories or do I need to pull in cpython first? I guess my question is, are these clones transitive? If you don't change repo configuration after these commands, hg pull in the 3.2 repo will pull from the local cpython repo. I'd advise to set the default entry in each of the clones' .hg/hgrc file to http://hg.python.org/cpython (as a committer you should be using ssh://h...@hg.python.org/cpython BTW). But would it work to just pull once into default from the central repository (slow) and then pull from there (fast) into maintenance clones? I expect to nearly always be only working on issues that affect default. Pulling just a few changes into local clones from remote should always be fast. If the entire history of 20 years is 80MB, even a whole month's changes are only 300kB. [1] Georg [1] of course, this is not a valid extrapolation since a majority of changes happened in the recent past... ___ 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
