From solipsis at pitrou.net  Tue Mar  1 00:02:19 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 1 Mar 2011 00:02:19 +0100
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <4D6C27B6.5000601@v.loewis.de>
References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de>
	<1298933106.3692.10.camel@localhost.localdomain>
	<4D6C27B6.5000601@v.loewis.de>
Message-ID: <20110301000219.0bef17fb@pitrou.net>

On Mon, 28 Feb 2011 23:54:46 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 28.02.2011 23:45, schrieb Antoine Pitrou:
> > Le lundi 28 f?vrier 2011 ? 23:26 +0100, "Martin v. L?wis" a ?crit :
> >>> In preparation for the hg switch, I would recommend that, if you have
> >>> any feature branches managed with svnmerge, you sync them with the py3k
> >>> branch before we switch. That way, it will make it easier to "bridge
> >>> the gap" when you create a new repository for your work after the
> >>> switch (the svnmerge information isn't retained in the converted repo).
> >>
> >> 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
> > 
> > It doesn't cover importing work from SVN
> 
> But that's what I was specifically asking about: if I svnmerge my
> feature branch now - what specifically do I gain? Why are you asking
> me to do that? Why does doing so make it easier to "bridge the gap"?

Because you don't have to find whichever faraway changeset on which to
base your initial changes. You can just apply your patch on the latest
"default" changeset in the Mercurial repository and, in all likelihood,
you won't get any conflicts.

Regards

Antoine.

From jackdied at gmail.com  Tue Mar  1 02:44:34 2011
From: jackdied at gmail.com (Jack Diederich)
Date: Mon, 28 Feb 2011 20:44:34 -0500
Subject: [Python-Dev] [Python-checkins] r88691 -
	python/branches/py3k/Lib/test/test_telnetlib.py
In-Reply-To: <20110301004110.BDE63EE987@mail.python.org>
References: <20110301004110.BDE63EE987@mail.python.org>
Message-ID: <AANLkTinPvLQbNTnFThAR=3EFpS6UPG6uppxtN_yEW-BF@mail.gmail.com>

Much thanks.

On Mon, Feb 28, 2011 at 7:41 PM, antoine.pitrou
<python-checkins at python.org> wrote:
> Author: antoine.pitrou
> Date: Tue Mar ?1 01:41:10 2011
> New Revision: 88691
>
> Log:
> Endly, fix UnboundLocalError in telnetlib
>
>
>
> Modified:
> ? python/branches/py3k/Lib/test/test_telnetlib.py
>
> Modified: python/branches/py3k/Lib/test/test_telnetlib.py
> ==============================================================================
> --- python/branches/py3k/Lib/test/test_telnetlib.py ? ? (original)
> +++ python/branches/py3k/Lib/test/test_telnetlib.py ? ? Tue Mar ?1 01:41:10 2011
> @@ -17,9 +17,10 @@
> ? ? ? ? conn, addr = serv.accept()
> ? ? except socket.timeout:
> ? ? ? ? pass
> + ? ?else:
> + ? ? ? ?conn.close()
> ? ? finally:
> ? ? ? ? serv.close()
> - ? ? ? ?conn.close()
> ? ? ? ? evt.set()
>
> ?class GeneralTests(TestCase):
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>

From solipsis at pitrou.net  Tue Mar  1 02:55:18 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 1 Mar 2011 02:55:18 +0100
Subject: [Python-Dev] devinabox: Properly clean up the 'build' directory
 from test runs.
References: <E1PuBC3-0000bN-9j@dinsdale.python.org>
Message-ID: <20110301025518.146669a4@pitrou.net>

On Mon, 28 Feb 2011 23:03:51 +0100
brett.cannon <python-checkins at python.org> wrote:
> +    try:
> +        subprocess.call([cmd, '-W', 'default', '-bb', '-E', '-m', 'test', '-r',
> +                         '-w', '-u', 'all', '-j',
> +                         str(multiprocessing.cpu_count())])
> +    finally:
> +        os.rmdir('build')

os.rmdir() won't work on a non-empty directory; you probably want
shutil.rmtree() instead.

Regards

Antoine.



From ncoghlan at gmail.com  Tue Mar  1 14:24:31 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 1 Mar 2011 23:24:31 +1000
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <4D6C2838.4000706@netwok.org>
References: <20110228182236.5F675EE982@mail.python.org>
	<4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net>
	<AANLkTinBcW5_QkSJ6QvHR5WE1DRKhappUoq3q0aVMV41@mail.gmail.com>
	<1298923136.3692.4.camel@localhost.localdomain>
	<4D6C2478.2070201@pearwood.info> <4D6C2838.4000706@netwok.org>
Message-ID: <AANLkTinVGWfFhZSyFN16dqOw2kH6xkBwqFn=5j_J_ZKm@mail.gmail.com>

On Tue, Mar 1, 2011 at 8:56 AM, ?ric Araujo <merwok at netwok.org> wrote:
>> I really meant superfetatory
>
> Those damn French people with their foreign words.

Remember there's no tone of voice, facial expressions or body language
on the internet - smileys are your friend when kidding around :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From merwok at netwok.org  Tue Mar  1 14:34:53 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 01 Mar 2011 14:34:53 +0100
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <AANLkTinVGWfFhZSyFN16dqOw2kH6xkBwqFn=5j_J_ZKm@mail.gmail.com>
References: <20110228182236.5F675EE982@mail.python.org>	<4D6BEB1B.1040004@udel.edu>	<20110228205442.257dcae1@pitrou.net>	<AANLkTinBcW5_QkSJ6QvHR5WE1DRKhappUoq3q0aVMV41@mail.gmail.com>	<1298923136.3692.4.camel@localhost.localdomain>	<4D6C2478.2070201@pearwood.info>	<4D6C2838.4000706@netwok.org>
	<AANLkTinVGWfFhZSyFN16dqOw2kH6xkBwqFn=5j_J_ZKm@mail.gmail.com>
Message-ID: <4D6CF5FD.8000400@netwok.org>

> Remember there's no tone of voice, facial expressions or body language
> on the internet
This linguist approves.

> smileys are your friend when kidding around :)
All French core developers know I?m French too, but other people on this
list could have mistaken me, you?re right.

Cheers

From ncoghlan at gmail.com  Tue Mar  1 14:36:38 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 1 Mar 2011 23:36:38 +1000
Subject: [Python-Dev] [Python-checkins] devinabox: Add a Python script
 which will run the test suite in the most rigorous way
In-Reply-To: <E1PuBC2-0000Zt-VT@dinsdale.python.org>
References: <E1PuBC2-0000Zt-VT@dinsdale.python.org>
Message-ID: <AANLkTimr8nv6gFMm669ff9U3D2L703-xCVnsA0nyXT=6@mail.gmail.com>

On Tue, Mar 1, 2011 at 8:03 AM, brett.cannon <python-checkins at python.org> wrote:
> brett.cannon pushed 3e5a61adb41d to devinabox:
>
> http://hg.python.org/devinabox/rev/3e5a61adb41d
> changeset: ? 8:3e5a61adb41d
> user: ? ? ? ?Brett Cannon <brett at python.org>
> date: ? ? ? ?Fri Feb 25 17:35:37 2011 -0800
> summary:
> ?Add a Python script which will run the test suite in the most rigorous way possible.

Is there any particular reason not to stick this in the main
repository somewhere, so it is available in all working copies, not
just devinabox?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Tue Mar  1 14:45:08 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 1 Mar 2011 14:45:08 +0100
Subject: [Python-Dev] devinabox: Add a Python script which will run the
 test suite in the most rigorous way
References: <E1PuBC2-0000Zt-VT@dinsdale.python.org>
	<AANLkTimr8nv6gFMm669ff9U3D2L703-xCVnsA0nyXT=6@mail.gmail.com>
Message-ID: <20110301144508.42c48572@pitrou.net>

On Tue, 1 Mar 2011 23:36:38 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Mar 1, 2011 at 8:03 AM, brett.cannon <python-checkins at python.org> wrote:
> > brett.cannon pushed 3e5a61adb41d to devinabox:
> >
> > http://hg.python.org/devinabox/rev/3e5a61adb41d
> > changeset: ? 8:3e5a61adb41d
> > user: ? ? ? ?Brett Cannon <brett at python.org>
> > date: ? ? ? ?Fri Feb 25 17:35:37 2011 -0800
> > summary:
> > ?Add a Python script which will run the test suite in the most rigorous way possible.
> 
> Is there any particular reason not to stick this in the main
> repository somewhere, so it is available in all working copies, not
> just devinabox?

We already have "make test" and "make buildbottest" in addition to
"./python -m test". I think another subtly different way of running the
tests would be a nuisance.

cheers

Antoine.



From ncoghlan at gmail.com  Tue Mar  1 14:45:24 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 1 Mar 2011 23:45:24 +1000
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <4D6CF5FD.8000400@netwok.org>
References: <20110228182236.5F675EE982@mail.python.org>
	<4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net>
	<AANLkTinBcW5_QkSJ6QvHR5WE1DRKhappUoq3q0aVMV41@mail.gmail.com>
	<1298923136.3692.4.camel@localhost.localdomain>
	<4D6C2478.2070201@pearwood.info> <4D6C2838.4000706@netwok.org>
	<AANLkTinVGWfFhZSyFN16dqOw2kH6xkBwqFn=5j_J_ZKm@mail.gmail.com>
	<4D6CF5FD.8000400@netwok.org>
Message-ID: <AANLkTi=Q85PVG6b3+sEWRe3RH4z+-uPMCpoPft6d9dsF@mail.gmail.com>

On Tue, Mar 1, 2011 at 11:34 PM, ?ric Araujo <merwok at netwok.org> wrote:
> All French core developers know I?m French too, but other people on this
> list could have mistaken me, you?re right.

I actually assumed it was something like that, but assumptions are
deucedly dangerous things with an annoying habit of biting you when
you least expect it :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From eliben at gmail.com  Tue Mar  1 15:52:58 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 1 Mar 2011 16:52:58 +0200
Subject: [Python-Dev] [Python-checkins] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <20110228182236.5F675EE982@mail.python.org>
References: <20110228182236.5F675EE982@mail.python.org>
Message-ID: <AANLkTimZaDTAjOWPQwbwhMyL=CpPgj7JBo-rm3Brq-iv@mail.gmail.com>

The PEP (http://www.python.org/dev/peps/pep-0385/) says in "Timeline":

2010-03-05: final conversion (tentative)

I assume 2011-03-05 is meant here.

Eli





On Mon, Feb 28, 2011 at 20:22, antoine.pitrou <python-checkins at python.org>wrote:

> Author: antoine.pitrou
> Date: Mon Feb 28 19:22:36 2011
> New Revision: 88676
>
> Log:
> Update PEP 385 with latest hooks work
>
>
>
> Modified:
>   peps/trunk/pep-0385.txt
>
> Modified: peps/trunk/pep-0385.txt
>
> ==============================================================================
> --- peps/trunk/pep-0385.txt     (original)
> +++ peps/trunk/pep-0385.txt     Mon Feb 28 19:22:36 2011
> @@ -262,7 +262,22 @@
>   on every build slave for the branch in which the changeset occurs.
>
>  The `hooks repository`_ contains ports of these server-side hooks to
> -Mercurial.  One additional hook could be beneficial:
> +Mercurial, as well as a couple additional ones:
> +
> +* check branch heads: a hook to reject pushes which create a new head on
> +  an existing branch.  The pusher then has to merge the superfetatory
> heads
> +  and try pushing again.
> +
> +* check branches: a hook to reject all changesets not on an allowed named
> +  branch.  This hook's whitelist will have to be updated when we want to
> +  create new maintenance branches.
> +
> +* check line endings: a hook, based on the `eol extension`_, to reject all
> +  changesets committing files with the wrong line endings.  The commits
> then
> +  have to be stripped and redone, possibly with the `eol extension`_
> enabled
> +  on the comitter's computer.
> +
> +One additional hook could be beneficial:
>
>  * check contributors: in the current setup, all changesets bear the
>   username of committers, who must have signed the contributor
> @@ -285,9 +300,8 @@
>  information is kept in a versioned file called ``.hgeol``, and such a
>  file has already been checked into the Subversion repository.
>
> -A hook on the server side that turns down any changegroup or changeset
> -introducing inconsistent newline data can still be implemented, if
> -deemed necessary.
> +A hook also exists on the server side to reject any changeset
> +introducing inconsistent newline data (see above).
>
>  .. _eol extension: http://mercurial.selenic.com/wiki/EolExtension
>  .. _win32text extension:
> http://mercurial.selenic.com/wiki/Win32TextExtension
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110301/7e151485/attachment.html>

From solipsis at pitrou.net  Tue Mar  1 16:05:22 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 1 Mar 2011 16:05:22 +0100
Subject: [Python-Dev] [Python-checkins] r88676 - peps/trunk/pep-0385.txt
References: <20110228182236.5F675EE982@mail.python.org>
	<AANLkTimZaDTAjOWPQwbwhMyL=CpPgj7JBo-rm3Brq-iv@mail.gmail.com>
Message-ID: <20110301160522.0871bc4d@pitrou.net>

On Tue, 1 Mar 2011 16:52:58 +0200
Eli Bendersky <eliben at gmail.com> wrote:
> The PEP (http://www.python.org/dev/peps/pep-0385/) says in "Timeline":
> 
> 2010-03-05: final conversion (tentative)
> 
> I assume 2011-03-05 is meant here.

Oh... I guess I was a bit optimistic.

Thanks for noticing

Antoine.



From g.brandl at gmx.net  Tue Mar  1 20:22:27 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 01 Mar 2011 20:22:27 +0100
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <AANLkTi=Q85PVG6b3+sEWRe3RH4z+-uPMCpoPft6d9dsF@mail.gmail.com>
References: <20110228182236.5F675EE982@mail.python.org>
	<4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net>
	<AANLkTinBcW5_QkSJ6QvHR5WE1DRKhappUoq3q0aVMV41@mail.gmail.com>
	<1298923136.3692.4.camel@localhost.localdomain>
	<4D6C2478.2070201@pearwood.info> <4D6C2838.4000706@netwok.org>
	<AANLkTinVGWfFhZSyFN16dqOw2kH6xkBwqFn=5j_J_ZKm@mail.gmail.com>
	<4D6CF5FD.8000400@netwok.org>
	<AANLkTi=Q85PVG6b3+sEWRe3RH4z+-uPMCpoPft6d9dsF@mail.gmail.com>
Message-ID: <ikjh3f$sk4$1@dough.gmane.org>

On 01.03.2011 14:45, Nick Coghlan wrote:
> On Tue, Mar 1, 2011 at 11:34 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> All French core developers know I?m French too, but other people on this
>> list could have mistaken me, you?re right.
> 
> I actually assumed it was something like that, but assumptions are
> deucedly dangerous things with an annoying habit of biting you when
> you least expect it :)

Just like the French.

Georg



From g.brandl at gmx.net  Tue Mar  1 20:22:52 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 01 Mar 2011 20:22:52 +0100
Subject: [Python-Dev] [Python-checkins] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <20110301160522.0871bc4d@pitrou.net>
References: <20110228182236.5F675EE982@mail.python.org>
	<AANLkTimZaDTAjOWPQwbwhMyL=CpPgj7JBo-rm3Brq-iv@mail.gmail.com>
	<20110301160522.0871bc4d@pitrou.net>
Message-ID: <ikjh48$sk4$2@dough.gmane.org>

On 01.03.2011 16:05, Antoine Pitrou wrote:
> On Tue, 1 Mar 2011 16:52:58 +0200
> Eli Bendersky <eliben at gmail.com> wrote:
>> The PEP (http://www.python.org/dev/peps/pep-0385/) says in "Timeline":
>> 
>> 2010-03-05: final conversion (tentative)
>> 
>> I assume 2011-03-05 is meant here.
> 
> Oh... I guess I was a bit optimistic.
> 
> Thanks for noticing

Hey, I still got the time machine locked away in my parents' basement...

Georg



From bcannon at gmail.com  Tue Mar  1 21:15:03 2011
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 1 Mar 2011 12:15:03 -0800
Subject: [Python-Dev] devinabox: Add a Python script which will run the
 test suite in the most rigorous way
In-Reply-To: <20110301144508.42c48572@pitrou.net>
References: <E1PuBC2-0000Zt-VT@dinsdale.python.org>
	<AANLkTimr8nv6gFMm669ff9U3D2L703-xCVnsA0nyXT=6@mail.gmail.com>
	<20110301144508.42c48572@pitrou.net>
Message-ID: <AANLkTimqmuBRaF1oNqLt7kj=zbJucQ9yY_o4WccVfkaD@mail.gmail.com>

The biggest problem with make test is it is not exactly the same as the
script (e.g., no automatic -j usage). It also is not cross-platform since
Windows dev's are left out without installing cygwin. And we can't simply
use -m test as that leaves out flags passed to the interpreter.
On Mar 1, 2011 5:45 AM, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
> On Tue, 1 Mar 2011 23:36:38 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Tue, Mar 1, 2011 at 8:03 AM, brett.cannon <python-checkins at python.org>
wrote:
>> > brett.cannon pushed 3e5a61adb41d to devinabox:
>> >
>> > http://hg.python.org/devinabox/rev/3e5a61adb41d
>> > changeset:   8:3e5a61adb41d
>> > user:        Brett Cannon <brett at python.org>
>> > date:        Fri Feb 25 17:35:37 2011 -0800
>> > summary:
>> >  Add a Python script which will run the test suite in the most rigorous
way possible.
>>
>> Is there any particular reason not to stick this in the main
>> repository somewhere, so it is available in all working copies, not
>> just devinabox?
>
> We already have "make test" and "make buildbottest" in addition to
> "./python -m test". I think another subtly different way of running the
> tests would be a nuisance.
>
> cheers
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/brett%40python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110301/9a0d6c08/attachment.html>

From merwok at netwok.org  Tue Mar  1 21:36:29 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 01 Mar 2011 21:36:29 +0100
Subject: [Python-Dev] [Python-checkins] devguide (hg_transition): Update
 instructions to	use the new "server-side clone" button
In-Reply-To: <E1PuVbl-00084l-3G@dinsdale.python.org>
References: <E1PuVbl-00084l-3G@dinsdale.python.org>
Message-ID: <4D6D58CD.9010900@netwok.org>

> user:        Antoine Pitrou <solipsis at pitrou.net>
> date:        Tue Mar 01 20:51:42 2011 +0100
> summary:
>   Update instructions to use the new "server-side clone" button

That?s seriously awesome.

Where can we have a look at the implementation?

A remark: Having all clones created under a dedicated namespace (say
sandbox) could make the hg.python.org listing clearer, since all user
clones would be grouped.

Some way to edit the clone description and contact would be great.  Even
without that, kudos for the excellent feature.

Regards

From g.brandl at gmx.net  Tue Mar  1 21:50:57 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 01 Mar 2011 21:50:57 +0100
Subject: [Python-Dev] [Python-checkins] devguide (hg_transition): Update
 instructions to use the new "server-side clone" button
In-Reply-To: <4D6D58CD.9010900@netwok.org>
References: <E1PuVbl-00084l-3G@dinsdale.python.org>
	<4D6D58CD.9010900@netwok.org>
Message-ID: <ikjm9d$r54$1@dough.gmane.org>

On 01.03.2011 21:36, ?ric Araujo wrote:
>> user:        Antoine Pitrou <solipsis at pitrou.net>
>> date:        Tue Mar 01 20:51:42 2011 +0100
>> summary:
>>   Update instructions to use the new "server-side clone" button
> 
> That?s seriously awesome.
> 
> Where can we have a look at the implementation?

Have a guess :)

> A remark: Having all clones created under a dedicated namespace (say
> sandbox) could make the hg.python.org listing clearer, since all user
> clones would be grouped.

Yes, but it also makes it harder to group by user.

> Some way to edit the clone description and contact would be great.

Seconded.

Georg



From solipsis at pitrou.net  Tue Mar  1 21:54:24 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 1 Mar 2011 21:54:24 +0100
Subject: [Python-Dev] [Python-checkins] devguide (hg_transition): Update
 instructions to	use the new "server-side clone" button
References: <E1PuVbl-00084l-3G@dinsdale.python.org>
	<4D6D58CD.9010900@netwok.org>
Message-ID: <20110301215424.1a37b75b@pitrou.net>

On Tue, 01 Mar 2011 21:36:29 +0100
?ric Araujo <merwok at netwok.org> wrote:
> > user:        Antoine Pitrou <solipsis at pitrou.net>
> > date:        Tue Mar 01 20:51:42 2011 +0100
> > summary:
> >   Update instructions to use the new "server-side clone" button
> 
> That?s seriously awesome.
> 
> Where can we have a look at the implementation?

It's versioned on the server. I can send you a diff in private.
I don't know how sensitive it might be, probably not unless there's some
glaring security hole in it.

> A remark: Having all clones created under a dedicated namespace (say
> sandbox) could make the hg.python.org listing clearer, since all user
> clones would be grouped.

Sure, we can change the enforced convention depending on the majority's
preference. I chose that one because other devs thought it would be bad
to let people create many repos at the top-level.

Regards

Antoine.



From mail at kerrickstaley.com  Tue Mar  1 22:19:15 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Tue, 1 Mar 2011 15:19:15 -0600
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
Message-ID: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>

Hello,
There is a need for the default Python2 install to place a symlink at
/usr/bin/python2 that points to /usr/bin/python, or for the documentation to
recommend that packagers ensure that python2 is defined. Also, all
documentation should be changed to recommend that "#!/usr/bin/env python2"
be used as the shebang for Python 2 scripts.
This is needed because some distributions (Arch Linux, in particular), point
/usr/bin/python to /usr/bin/python3, while others (including Slackware,
Debian, and the BSDs, probably more) do not even define the python2 command.
This means that a script has no way of achieving cross-platform
compatibility. The point at which many distributions begin to alias
/usr/bin/python to /usr/bin/python3 is due soon, and for the next couple of
years, it would be best to use a python2 or python3 shebang in all scripts,
making no assumptions about plain python, which should only be invoked
interactively. This email from about 3 years ago seems relevant: :
http://mail.python.org/pipermail/python-3000/2008-March/012421.html
Again, this issue needs to be addressed by the Python developers themselves
so that different *nix distributions will handle it consistently, allowing
Python scripts to continue to be cross-platform.
Thanks,
Kerrick Staley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110301/c04375f6/attachment.html>

From solipsis at pitrou.net  Tue Mar  1 22:24:08 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 01 Mar 2011 22:24:08 +0100
Subject: [Python-Dev] contributors survey?
Message-ID: <1299014648.3709.16.camel@localhost.localdomain>


Hello,

In
http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I was asking whether it would be useful to make a survey of past contributors, as in:

        First, we did a survey of all our past developers who had left
        the project, asking them why they had left. This was just a
        free-form survey, allowing people to answer any way they wanted.

(from the quoted article in the thread linked above)

Since I didn't get any answer, I wonder if the idea simply got
overlooked, or if there's no need at all.

Regards

Antoine.



From eric at trueblade.com  Tue Mar  1 22:26:05 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 01 Mar 2011 16:26:05 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
Message-ID: <4D6D646D.6070506@trueblade.com>

On 3/1/2011 4:19 PM, Kerrick Staley wrote:
> Hello,
> There is a need for the default Python2 install to place a symlink at
> /usr/bin/python2 that points to /usr/bin/python, or for the
> documentation to recommend that packagers ensure that python2 is
> defined. Also, all documentation should be changed to recommend that
> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts.
> This is needed because some distributions (Arch Linux, in particular),
> point /usr/bin/python to /usr/bin/python3, while others (including
> Slackware, Debian, and the BSDs, probably more) do not even define the
> python2 command. This means that a script has no way of achieving
> cross-platform compatibility. The point at which many distributions
> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for
> the next couple of years, it would be best to use a python2 or python3
> shebang in all scripts, making no assumptions about plain python, which
> should only be invoked interactively. This email from about 3 years ago
> seems relevant: :
> http://mail.python.org/pipermail/python-3000/2008-March/012421.html
> Again, this issue needs to be addressed by the Python developers
> themselves so that different *nix distributions will handle it
> consistently, allowing Python scripts to continue to be cross-platform.
>

I believe we agreed at the language summit last year (or maybe even the 
year before) that "python" would always be python2.x, and "python3" 
would be python3.x.

And by "always" we indeed meant forever. To do otherwise would break 
scripts even many, many years from now.

Eric.

From mail at kerrickstaley.com  Tue Mar  1 22:50:34 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Tue, 1 Mar 2011 15:50:34 -0600
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6D646D.6070506@trueblade.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
Message-ID: <AANLkTi=YYfQQrbFvvwB5ALsMJC1gvkBY_m9XFguub55g@mail.gmail.com>

I understand, but is it at least possible to officially recommend that
python, python2, and python3 all exist, that distributions point python to
python2, and that scripts specify which of python2 and python3 they are
using? This would create a redundant system that doesn't avoids problems
even if distributions do decide to ignore the second point. If not, can
someone point me to official documentation that recommends that python
always invoke Python2, so that I can take the case up with the Arch
developers?
Thanks,
Kerrick Staley

On Tue, Mar 1, 2011 at 3:26 PM, Eric Smith <eric at trueblade.com> wrote:

> On 3/1/2011 4:19 PM, Kerrick Staley wrote:
>
>> Hello,
>> There is a need for the default Python2 install to place a symlink at
>> /usr/bin/python2 that points to /usr/bin/python, or for the
>> documentation to recommend that packagers ensure that python2 is
>> defined. Also, all documentation should be changed to recommend that
>> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts.
>> This is needed because some distributions (Arch Linux, in particular),
>> point /usr/bin/python to /usr/bin/python3, while others (including
>> Slackware, Debian, and the BSDs, probably more) do not even define the
>> python2 command. This means that a script has no way of achieving
>> cross-platform compatibility. The point at which many distributions
>> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for
>> the next couple of years, it would be best to use a python2 or python3
>> shebang in all scripts, making no assumptions about plain python, which
>> should only be invoked interactively. This email from about 3 years ago
>> seems relevant: :
>> http://mail.python.org/pipermail/python-3000/2008-March/012421.html
>> Again, this issue needs to be addressed by the Python developers
>> themselves so that different *nix distributions will handle it
>> consistently, allowing Python scripts to continue to be cross-platform.
>>
>>
> I believe we agreed at the language summit last year (or maybe even the
> year before) that "python" would always be python2.x, and "python3" would be
> python3.x.
>
> And by "always" we indeed meant forever. To do otherwise would break
> scripts even many, many years from now.
>
> Eric.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110301/ba55518e/attachment.html>

From arfrever.fta at gmail.com  Tue Mar  1 23:04:15 2011
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 1 Mar 2011 23:04:15 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTi=YYfQQrbFvvwB5ALsMJC1gvkBY_m9XFguub55g@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<AANLkTi=YYfQQrbFvvwB5ALsMJC1gvkBY_m9XFguub55g@mail.gmail.com>
Message-ID: <201103012304.58866.Arfrever.FTA@gmail.com>

2011-03-01 22:50:34 Kerrick Staley napisa?(a):
> On Tue, Mar 1, 2011 at 3:26 PM, Eric Smith <eric at trueblade.com> wrote:
> > On 3/1/2011 4:19 PM, Kerrick Staley wrote:
> >> Hello,
> >> There is a need for the default Python2 install to place a symlink at
> >> /usr/bin/python2 that points to /usr/bin/python, or for the
> >> documentation to recommend that packagers ensure that python2 is
> >> defined. Also, all documentation should be changed to recommend that
> >> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts.
> >> This is needed because some distributions (Arch Linux, in particular),
> >> point /usr/bin/python to /usr/bin/python3, while others (including
> >> Slackware, Debian, and the BSDs, probably more) do not even define the
> >> python2 command. This means that a script has no way of achieving
> >> cross-platform compatibility. The point at which many distributions
> >> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for
> >> the next couple of years, it would be best to use a python2 or python3
> >> shebang in all scripts, making no assumptions about plain python, which
> >> should only be invoked interactively. This email from about 3 years ago
> >> seems relevant: :
> >> http://mail.python.org/pipermail/python-3000/2008-March/012421.html
> >> Again, this issue needs to be addressed by the Python developers
> >> themselves so that different *nix distributions will handle it
> >> consistently, allowing Python scripts to continue to be cross-platform.
> >>
> >>
> > I believe we agreed at the language summit last year (or maybe even the
> > year before) that "python" would always be python2.x, and "python3" would be
> > python3.x.
> >
> > And by "always" we indeed meant forever. To do otherwise would break
> > scripts even many, many years from now.
> 
> I understand, but is it at least possible to officially recommend that
> python, python2, and python3 all exist, that distributions point python to
> python2, and that scripts specify which of python2 and python3 they are
> using? This would create a redundant system that doesn't avoids problems
> even if distributions do decide to ignore the second point. If not, can
> someone point me to official documentation that recommends that python
> always invoke Python2, so that I can take the case up with the Arch
> developers?

Gentoo most likely will switch /usr/bin/python to Python 3 in this year.
Majority of Python-2-only packages have been already prepared to use /usr/bin/python2 or
/usr/bin/python2.X.

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110301/bbb7940f/attachment.pgp>

From guido at python.org  Tue Mar  1 23:06:07 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Mar 2011 14:06:07 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6D646D.6070506@trueblade.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
Message-ID: <AANLkTikN=KFqvZ7mhRyCLdgUjiGU-u50b=4m9D-muAD4@mail.gmail.com>

On Tue, Mar 1, 2011 at 1:26 PM, Eric Smith <eric at trueblade.com> wrote:
> On 3/1/2011 4:19 PM, Kerrick Staley wrote:
>>
>> Hello,
>> There is a need for the default Python2 install to place a symlink at
>> /usr/bin/python2 that points to /usr/bin/python, or for the
>> documentation to recommend that packagers ensure that python2 is
>> defined. Also, all documentation should be changed to recommend that
>> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts.
>> This is needed because some distributions (Arch Linux, in particular),
>> point /usr/bin/python to /usr/bin/python3, while others (including
>> Slackware, Debian, and the BSDs, probably more) do not even define the
>> python2 command. This means that a script has no way of achieving
>> cross-platform compatibility. The point at which many distributions
>> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for
>> the next couple of years, it would be best to use a python2 or python3
>> shebang in all scripts, making no assumptions about plain python, which
>> should only be invoked interactively. This email from about 3 years ago
>> seems relevant: :
>> http://mail.python.org/pipermail/python-3000/2008-March/012421.html
>> Again, this issue needs to be addressed by the Python developers
>> themselves so that different *nix distributions will handle it
>> consistently, allowing Python scripts to continue to be cross-platform.
>>
>
> I believe we agreed at the language summit last year (or maybe even the year
> before) that "python" would always be python2.x, and "python3" would be
> python3.x.
>
> And by "always" we indeed meant forever. To do otherwise would break scripts
> even many, many years from now.

Unfortunately distros are not following these guidelines. As long as
we still have the pythonX.Y links I think it's better to have
"python2", "python3" and "python" than total anarchy.

-- 
--Guido van Rossum (python.org/~guido)

From jnoller at gmail.com  Tue Mar  1 23:12:14 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Tue, 1 Mar 2011 17:12:14 -0500
Subject: [Python-Dev] contributors survey?
In-Reply-To: <1299014648.3709.16.camel@localhost.localdomain>
References: <1299014648.3709.16.camel@localhost.localdomain>
Message-ID: <AANLkTi=4Vn4E4sgmS3bs6TpPDDJTX6g3=bFhSLtu1Zu9@mail.gmail.com>

On Tue, Mar 1, 2011 at 4:24 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hello,
>
> In
> http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I was asking whether it would be useful to make a survey of past contributors, as in:
>
> ? ? ? ?First, we did a survey of all our past developers who had left
> ? ? ? ?the project, asking them why they had left. This was just a
> ? ? ? ?free-form survey, allowing people to answer any way they wanted.
>
> (from the quoted article in the thread linked above)
>
> Since I didn't get any answer, I wonder if the idea simply got
> overlooked, or if there's no need at all.
>
> Regards
>
> Antoine.

I think doing a survey like this is a *really* good idea. We have an
account at our disposal (as the PSF) at http://www.surveymonkey.com/
which we use for PyCon feedback. Maybe we can leverage that, if we can
come up with good questions?

jesse

From foom at fuhm.net  Tue Mar  1 23:15:50 2011
From: foom at fuhm.net (James Y Knight)
Date: Tue, 1 Mar 2011 17:15:50 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikN=KFqvZ7mhRyCLdgUjiGU-u50b=4m9D-muAD4@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<AANLkTikN=KFqvZ7mhRyCLdgUjiGU-u50b=4m9D-muAD4@mail.gmail.com>
Message-ID: <70B4E399-E6F7-4612-9E58-E092E5216AD9@fuhm.net>


On Mar 1, 2011, at 5:06 PM, Guido van Rossum wrote:

> On Tue, Mar 1, 2011 at 1:26 PM, Eric Smith <eric at trueblade.com> wrote:
>> On 3/1/2011 4:19 PM, Kerrick Staley wrote:
>>> 
>>> Hello,
>>> There is a need for the default Python2 install to place a symlink at
>>> /usr/bin/python2 that points to /usr/bin/python, or for the
>>> documentation to recommend that packagers ensure that python2 is
>>> defined. Also, all documentation should be changed to recommend that
>>> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts.
>>> This is needed because some distributions (Arch Linux, in particular),
>>> point /usr/bin/python to /usr/bin/python3, while others (including
>>> Slackware, Debian, and the BSDs, probably more) do not even define the
>>> python2 command. This means that a script has no way of achieving
>>> cross-platform compatibility. The point at which many distributions
>>> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for
>>> the next couple of years, it would be best to use a python2 or python3
>>> shebang in all scripts, making no assumptions about plain python, which
>>> should only be invoked interactively. This email from about 3 years ago
>>> seems relevant: :
>>> http://mail.python.org/pipermail/python-3000/2008-March/012421.html
>>> Again, this issue needs to be addressed by the Python developers
>>> themselves so that different *nix distributions will handle it
>>> consistently, allowing Python scripts to continue to be cross-platform.
>>> 
>> 
>> I believe we agreed at the language summit last year (or maybe even the year
>> before) that "python" would always be python2.x, and "python3" would be
>> python3.x.
>> 
>> And by "always" we indeed meant forever. To do otherwise would break scripts
>> even many, many years from now.
> 
> Unfortunately distros are not following these guidelines. As long as
> we still have the pythonX.Y links I think it's better to have
> "python2", "python3" and "python" than total anarchy.

If python upstream would make it clear that that *IS* the policy, distros might follow it. Right now, there is no clear guidance, as far as I can tell. If you do not want distros making python be a link to python3, please say so loudly, preferably on a webpage on python.org that users can point the distros to.

James


From rdmurray at bitdance.com  Tue Mar  1 23:21:48 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 01 Mar 2011 17:21:48 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6D646D.6070506@trueblade.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
Message-ID: <20110301222148.49F91249CF7@kimball.webabinitio.net>

On Tue, 01 Mar 2011 16:26:05 -0500, Eric Smith <eric at trueblade.com> wrote:
> On 3/1/2011 4:19 PM, Kerrick Staley wrote:
> > Hello,
> > There is a need for the default Python2 install to place a symlink at
> > /usr/bin/python2 that points to /usr/bin/python, or for the
> > documentation to recommend that packagers ensure that python2 is
> > defined. Also, all documentation should be changed to recommend that
> > "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts.
> > This is needed because some distributions (Arch Linux, in particular),
> > point /usr/bin/python to /usr/bin/python3, while others (including
> > Slackware, Debian, and the BSDs, probably more) do not even define the
> > python2 command. This means that a script has no way of achieving
> > cross-platform compatibility. The point at which many distributions
> > begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for
> > the next couple of years, it would be best to use a python2 or python3
> > shebang in all scripts, making no assumptions about plain python, which
> > should only be invoked interactively. This email from about 3 years ago
> > seems relevant: :
> > http://mail.python.org/pipermail/python-3000/2008-March/012421.html
> > Again, this issue needs to be addressed by the Python developers
> > themselves so that different *nix distributions will handle it
> > consistently, allowing Python scripts to continue to be cross-platform.
> >
> 
> I believe we agreed at the language summit last year (or maybe even the 
> year before) that "python" would always be python2.x, and "python3" 
> would be python3.x.
> 
> And by "always" we indeed meant forever. To do otherwise would break 
> scripts even many, many years from now.

It sounds like the distributions aren't going to cooperate with us.
Arch has already switched.  Gentoo will allow the user to switch
/usr/bin/python to point to python3, and I suspect this will become
the default at some point.

I'm not sad about that, myself.

--David

From benjamin at python.org  Tue Mar  1 23:23:42 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 1 Mar 2011 16:23:42 -0600
Subject: [Python-Dev] contributors survey?
In-Reply-To: <1299014648.3709.16.camel@localhost.localdomain>
References: <1299014648.3709.16.camel@localhost.localdomain>
Message-ID: <AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>

2011/3/1 Antoine Pitrou <solipsis at pitrou.net>:
>
> Hello,
>
> In
> http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I was asking whether it would be useful to make a survey of past contributors, as in:
>
> ? ? ? ?First, we did a survey of all our past developers who had left
> ? ? ? ?the project, asking them why they had left. This was just a
> ? ? ? ?free-form survey, allowing people to answer any way they wanted.
>
> (from the quoted article in the thread linked above)
>
> Since I didn't get any answer, I wonder if the idea simply got
> overlooked, or if there's no need at all.

How do you determine past developers?



-- 
Regards,
Benjamin

From solipsis at pitrou.net  Tue Mar  1 23:32:10 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 1 Mar 2011 23:32:10 +0100
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTi=4Vn4E4sgmS3bs6TpPDDJTX6g3=bFhSLtu1Zu9@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTi=4Vn4E4sgmS3bs6TpPDDJTX6g3=bFhSLtu1Zu9@mail.gmail.com>
Message-ID: <20110301233210.5d6206e6@pitrou.net>

On Tue, 1 Mar 2011 17:12:14 -0500
Jesse Noller <jnoller at gmail.com> wrote:
> On Tue, Mar 1, 2011 at 4:24 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >
> > Hello,
> >
> > In
> > http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I was asking whether it would be useful to make a survey of past contributors, as in:
> >
> > ? ? ? ?First, we did a survey of all our past developers who had left
> > ? ? ? ?the project, asking them why they had left. This was just a
> > ? ? ? ?free-form survey, allowing people to answer any way they wanted.
> >
> > (from the quoted article in the thread linked above)
> >
> > Since I didn't get any answer, I wonder if the idea simply got
> > overlooked, or if there's no need at all.
> >
> > Regards
> >
> > Antoine.
> 
> I think doing a survey like this is a *really* good idea. We have an
> account at our disposal (as the PSF) at http://www.surveymonkey.com/
> which we use for PyCon feedback. Maybe we can leverage that, if we can
> come up with good questions?

Following the example given in the original article, I was considering
a single freeform question: "why did you stop contributing after your
last patch to CPython?" (of course, that text should be decorated with
a greeting and an introduction and the wording can be improved).

Regards

Antoine.

From solipsis at pitrou.net  Tue Mar  1 23:32:38 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 1 Mar 2011 23:32:38 +0100
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
Message-ID: <20110301233238.3ef4b05f@pitrou.net>

On Tue, 1 Mar 2011 16:23:42 -0600
Benjamin Peterson <benjamin at python.org> wrote:
> 2011/3/1 Antoine Pitrou <solipsis at pitrou.net>:
> >
> > Hello,
> >
> > In
> > http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I was asking whether it would be useful to make a survey of past contributors, as in:
> >
> > ? ? ? ?First, we did a survey of all our past developers who had left
> > ? ? ? ?the project, asking them why they had left. This was just a
> > ? ? ? ?free-form survey, allowing people to answer any way they wanted.
> >
> > (from the quoted article in the thread linked above)
> >
> > Since I didn't get any answer, I wonder if the idea simply got
> > overlooked, or if there's no need at all.
> 
> How do you determine past developers?

Using Misc/ACKS.

Regards

Antoine.

From benjamin at python.org  Tue Mar  1 23:41:13 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 1 Mar 2011 16:41:13 -0600
Subject: [Python-Dev] contributors survey?
In-Reply-To: <20110301233238.3ef4b05f@pitrou.net>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
	<20110301233238.3ef4b05f@pitrou.net>
Message-ID: <AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>

2011/3/1 Antoine Pitrou <solipsis at pitrou.net>:
> On Tue, 1 Mar 2011 16:23:42 -0600
> Benjamin Peterson <benjamin at python.org> wrote:
>> 2011/3/1 Antoine Pitrou <solipsis at pitrou.net>:
>> >
>> > Hello,
>> >
>> > In
>> > http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I was asking whether it would be useful to make a survey of past contributors, as in:
>> >
>> > ? ? ? ?First, we did a survey of all our past developers who had left
>> > ? ? ? ?the project, asking them why they had left. This was just a
>> > ? ? ? ?free-form survey, allowing people to answer any way they wanted.
>> >
>> > (from the quoted article in the thread linked above)
>> >
>> > Since I didn't get any answer, I wonder if the idea simply got
>> > overlooked, or if there's no need at all.
>>
>> How do you determine past developers?

By that I meant how do you determine that they're not actively contributing?


-- 
Regards,
Benjamin

From solipsis at pitrou.net  Tue Mar  1 23:45:47 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 01 Mar 2011 23:45:47 +0100
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
	<20110301233238.3ef4b05f@pitrou.net>
	<AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>
Message-ID: <1299019547.3709.18.camel@localhost.localdomain>

Le mardi 01 mars 2011 ? 16:41 -0600, Benjamin Peterson a ?crit :
> 2011/3/1 Antoine Pitrou <solipsis at pitrou.net>:
> > On Tue, 1 Mar 2011 16:23:42 -0600
> > Benjamin Peterson <benjamin at python.org> wrote:
> >> 2011/3/1 Antoine Pitrou <solipsis at pitrou.net>:
> >> >
> >> > Hello,
> >> >
> >> > In
> >> > http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I was asking whether it would be useful to make a survey of past contributors, as in:
> >> >
> >> >        First, we did a survey of all our past developers who had left
> >> >        the project, asking them why they had left. This was just a
> >> >        free-form survey, allowing people to answer any way they wanted.
> >> >
> >> > (from the quoted article in the thread linked above)
> >> >
> >> > Since I didn't get any answer, I wonder if the idea simply got
> >> > overlooked, or if there's no need at all.
> >>
> >> How do you determine past developers?
> 
> By that I meant how do you determine that they're not actively contributing?

hg log -k "contributor name"

Also, memory helps although it's quite perfectible :)

At worse, we'll have a couple of false positives and we'll have to
apologize to them...

Regards

Antoine.



From skip at pobox.com  Tue Mar  1 23:49:42 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 1 Mar 2011 16:49:42 -0600
Subject: [Python-Dev] devinabox: Add a Python script which will run the
 test suite in the most rigorous way
In-Reply-To: <20110301144508.42c48572@pitrou.net>
References: <E1PuBC2-0000Zt-VT@dinsdale.python.org>
	<AANLkTimr8nv6gFMm669ff9U3D2L703-xCVnsA0nyXT=6@mail.gmail.com>
	<20110301144508.42c48572@pitrou.net>
Message-ID: <19821.30726.763043.418363@montanaro.dyndns.org>


    Antoine> We already have "make test" and "make buildbottest" in addition
    Antoine> to "./python -m test". I think another subtly different way of
    Antoine> running the tests would be a nuisance.

I see nothing wrong with "make rigoroustest" or "make brutaltest".  I
routinely use "make test" but never remember the necessary incantations for
enabling everything that regrtest can do (random test order, leak tests,
skip nothing, etc).  Having that encoded in a make target would at least
mean all I need to do is

  egrep 'test *:' Makefile

to see what my choices were.

Skip

From solipsis at pitrou.net  Tue Mar  1 23:58:53 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 1 Mar 2011 23:58:53 +0100
Subject: [Python-Dev] devinabox: Add a Python script which will run the
 test suite in the most rigorous way
In-Reply-To: <19821.30726.763043.418363@montanaro.dyndns.org>
References: <E1PuBC2-0000Zt-VT@dinsdale.python.org>
	<AANLkTimr8nv6gFMm669ff9U3D2L703-xCVnsA0nyXT=6@mail.gmail.com>
	<20110301144508.42c48572@pitrou.net>
	<19821.30726.763043.418363@montanaro.dyndns.org>
Message-ID: <20110301235853.771beab1@pitrou.net>

On Tue, 1 Mar 2011 16:49:42 -0600
skip at pobox.com wrote:
> 
>     Antoine> We already have "make test" and "make buildbottest" in addition
>     Antoine> to "./python -m test". I think another subtly different way of
>     Antoine> running the tests would be a nuisance.
> 
> I see nothing wrong with "make rigoroustest" or "make brutaltest".  I
> routinely use "make test" but never remember the necessary incantations for
> enabling everything that regrtest can do (random test order, leak tests,
> skip nothing, etc).

Well, "make buildbottest" should do the trick.

Regards

Antoine.

From skip at pobox.com  Wed Mar  2 00:05:25 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 1 Mar 2011 17:05:25 -0600
Subject: [Python-Dev] devinabox: Add a Python script which will run the
 test suite in the most rigorous way
In-Reply-To: <20110301235853.771beab1@pitrou.net>
References: <E1PuBC2-0000Zt-VT@dinsdale.python.org>
	<AANLkTimr8nv6gFMm669ff9U3D2L703-xCVnsA0nyXT=6@mail.gmail.com>
	<20110301144508.42c48572@pitrou.net>
	<19821.30726.763043.418363@montanaro.dyndns.org>
	<20110301235853.771beab1@pitrou.net>
Message-ID: <19821.31669.853320.528390@montanaro.dyndns.org>


    Antoine> Well, "make buildbottest" should do the trick.

Perhaps it should be given a somewhat less specialized sounding name...

Skip

From solipsis at pitrou.net  Wed Mar  2 00:10:44 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 2 Mar 2011 00:10:44 +0100
Subject: [Python-Dev] devinabox: Add a Python script which will run the
 test suite in the most rigorous way
In-Reply-To: <19821.31669.853320.528390@montanaro.dyndns.org>
References: <E1PuBC2-0000Zt-VT@dinsdale.python.org>
	<AANLkTimr8nv6gFMm669ff9U3D2L703-xCVnsA0nyXT=6@mail.gmail.com>
	<20110301144508.42c48572@pitrou.net>
	<19821.30726.763043.418363@montanaro.dyndns.org>
	<20110301235853.771beab1@pitrou.net>
	<19821.31669.853320.528390@montanaro.dyndns.org>
Message-ID: <20110302001044.7f1bce9b@pitrou.net>

On Tue, 1 Mar 2011 17:05:25 -0600
skip at pobox.com wrote:
> 
>     Antoine> Well, "make buildbottest" should do the trick.
> 
> Perhaps it should be given a somewhat less specialized sounding name...

It *is* specialized since it's meant primarily for the buildbots :)
It happens to be usable by anyone else, but that's not the goal.

That said, I think it's usually best to choose the desired flags for
the task at hand, which will of course vary (do you want to test
refleaks? to enable networking or largefile tests? do you have
several CPUs to spawn tests in parallel on?). The devguide has a small
section about this:
http://docs.python.org/devguide/runtests.html#running

(also, as Brett mentioned, a make target doesn't really help Windows
users)

Regards

Antoine.

From mail at kerrickstaley.com  Wed Mar  2 00:16:32 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Tue, 1 Mar 2011 17:16:32 -0600
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <70B4E399-E6F7-4612-9E58-E092E5216AD9@fuhm.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<AANLkTikN=KFqvZ7mhRyCLdgUjiGU-u50b=4m9D-muAD4@mail.gmail.com>
	<70B4E399-E6F7-4612-9E58-E092E5216AD9@fuhm.net>
Message-ID: <AANLkTimoUKJHsUR97SKWuA3HOXtae_HdR_E+G+4Q_Snq@mail.gmail.com>

I think that it's a good idea to not only state that python should be Python
2, but also that python2 should be implemented and that scripts should
specify it, to provide redundancy and handle distros that won't or have not
yet switched back to the python -> python2 convention. I've . In any event,
I do agree that there needs to be a clear standard coming from the Python
community.
Should I submit a PEP for this?
I'm also going to talk to the Arch devs and ask them to follow these
proposed standards (or at least to allow python to be user-switchable).
Thanks,
Kerrick Staley

On Tue, Mar 1, 2011 at 4:15 PM, James Y Knight <foom at fuhm.net> wrote:

>
> On Mar 1, 2011, at 5:06 PM, Guido van Rossum wrote:
>
> > On Tue, Mar 1, 2011 at 1:26 PM, Eric Smith <eric at trueblade.com> wrote:
> >> On 3/1/2011 4:19 PM, Kerrick Staley wrote:
> >>>
> >>> Hello,
> >>> There is a need for the default Python2 install to place a symlink at
> >>> /usr/bin/python2 that points to /usr/bin/python, or for the
> >>> documentation to recommend that packagers ensure that python2 is
> >>> defined. Also, all documentation should be changed to recommend that
> >>> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts.
> >>> This is needed because some distributions (Arch Linux, in particular),
> >>> point /usr/bin/python to /usr/bin/python3, while others (including
> >>> Slackware, Debian, and the BSDs, probably more) do not even define the
> >>> python2 command. This means that a script has no way of achieving
> >>> cross-platform compatibility. The point at which many distributions
> >>> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for
> >>> the next couple of years, it would be best to use a python2 or python3
> >>> shebang in all scripts, making no assumptions about plain python, which
> >>> should only be invoked interactively. This email from about 3 years ago
> >>> seems relevant: :
> >>> http://mail.python.org/pipermail/python-3000/2008-March/012421.html
> >>> Again, this issue needs to be addressed by the Python developers
> >>> themselves so that different *nix distributions will handle it
> >>> consistently, allowing Python scripts to continue to be cross-platform.
> >>>
> >>
> >> I believe we agreed at the language summit last year (or maybe even the
> year
> >> before) that "python" would always be python2.x, and "python3" would be
> >> python3.x.
> >>
> >> And by "always" we indeed meant forever. To do otherwise would break
> scripts
> >> even many, many years from now.
> >
> > Unfortunately distros are not following these guidelines. As long as
> > we still have the pythonX.Y links I think it's better to have
> > "python2", "python3" and "python" than total anarchy.
>
> If python upstream would make it clear that that *IS* the policy, distros
> might follow it. Right now, there is no clear guidance, as far as I can
> tell. If you do not want distros making python be a link to python3, please
> say so loudly, preferably on a webpage on python.org that users can point
> the distros to.
>
> James
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110301/9b3d22b3/attachment.html>

From martin at v.loewis.de  Wed Mar  2 00:43:56 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Mar 2011 00:43:56 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTimoUKJHsUR97SKWuA3HOXtae_HdR_E+G+4Q_Snq@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<AANLkTikN=KFqvZ7mhRyCLdgUjiGU-u50b=4m9D-muAD4@mail.gmail.com>	<70B4E399-E6F7-4612-9E58-E092E5216AD9@fuhm.net>
	<AANLkTimoUKJHsUR97SKWuA3HOXtae_HdR_E+G+4Q_Snq@mail.gmail.com>
Message-ID: <4D6D84BC.4050001@v.loewis.de>

Am 02.03.2011 00:16, schrieb Kerrick Staley:
> I think that it's a good idea to not only state that python should be
> Python 2, but also that python2 should be implemented and that scripts
> should specify it, to provide redundancy and handle distros that won't
> or have not yet switched back to the python -> python2 convention. I've
> . In any event, I do agree that there needs to be a clear standard
> coming from the Python community.
> Should I submit a PEP for this?

If you want this to become policy: yes, you will have to specify a PEP
for that. Even a PEP might not make it policy (practicality beats
purity), but not having a PEP guarantees that it won't become policy.

Regards,
Martin

From martin at v.loewis.de  Wed Mar  2 00:45:51 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Mar 2011 00:45:51 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110301222148.49F91249CF7@kimball.webabinitio.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
Message-ID: <4D6D852F.7010500@v.loewis.de>

>> I believe we agreed at the language summit last year (or maybe even the 
>> year before) that "python" would always be python2.x, and "python3" 
>> would be python3.x.
>>
>> And by "always" we indeed meant forever. To do otherwise would break 
>> scripts even many, many years from now.
> 
> It sounds like the distributions aren't going to cooperate with us.
> Arch has already switched.  Gentoo will allow the user to switch
> /usr/bin/python to point to python3, and I suspect this will become
> the default at some point.
> 
> I'm not sad about that, myself.

Neither am I. I personally also disagree with the decision taken at
the language summit (and believe that the language summit is no place
to make such decisions).

Regards,
Martin

From guido at python.org  Wed Mar  2 00:57:45 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Mar 2011 15:57:45 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6D852F.7010500@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
Message-ID: <AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>

On Tue, Mar 1, 2011 at 3:45 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> I believe we agreed at the language summit last year (or maybe even the
>>> year before) that "python" would always be python2.x, and "python3"
>>> would be python3.x.
>>>
>>> And by "always" we indeed meant forever. To do otherwise would break
>>> scripts even many, many years from now.
>>
>> It sounds like the distributions aren't going to cooperate with us.
>> Arch has already switched. ?Gentoo will allow the user to switch
>> /usr/bin/python to point to python3, and I suspect this will become
>> the default at some point.
>>
>> I'm not sad about that, myself.
>
> Neither am I. I personally also disagree with the decision taken at
> the language summit (and believe that the language summit is no place
> to make such decisions).

I don't recall which side I was on at the time, but now I agree we
should try to encourage distros to use python2 for Python 2.x and
python for whatever they like to promote.

I think a PEP would help, but in this case I would request that before
the PEP gets written (it can be a really short one!) somebody actually
go out and get consensus from a number of important distros. Besides
Barry, do we have any representatives of distros here?

-- 
--Guido van Rossum (python.org/~guido)

From allan at archlinux.org  Wed Mar  2 00:57:59 2011
From: allan at archlinux.org (Allan McRae)
Date: Wed, 02 Mar 2011 09:57:59 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikN=KFqvZ7mhRyCLdgUjiGU-u50b=4m9D-muAD4@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>
	<AANLkTikN=KFqvZ7mhRyCLdgUjiGU-u50b=4m9D-muAD4@mail.gmail.com>
Message-ID: <4D6D8807.6020509@archlinux.org>

On 02/03/11 08:06, Guido van Rossum wrote:
> On Tue, Mar 1, 2011 at 1:26 PM, Eric Smith<eric at trueblade.com>  wrote:
>> On 3/1/2011 4:19 PM, Kerrick Staley wrote:
>>>
>>> Hello,
>>> There is a need for the default Python2 install to place a symlink at
>>> /usr/bin/python2 that points to /usr/bin/python, or for the
>>> documentation to recommend that packagers ensure that python2 is
>>> defined. Also, all documentation should be changed to recommend that
>>> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts.
>>> This is needed because some distributions (Arch Linux, in particular),
>>> point /usr/bin/python to /usr/bin/python3, while others (including
>>> Slackware, Debian, and the BSDs, probably more) do not even define the
>>> python2 command. This means that a script has no way of achieving
>>> cross-platform compatibility. The point at which many distributions
>>> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for
>>> the next couple of years, it would be best to use a python2 or python3
>>> shebang in all scripts, making no assumptions about plain python, which
>>> should only be invoked interactively. This email from about 3 years ago
>>> seems relevant: :
>>> http://mail.python.org/pipermail/python-3000/2008-March/012421.html
>>> Again, this issue needs to be addressed by the Python developers
>>> themselves so that different *nix distributions will handle it
>>> consistently, allowing Python scripts to continue to be cross-platform.
>>>
>>
>> I believe we agreed at the language summit last year (or maybe even the year
>> before) that "python" would always be python2.x, and "python3" would be
>> python3.x.
>>
>> And by "always" we indeed meant forever. To do otherwise would break scripts
>> even many, many years from now.
>
> Unfortunately distros are not following these guidelines. As long as
> we still have the pythonX.Y links I think it's better to have
> "python2", "python3" and "python" than total anarchy.
>

This was brought up when Arch Linux switched /usr/bin/python to point a 
python3 around six months ago, and at the time no-one could actually 
recall the decision to always point /usr/bin/python at python2 forever. 
  In fact, the only decision that was clearly made (and acted on) was 
that "make install" for python3 would install /usr/bin/python3.

e.g. http://www.mail-archive.com/python-dev at python.org/msg53204.html

But if that decision was made, it was not documented anywhere that I can 
find, so effectively was a non-decision...

Deciding that /usr/bin/python going to always point at python2 just 
makes me think that python3 is always going to be a second class 
citizen.  Eventually python-2.7 will be long gone and it would seem 
wrong for people will still be using "python3" to run their scripts once 
python-3.xx is the primary python version.

So a transition is going to need to be made here at some stage.  Most 
distributions have been providing the /usr/bin/python2 symlink for a 
long time, with Debian being the notable exception.  I think adding such 
a symlink is in the realm of what distribution packagers can choose to 
do on their own, but having it done automatically for python-2.7 would 
also be of benefit.

Allan

From martin at v.loewis.de  Wed Mar  2 01:14:32 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Mar 2011 01:14:32 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
Message-ID: <4D6D8BE8.7020808@v.loewis.de>

> I think a PEP would help, but in this case I would request that before
> the PEP gets written (it can be a really short one!) somebody actually
> go out and get consensus from a number of important distros. Besides
> Barry, do we have any representatives of distros here?

Matthias Klose represents Debian, Dave Malcolm represents Redhat,
and Dirkjan Ochtman represents Gentoo.

Regards,
Martin

From solipsis at pitrou.net  Wed Mar  2 01:38:37 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 2 Mar 2011 01:38:37 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
Message-ID: <20110302013837.7d593053@pitrou.net>

On Wed, 02 Mar 2011 00:45:51 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> >> I believe we agreed at the language summit last year (or maybe even the 
> >> year before) that "python" would always be python2.x, and "python3" 
> >> would be python3.x.
> >>
> >> And by "always" we indeed meant forever. To do otherwise would break 
> >> scripts even many, many years from now.
> > 
> > It sounds like the distributions aren't going to cooperate with us.
> > Arch has already switched.  Gentoo will allow the user to switch
> > /usr/bin/python to point to python3, and I suspect this will become
> > the default at some point.
> > 
> > I'm not sad about that, myself.
> 
> Neither am I. I personally also disagree with the decision taken at
> the language summit (and believe that the language summit is no place
> to make such decisions).

+1 with the latter.

Regards

Antoine.



From a.badger at gmail.com  Wed Mar  2 01:42:37 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 1 Mar 2011 16:42:37 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6D8BE8.7020808@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
Message-ID: <20110302004237.GB19342@unaka.lan>

On Wed, Mar 02, 2011 at 01:14:32AM +0100, "Martin v. L?wis" wrote:
> > I think a PEP would help, but in this case I would request that before
> > the PEP gets written (it can be a really short one!) somebody actually
> > go out and get consensus from a number of important distros. Besides
> > Barry, do we have any representatives of distros here?
> 
> Matthias Klose represents Debian, Dave Malcolm represents Redhat,
> and Dirkjan Ochtman represents Gentoo.
> 
I'm here from Fedora.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110301/48c07152/attachment.pgp>

From rrr at ronadam.com  Wed Mar  2 03:03:45 2011
From: rrr at ronadam.com (Ron Adam)
Date: Tue, 01 Mar 2011 20:03:45 -0600
Subject: [Python-Dev] [Python-checkins] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <ikjh48$sk4$2@dough.gmane.org>
References: <20110228182236.5F675EE982@mail.python.org>	<AANLkTimZaDTAjOWPQwbwhMyL=CpPgj7JBo-rm3Brq-iv@mail.gmail.com>	<20110301160522.0871bc4d@pitrou.net>
	<ikjh48$sk4$2@dough.gmane.org>
Message-ID: <4D6DA581.5010204@ronadam.com>



On 03/01/2011 01:22 PM, Georg Brandl wrote:
> On 01.03.2011 16:05, Antoine Pitrou wrote:
>> On Tue, 1 Mar 2011 16:52:58 +0200
>> Eli Bendersky<eliben at gmail.com>  wrote:
>>> The PEP (http://www.python.org/dev/peps/pep-0385/) says in "Timeline":
>>>
>>> 2010-03-05: final conversion (tentative)
>>>
>>> I assume 2011-03-05 is meant here.
>>
>> Oh... I guess I was a bit optimistic.
>>
>> Thanks for noticing
>
> Hey, I still got the time machine locked away in my parents' basement...

It's a time machine, there is no way you can be sure it isn't being used in 
this present time, from some other time period. ;-)

Cheers,
   Ron


From stephen at xemacs.org  Wed Mar  2 03:22:34 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 02 Mar 2011 11:22:34 +0900
Subject: [Python-Dev] contributors survey?
In-Reply-To: <20110301233210.5d6206e6@pitrou.net>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTi=4Vn4E4sgmS3bs6TpPDDJTX6g3=bFhSLtu1Zu9@mail.gmail.com>
	<20110301233210.5d6206e6@pitrou.net>
Message-ID: <87wrki8dn9.fsf@uwakimon.sk.tsukuba.ac.jp>

Antoine Pitrou writes:

 > Following the example given in the original article, I was considering
 > a single freeform question: "why did you stop contributing after your
 > last patch to CPython?" (of course, that text should be decorated with
 > a greeting and an introduction and the wording can be improved).

Does anybody ever stop contributing?  Occasionally, yes, but in most
cases it's just that this interval between explicit contributions
(usually patches, but also reviews, PEPs, mailing list posting, bug
reports, ...) is longer than the period since the last one. :-)

How about

    Hello.  We [the PSF?] would like to thank you for your past
    patches to CPython, and take this opportunity to learn something
    about how to improve our workflow.  We would appreciate your
    cooperation in answering the following question.

    It has been more than one year since your last patch to CPython.
    We would like to understand why it's been so long [, and if there
    is anything we could do to help you contribute patches more
    frequently].

The clause in brackets is outside the scope of Antoine's wording, but
I assume that's where we're going with this.

From jnoller at gmail.com  Wed Mar  2 03:31:48 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Tue, 1 Mar 2011 21:31:48 -0500
Subject: [Python-Dev] contributors survey?
In-Reply-To: <87wrki8dn9.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTi=4Vn4E4sgmS3bs6TpPDDJTX6g3=bFhSLtu1Zu9@mail.gmail.com>
	<20110301233210.5d6206e6@pitrou.net>
	<87wrki8dn9.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTik5MCQaJDSEnh4QhtgVyweum3uHPrtr0jn52NFW@mail.gmail.com>

On Tue, Mar 1, 2011 at 9:22 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Antoine Pitrou writes:
>
> ?> Following the example given in the original article, I was considering
> ?> a single freeform question: "why did you stop contributing after your
> ?> last patch to CPython?" (of course, that text should be decorated with
> ?> a greeting and an introduction and the wording can be improved).
>
> Does anybody ever stop contributing? ?Occasionally, yes, but in most
> cases it's just that this interval between explicit contributions
> (usually patches, but also reviews, PEPs, mailing list posting, bug
> reports, ...) is longer than the period since the last one. :-)
>
> How about
>
> ? ?Hello. ?We [the PSF?] would like to thank you for your past
> ? ?patches to CPython, and take this opportunity to learn something
> ? ?about how to improve our workflow. ?We would appreciate your
> ? ?cooperation in answering the following question.
>
> ? ?It has been more than one year since your last patch to CPython.
> ? ?We would like to understand why it's been so long [, and if there
> ? ?is anything we could do to help you contribute patches more
> ? ?frequently].
>
> The clause in brackets is outside the scope of Antoine's wording, but
> I assume that's where we're going with this.

Personally, I like this, but I would skip the PSF aspect of it, and
focus on core. The PSF exists "outside" of the domain of CPython and
should probably avoid taking too much credit or inserting itself more.
:)

jesse

From rrr at ronadam.com  Wed Mar  2 03:03:45 2011
From: rrr at ronadam.com (Ron Adam)
Date: Tue, 01 Mar 2011 20:03:45 -0600
Subject: [Python-Dev] [Python-checkins] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <ikjh48$sk4$2@dough.gmane.org>
References: <20110228182236.5F675EE982@mail.python.org>	<AANLkTimZaDTAjOWPQwbwhMyL=CpPgj7JBo-rm3Brq-iv@mail.gmail.com>	<20110301160522.0871bc4d@pitrou.net>
	<ikjh48$sk4$2@dough.gmane.org>
Message-ID: <4D6DA581.5010204@ronadam.com>



On 03/01/2011 01:22 PM, Georg Brandl wrote:
> On 01.03.2011 16:05, Antoine Pitrou wrote:
>> On Tue, 1 Mar 2011 16:52:58 +0200
>> Eli Bendersky<eliben at gmail.com>  wrote:
>>> The PEP (http://www.python.org/dev/peps/pep-0385/) says in "Timeline":
>>>
>>> 2010-03-05: final conversion (tentative)
>>>
>>> I assume 2011-03-05 is meant here.
>>
>> Oh... I guess I was a bit optimistic.
>>
>> Thanks for noticing
>
> Hey, I still got the time machine locked away in my parents' basement...

It's a time machine, there is no way you can be sure it isn't being used in 
this present time, from some other time period. ;-)

Cheers,
   Ron

From anikom15 at gmail.com  Wed Mar  2 04:25:00 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Tue, 01 Mar 2011 19:25:00 -0800
Subject: [Python-Dev] contributors survey?
In-Reply-To: <1299014648.3709.16.camel@localhost.localdomain>
References: <1299014648.3709.16.camel@localhost.localdomain>
Message-ID: <1299036300.3153.1.camel@localhost.localdomain>

On Tue, 2011-03-01 at 22:24 +0100, Antoine Pitrou wrote:
> Hello,
> 
> In
> http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I was asking whether it would be useful to make a survey of past contributors, as in:
> 
>         First, we did a survey of all our past developers who had left
>         the project, asking them why they had left. This was just a
>         free-form survey, allowing people to answer any way they wanted.
> 
> (from the quoted article in the thread linked above)
> 
> Since I didn't get any answer, I wonder if the idea simply got
> overlooked, or if there's no need at all.
> 
> Regards
> 
> Antoine.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/anikom15%40gmail.com

If I got a message like that in my mailbox I would be rather annoyed,
mark it as spam, and be less likely to contribute again.

Just my point of view.


From orsenthil at gmail.com  Wed Mar  2 04:34:00 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 2 Mar 2011 11:34:00 +0800
Subject: [Python-Dev] contributors survey?
In-Reply-To: <1299019547.3709.18.camel@localhost.localdomain>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
	<20110301233238.3ef4b05f@pitrou.net>
	<AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>
	<1299019547.3709.18.camel@localhost.localdomain>
Message-ID: <20110302033400.GA31811@kevin>

On Tue, Mar 01, 2011 at 11:45:47PM +0100, Antoine Pitrou wrote:
> hg log -k "contributor name"
> 
> Also, memory helps although it's quite perfectible :)
> 
> At worse, we'll have a couple of false positives and we'll have to
> apologize to them...

There are about 948 folks in the Misc/ACKS and many would have been
1/2 time contributors. There should be a handful of them who might
have contributed significantly. Just asking them would be good idea
(if you really need to survey). 

Personally, I am not sure how this survey is going to be helpful.


-- 
Senthil

From guido at python.org  Wed Mar  2 05:43:27 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Mar 2011 20:43:27 -0800
Subject: [Python-Dev] contributors survey?
In-Reply-To: <20110302033400.GA31811@kevin>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
	<20110301233238.3ef4b05f@pitrou.net>
	<AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>
	<1299019547.3709.18.camel@localhost.localdomain>
	<20110302033400.GA31811@kevin>
Message-ID: <AANLkTimHAoXrr_V7fMsdpo0sqXXfvE4HNzKmF7pfmsx4@mail.gmail.com>

On Tue, Mar 1, 2011 at 7:34 PM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> On Tue, Mar 01, 2011 at 11:45:47PM +0100, Antoine Pitrou wrote:
>> hg log -k "contributor name"
>>
>> Also, memory helps although it's quite perfectible :)
>>
>> At worse, we'll have a couple of false positives and we'll have to
>> apologize to them...
>
> There are about 948 folks in the Misc/ACKS and many would have been
> 1/2 time contributors. There should be a handful of them who might
> have contributed significantly. Just asking them would be good idea
> (if you really need to survey).

It's impossible to match the ACKS file with email addresses; that was
never the intention anyway, it was meant to thank people. (Some people
are on the list for reasons having nothing to do with code
contributions, too.)

> Personally, I am not sure how this survey is going to be helpful.

I think it would be at least mildly useful to find out why people who
contributed code in the past stopped contributing. Over the years I've
sometimes had the opportunity to find out -- the reasons more often
than not had to do with life or career changes that are out of our
control; some have stopped contributing code to CPython but are
contributing in other ways (e.g. they may have started a different
project).

But I wouldn't be surprised if some people had regrets about the way
the community works (I can recall at least one such case) and it would
be useful to learn from those occasions, if they'll let us. And the
numbers might tell us something, too.

Perhaps a better way than scanning ACKS would be to collect
contributor email addresses from the svn logs and note those that
haven't contributed in the past 12 months.

-- 
--Guido van Rossum (python.org/~guido)

From piotr at debian.org  Wed Mar  2 10:01:55 2011
From: piotr at debian.org (Piotr =?utf-8?Q?O=C5=BCarowski?=)
Date: Wed, 2 Mar 2011 10:01:55 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6D8BE8.7020808@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
Message-ID: <20110302090155.GL30982@piotro.eu>

["Martin v. L?wis", 2011-03-02]
> > I think a PEP would help, but in this case I would request that before
> > the PEP gets written (it can be a really short one!) somebody actually
> > go out and get consensus from a number of important distros. Besides
> > Barry, do we have any representatives of distros here?
> 
> Matthias Klose represents Debian, Dave Malcolm represents Redhat,
> and Dirkjan Ochtman represents Gentoo.

I co-maintain with Matthias a package that provides /usr/bin/python
symlink in Debian and I can confirm that it will always point to Python
2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
only accepted PEP can change that)
-- 
Piotr O?arowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

From asmodai at in-nomine.org  Wed Mar  2 11:02:11 2011
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Wed, 2 Mar 2011 11:02:11 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6D8BE8.7020808@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
Message-ID: <20110302100211.GC20060@nexus.in-nomine.org>

-On [20110302 01:17], "Martin v. L?wis" (martin at v.loewis.de) wrote:
>Matthias Klose represents Debian, Dave Malcolm represents Redhat,
>and Dirkjan Ochtman represents Gentoo.

With FreeBSD's ports if you install a Python port it will install a
pythonX.Y in /usr/local/bin, depending on what is specified with the make
variable PYTHON_DEFAULT_VERSION "python" will point to that version. So it
can refer to either 2.x or 3.x.

NetBSD's pkgsrc does not have 3.x in the tree yet. But if no "python" exists
yet, then pkg_alternatives will link it to the version of choice.

Not sure what either OpenBSD or DragonFly BSD are doing, but it will be
along these lines as well.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | GPG: 2EAC625B
Ain't gonna spend the rest of my Life, quietly fading away...

From solipsis at pitrou.net  Wed Mar  2 12:08:07 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 2 Mar 2011 12:08:07 +0100
Subject: [Python-Dev] devinabox: Add a script which will build CPython.
References: <E1PuBC2-0000Zx-W3@dinsdale.python.org>
Message-ID: <20110302120807.3e6957c1@pitrou.net>

On Mon, 28 Feb 2011 23:03:50 +0100
brett.cannon <python-checkins at python.org> wrote:
> +
> +if sys.platform == 'win32':
> +    print("See the devguide's Getting Set Up guide for building under Windows")

Actually, you can also build from the command line under Windows:
using Tools/buildbot/build.bat or Tools/buildbot/build-amd64.bat
depending on the build you want (but perhaps it's good to teach people
to use the MSVC UI, since that's the reference IDE under Windows;
besides, these scripts will need MSVN installed anyway).

Regards

Antoine.



From fuzzyman at voidspace.org.uk  Wed Mar  2 12:40:56 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 02 Mar 2011 11:40:56 +0000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
Message-ID: <4D6E2CC7.1080000@voidspace.org.uk>

On 01/03/2011 21:19, Kerrick Staley wrote:
> Hello,
> There is a need for the default Python2 install to place a symlink at 
> /usr/bin/python2 that points to /usr/bin/python, or for the 
> documentation to recommend that packagers ensure that python2 is 
> defined. Also, all documentation should be changed to recommend that 
> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts.
> This is needed because some distributions (Arch Linux, in particular), 
> point /usr/bin/python to /usr/bin/python3, while others (including 
> Slackware, Debian, and the BSDs, probably more) do not even define the 
> python2 command. This means that a script has no way of achieving 
> cross-platform compatibility. The point at which many distributions 
> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and 
> for the next couple of years, it would be best to use a python2 or 
> python3 shebang in all scripts, making no assumptions about plain 
> python, which should only be invoked interactively. This email from 
> about 3 years ago seems relevant: : 
> http://mail.python.org/pipermail/python-3000/2008-March/012421.html
> Again, this issue needs to be addressed by the Python developers 
> themselves so that different *nix distributions will handle it 
> consistently, allowing Python scripts to continue to be cross-platform.

+1

Note that a PEP will need to address what we do for Windows and Mac OS 
X. Less of an issue for Windows where we don't put python.exe on the 
PATH (which we *should*), but we still need to decide whether we will 
add python2 / python3 binaries.

Michael Foord

> Thanks,
> Kerrick Staley
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/81fd9e9c/attachment.html>

From solipsis at pitrou.net  Wed Mar  2 13:07:17 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 2 Mar 2011 13:07:17 +0100
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTimHAoXrr_V7fMsdpo0sqXXfvE4HNzKmF7pfmsx4@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
	<20110301233238.3ef4b05f@pitrou.net>
	<AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>
	<1299019547.3709.18.camel@localhost.localdomain>
	<20110302033400.GA31811@kevin>
	<AANLkTimHAoXrr_V7fMsdpo0sqXXfvE4HNzKmF7pfmsx4@mail.gmail.com>
Message-ID: <20110302130717.1d9d8787@pitrou.net>

On Tue, 1 Mar 2011 20:43:27 -0800
Guido van Rossum <guido at python.org> wrote:
> 
> But I wouldn't be surprised if some people had regrets about the way
> the community works (I can recall at least one such case) and it would
> be useful to learn from those occasions, if they'll let us. And the
> numbers might tell us something, too.

Yes, that's the kind of things that would be good to hear about IMO.
It's obvious that in some cases patches and reports go simply
unanswered for years, and in these cases a first-time reporter or
contributor won't bother again (who would?).
But I wonder if there are other social or technical factors, such as
the community being too intimidating or not welcoming enough.

Actually, if some python-dev readers have something to say about that,
they are welcome :)

> Perhaps a better way than scanning ACKS would be to collect
> contributor email addresses from the svn logs and note those that
> haven't contributed in the past 12 months.

SVN logs usually don't mention contributor emails (except for
committers). Also, it's probably more difficult to extract contributor
names from the SVN logs than from the ACKS file.

Ok, finding emails might be harder than I initially thought it to be.
I hadn't counted the number of lines in ACKS and assumed it
was much smaller than that!

Regards

Antoine.

From solipsis at pitrou.net  Wed Mar  2 13:08:05 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 2 Mar 2011 13:08:05 +0100
Subject: [Python-Dev] contributors survey?
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
Message-ID: <20110302130805.3ca921fc@pitrou.net>


Hello,

On Tue, 01 Mar 2011 19:25:00 -0800
Westley Mart?nez <anikom15 at gmail.com> wrote:
> 
> If I got a message like that in my mailbox I would be rather annoyed,
> mark it as spam, and be less likely to contribute again.

Yes, I think that's a risk. Do you think of a wording that could
alleviate such perception?

Thank you

Antoine.



From andrew.svetlov at gmail.com  Wed Mar  2 13:29:18 2011
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Wed, 2 Mar 2011 14:29:18 +0200
Subject: [Python-Dev] contributors survey?
In-Reply-To: <20110302130805.3ca921fc@pitrou.net>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
	<20110302130805.3ca921fc@pitrou.net>
Message-ID: <AANLkTinmN_1JbG0XsqH_a=EvUSbiQS3crarHCdHqD-8i@mail.gmail.com>

SVN is very bad instrument to contribute or follow an issue patches.
And, of course, very long lifecycle of the most issues greatly reduces
enthusisasm.

On Wed, Mar 2, 2011 at 2:08 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hello,
>
> On Tue, 01 Mar 2011 19:25:00 -0800
> Westley Mart?nez <anikom15 at gmail.com> wrote:
>>
>> If I got a message like that in my mailbox I would be rather annoyed,
>> mark it as spam, and be less likely to contribute again.
>
> Yes, I think that's a risk. Do you think of a wording that could
> alleviate such perception?
>
> Thank you
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com
>

From solipsis at pitrou.net  Wed Mar  2 13:39:57 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 2 Mar 2011 13:39:57 +0100
Subject: [Python-Dev] contributors survey?
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
	<20110302130805.3ca921fc@pitrou.net>
	<AANLkTinmN_1JbG0XsqH_a=EvUSbiQS3crarHCdHqD-8i@mail.gmail.com>
Message-ID: <20110302133957.22d36065@pitrou.net>


On Wed, 2 Mar 2011 14:29:18 +0200
Andrew Svetlov <andrew.svetlov at gmail.com> wrote:
> SVN is very bad instrument to contribute or follow an issue patches.

Will Mercurial make things more attractive?

> And, of course, very long lifecycle of the most issues greatly reduces
> enthusisasm.

True. I believe we are improving that, but perhaps that's a
misperception on my part.

Thanks

Antoine.



From morph at debian.org  Wed Mar  2 13:44:31 2011
From: morph at debian.org (Sandro Tosi)
Date: Wed, 2 Mar 2011 13:44:31 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302090155.GL30982@piotro.eu>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
Message-ID: <AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>

On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski <piotr at debian.org> wrote:
> I co-maintain with Matthias a package that provides /usr/bin/python
> symlink in Debian and I can confirm that it will always point to Python
> 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
> only accepted PEP can change that)

Can you please explain why you NACK this proposed change?

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From andrew.svetlov at gmail.com  Wed Mar  2 13:54:24 2011
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Wed, 2 Mar 2011 14:54:24 +0200
Subject: [Python-Dev] contributors survey?
In-Reply-To: <20110302133957.22d36065@pitrou.net>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
	<20110302130805.3ca921fc@pitrou.net>
	<AANLkTinmN_1JbG0XsqH_a=EvUSbiQS3crarHCdHqD-8i@mail.gmail.com>
	<20110302133957.22d36065@pitrou.net>
Message-ID: <AANLkTikh9ETJUFAEfA46AsL7KpuDY+Z4AH2=CjS2i6GE@mail.gmail.com>

On Wed, Mar 2, 2011 at 2:39 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Will Mercurial make things more attractive?
>
Definitely yes! I welcome upcoming migration.

>> And, of course, very long lifecycle of the most issues greatly reduces
>> enthusisasm.
>
> True. I believe we are improving that, but perhaps that's a
> misperception on my part.
>

I understand reasons for that situation and really doubt if process
can be significantly accelerated.
But it just very unconvenient.

From piotr at debian.org  Wed Mar  2 13:56:41 2011
From: piotr at debian.org (Piotr =?utf-8?Q?O=C5=BCarowski?=)
Date: Wed, 2 Mar 2011 13:56:41 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
Message-ID: <20110302125641.GM30982@piotro.eu>

[Sandro Tosi, 2011-03-02]
> On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski <piotr at debian.org> wrote:
> > I co-maintain with Matthias a package that provides /usr/bin/python
> > symlink in Debian and I can confirm that it will always point to Python
> > 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
> > only accepted PEP can change that)
> 
> Can you please explain why you NACK this proposed change?

it encourages people to change /usr/bin/python symlink to point to
python3.X which I'm strongly against (how can I tell that upstream
author meant python3.X and not python2.X without checking the code?)
-- 
Piotr O?arowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

From p.f.moore at gmail.com  Wed Mar  2 13:57:53 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 2 Mar 2011 12:57:53 +0000
Subject: [Python-Dev] contributors survey?
In-Reply-To: <20110302130717.1d9d8787@pitrou.net>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
	<20110301233238.3ef4b05f@pitrou.net>
	<AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>
	<1299019547.3709.18.camel@localhost.localdomain>
	<20110302033400.GA31811@kevin>
	<AANLkTimHAoXrr_V7fMsdpo0sqXXfvE4HNzKmF7pfmsx4@mail.gmail.com>
	<20110302130717.1d9d8787@pitrou.net>
Message-ID: <AANLkTikOxj27QxFjCeBq5s8rsX7hGKTfsed6YQED8ZVE@mail.gmail.com>

On 2 March 2011 12:07, Antoine Pitrou <solipsis at pitrou.net> wrote:
> But I wonder if there are other social or technical factors, such as
> the community being too intimidating or not welcoming enough.
>
> Actually, if some python-dev readers have something to say about that,
> they are welcome :)

>From a personal POV, it's the long time it takes for a change to get
applied that really discourages me. I know all the reasons why it
happens, and I fully appreciate that it's a chicken and egg situation,
but nevertheless it's a huge discouragement.

As an example (and I'm not picking on anyone here!) my buildbot has
been ineffective for some time because it was continually failing on
test_ttk_guionly, which simply isn't valid in my setup (buildbot
running as a service, so no GUI to test). There was a patch around for
quite some time, which I wasn't qualified to judge in detail but which
looked OK to me. Recently, Antoine applied it (thanks, Antione!) and
it has fixed that issue. Of course, now, my buildbot is failing again,
this time with "no space on device" errors. I suspect that again it's
an environmental issue, but I'm not really motivated to try to
diagnose it given (a) the likely time it'll take to get any fix
applied and (b) it's presumably not a general issue as otherwise I'd
see other buildbots failing with the same error. (Personal commitments
also mean I have little time to spend on this, which doesn't help...)
So I will probably leave it.

Sadly, I have no solution to offer, and TBH, this is probably not news
to anyone on this list, but I really do believe that this is the main
blocker to getting additional contributors involved.

Paul.

PS My one experience of participating in a bug day was that it was a
very encouraging experience of being involved in contribution. So more
bug days and/or sprints would definitely be good from this perspective
:-)

From mark.smith at practicalpoetry.co.uk  Wed Mar  2 14:10:04 2011
From: mark.smith at practicalpoetry.co.uk (Mark Smith)
Date: Wed, 2 Mar 2011 13:10:04 +0000
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTikh9ETJUFAEfA46AsL7KpuDY+Z4AH2=CjS2i6GE@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
	<20110302130805.3ca921fc@pitrou.net>
	<AANLkTinmN_1JbG0XsqH_a=EvUSbiQS3crarHCdHqD-8i@mail.gmail.com>
	<20110302133957.22d36065@pitrou.net>
	<AANLkTikh9ETJUFAEfA46AsL7KpuDY+Z4AH2=CjS2i6GE@mail.gmail.com>
Message-ID: <AANLkTi=GBbci+vbPiWxpfyJbQqMdkrDgH-seX9s52yHX@mail.gmail.com>

The following is going to sound bitter...

I was fired with enthusiasm for working on Python after the sprints at
EuroPython last year. I submitted 3 (I think) patches for pulldom - a test
suite (it has 0% code coverage at present), documentation for the module
(there isn't any at present), and a patch deprecating a function that is
broken. They're all still open, and the patches are getting staler by the
month.

The point of this level of detail is: I was new to the project; I submitted
some relatively uncomplicated patches that trivially, visibly, and (mostly)
uncontroversially improve Python - one of them was a /documentation/ patch.
Then nothing happened, apart from the odd comment from people who commented
on the tickets - and I responded to their queries. So now I'm of the opinion
that it's not worth submitting patches to the Python project at all, because
they'll never be accepted. I'll dedicate my time to something else instead.

Mercurial /will/ make it easier to contribute code, but if it doesn't get
accepted into a release branch, then that makes no real difference to me.

Seriously guys - fix the issue lifecycle; I'll come back.

--Mark

On 2 March 2011 12:54, Andrew Svetlov <andrew.svetlov at gmail.com> wrote:

> On Wed, Mar 2, 2011 at 2:39 PM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> >
> > Will Mercurial make things more attractive?
> >
> Definitely yes! I welcome upcoming migration.
>
> >> And, of course, very long lifecycle of the most issues greatly reduces
> >> enthusisasm.
> >
> > True. I believe we are improving that, but perhaps that's a
> > misperception on my part.
> >
>
> I understand reasons for that situation and really doubt if process
> can be significantly accelerated.
> But it just very unconvenient.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mark.smith%40practicalpoetry.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/01fc9441/attachment-0001.html>

From morph at debian.org  Wed Mar  2 14:23:27 2011
From: morph at debian.org (Sandro Tosi)
Date: Wed, 2 Mar 2011 14:23:27 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302125641.GM30982@piotro.eu>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
Message-ID: <AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>

On Wed, Mar 2, 2011 at 13:56, Piotr O?arowski <piotr at debian.org> wrote:
> [Sandro Tosi, 2011-03-02]
>> On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski <piotr at debian.org> wrote:
>> > I co-maintain with Matthias a package that provides /usr/bin/python
>> > symlink in Debian and I can confirm that it will always point to Python
>> > 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
>> > only accepted PEP can change that)
>>
>> Can you please explain why you NACK this proposed change?
>
> it encourages people to change /usr/bin/python symlink to point to
> python3.X which I'm strongly against (how can I tell that upstream
> author meant python3.X and not python2.X without checking the code?)

with 'people' do you mean 'users'? if so, isn't this risk already present?

If you, user, change the python symlink (provided by python-minimal in
Debian) to something else than what's shipped, it's still a local
change, and will never be supported; but with python2 *Debian is free*
to decide if python can be pointed to python3, if the time will come.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From ncoghlan at gmail.com  Wed Mar  2 14:46:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 2 Mar 2011 23:46:17 +1000
Subject: [Python-Dev] [Python-checkins] devguide (hg_transition): Update
 instructions to use the new "server-side clone" button
In-Reply-To: <20110301215424.1a37b75b@pitrou.net>
References: <E1PuVbl-00084l-3G@dinsdale.python.org>
	<4D6D58CD.9010900@netwok.org> <20110301215424.1a37b75b@pitrou.net>
Message-ID: <AANLkTimaMwEz+42wAJrt1h3icWOjpDGPcVj7ikUqFaoo@mail.gmail.com>

On Wed, Mar 2, 2011 at 6:54 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> A remark: Having all clones created under a dedicated namespace (say
>> sandbox) could make the hg.python.org listing clearer, since all user
>> clones would be grouped.
>
> Sure, we can change the enforced convention depending on the majority's
> preference. I chose that one because other devs thought it would be bad
> to let people create many repos at the top-level.

Having user clones flagged by the two-level names should be more than
enough when it comes to what the server enforces. That way we can be
flexible about additional namespaces (although using "sandbox" by
convention should cover most use cases).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From piotr at debian.org  Wed Mar  2 15:03:23 2011
From: piotr at debian.org (Piotr =?utf-8?Q?O=C5=BCarowski?=)
Date: Wed, 2 Mar 2011 15:03:23 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
Message-ID: <20110302140323.GN30982@piotro.eu>

[Sandro Tosi, 2011-03-02]
> On Wed, Mar 2, 2011 at 13:56, Piotr O?arowski <piotr at debian.org> wrote:
> > [Sandro Tosi, 2011-03-02]
> >> On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski <piotr at debian.org> wrote:
> >> > I co-maintain with Matthias a package that provides /usr/bin/python
> >> > symlink in Debian and I can confirm that it will always point to Python
> >> > 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
> >> > only accepted PEP can change that)
> >>
> >> Can you please explain why you NACK this proposed change?
> >
> > it encourages people to change /usr/bin/python symlink to point to
> > python3.X which I'm strongly against (how can I tell that upstream
> > author meant python3.X and not python2.X without checking the code?)
> 
> with 'people' do you mean 'users'? if so, isn't this risk already present?

users already break their systems via "sudo ez_install ..." (note the
"sudo" part!), I meant developers (distro and upstream authors).
If a programmer develops a script in Python 3 on Arch and later ships
his file with /usr/bin/python in shebang, it's very likely that this
script will not work on all distributions that didn't (yet?) change the
symlink.

> If you, user, change the python symlink (provided by python-minimal in
> Debian) to something else than what's shipped, it's still a local
> change, and will never be supported; but with python2 *Debian is free*
> to decide if python can be pointed to python3, if the time will come.

... and make other distributions developers' life miserable?
-- 
Piotr O?arowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

From foom at fuhm.net  Wed Mar  2 15:04:51 2011
From: foom at fuhm.net (James Y Knight)
Date: Wed, 2 Mar 2011 09:04:51 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
Message-ID: <69C30191-BB34-4377-AE79-CAE6C3B68357@fuhm.net>


On Mar 2, 2011, at 8:23 AM, Sandro Tosi wrote:

> On Wed, Mar 2, 2011 at 13:56, Piotr O?arowski <piotr at debian.org> wrote:
>> [Sandro Tosi, 2011-03-02]
>>> On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski <piotr at debian.org> wrote:
>>>> I co-maintain with Matthias a package that provides /usr/bin/python
>>>> symlink in Debian and I can confirm that it will always point to Python
>>>> 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
>>>> only accepted PEP can change that)
>>> 
>>> Can you please explain why you NACK this proposed change?
>> 
>> it encourages people to change /usr/bin/python symlink to point to
>> python3.X which I'm strongly against (how can I tell that upstream
>> author meant python3.X and not python2.X without checking the code?)
> 
> with 'people' do you mean 'users'? if so, isn't this risk already present?
> 
> If you, user, change the python symlink (provided by python-minimal in
> Debian) to something else than what's shipped, it's still a local
> change, and will never be supported; but with python2 *Debian is free*
> to decide if python can be pointed to python3, if the time will come.

I suspect he's saying it'd be better if the time didn't come (if so, I'd agree). Python3 *is* unfortunately a new and incompatible programming language, it makes sense for it to have it have its own interpreter name. Eventually /usr/bin/python might no longer be installed, but that doesn't mean python3 shouldn't simply be called python3 forever.

James

From jerome.radix at gmail.com  Wed Mar  2 15:07:38 2011
From: jerome.radix at gmail.com (=?ISO-8859-1?B?Suly9G1lIFJhZGl4?=)
Date: Wed, 2 Mar 2011 15:07:38 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
Message-ID: <AANLkTikTfOyGoTkEx=A6jB1-meQ2=_i822f9L3GMOFVA@mail.gmail.com>

Hello,

Defensive programming will force you to do things like :

import sys
if sys.version[0] == '2':
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/1bc91fae/attachment.html>

From allan at archlinux.org  Wed Mar  2 15:18:15 2011
From: allan at archlinux.org (Allan McRae)
Date: Thu, 03 Mar 2011 00:18:15 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302140323.GN30982@piotro.eu>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu>
Message-ID: <4D6E51A7.6020302@archlinux.org>

On 03/03/11 00:03, Piotr O?arowski wrote:
> [Sandro Tosi, 2011-03-02]
>> On Wed, Mar 2, 2011 at 13:56, Piotr O?arowski<piotr at debian.org>  wrote:
>>> [Sandro Tosi, 2011-03-02]
>>>> On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski<piotr at debian.org>  wrote:
>>>>> I co-maintain with Matthias a package that provides /usr/bin/python
>>>>> symlink in Debian and I can confirm that it will always point to Python
>>>>> 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
>>>>> only accepted PEP can change that)
>>>>
>>>> Can you please explain why you NACK this proposed change?
>>>
>>> it encourages people to change /usr/bin/python symlink to point to
>>> python3.X which I'm strongly against (how can I tell that upstream
>>> author meant python3.X and not python2.X without checking the code?)
>>
>> with 'people' do you mean 'users'? if so, isn't this risk already present?
>
> users already break their systems via "sudo ez_install ..." (note the
> "sudo" part!), I meant developers (distro and upstream authors).
> If a programmer develops a script in Python 3 on Arch and later ships
> his file with /usr/bin/python in shebang, it's very likely that this
> script will not work on all distributions that didn't (yet?) change the
> symlink.
>
>> If you, user, change the python symlink (provided by python-minimal in
>> Debian) to something else than what's shipped, it's still a local
>> change, and will never be supported; but with python2 *Debian is free*
>> to decide if python can be pointed to python3, if the time will come.
>
> ... and make other distributions developers' life miserable?

But is that not the whole point of adding the /usr/bin/python2 symlink. 
  That way a developer can explicitly use a /usr/bin/python2 or 
/usr/bin/python3 shebang and have it portable everywhere.  At the 
moment, Debian seems to be the major hold-up on that actually being a 
reality being the only major distro I could find that does not provide 
such a symlink.

Note also that even restricting /usr/bin/python to point at a python-2.x 
binary gives no guarantee on what actual python-2.x version you are 
getting, so it is not as if guaranteeing portability is not a problem 
already...

Allan

From fuzzyman at voidspace.org.uk  Wed Mar  2 15:16:46 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 02 Mar 2011 14:16:46 +0000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <69C30191-BB34-4377-AE79-CAE6C3B68357@fuhm.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<69C30191-BB34-4377-AE79-CAE6C3B68357@fuhm.net>
Message-ID: <4D6E514E.3040904@voidspace.org.uk>

On 02/03/2011 14:04, James Y Knight wrote:
> On Mar 2, 2011, at 8:23 AM, Sandro Tosi wrote:
>
>> On Wed, Mar 2, 2011 at 13:56, Piotr O?arowski<piotr at debian.org>  wrote:
>>> [Sandro Tosi, 2011-03-02]
>>>> On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski<piotr at debian.org>  wrote:
>>>>> I co-maintain with Matthias a package that provides /usr/bin/python
>>>>> symlink in Debian and I can confirm that it will always point to Python
>>>>> 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
>>>>> only accepted PEP can change that)
>>>> Can you please explain why you NACK this proposed change?
>>> it encourages people to change /usr/bin/python symlink to point to
>>> python3.X which I'm strongly against (how can I tell that upstream
>>> author meant python3.X and not python2.X without checking the code?)
>> with 'people' do you mean 'users'? if so, isn't this risk already present?
>>
>> If you, user, change the python symlink (provided by python-minimal in
>> Debian) to something else than what's shipped, it's still a local
>> change, and will never be supported; but with python2 *Debian is free*
>> to decide if python can be pointed to python3, if the time will come.
> I suspect he's saying it'd be better if the time didn't come (if so, I'd agree). Python3 *is* unfortunately a new and incompatible programming language,

Only partly true. It's a new version of an existing language that 
introduces backwards incompatible changes. It *isn't* a new language and 
I write code that happily runs under Python 2 (2.4+) and 3.

Michael

>   it makes sense for it to have it have its own interpreter name. Eventually /usr/bin/python might no longer be installed, but that doesn't mean python3 shouldn't simply be called python3 forever.
>
> James
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From piotr at debian.org  Wed Mar  2 15:29:18 2011
From: piotr at debian.org (Piotr =?utf-8?Q?O=C5=BCarowski?=)
Date: Wed, 2 Mar 2011 15:29:18 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6E51A7.6020302@archlinux.org>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
Message-ID: <20110302142918.GO30982@piotro.eu>

[Allan McRae, 2011-03-02]
> But is that not the whole point of adding the /usr/bin/python2 symlink.  
> That way a developer can explicitly use a /usr/bin/python2 or  
> /usr/bin/python3 shebang and have it portable everywhere.  At the moment, 
> Debian seems to be the major hold-up on that actually being a reality 
> being the only major distro I could find that does not provide such a 
> symlink.

Do you realize how many (still perfectly usable) scripts written in
Python 2.x few years ago (and not modified since then) are out there?
Do you realize how much work would it require to fix every single one
of them to point to /usr/bin/python2 instead? Even if we'd start checking
mdate and change it at build time automatically, there still will be way
too many false positives... for no clear gain.
-- 
Piotr O?arowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

From allan at archlinux.org  Wed Mar  2 15:54:11 2011
From: allan at archlinux.org (Allan McRae)
Date: Thu, 03 Mar 2011 00:54:11 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302142918.GO30982@piotro.eu>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>	<20110302140323.GN30982@piotro.eu>
	<4D6E51A7.6020302@archlinux.org> <20110302142918.GO30982@piotro.eu>
Message-ID: <4D6E5A13.5080507@archlinux.org>

On 03/03/11 00:29, Piotr O?arowski wrote:
> [Allan McRae, 2011-03-02]
>> But is that not the whole point of adding the /usr/bin/python2 symlink.
>> That way a developer can explicitly use a /usr/bin/python2 or
>> /usr/bin/python3 shebang and have it portable everywhere.  At the moment,
>> Debian seems to be the major hold-up on that actually being a reality
>> being the only major distro I could find that does not provide such a
>> symlink.
>
> Do you realize how many (still perfectly usable) scripts written in
> Python 2.x few years ago (and not modified since then) are out there?
> Do you realize how much work would it require to fix every single one
> of them to point to /usr/bin/python2 instead? Even if we'd start checking
> mdate and change it at build time automatically, there still will be way
> too many false positives... for no clear gain.

Having made the packages using python-2.x code from an entire 
distribution point at /usr/bin/python2, I have a fair idea of how much 
work is involved...

And that is exactly why changes need made now so that time is available 
for transition.  Providing the /usr/bin/python2 symlink now means that 
any future code would be able to point to it rather than some 
unversioned python binary.  That way in ?? years when python-3.x is 
"the" python and python-2.x is obsolete, and it is decided that 
/usr/bin/python will be python-3.x (which I believe is the only logical 
outcome), then everyone will be a lot more prepared.

Allan

From anikom15 at gmail.com  Wed Mar  2 15:57:59 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Wed, 02 Mar 2011 06:57:59 -0800
Subject: [Python-Dev] contributors survey?
In-Reply-To: <20110302130805.3ca921fc@pitrou.net>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
	<20110302130805.3ca921fc@pitrou.net>
Message-ID: <1299077879.29197.2.camel@localhost.localdomain>

On Wed, 2011-03-02 at 13:08 +0100, Antoine Pitrou wrote:
> Hello,
> 
> On Tue, 01 Mar 2011 19:25:00 -0800
> Westley Mart?nez <anikom15 at gmail.com> wrote:
> > 
> > If I got a message like that in my mailbox I would be rather annoyed,
> > mark it as spam, and be less likely to contribute again.
> 
> Yes, I think that's a risk. Do you think of a wording that could
> alleviate such perception?
> 
> Thank you
> 
> Antoine.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/anikom15%40gmail.com

No. Python is a voluntary effort; I think it would be in the best
interest to keep it as such. If there's a fundamental flaw in the way
the community does something, it will heal itself.


From jnoller at gmail.com  Wed Mar  2 16:00:10 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 2 Mar 2011 10:00:10 -0500
Subject: [Python-Dev] contributors survey?
In-Reply-To: <20110302130717.1d9d8787@pitrou.net>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
	<20110301233238.3ef4b05f@pitrou.net>
	<AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>
	<1299019547.3709.18.camel@localhost.localdomain>
	<20110302033400.GA31811@kevin>
	<AANLkTimHAoXrr_V7fMsdpo0sqXXfvE4HNzKmF7pfmsx4@mail.gmail.com>
	<20110302130717.1d9d8787@pitrou.net>
Message-ID: <AANLkTikeB1FbrxnqR0q1bEKxFZkZD0P96oKgWy5Qd2GM@mail.gmail.com>

On Wed, Mar 2, 2011 at 7:07 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 1 Mar 2011 20:43:27 -0800
> Guido van Rossum <guido at python.org> wrote:
>>
>> But I wouldn't be surprised if some people had regrets about the way
>> the community works (I can recall at least one such case) and it would
>> be useful to learn from those occasions, if they'll let us. And the
>> numbers might tell us something, too.
>
> Yes, that's the kind of things that would be good to hear about IMO.
> It's obvious that in some cases patches and reports go simply
> unanswered for years, and in these cases a first-time reporter or
> contributor won't bother again (who would?).
> But I wonder if there are other social or technical factors, such as
> the community being too intimidating or not welcoming enough.
>
> Actually, if some python-dev readers have something to say about that,
> they are welcome :)

FWIW, Here's some feedback I got from the community awhile ago - not
all of the respondents are ex contributors, but rather this is a
general "why don't you contribute" question. I've still not had the
time to internalize it, other then to pester Brett to work on the dev
docs.

http://jessenoller.com/2010/04/22/why-arent-you-contributing-to-python/
http://news.ycombinator.com/item?id=1285897
http://www.reddit.com/r/Python/comments/burio/why_arent_you_contributing_to_python/

It's worth a good read-through. I got a lot of private emails all in
the same tone. Speed of turn around, push back from entrenched
developers turning off new contributors, etc.

Jesse

From jnoller at gmail.com  Wed Mar  2 16:01:59 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 2 Mar 2011 10:01:59 -0500
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTikeB1FbrxnqR0q1bEKxFZkZD0P96oKgWy5Qd2GM@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
	<20110301233238.3ef4b05f@pitrou.net>
	<AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>
	<1299019547.3709.18.camel@localhost.localdomain>
	<20110302033400.GA31811@kevin>
	<AANLkTimHAoXrr_V7fMsdpo0sqXXfvE4HNzKmF7pfmsx4@mail.gmail.com>
	<20110302130717.1d9d8787@pitrou.net>
	<AANLkTikeB1FbrxnqR0q1bEKxFZkZD0P96oKgWy5Qd2GM@mail.gmail.com>
Message-ID: <AANLkTin-qo7LC5G5z4Uct-sd-gZKQhHEYJ0USX2GZCR4@mail.gmail.com>

On Wed, Mar 2, 2011 at 10:00 AM, Jesse Noller <jnoller at gmail.com> wrote:
> On Wed, Mar 2, 2011 at 7:07 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Tue, 1 Mar 2011 20:43:27 -0800
>> Guido van Rossum <guido at python.org> wrote:
>>>
>>> But I wouldn't be surprised if some people had regrets about the way
>>> the community works (I can recall at least one such case) and it would
>>> be useful to learn from those occasions, if they'll let us. And the
>>> numbers might tell us something, too.
>>
>> Yes, that's the kind of things that would be good to hear about IMO.
>> It's obvious that in some cases patches and reports go simply
>> unanswered for years, and in these cases a first-time reporter or
>> contributor won't bother again (who would?).
>> But I wonder if there are other social or technical factors, such as
>> the community being too intimidating or not welcoming enough.
>>
>> Actually, if some python-dev readers have something to say about that,
>> they are welcome :)
>
> FWIW, Here's some feedback I got from the community awhile ago - not
> all of the respondents are ex contributors, but rather this is a
> general "why don't you contribute" question. I've still not had the
> time to internalize it, other then to pester Brett to work on the dev
> docs.
>
> http://jessenoller.com/2010/04/22/why-arent-you-contributing-to-python/
> http://news.ycombinator.com/item?id=1285897
> http://www.reddit.com/r/Python/comments/burio/why_arent_you_contributing_to_python/
>
> It's worth a good read-through. I got a lot of private emails all in
> the same tone. Speed of turn around, push back from entrenched
> developers turning off new contributors, etc.
>
> Jesse
>

Let me point out, in a positive light, that the feedback from the
above is what triggered me to drive the PSF Sprints project
(http://pythonsprints.com/) at the board/PSF level.

From foom at fuhm.net  Wed Mar  2 16:13:59 2011
From: foom at fuhm.net (James Y Knight)
Date: Wed, 2 Mar 2011 10:13:59 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6E5A13.5080507@archlinux.org>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>	<20110302140323.GN30982@piotro.eu>
	<4D6E51A7.6020302@archlinux.org> <20110302142918.GO30982@piotro.eu>
	<4D6E5A13.5080507@archlinux.org>
Message-ID: <E1472717-8C04-4AAB-8BF3-9606FCB68B9F@fuhm.net>

On Mar 2, 2011, at 9:54 AM, Allan McRae wrote:
> That way in ?? years when python-3.x is "the" python and python-2.x is obsolete, and it is decided that /usr/bin/python will be python-3.x (which I believe is the only logical outcome), 

But that's not the only logical outcome. A perfectly logical outcome is that /usr/bin/python disappears completely if python2.X isn't installed, and python3 is always called python3. That is the outcome I find sensible. And that is the crux of the disagreement in this thread. 


Those who think python3.X should stay /usr/bin/python3 forever do not see any reason to make everyone rewrite their existing python scripts to say "/usr/bin/python2" instead of "/usr/bin/python". So, there's no point in adding a /usr/bin/python2 now. Scripts that want python2 can remain using /usr/bin/python forever, and that will either be installed, or not installed, depending on whether that OS has a copy of python2.X.

Those who think python3 should (eventually someday, or maybe immediately, depending) be named or have an alias of "/usr/bin/python" want to make everyone rewrite their scripts to say /usr/bin/python2 now. For that position, it's unfortunate that python source doesn't install itself with an alias of /usr/bin/python2, and some distros don't install that alias either. So they want to fix that.

James

From piotr at debian.org  Wed Mar  2 16:20:03 2011
From: piotr at debian.org (Piotr =?utf-8?Q?O=C5=BCarowski?=)
Date: Wed, 2 Mar 2011 16:20:03 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6E5A13.5080507@archlinux.org>
References: <AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu> <4D6E5A13.5080507@archlinux.org>
Message-ID: <20110302152003.GP30982@piotro.eu>

[Allan McRae, 2011-03-02]
> Having made the packages using python-2.x code from an entire  
> distribution point at /usr/bin/python2, I have a fair idea of how much  
> work is involved...

* is every Arch package that uses Python 2.X already working with
  /usr/bin/python and why not? ;-)
* how many Python packages do Arch have in the first place and why so
  little? ;-)
* how does Arch deal with scripts that are not packaged, what do you say
  to users who report bugs against your packages because their local
  scripts do not work anymore? :-|
-- 
Piotr O?arowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

From jerome.radix at gmail.com  Wed Mar  2 16:23:48 2011
From: jerome.radix at gmail.com (=?ISO-8859-1?B?Suly9G1lIFJhZGl4?=)
Date: Wed, 2 Mar 2011 16:23:48 +0100
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTin-qo7LC5G5z4Uct-sd-gZKQhHEYJ0USX2GZCR4@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTinUCbQECQqUtQf=Db4ykgc5P470jz532Pyapg=S@mail.gmail.com>
	<20110301233238.3ef4b05f@pitrou.net>
	<AANLkTikQnpaa_5e1FW43mb=5-uMsmsLV9a7GcvVHGCg4@mail.gmail.com>
	<1299019547.3709.18.camel@localhost.localdomain>
	<20110302033400.GA31811@kevin>
	<AANLkTimHAoXrr_V7fMsdpo0sqXXfvE4HNzKmF7pfmsx4@mail.gmail.com>
	<20110302130717.1d9d8787@pitrou.net>
	<AANLkTikeB1FbrxnqR0q1bEKxFZkZD0P96oKgWy5Qd2GM@mail.gmail.com>
	<AANLkTin-qo7LC5G5z4Uct-sd-gZKQhHEYJ0USX2GZCR4@mail.gmail.com>
Message-ID: <AANLkTi=jTMCPB2mt76CZasFEdHV3uLXkT993EwWm1fCq@mail.gmail.com>

It seems that there are two kinds of developers (ok, it's over-generalized)
:

1- the ones that have a problem with python and file bugs into the issue
trackers : they don't try to search for solutions, they want core-developers
to check and correct their bugs. The motivation for these developers are
that they have a problem to solve. They do a great job finding tricky
problems.

2- the ones that try to reproduce bugs filed into the issue tracker, that
try to create patches : the motivation for these developers are that they
"love" python, they "love" to solve problems and learn about the python
language details. These are generally the ones that participate to events
like hackathons, bug days...

IMHO, what python misses the most are developers of the second category. A
solution would be to organize and promote this second category of developers
in order to grow their number.

J?r?me.

2011/3/2 Jesse Noller <jnoller at gmail.com>

> On Wed, Mar 2, 2011 at 10:00 AM, Jesse Noller <jnoller at gmail.com> wrote:
> > On Wed, Mar 2, 2011 at 7:07 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> >> On Tue, 1 Mar 2011 20:43:27 -0800
> >> Guido van Rossum <guido at python.org> wrote:
> >>>
> >>> But I wouldn't be surprised if some people had regrets about the way
> >>> the community works (I can recall at least one such case) and it would
> >>> be useful to learn from those occasions, if they'll let us. And the
> >>> numbers might tell us something, too.
> >>
> >> Yes, that's the kind of things that would be good to hear about IMO.
> >> It's obvious that in some cases patches and reports go simply
> >> unanswered for years, and in these cases a first-time reporter or
> >> contributor won't bother again (who would?).
> >> But I wonder if there are other social or technical factors, such as
> >> the community being too intimidating or not welcoming enough.
> >>
> >> Actually, if some python-dev readers have something to say about that,
> >> they are welcome :)
> >
> > FWIW, Here's some feedback I got from the community awhile ago - not
> > all of the respondents are ex contributors, but rather this is a
> > general "why don't you contribute" question. I've still not had the
> > time to internalize it, other then to pester Brett to work on the dev
> > docs.
> >
> > http://jessenoller.com/2010/04/22/why-arent-you-contributing-to-python/
> > http://news.ycombinator.com/item?id=1285897
> >
> http://www.reddit.com/r/Python/comments/burio/why_arent_you_contributing_to_python/
> >
> > It's worth a good read-through. I got a lot of private emails all in
> > the same tone. Speed of turn around, push back from entrenched
> > developers turning off new contributors, etc.
> >
> > Jesse
> >
>
> Let me point out, in a positive light, that the feedback from the
> above is what triggered me to drive the PSF Sprints project
> (http://pythonsprints.com/) at the board/PSF level.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jerome.radix%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/d375afd2/attachment.html>

From ncoghlan at gmail.com  Wed Mar  2 16:46:15 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 3 Mar 2011 01:46:15 +1000
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTi=GBbci+vbPiWxpfyJbQqMdkrDgH-seX9s52yHX@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
	<20110302130805.3ca921fc@pitrou.net>
	<AANLkTinmN_1JbG0XsqH_a=EvUSbiQS3crarHCdHqD-8i@mail.gmail.com>
	<20110302133957.22d36065@pitrou.net>
	<AANLkTikh9ETJUFAEfA46AsL7KpuDY+Z4AH2=CjS2i6GE@mail.gmail.com>
	<AANLkTi=GBbci+vbPiWxpfyJbQqMdkrDgH-seX9s52yHX@mail.gmail.com>
Message-ID: <AANLkTimtt14YvoTCDXK8TT+dodqTCB_f7BOzeL-PN+a_@mail.gmail.com>

On Wed, Mar 2, 2011 at 11:10 PM, Mark Smith
<mark.smith at practicalpoetry.co.uk> wrote:
> The following is going to sound bitter...
> I was fired with enthusiasm for working on Python after the sprints at
> EuroPython last year. I submitted 3 (I think) patches for pulldom - a test
> suite (it has 0% code coverage at present), documentation for the module
> (there isn't any at present), and a patch deprecating a function that is
> broken. They're all still open, and the patches are getting staler by the
> month.
> The point of this level of detail is: I was new to the project; I submitted
> some relatively uncomplicated patches that trivially, visibly, and (mostly)
> uncontroversially improve Python - one of them was a /documentation/ patch.
> Then nothing happened, apart from the odd comment from people who commented
> on the tickets - and I responded to their queries. So now I'm of the opinion
> that it's not worth submitting patches to the Python project at all, because
> they'll never be accepted. I'll dedicate my time to something else instead.
> Mercurial /will/ make it easier to contribute code, but if it doesn't get
> accepted into a release branch, then that makes no real difference to me.
> Seriously guys - fix the issue lifecycle; I'll come back.

I think a key point in your experience there is that contributing on
orphaned modules can be *really* hard, because it is difficult to find
a committer that feels qualified to accept it. That's a serious
chicken-and-egg problem, because someone needs to contribute in order
for the existing core developers to gain confidence in their
abilities, but if the components they're interested in are
comparatively unmaintained, their contributions may not be accepted
due to a lack of a capable reviewer...

I know there's a patch that has been sitting on the tracker for ages
that gave the mimetools module some love, and was generally a positive
change, but needed someone with the expertise to really pick it apart
and figure out which elements were acceptable from a backwards
compatibility point of view, and which needed to be dropped and/or
turned into feature requests. I was able to highlight a few problem
areas, but it really needed a fresh set of eyes that was more familiar
with mimetools than I am, but also more familiar with the standard
library development life cycle than the patch contributor.

In contrast, particularly with the triage folks on the tracker doing
such good work, patches to actively maintained modules are far more
likely to get some decent consideration from the relevant maintainer.
There have been a few cases of folks being granted commit access to
work on previously orphaned modules (e.g. Lars with tarfile), but I'm
not sure what we can do about that problem more generally.

So perhaps a question we should be focusing on is how we might go
about getting better module coverage in the first table at
http://docs.python.org/devguide/experts

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Mar  2 16:48:10 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 3 Mar 2011 01:48:10 +1000
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTimtt14YvoTCDXK8TT+dodqTCB_f7BOzeL-PN+a_@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
	<20110302130805.3ca921fc@pitrou.net>
	<AANLkTinmN_1JbG0XsqH_a=EvUSbiQS3crarHCdHqD-8i@mail.gmail.com>
	<20110302133957.22d36065@pitrou.net>
	<AANLkTikh9ETJUFAEfA46AsL7KpuDY+Z4AH2=CjS2i6GE@mail.gmail.com>
	<AANLkTi=GBbci+vbPiWxpfyJbQqMdkrDgH-seX9s52yHX@mail.gmail.com>
	<AANLkTimtt14YvoTCDXK8TT+dodqTCB_f7BOzeL-PN+a_@mail.gmail.com>
Message-ID: <AANLkTin5COL+iRc3oQ5GbOJUDjywiTBhpgOeKjhgChwW@mail.gmail.com>

On Thu, Mar 3, 2011 at 1:46 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I know there's a patch that has been sitting on the tracker for ages
> that gave the mimetools module some love

s/mimetools/mimetypes/

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Mar  2 16:54:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 3 Mar 2011 01:54:17 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302152003.GP30982@piotro.eu>
References: <AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu> <4D6E5A13.5080507@archlinux.org>
	<20110302152003.GP30982@piotro.eu>
Message-ID: <AANLkTimROmiCUczRPR5KnTBnfKMbUd9KkZwYKf-3km8q@mail.gmail.com>

/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)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From rdmurray at bitdance.com  Wed Mar  2 17:05:03 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 02 Mar 2011 11:05:03 -0500
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTi=GBbci+vbPiWxpfyJbQqMdkrDgH-seX9s52yHX@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
	<20110302130805.3ca921fc@pitrou.net>
	<AANLkTinmN_1JbG0XsqH_a=EvUSbiQS3crarHCdHqD-8i@mail.gmail.com>
	<20110302133957.22d36065@pitrou.net>
	<AANLkTikh9ETJUFAEfA46AsL7KpuDY+Z4AH2=CjS2i6GE@mail.gmail.com>
	<AANLkTi=GBbci+vbPiWxpfyJbQqMdkrDgH-seX9s52yHX@mail.gmail.com>
Message-ID: <20110302160504.146D8241727@kimball.webabinitio.net>

On Wed, 02 Mar 2011 13:10:04 +0000, Mark Smith <mark.smith at practicalpoetry.co.uk> wrote:
> The following is going to sound bitter...
> 
> I was fired with enthusiasm for working on Python after the sprints at
> EuroPython last year. I submitted 3 (I think) patches for pulldom - a test
> suite (it has 0% code coverage at present), documentation for the module
> (there isn't any at present), and a patch deprecating a function that is
> broken. They're all still open, and the patches are getting staler by the
> month.
> 
> The point of this level of detail is: I was new to the project; I submitted
> some relatively uncomplicated patches that trivially, visibly, and (mostly)
> uncontroversially improve Python - one of them was a /documentation/ patch.
> Then nothing happened, apart from the odd comment from people who commented
> on the tickets - and I responded to their queries. So now I'm of the opinion
> that it's not worth submitting patches to the Python project at all, because
> they'll never be accepted. I'll dedicate my time to something else instead.
> 
> Mercurial /will/ make it easier to contribute code, but if it doesn't get
> accepted into a release branch, then that makes no real difference to me.
> 
> Seriously guys - fix the issue lifecycle; I'll come back.

After running a core sprint at PyOhio I realized that one thing that is
*seriously* needed is more followup after a sprint (and probably after
bug days as well).  I didn't gather the information at the sprint that
I would have needed to do that followup (who exactly did submit patches
during the sprint and which patches?).

I'd like to suggest that we collect such information one way or another
for the PyCon sprint, and pay special attention to those patches in the
weeks following PyCon.

The other issue with the pulldom patches, Mark, is that unfortunately
you fell into one of the black holes:  I don't think there are any active
committers who know much, if anything, about pulldom.

As with everything else, it comes down to lack of people hours.  People pay
attention to what interests them, and some attention to other stuff,
and there aren't enough people for that "some attention to other stuff"
to cover all the patches that are submitted.

There are probably ways to improve patch lifecycle management, but I don't
think there is any *fix* other than more people.  So, doing followup after
sprints/bug days to help keep contributor enthusiasm going and get some of
them converted into committers is perhaps the best "fix" we could apply.
Of course, doing that followup requires people-time.......

--
R. David Murray                                      www.bitdance.com

From rdmurray at bitdance.com  Wed Mar  2 17:42:21 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 02 Mar 2011 11:42:21 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <E1472717-8C04-4AAB-8BF3-9606FCB68B9F@fuhm.net>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu> <4D6E5A13.5080507@archlinux.org>
	<E1472717-8C04-4AAB-8BF3-9606FCB68B9F@fuhm.net>
Message-ID: <20110302164221.D7581249C23@kimball.webabinitio.net>

On Wed, 02 Mar 2011 10:13:59 -0500, James Y Knight <foom at fuhm.net> wrote:
> On Mar 2, 2011, at 9:54 AM, Allan McRae wrote:
> > That way in ?? years when python-3.x is "the" python and python-2.x
> > is obsolete, and it is decided that /usr/bin/python will be
> > python-3.x (which I believe is the only logical outcome), 
> 
> But that's not the only logical outcome. A perfectly logical outcome
> is that /usr/bin/python disappears completely if python2.X isn't
> installed, and python3 is always called python3. That is the outcome I
> find sensible. And that is the crux of the disagreement in this
> thread.

Well, I personally won't use a distribution that makes this choice.
For whatever that's worth :)

But, even if a distribution *does* make that choice, if it wants to
be compatible with code developed on distributions that make
the other choice, it should provide a /usr/bin/python2 symlink.
Otherwise, it is going to be getting bug reports from users asking
why XYZ script doesn't run.

In short, I don't see any *downside* to providing a /usr/bin/python2
symlink.

--
R. David Murray                                      www.bitdance.com

From barry at python.org  Wed Mar  2 18:14:39 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 2 Mar 2011 12:14:39 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302142918.GO30982@piotro.eu>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu>
Message-ID: <20110302121439.09486f98@limelight.wooz.org>

On Mar 02, 2011, at 03:29 PM, Piotr O?arowski wrote:

>[Allan McRae, 2011-03-02]
>> But is that not the whole point of adding the /usr/bin/python2 symlink.  
>> That way a developer can explicitly use a /usr/bin/python2 or  
>> /usr/bin/python3 shebang and have it portable everywhere.  At the moment, 
>> Debian seems to be the major hold-up on that actually being a reality 
>> being the only major distro I could find that does not provide such a 
>> symlink.
>
>Do you realize how many (still perfectly usable) scripts written in
>Python 2.x few years ago (and not modified since then) are out there?
>Do you realize how much work would it require to fix every single one
>of them to point to /usr/bin/python2 instead? Even if we'd start checking
>mdate and change it at build time automatically, there still will be way
>too many false positives... for no clear gain.

There's no need to require that change.  In Debian, /usr/bin/python can
continue point to python2 for a very long time.

I don't have a problem with adding such a symlink, and I think it should be
done by Informational PEP, not Standards Track PEP.  Since there will be no
Python 2.8, our own build system shouldn't ever be changed to add such a link,
but we can recommend it for consistency among distros, which would be free to
adopt it or not.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/671ee020/attachment.pgp>

From guido at python.org  Wed Mar  2 19:03:27 2011
From: guido at python.org (Guido van Rossum)
Date: Wed, 2 Mar 2011 10:03:27 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302125641.GM30982@piotro.eu>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
Message-ID: <AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>

On Wed, Mar 2, 2011 at 4:56 AM, Piotr O?arowski <piotr at debian.org> wrote:
> [Sandro Tosi, 2011-03-02]
>> On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski <piotr at debian.org> wrote:
>> > I co-maintain with Matthias a package that provides /usr/bin/python
>> > symlink in Debian and I can confirm that it will always point to Python
>> > 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
>> > only accepted PEP can change that)
>>
>> Can you please explain why you NACK this proposed change?
>
> it encourages people to change /usr/bin/python symlink to point to
> python3.X which I'm strongly against (how can I tell that upstream
> author meant python3.X and not python2.X without checking the code?)

But the same is already true for python2.X vs. python2.Y. Explicit is
better than implicit etc. Plus, 5 years from now everybody is going to
be annoyed that "python" still refers to some ancient unused version
of Python.

If it takes a PEP to change your position, let's write the PEP.

-- 
--Guido van Rossum (python.org/~guido)

From steve at pearwood.info  Wed Mar  2 20:35:01 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Thu, 03 Mar 2011 06:35:01 +1100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikTfOyGoTkEx=A6jB1-meQ2=_i822f9L3GMOFVA@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<AANLkTikTfOyGoTkEx=A6jB1-meQ2=_i822f9L3GMOFVA@mail.gmail.com>
Message-ID: <4D6E9BE5.6020501@pearwood.info>

J?r?me Radix wrote:
> Hello,
> 
> Defensive programming will force you to do things like :
> 
> import sys
> if sys.version[0] == '2':


Really? Do you already do this?

if sys.version < '2.2':
     result = apply(func, arguments)
else:
     result = func(*arguments)


And if so, have you tested it in Python 1.5 to see what happens?



-- 
Steven

From foom at fuhm.net  Wed Mar  2 20:49:14 2011
From: foom at fuhm.net (James Y Knight)
Date: Wed, 2 Mar 2011 14:49:14 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302121439.09486f98@limelight.wooz.org>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu>
	<20110302121439.09486f98@limelight.wooz.org>
Message-ID: <5F730AA7-4866-4081-8092-2C884F9D8D86@fuhm.net>

On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote:
> I don't have a problem with adding such a symlink, and I think it should be
> done by Informational PEP, not Standards Track PEP.  Since there will be no
> Python 2.8, our own build system shouldn't ever be changed to add such a link,
> but we can recommend it for consistency among distros, which would be free to
> adopt it or not.

Why not? 2.7 is supposed to be in long term maintenance mode. Surely if it's a good idea for everyone else to ship a python2 binary, 2.7.next should also install it when building from source...

James

From foom at fuhm.net  Wed Mar  2 20:54:24 2011
From: foom at fuhm.net (James Y Knight)
Date: Wed, 2 Mar 2011 14:54:24 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302164221.D7581249C23@kimball.webabinitio.net>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu> <4D6E5A13.5080507@archlinux.org>
	<E1472717-8C04-4AAB-8BF3-9606FCB68B9F@fuhm.net>
	<20110302164221.D7581249C23@kimball.webabinitio.net>
Message-ID: <1A8F8AAC-4C88-44BC-BF68-EC70177E8D85@fuhm.net>

On Mar 2, 2011, at 11:42 AM, R. David Murray wrote:
> Well, I personally won't use a distribution that makes this choice.
> For whatever that's worth :)

This ***shouldn't*** be a choice distros have to make. There should be a standard upstream recommended way to install python, and that's also what "make install" should do. That distros are having to make a choice here is a problem in communication from python core developers -- it sucks that we've gotten this far without consensus on a proper transition plan for moving from Python 2.X to Python 3.X.

James

From steve at pearwood.info  Wed Mar  2 21:16:30 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Thu, 03 Mar 2011 07:16:30 +1100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <69C30191-BB34-4377-AE79-CAE6C3B68357@fuhm.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<69C30191-BB34-4377-AE79-CAE6C3B68357@fuhm.net>
Message-ID: <4D6EA59E.2090403@pearwood.info>

James Y Knight wrote:

> I suspect he's saying it'd be better if the time didn't come (if so,
> I'd agree). Python3 *is* unfortunately a new and incompatible
> programming language, it makes sense for it to have it have its own
> interpreter name. 


Oh come on, there's like three incompatibilities versus three thousand 
things that are compatible. A pox on your discontinuous mind! *wink*

Seriously, most of the changes are library changes, not language 
changes. The similarities far outweigh the differences. I don't think 
there is a generally agreed upon objective boundary between "dialect" 
and "language", but to my mind the change between 2.x and 3.x falls 
squarely under "dialect".

In the same way, I don't care that William Shakespeare's everyday speech 
would be nearly incomprehensible to my ears, and mine to his, we both 
speak (spoke?) English.

In my opinion, the biggest change from Python 2 -> 3 is that we actually 
provide developers tools for migrating scripts rather than leave it for 
them to deal with the changes themselves. I recently ported a client's 
application written for 2.3 that used string exceptions everywhere to 
2.6. I would have loved a "2.3to2.6" fixer :) I don't consider 2.3 and 
2.6 to be different languages, and I suspect neither do you, even though 
code that runs fine without even a warning under one raises a 
SyntaxError under the other.

Every time we drop or rename a module from the standard library, we 
break scripts. Such backwards incompatibility is not enough to delineate 
different languages. Even syntax changes are not necessarily enough.


> Eventually /usr/bin/python might no longer be
> installed, but that doesn't mean python3 shouldn't simply be called
> python3 forever.

I already call Python 3 "python" in casual conversation. There is *no 
way* that I will be calling it "python3" in fifteen years time, when 
Python 2.7 is as dead and forgotten as Python 1.5 is now, just to 
satisfy some overly strict definition of "different language".



-- 
Steven

From barry at python.org  Wed Mar  2 21:18:38 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 2 Mar 2011 15:18:38 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <5F730AA7-4866-4081-8092-2C884F9D8D86@fuhm.net>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu>
	<20110302121439.09486f98@limelight.wooz.org>
	<5F730AA7-4866-4081-8092-2C884F9D8D86@fuhm.net>
Message-ID: <20110302151838.288d03bd@limelight.wooz.org>

On Mar 02, 2011, at 02:49 PM, James Y Knight wrote:

>On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote:
>> I don't have a problem with adding such a symlink, and I think it should be
>> done by Informational PEP, not Standards Track PEP.  Since there will be no
>> Python 2.8, our own build system shouldn't ever be changed to add such a link,
>> but we can recommend it for consistency among distros, which would be free to
>> adopt it or not.
>
>Why not? 2.7 is supposed to be in long term maintenance mode. Surely if it's
>a good idea for everyone else to ship a python2 binary, 2.7.next should also
>install it when building from source...

Seems like it's straying into new feature territory to me, but then I'm not
the 2.7 RM.  OTOH, if it really does help Python 3 adoption, it might be worth it.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/81ba0e02/attachment.pgp>

From steve at pearwood.info  Wed Mar  2 21:20:27 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Thu, 03 Mar 2011 07:20:27 +1100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6E9BE5.6020501@pearwood.info>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>	<AANLkTikTfOyGoTkEx=A6jB1-meQ2=_i822f9L3GMOFVA@mail.gmail.com>
	<4D6E9BE5.6020501@pearwood.info>
Message-ID: <4D6EA68B.1000003@pearwood.info>

Steven D'Aprano wrote:
> J?r?me Radix wrote:
>> Hello,
>>
>> Defensive programming will force you to do things like :
>>
>> import sys
>> if sys.version[0] == '2':
> 
> 
> Really? Do you already do this?
> 
> if sys.version < '2.2':
>     result = apply(func, arguments)
> else:
>     result = func(*arguments)
> 
> 
> And if so, have you tested it in Python 1.5 to see what happens?

Sorry, that reads harsher than I intended. Please insert a wink and a 
smiley.



-- 
Steven

From martin at v.loewis.de  Wed Mar  2 23:04:53 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Mar 2011 23:04:53 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <5F730AA7-4866-4081-8092-2C884F9D8D86@fuhm.net>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>	<20110302140323.GN30982@piotro.eu>
	<4D6E51A7.6020302@archlinux.org>	<20110302142918.GO30982@piotro.eu>	<20110302121439.09486f98@limelight.wooz.org>
	<5F730AA7-4866-4081-8092-2C884F9D8D86@fuhm.net>
Message-ID: <4D6EBF05.7030607@v.loewis.de>

Am 02.03.2011 20:49, schrieb James Y Knight:
> On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote:
>> I don't have a problem with adding such a symlink, and I think it
>> should be done by Informational PEP, not Standards Track PEP.
>> Since there will be no Python 2.8, our own build system shouldn't
>> ever be changed to add such a link, but we can recommend it for
>> consistency among distros, which would be free to adopt it or not.
> 
> Why not? 2.7 is supposed to be in long term maintenance mode. Surely
> if it's a good idea for everyone else to ship a python2 binary,
> 2.7.next should also install it when building from source...

I agree with Barry that this would be a new feature, and, by default,
cannot be added to the 2.7 release which is in maintenance mode.

IMO, an accepted PEP could override the policy, though.

Regards,
Martin

From foom at fuhm.net  Wed Mar  2 23:31:48 2011
From: foom at fuhm.net (James Y Knight)
Date: Wed, 2 Mar 2011 17:31:48 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6EBF05.7030607@v.loewis.de>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>	<20110302140323.GN30982@piotro.eu>
	<4D6E51A7.6020302@archlinux.org>	<20110302142918.GO30982@piotro.eu>	<20110302121439.09486f98@limelight.wooz.org>
	<5F730AA7-4866-4081-8092-2C884F9D8D86@fuhm.net>
	<4D6EBF05.7030607@v.loewis.de>
Message-ID: <4AD0188C-6786-472E-8123-D58A92A07F7C@fuhm.net>


On Mar 2, 2011, at 5:04 PM, Martin v. L?wis wrote:

> Am 02.03.2011 20:49, schrieb James Y Knight:
>> On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote:
>>> I don't have a problem with adding such a symlink, and I think it
>>> should be done by Informational PEP, not Standards Track PEP.
>>> Since there will be no Python 2.8, our own build system shouldn't
>>> ever be changed to add such a link, but we can recommend it for
>>> consistency among distros, which would be free to adopt it or not.
>> 
>> Why not? 2.7 is supposed to be in long term maintenance mode. Surely
>> if it's a good idea for everyone else to ship a python2 binary,
>> 2.7.next should also install it when building from source...
> 
> I agree with Barry that this would be a new feature, and, by default,
> cannot be added to the 2.7 release which is in maintenance mode.
> 
> IMO, an accepted PEP could override the policy, though.

That sounds like an entirely reasonable position to take.

All the more reason for someone who's in favor of python3 being called "python" in the future to write the PEP outlining how to ease the transition by providing a "python2" link now.

James

From jerome.radix at gmail.com  Wed Mar  2 23:36:07 2011
From: jerome.radix at gmail.com (=?ISO-8859-1?B?Suly9G1lIFJhZGl4?=)
Date: Wed, 2 Mar 2011 23:36:07 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6EA68B.1000003@pearwood.info>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<AANLkTikTfOyGoTkEx=A6jB1-meQ2=_i822f9L3GMOFVA@mail.gmail.com>
	<4D6E9BE5.6020501@pearwood.info> <4D6EA68B.1000003@pearwood.info>
Message-ID: <AANLkTindOayE7S6EMKbXfJwVf+P_-Tn3oh++OgqV5J6m@mail.gmail.com>

No, I don't do it now. But taking like granted the fact that 2.x python will
be dead in 5 years and that /usr/bin/python will point to python3 is, imho,
a little too optimistic. Thus, as time passes, python scripts will have to
guess if they are running through python3 or python2 because the two will be
installed on most systems, with no strict convention on how to run a 2.x
python script or a 3.x python script.

/usr/bin/python is meant to point to python3 one time or another. The time
will never be the same for all distros.

And, yes, people are already testing python version in their
scripts<http://www.google.com/search?q=python+version+test+site%3Astackoverflow.com&ie=utf-8>
.

As a matter of fact, they've already had this kind of discussion for Perl :
they use require <http://perldoc.perl.org/functions/require.html>.


J?r?me.


2011/3/2 Steven D'Aprano <steve at pearwood.info>

> Steven D'Aprano wrote:
>
>> J?r?me Radix wrote:
>>
>>> Hello,
>>>
>>> Defensive programming will force you to do things like :
>>>
>>> import sys
>>> if sys.version[0] == '2':
>>>
>>
>>
>> Really? Do you already do this?
>>
>> if sys.version < '2.2':
>>    result = apply(func, arguments)
>> else:
>>    result = func(*arguments)
>>
>>
>> And if so, have you tested it in Python 1.5 to see what happens?
>>
>
> Sorry, that reads harsher than I intended. Please insert a wink and a
> smiley.
>
>
>
>
> --
> Steven
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jerome.radix%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/14888bae/attachment.html>

From martin at v.loewis.de  Thu Mar  3 00:00:54 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Mar 2011 00:00:54 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTindOayE7S6EMKbXfJwVf+P_-Tn3oh++OgqV5J6m@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>	<AANLkTikTfOyGoTkEx=A6jB1-meQ2=_i822f9L3GMOFVA@mail.gmail.com>	<4D6E9BE5.6020501@pearwood.info>
	<4D6EA68B.1000003@pearwood.info>
	<AANLkTindOayE7S6EMKbXfJwVf+P_-Tn3oh++OgqV5J6m@mail.gmail.com>
Message-ID: <4D6ECC26.3090105@v.loewis.de>

Am 02.03.2011 23:36, schrieb J?r?me Radix:
> No, I don't do it now. But taking like granted the fact that 2.x python
> will be dead in 5 years and that /usr/bin/python will point to python3
> is, imho, a little too optimistic.

I don't think Steven said, or assumed, a scope of 5 years - more like
a scope of 30 years. In 30 years, Python 2 will surely be dead (as
will likely be Python 3).

The defensive programming you promote is likely to fail. Many Python 2
scripts are syntactically invalid when interpreted as Python 3, so a
version test won't even be executed.

With separate python2 and python3 executables, people can have scripts
depend on the right binary.

In interactive mode, I would like to use /usr/bin/python be the
"current" Python binary always (even when Python 4.6 comes along).
Python will, interactively, greet me with its version number, and I
can adjust. So the idea of /usr/bin/python being reserved for Python 2
strikes me as inconvenient.

Regards,
Martin

From anikom15 at gmail.com  Thu Mar  3 00:35:24 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Wed, 02 Mar 2011 15:35:24 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110302152003.GP30982@piotro.eu>
References: <AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu> <4D6E5A13.5080507@archlinux.org>
	<20110302152003.GP30982@piotro.eu>
Message-ID: <1299108924.29197.5.camel@localhost.localdomain>

On Wed, 2011-03-02 at 16:20 +0100, Piotr O?arowski wrote:
> [Allan McRae, 2011-03-02]
> > Having made the packages using python-2.x code from an entire  
> > distribution point at /usr/bin/python2, I have a fair idea of how much  
> > work is involved...
> 
> * is every Arch package that uses Python 2.X already working with
>   /usr/bin/python and why not? ;-)
> * how many Python packages do Arch have in the first place and why so
>   little? ;-)
> * how does Arch deal with scripts that are not packaged, what do you say
>   to users who report bugs against your packages because their local
>   scripts do not work anymore? :-|

Is that a silver spoon in your mouth?


From guido at python.org  Thu Mar  3 00:49:00 2011
From: guido at python.org (Guido van Rossum)
Date: Wed, 2 Mar 2011 15:49:00 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6ECC26.3090105@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<AANLkTikTfOyGoTkEx=A6jB1-meQ2=_i822f9L3GMOFVA@mail.gmail.com>
	<4D6E9BE5.6020501@pearwood.info> <4D6EA68B.1000003@pearwood.info>
	<AANLkTindOayE7S6EMKbXfJwVf+P_-Tn3oh++OgqV5J6m@mail.gmail.com>
	<4D6ECC26.3090105@v.loewis.de>
Message-ID: <AANLkTi=UiHMgSUsWjdTWdm+2LVs+47r0FchPeo4SVgNy@mail.gmail.com>

On Wed, Mar 2, 2011 at 3:00 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 02.03.2011 23:36, schrieb J?r?me Radix:
>> No, I don't do it now. But taking like granted the fact that 2.x python
>> will be dead in 5 years and that /usr/bin/python will point to python3
>> is, imho, a little too optimistic.
>
> I don't think Steven said, or assumed, a scope of 5 years - more like
> a scope of 30 years. In 30 years, Python 2 will surely be dead (as
> will likely be Python 3).
>
> The defensive programming you promote is likely to fail. Many Python 2
> scripts are syntactically invalid when interpreted as Python 3, so a
> version test won't even be executed.
>
> With separate python2 and python3 executables, people can have scripts
> depend on the right binary.
>
> In interactive mode, I would like to use /usr/bin/python be the
> "current" Python binary always (even when Python 4.6 comes along).
> Python will, interactively, greet me with its version number, and I
> can adjust. So the idea of /usr/bin/python being reserved for Python 2
> strikes me as inconvenient.

+1 on all that.

-- 
--Guido van Rossum (python.org/~guido)

From mail at kerrickstaley.com  Thu Mar  3 01:01:07 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Wed, 2 Mar 2011 18:01:07 -0600
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <E1472717-8C04-4AAB-8BF3-9606FCB68B9F@fuhm.net>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu> <4D6E5A13.5080507@archlinux.org>
	<E1472717-8C04-4AAB-8BF3-9606FCB68B9F@fuhm.net>
Message-ID: <AANLkTikPFBGBZt2nwiaBG5as01QWXDbKKxX5=qOMdAqG@mail.gmail.com>

The point is that there never has to be an agreement about the python
command, as long as all distros support python2/python3 and all scripts use
it (I think that the distinction should continue to be made if/when python2
becomes uncommon, otherwise we'll hit the same issue with python4). We don't
have to force anyone to change the python command itself.

That being said, I feel that the python command should only be invoked from
an interactive terminal, and in fact it would be good if distros would use
the python2/python3 convention in their own packages, so that the sysadmin
can point python to wherever he wants, and when he types python into a
terminal get the version he wants. As an added plus, should a distro
supporting this feature decide to make the Python 2 -> Python 3 switch, it
would be an effortless process. Again, however, force this requirement
shouldn't be forced on distros.

As an aside, this whole thing started when I tried installing
ROS<http://www.ros.org/wiki/>,
only to find that it made assumptions about /usr/bin/python, which points to
python3 on my Arch Linux system. I went in search of documentation for the
python2/python3 convention so that I could make the ROS developers aware of
it and help them to follow it, only to find out that no such convention
actually exists. Since ROS uses a rather complicated python-based installer
that makes assumptions about /usr/bin/python not only in the shebangs of
many files but also in other places (apparently in connection with the
subprocess module), it has proven thus far unworkable unless I change
/usr/bin/python back to Python 2, a move that could potentially break many
other aspects of my system. I'm sure there are many other users out there
that are frustrated by similar issues; supporting a python2/python3
convention on all distros as well as in scripts would solve these issues
without creating further problems and without the need for a slow consensus
to be reached on what /usr/bin/python should be.

Here is a draft PEP (forgive me if it's incorrectly formatted; I've never
done this before). I think it's a little long winded given how simple the
idea it proposes is, but I thought it would be better to be more specific
than necessary rather than less.
.
PEP: ???
Title: The python Command on Unix-Like Systems
Version: ???
Last-Modified: ???
Author: Kerrick Staley <mail at kerrickstaley.com>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: ???

Abstract
==========
This PEP provides a convention to ensure that Python scripts can continue to
be portable across *nix systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the "python" command).

Recommendation
================

* ``*nix`` software distributions should install the command "python2" into
the default path whenever a version of the Python 2 interpreter is
installed, and the same for "python3" and the Python 3 interpreter. When
invoked, "python2" should run some version of the Python 2 interpreter, and
"python3" should run some version of the Python 3 interpreter.
* All new code that needs to invoke the Python interpreter should specify
either "python2" or "python3", according to the version it requires, but not
"python". This distinction should be made in shebangs, when invoking from a
shell script, when invoking via the system() call, or when invoking in any
other context.

Rationale
===========

This is needed because some distributions alias the "python" command to
Python 3, while others alias it to Python 2. Some distributions also do not
provide a "python2" command; hence, there is no way for Python 2 code (or
any code that invokes the Python 2 interpreter) to reliably run on all
systems without modification, because both the "python" and the "python2"
commands will fail on some systems. The recommendations in this PEP provide
a very simple mechanism to restore cross-platform support, with very little
additional work required on the part of distribution maintainers.

Notes
=======

* Distributions can alias the "python" command to whichever version of the
Python interpreter they choose.
* It would be wise for distributions to always follow the convention that
this PEP recommends, even in code that is not intended to operate on other
distributions. This will make it easier if the code ever needs to be ported
to another distribution or if the distribution decides to change the version
of the Python interpreter that the "python" command invokes. Distributions
can test whether they are fully following this convention by switching the
"python" interpreter and seeing if anything breaks.
* If the above point is adhered to, then the "python" command should always
be a link to the interpreter binary (or a link to a link) and not vice
versa. That way, if users decide to change where the "python" command
points, they can do so without inadvertently deleting the binary.
* The first recommendation can be ignored for systems on which the python
command itself has traditionally been left undefined and users have always
had the responsibility of linking the "python" command to the Python
interpreter.
* 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
is released.
* If these conventions are adhered to, it will be the case that the "python"
command is only executed in an interactive manner.

Backwards Compatibility
=========================
A potential problem can arise if a script adhering to the
"python2"/"python3" convention is executed on a system not supporting these
commands. This is mostly a non-issue, since the sysadmin can simply create
these symbolic links and avoid further problems.

Copyright
===========
This document has been placed in the public domain.

EOF

-Kerrick Staley

On Wed, Mar 2, 2011 at 9:13 AM, James Y Knight <foom at fuhm.net> wrote:

> On Mar 2, 2011, at 9:54 AM, Allan McRae wrote:
> > That way in ?? years when python-3.x is "the" python and python-2.x is
> obsolete, and it is decided that /usr/bin/python will be python-3.x (which I
> believe is the only logical outcome),
>
> But that's not the only logical outcome. A perfectly logical outcome is
> that /usr/bin/python disappears completely if python2.X isn't installed, and
> python3 is always called python3. That is the outcome I find sensible. And
> that is the crux of the disagreement in this thread.
>
>
> Those who think python3.X should stay /usr/bin/python3 forever do not see
> any reason to make everyone rewrite their existing python scripts to say
> "/usr/bin/python2" instead of "/usr/bin/python". So, there's no point in
> adding a /usr/bin/python2 now. Scripts that want python2 can remain using
> /usr/bin/python forever, and that will either be installed, or not
> installed, depending on whether that OS has a copy of python2.X.
>
> Those who think python3 should (eventually someday, or maybe immediately,
> depending) be named or have an alias of "/usr/bin/python" want to make
> everyone rewrite their scripts to say /usr/bin/python2 now. For that
> position, it's unfortunate that python source doesn't install itself with an
> alias of /usr/bin/python2, and some distros don't install that alias either.
> So they want to fix that.
>
> James
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/9c90de37/attachment.html>

From foom at fuhm.net  Thu Mar  3 02:47:28 2011
From: foom at fuhm.net (James Y Knight)
Date: Wed, 2 Mar 2011 20:47:28 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikPFBGBZt2nwiaBG5as01QWXDbKKxX5=qOMdAqG@mail.gmail.com>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>
	<20110302140323.GN30982@piotro.eu> <4D6E51A7.6020302@archlinux.org>
	<20110302142918.GO30982@piotro.eu> <4D6E5A13.5080507@archlinux.org>
	<E1472717-8C04-4AAB-8BF3-9606FCB68B9F@fuhm.net>
	<AANLkTikPFBGBZt2nwiaBG5as01QWXDbKKxX5=qOMdAqG@mail.gmail.com>
Message-ID: <09576165-F35C-4350-BB6B-C84A36DE9EF8@fuhm.net>

On Mar 2, 2011, at 7:01 PM, Kerrick Staley wrote:
> As an aside, this whole thing started when I tried installing ROS, only to find that it made assumptions about /usr/bin/python, which points to python3 on my Arch Linux system.

Yep, exactly that kind of problem is why I think it's an absolutely terrible idea to switch the /usr/bin/python link to point to python3 (ever). When python 2.x is dead, I really don't see what the problem is with only having a "python3" binary, and no "python" binary.

That said, since the conclusion here is that it *IS* a good idea to point "python" to a python3 interpreter eventually, I guess it's better to add the python2 link 4 years late than never.

A lot of pain could've been spared if python 2.x had started installing python2 years ago, so by now everyone would depend on it existing. But oh well, too late for that, unless someone has a time machine handy.


>  I went in search of documentation for the python2/python3 convention so that I could make the ROS developers aware of it and help them to follow it, only to find out that no such convention actually exists.


> I'm sure there are many other users out there that are frustrated by similar issues;

Well, so far, only those unfortunate users of Arch Linux...but considering the consensus here, I'm sure there will be more in the future.

> supporting a python2/python3 convention on all distros as well as in scripts would solve these issues without creating further problems and without the need for a slow consensus to be reached on what /usr/bin/python should be.


Well, it will definitely will create problems: scripts may start using the python2 name to be compatible with Arch Linux (or anyone else who sets python->python3), but the python2 link won't exist on any existing from-source Python install, or OSX, or Debian, or Ubuntu. And it likely will not start existing on some of those systems for years to come, even if the PEP is accepted today. 

Perhaps that problem is considered less of a problem than the problem Arch Linux users have today (as you point out, sysadmins can create the link themselves), but it still is a problem.

As to the PEP itself: you should specify an action item that the Python 2.7.N upstream makefile be modified to install a python2 symlink, as well.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110302/fe0e659f/attachment.html>

From martin at v.loewis.de  Thu Mar  3 09:33:11 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Mar 2011 09:33:11 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikPFBGBZt2nwiaBG5as01QWXDbKKxX5=qOMdAqG@mail.gmail.com>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>	<20110302140323.GN30982@piotro.eu>
	<4D6E51A7.6020302@archlinux.org>	<20110302142918.GO30982@piotro.eu>
	<4D6E5A13.5080507@archlinux.org>	<E1472717-8C04-4AAB-8BF3-9606FCB68B9F@fuhm.net>
	<AANLkTikPFBGBZt2nwiaBG5as01QWXDbKKxX5=qOMdAqG@mail.gmail.com>
Message-ID: <4D6F5247.8020000@v.loewis.de>

> Here is a draft PEP (forgive me if it's incorrectly formatted; I've
> never done this before).

LGTM. Please specify what /usr/bin/python is supposed to be also
(rather: the "python" utility). I'd like it ruled out that
installations *only* provide python2 and python3 - "python" could
be either one, but should be present "normally" (i.e. SHOULD
in the RFC 2119 sense).

Nitpickingly, I'd add that scripts can, of course, also specify
python2.7 (or some such). Actually, scripts can do whatever they
want - it's more about what they then can expect to happen.

Regards,
Martin

From piotr at debian.org  Thu Mar  3 09:55:25 2011
From: piotr at debian.org (Piotr =?utf-8?Q?O=C5=BCarowski?=)
Date: Thu, 3 Mar 2011 09:55:25 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
Message-ID: <20110303085525.GQ30982@piotro.eu>

[Guido van Rossum, 2011-03-02]
> On Wed, Mar 2, 2011 at 4:56 AM, Piotr O?arowski <piotr at debian.org> wrote:
> > [Sandro Tosi, 2011-03-02]
> >> On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski <piotr at debian.org> wrote:
> >> > I co-maintain with Matthias a package that provides /usr/bin/python
> >> > symlink in Debian and I can confirm that it will always point to Python
> >> > 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
> >> > only accepted PEP can change that)
> >>
> >> Can you please explain why you NACK this proposed change?
> >
> > it encourages people to change /usr/bin/python symlink to point to
> > python3.X which I'm strongly against (how can I tell that upstream
> > author meant python3.X and not python2.X without checking the code?)
> 
> But the same is already true for python2.X vs. python2.Y. Explicit is
> better than implicit etc. Plus, 5 years from now everybody is going to
> be annoyed that "python" still refers to some ancient unused version
> of Python.

I don't really mind adding /usr/bin/python2 symlink just to clean Arch
mess, but I do mind changing /usr/bin/python to point to python3 (and I
can use the same argument - "Explicit is better than implicit" - if you
need Python 3, say so in the shebang, right?). What I'm afraid of is
when we'll add /usr/bin/python2, we'll start getting a lot of scripts
that will have to be checked manually every time new upstream version is
released because we cannot assume what upstream author is using at given
point.

If /usr/bin/python will be disallowed in shebangs on the other hand
(and all scripts will use /usr/bin/python2, /usr/bin/python3,
/usr/bin/python4 or /usr/bin/python2.6 etc.) I don't see a problem with
letting administrators choose /usr/bin/python (right now not only
changing it from python2.X to python3.X will break the system but also
changing it from /usr/bin/pytohn2.X to /usr/bin/python2.Y will break it,
and believe me, I know what I'm talking about (one of the guys at work
did something like this once))

[all IMHO, dunno if other Debian's python-defaults maintainers agree
with me]
-- 
Piotr O?arowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

From sumerc at gmail.com  Thu Mar  3 10:06:20 2011
From: sumerc at gmail.com (=?ISO-8859-1?Q?S=FCmer_Cip?=)
Date: Thu, 3 Mar 2011 11:06:20 +0200
Subject: [Python-Dev] Improvements for Porting C Extension from 2 to 3
Message-ID: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>

Hi,

While porting a C extension from 2 to 3, I realized that there are some
general cases which can be automated. For example, for my specific
application (yappi - http://code.google.com/p/yappi/), all I need to do is
following things:

1) define PyModuleDef
2) change PyString_AS_STRING calls  to _PyUnicode_AsString
3) change module init code a little.

It occurred to me all these kind of standart changes can be automated via a
script.

Not sure on the usability of this however, because of my limited knowledge
on the area.

Does such a tool worth being implemented?

-- 
Sumer Cip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/0475d01b/attachment.html>

From mal at egenix.com  Thu Mar  3 10:15:00 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 03 Mar 2011 10:15:00 +0100
Subject: [Python-Dev] Improvements for Porting C Extension from 2 to 3
In-Reply-To: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>
References: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>
Message-ID: <4D6F5C14.4080000@egenix.com>

S?mer Cip wrote:
> Hi,
> 
> While porting a C extension from 2 to 3, I realized that there are some
> general cases which can be automated. For example, for my specific
> application (yappi - http://code.google.com/p/yappi/), all I need to do is
> following things:
> 
> 1) define PyModuleDef
> 2) change PyString_AS_STRING calls  to _PyUnicode_AsString

Aside: Please don't use private APIs in Python extensions. Esp.
the above Unicode API is likely going to be phased out.

You're better off, using PyUnicode_AsUTF8String() instead and
then leaving the PyString_AS_STRING() macro in place.

> 3) change module init code a little.
> 
> It occurred to me all these kind of standart changes can be automated via a
> script.
> 
> Not sure on the usability of this however, because of my limited knowledge
> on the area.
> 
> Does such a tool worth being implemented?

I'm not sure whether you can really automate this: The change from
8-bit strings to Unicode support usually requires reconsidering
whether you're dealing with plain text, encoded text data or
binary data.

However, a guide of what to replace and how to change the code
would probably help a lot. Please share your thoughts on the
python-porting mailint list and/or add to these wiki pages:

http://wiki.python.org/moin/PortingToPy3k
http://wiki.python.org/moin/PortingExtensionModulesToPy3k

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 03 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From victor.stinner at haypocalc.com  Thu Mar  3 11:08:54 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 03 Mar 2011 11:08:54 +0100
Subject: [Python-Dev] Improvements for Porting C Extension from 2 to 3
In-Reply-To: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>
References: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>
Message-ID: <1299146934.13068.5.camel@marge>

Le jeudi 03 mars 2011 ? 11:06 +0200, S?mer Cip a ?crit :
> While porting a C extension from 2 to 3, I realized that there are some
> general cases which can be automated. For example, for my specific
> application (yappi - http://code.google.com/p/yappi/), all I need to do is
> following things:

See also 2to3c project based on Coccinelle:
https://fedorahosted.org/2to3c/
http://coccinelle.lip6.fr/

Victor


From techtonik at gmail.com  Thu Mar  3 13:40:46 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 3 Mar 2011 14:40:46 +0200
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into Python
	3.3)
Message-ID: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>

On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum <guido at python.org> wrote:
> Now that the language moratorium is lifted, let's make sure to get PEP
> 380 implemented for Python 3.3.

How about official RoadMap? There is no visibility into what's going
on in Python development. New people can' t jump in and help do bring
some features faster. http://dungeonhack.sourceforge.net/Roadmap

"yield from" seems useful.

-- 
anatoly t.

From sumerc at gmail.com  Thu Mar  3 14:39:23 2011
From: sumerc at gmail.com (=?ISO-8859-1?Q?S=FCmer_Cip?=)
Date: Thu, 3 Mar 2011 15:39:23 +0200
Subject: [Python-Dev] Improvements for Porting C Extension from 2 to 3
In-Reply-To: <4D6F5C14.4080000@egenix.com>
References: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>
	<4D6F5C14.4080000@egenix.com>
Message-ID: <AANLkTim1CJk2cRdFxsK-_VSyCbScb5JiqPKLBzrrrsR0@mail.gmail.com>

> >
> > 1) define PyModuleDef
> > 2) change PyString_AS_STRING calls  to _PyUnicode_AsString
>
> Aside: Please don't use private APIs in Python extensions. Esp.
> the above Unicode API is likely going to be phased out.
>
> You're better off, using PyUnicode_AsUTF8String() instead and
> then leaving the PyString_AS_STRING() macro in place.
>

In the standart Python 3.2 source tree, Modules/_lsprof.c uses that internal
function _PyUnicode_AsString. Internal means internal to the whole
distribution here I think?. But IMHO, this should not be the case, C API
modules in the standart dist. should not use internal functions of other
areas. Like in the example: cProfile code has nothing to do with the Unicode
internals. New developers like me, are in need a consistent examples of
usage of Python C API, especially on Python 3.2.

Thanks,



-- 
Sumer Cip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/cdc7c49a/attachment.html>

From benjamin at python.org  Thu Mar  3 14:45:31 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 3 Mar 2011 07:45:31 -0600
Subject: [Python-Dev] Improvements for Porting C Extension from 2 to 3
In-Reply-To: <AANLkTim1CJk2cRdFxsK-_VSyCbScb5JiqPKLBzrrrsR0@mail.gmail.com>
References: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>
	<4D6F5C14.4080000@egenix.com>
	<AANLkTim1CJk2cRdFxsK-_VSyCbScb5JiqPKLBzrrrsR0@mail.gmail.com>
Message-ID: <AANLkTinWA4uQhLf2PYvFY3M6weKoq0uPTKQrgjWiUE1m@mail.gmail.com>

2011/3/3 S?mer Cip <sumerc at gmail.com>:
>
>> >
>> > 1) define PyModuleDef
>> > 2) change PyString_AS_STRING calls ?to _PyUnicode_AsString
>>
>> Aside: Please don't use private APIs in Python extensions. Esp.
>> the above Unicode API is likely going to be phased out.
>>
>> You're better off, using PyUnicode_AsUTF8String() instead and
>> then leaving the PyString_AS_STRING() macro in place.
>
> In the standart Python 3.2 source tree, Modules/_lsprof.c uses that internal
> function _PyUnicode_AsString. Internal means internal to the whole
> distribution here I think?. But IMHO, this should not be the case, C API
> modules in the standart dist. should not use internal functions of other
> areas. Like in the example: cProfile code has nothing to do with the Unicode
> internals. New developers like me, are in need a consistent examples of
> usage of Python C API, especially on Python 3.2.

I'm not sure why what C-API is used in Python's extension modules
needs to be anyway to you.



-- 
Regards,
Benjamin

From sumerc at gmail.com  Thu Mar  3 15:00:39 2011
From: sumerc at gmail.com (=?ISO-8859-1?Q?S=FCmer_Cip?=)
Date: Thu, 3 Mar 2011 16:00:39 +0200
Subject: [Python-Dev] Improvements for Porting C Extension from 2 to 3
In-Reply-To: <AANLkTinWA4uQhLf2PYvFY3M6weKoq0uPTKQrgjWiUE1m@mail.gmail.com>
References: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>
	<4D6F5C14.4080000@egenix.com>
	<AANLkTim1CJk2cRdFxsK-_VSyCbScb5JiqPKLBzrrrsR0@mail.gmail.com>
	<AANLkTinWA4uQhLf2PYvFY3M6weKoq0uPTKQrgjWiUE1m@mail.gmail.com>
Message-ID: <AANLkTiknKfSYXb69FUV2LsZ1ZC2=96fjkx2r=wTcWA8=@mail.gmail.com>

>
> I'm not sure why what C-API is used in Python's extension modules
> needs to be anyway to you.
>

I just tought it is a better programming practice to decrease/narrow inter
modular usage of functions inside the whole dist. and also a good example
for the other 3rd party C Extension developers. I may be wrong. Anyway
thanks for the answers. This is just a suggestion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/ac80e6d7/attachment.html>

From fuzzyman at voidspace.org.uk  Thu Mar  3 15:05:21 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 03 Mar 2011 14:05:21 +0000
Subject: [Python-Dev] Improvements for Porting C Extension from 2 to 3
In-Reply-To: <AANLkTinWA4uQhLf2PYvFY3M6weKoq0uPTKQrgjWiUE1m@mail.gmail.com>
References: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>	<4D6F5C14.4080000@egenix.com>	<AANLkTim1CJk2cRdFxsK-_VSyCbScb5JiqPKLBzrrrsR0@mail.gmail.com>
	<AANLkTinWA4uQhLf2PYvFY3M6weKoq0uPTKQrgjWiUE1m@mail.gmail.com>
Message-ID: <4D6FA021.6020402@voidspace.org.uk>

On 03/03/2011 13:45, Benjamin Peterson wrote:
> 2011/3/3 S?mer Cip<sumerc at gmail.com>:
>>>> 1) define PyModuleDef
>>>> 2) change PyString_AS_STRING calls  to _PyUnicode_AsString
>>> Aside: Please don't use private APIs in Python extensions. Esp.
>>> the above Unicode API is likely going to be phased out.
>>>
>>> You're better off, using PyUnicode_AsUTF8String() instead and
>>> then leaving the PyString_AS_STRING() macro in place.
>> In the standart Python 3.2 source tree, Modules/_lsprof.c uses that internal
>> function _PyUnicode_AsString. Internal means internal to the whole
>> distribution here I think?. But IMHO, this should not be the case, C API
>> modules in the standart dist. should not use internal functions of other
>> areas. Like in the example: cProfile code has nothing to do with the Unicode
>> internals. New developers like me, are in need a consistent examples of
>> usage of Python C API, especially on Python 3.2.
> I'm not sure why what C-API is used in Python's extension modules
> needs to be anyway to you.
>
I think its fair enough to point out the inconsistency in python-dev 
declaring that authors *should not* use certain parts of the C-API in 
extensions whilst using them in the extensions python-dev is responsible 
for...

Michael

-- 
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


From brian.curtin at gmail.com  Thu Mar  3 15:12:31 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Thu, 3 Mar 2011 08:12:31 -0600
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into
	Python 3.3)
In-Reply-To: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
References: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
Message-ID: <AANLkTimkQHFEPXa9gkLb8b+ubTzQfhuw+kt9B+uE8HAC@mail.gmail.com>

On Thu, Mar 3, 2011 at 06:40, anatoly techtonik <techtonik at gmail.com> wrote:

> On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum <guido at python.org>
> wrote:
> > Now that the language moratorium is lifted, let's make sure to get PEP
> > 380 implemented for Python 3.3.
>
> How about official RoadMap? There is no visibility into what's going
> on in Python development. New people can' t jump in and help do bring
> some features faster. http://dungeonhack.sourceforge.net/Roadmap


You could put together something fancy out of a query for all 3.3 feature
requests [0] if you want this.

I'm also not sure if that would be entirely useful. Python development is
fairly relaxed in that you work on what you want to work on, when you want
to do it. If you fill up some roadmap with all 180 feature requests on that
page, they are not all going to get done, and it's not a condition of doing
the release.


[0] http://goo.gl/4RMp8
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/7f0cf50e/attachment.html>

From guido at python.org  Thu Mar  3 16:59:39 2011
From: guido at python.org (Guido van Rossum)
Date: Thu, 3 Mar 2011 07:59:39 -0800
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into
	Python 3.3)
In-Reply-To: <AANLkTimkQHFEPXa9gkLb8b+ubTzQfhuw+kt9B+uE8HAC@mail.gmail.com>
References: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
	<AANLkTimkQHFEPXa9gkLb8b+ubTzQfhuw+kt9B+uE8HAC@mail.gmail.com>
Message-ID: <AANLkTikPD=+w+4rt6bjc+=j5xc72LRO31c2n6Fu=Jmf0@mail.gmail.com>

A project roadmap is usually something that a team commits to, with
some caveats, in order to give the customers (the "outside world")
some view in development that is already planned or under way or on
some other way committed to.

But a roadmap itself takes effort to create and maintain. Also, often
projects are undertaken on the spur of the moment that aren't on the
roadmap, and changes in personnel or priorities may cause items to
linger on the "official" roadmap without making much progress.

I think that if someone is interested in contributing to Python but
they aren't into coding, managing a roadmap could be a useful role to
perform, especially for someone with some project management skills
and the tenacity to stick around for a long time. (You don't publish a
roadmap and then leave; it needs regular updates, say every month or
quarter at least.)

At the same time the roadmap manager ought to recall that they are not
the project manager and they will have to be careful not to use the
roadmap to force core developers (who all have their own agendas) to
do (or refrain from) specific things.

The kind of items that would make sense to have on a roadmap are
probably usually PEP-sized features; a list of feature extracted from
the tracker would be too overwhelming for the external consumers of
the roadmap.

A note about the example from dungeonhack: that format is probably too
detailed for Python; I don't think we need to have dates and assigned
developers in the roadmap. An example entry could say "yield from (PEP
380)".

There is no expectation for roadmaps to be complete or always uptodate.

Anyone feel compelled to give it a try?

--Guido

On Thu, Mar 3, 2011 at 6:12 AM, Brian Curtin <brian.curtin at gmail.com> wrote:
> On Thu, Mar 3, 2011 at 06:40, anatoly techtonik <techtonik at gmail.com> wrote:
>>
>> On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum <guido at python.org>
>> wrote:
>> > Now that the language moratorium is lifted, let's make sure to get PEP
>> > 380 implemented for Python 3.3.
>>
>> How about official RoadMap? There is no visibility into what's going
>> on in Python development. New people can' t jump in and help do bring
>> some features faster. http://dungeonhack.sourceforge.net/Roadmap
>
> You could put together something fancy out of a query for all 3.3 feature
> requests [0] if you want this.
> I'm also not sure if that would be entirely useful. Python development is
> fairly relaxed in that you work on what you want to work on, when you want
> to do it. If you fill up some roadmap with all 180 feature requests on that
> page, they are not all going to get done, and it's not a condition of doing
> the release.
>
> [0]?http://goo.gl/4RMp8
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>



-- 
--Guido van Rossum (python.org/~guido)

From alexander.belopolsky at gmail.com  Thu Mar  3 17:37:18 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Thu, 3 Mar 2011 11:37:18 -0500
Subject: [Python-Dev] Improvements for Porting C Extension from 2 to 3
In-Reply-To: <4D6FA021.6020402@voidspace.org.uk>
References: <AANLkTin5Ksp4S66-1sy5dD5FE9nhoWKHP4AqTMHU0gVD@mail.gmail.com>
	<4D6F5C14.4080000@egenix.com>
	<AANLkTim1CJk2cRdFxsK-_VSyCbScb5JiqPKLBzrrrsR0@mail.gmail.com>
	<AANLkTinWA4uQhLf2PYvFY3M6weKoq0uPTKQrgjWiUE1m@mail.gmail.com>
	<4D6FA021.6020402@voidspace.org.uk>
Message-ID: <AANLkTimwYausWQH2q44BvRi73kWJ1XQtMZpXExQq=Mfg@mail.gmail.com>

On Thu, Mar 3, 2011 at 9:05 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
..
> I think its fair enough to point out the inconsistency in python-dev
> declaring that authors *should not* use certain parts of the C-API in
> extensions whilst using them in the extensions python-dev is responsible
> for...


This is not an inconsistency, but a balancing act.  By using APIs that
are likely to change or be removed, we assume the responsibility to
clean up code that is under our control at some point in the future.
Users or 3rd party developers can do the same balancing, but the
assumption is that the amount of code in their libraries is much
greater than that in stdlib and they do not follow Python changes as
closely as core developers.  These considerations usually tip the
scale towards not using private APIs.  (For example, they don't and
should not run buildbots testing their code with the latest VC
checkout.)

On the other hand, if you can ship your application sooner using a hack like

#define PyString_AS_STRING _PyUnicode_AsString

more power to you, but you have been warned - don't file a bug report
when you code stops working with Python 3.5.

From a.badger at gmail.com  Thu Mar  3 18:08:04 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 3 Mar 2011 09:08:04 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110303085525.GQ30982@piotro.eu>
References: <4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
Message-ID: <20110303170804.GD3275@unaka.lan>

On Thu, Mar 03, 2011 at 09:55:25AM +0100, Piotr O?arowski wrote:
> [Guido van Rossum, 2011-03-02]
> > On Wed, Mar 2, 2011 at 4:56 AM, Piotr O?arowski <piotr at debian.org> wrote:
> > > [Sandro Tosi, 2011-03-02]
> > >> On Wed, Mar 2, 2011 at 10:01, Piotr O?arowski <piotr at debian.org> wrote:
> > >> > I co-maintain with Matthias a package that provides /usr/bin/python
> > >> > symlink in Debian and I can confirm that it will always point to Python
> > >> > 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess
> > >> > only accepted PEP can change that)
> > >>
> > >> Can you please explain why you NACK this proposed change?
> > >
> > > it encourages people to change /usr/bin/python symlink to point to
> > > python3.X which I'm strongly against (how can I tell that upstream
> > > author meant python3.X and not python2.X without checking the code?)
> > 
> > But the same is already true for python2.X vs. python2.Y. Explicit is
> > better than implicit etc. Plus, 5 years from now everybody is going to
> > be annoyed that "python" still refers to some ancient unused version
> > of Python.
> 
> I don't really mind adding /usr/bin/python2 symlink just to clean Arch
> mess, but I do mind changing /usr/bin/python to point to python3 (and I
> can use the same argument - "Explicit is better than implicit" - if you
> need Python 3, say so in the shebang, right?). What I'm afraid of is
> when we'll add /usr/bin/python2, we'll start getting a lot of scripts
> that will have to be checked manually every time new upstream version is
> released because we cannot assume what upstream author is using at given
> point.
> 
> If /usr/bin/python will be disallowed in shebangs on the other hand
> (and all scripts will use /usr/bin/python2, /usr/bin/python3,
> /usr/bin/python4 or /usr/bin/python2.6 etc.) I don't see a problem with
> letting administrators choose /usr/bin/python (right now not only
> changing it from python2.X to python3.X will break the system but also
> changing it from /usr/bin/pytohn2.X to /usr/bin/python2.Y will break it,
> and believe me, I know what I'm talking about (one of the guys at work
> did something like this once))
> 
> [all IMHO, dunno if other Debian's python-defaults maintainers agree
> with me]
>
Thinking outside of the box, I can think of something that would satisfy
your requirements but I don't know how appropriate it is for upstream python
to ship with.  Stop shipping /usr/bin/python.  Ship "python" in an alternate
location like $LIBEXECDIR/python2.7/bin (I think this would be
/usr/lib/python2.7/bin on Debian and /usr/libexec/python2.7/bin on Fedora
which would both be appropriate) then configure which python version is
invoked by the user typing "python" by configuring PATH (a shell alias might
also work).  You could configure this with environment-modules[1]_ if Debian
supports using that in packaging.

Coupled with a PEP that recommends against using /usr/bin/python in scripts
and instead using /usr/bin/python$MAJOR, this might be sufficient.  OTOH, my
cynical side doubts that script authors read PEPs so it'll take either
upstream python shipping without /usr/bin/python or consensus among the
distros to ship without /usr/bin/python to reach the point where script
authors realize that they need to use /usr/bin/python{2,3} instead of
/usr/bin/python.

.. _[1]: http://modules.sourceforge.net/

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/a574f4e3/attachment.pgp>

From raymond.hettinger at gmail.com  Thu Mar  3 18:24:29 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Thu, 3 Mar 2011 09:24:29 -0800
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into
	Python 3.3)
In-Reply-To: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
References: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
Message-ID: <97D7A72F-198C-409B-A684-0AA851A9E438@gmail.com>


On Mar 3, 2011, at 4:40 AM, anatoly techtonik wrote:

> How about official RoadMap? There is no visibility into what's going
> on in Python development. New people can' t jump in and help do bring
> some features faster. http://dungeonhack.sourceforge.net/Roadmap

Thanks for the link.  Their roadmap made my day:

   High priority: code to spawn spiders in the forest
   Medium priority: write pet rat fetch quest

And best of all, the "animate rat" task is assigned to "Musk of Ephesus".


Raymond

From techtonik at gmail.com  Thu Mar  3 18:26:42 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 3 Mar 2011 19:26:42 +0200
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into
	Python 3.3)
In-Reply-To: <AANLkTimkQHFEPXa9gkLb8b+ubTzQfhuw+kt9B+uE8HAC@mail.gmail.com>
References: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
	<AANLkTimkQHFEPXa9gkLb8b+ubTzQfhuw+kt9B+uE8HAC@mail.gmail.com>
Message-ID: <AANLkTim-0eT8Ph+99Hhfoy8XkxxTLxCs+ACmKkabLhpE@mail.gmail.com>

On Thu, Mar 3, 2011 at 4:12 PM, Brian Curtin <brian.curtin at gmail.com> wrote:
> On Thu, Mar 3, 2011 at 06:40, anatoly techtonik <techtonik at gmail.com> wrote:
>>
>> On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum <guido at python.org>
>> wrote:
>> > Now that the language moratorium is lifted, let's make sure to get PEP
>> > 380 implemented for Python 3.3.
>>
>> How about official RoadMap? There is no visibility into what's going
>> on in Python development. New people can' t jump in and help do bring
>> some features faster. http://dungeonhack.sourceforge.net/Roadmap
>
> You could put together something fancy out of a query for all 3.3 feature
> requests [0] if you want this.

> [0]?http://goo.gl/4RMp8

I've got error - "You do not have permission to store queries". That
should mean something.

> I'm also not sure if that would be entirely useful. Python development is
> fairly relaxed in that you work on what you want to work on, when you want
> to do it. If you fill up some roadmap with all 180 feature requests on that
> page, they are not all going to get done, and it's not a condition of doing
> the release.

Roadmap is not a strict plan for release. It helps people
*self-organize into teams* around specific feature or bugs. One of the
features of Roadmap is that *if you add an item to it, you're willing
to support development* of this item. Roadmap is not needed for those
core developers, who prefer to work in isolation, but even they can
find it *useful to see who works on what, and what users actually
want*.

Yes, there can (or even should) be a way for everybody with Python
account to vote on items in the Roadmap and subscribe to updates (like
commits, messages, code reviews, tweets and other stuff related to one
item). This will give Jesse and teams a better picture, what sprints
need funding. Tracker doesn't allow this - even though users can
subscribe to Roundup issues, it just doesn't work for them. And the
last distinction between Roadmap and Tracker is that the former gives
you a quick overview of each item without going into the gory details
of lengthy discussions.

I'd say this is a good project for Google Summer of Code, which
deadline for submission is next Friday, BTW.
-- 
anatoly t.

From python at mrabarnett.plus.com  Thu Mar  3 18:40:40 2011
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 03 Mar 2011 17:40:40 +0000
Subject: [Python-Dev] Strange occasional marshal error
In-Reply-To: <93db1a69-5b83-4df2-aa98-50e987e1d09b@a28g2000vbo.googlegroups.com>
References: <09f6f042-daee-4067-a32d-4dc5caad346f@v31g2000vbs.googlegroups.com>
	<93db1a69-5b83-4df2-aa98-50e987e1d09b@a28g2000vbo.googlegroups.com>
Message-ID: <4D6FD298.3040904@mrabarnett.plus.com>

On 03/03/2011 15:09, Graham Stratton wrote:
> On Mar 2, 3:01 pm, Graham Stratton<grahamstrat... at gmail.com>  wrote:
>> We are using marshal for serialising objects before distributing them
>> around the cluster, and extremely occasionally a corrupted marshal is
>> produced. The current workaround is to serialise everything twice and
>> check that the serialisations are the same. On the rare occasions that
>> they are not, I have dumped the files for comparison. It turns out
>> that there are a few positions within the serialisation where
>> corruption tends to occur (these positions seem to be independent of
>> the data of the size of the complete serialisation). These are:
>>
>> 4 bytes starting at 548867 (0x86003)
>> 4 bytes starting at 4398083 (0x431c03)
>> 4 bytes starting at 17595395 (0x10c7c03)
>> 4 bytes starting at 19794819 (0x12e0b83)
>> 4 bytes starting at 22269171 (0x153ccf3)
>> 2 bytes starting at 25052819 (0x17e4693)
>> 3 bytes starting at 28184419 (0x1ae0f63)
>
> I modified marshal.c to print when it extends the string used to write
> the marshal to. This gave me these results:
>
>>>> s = marshal.dumps(list((i, str(i)) for i in range(1400000)))
> Resizing string from 50 to 1124 bytes
> Resizing string from 1124 to 3272 bytes
> Resizing string from 3272 to 7568 bytes
> Resizing string from 7568 to 16160 bytes
> Resizing string from 16160 to 33344 bytes
> Resizing string from 33344 to 67712 bytes
> Resizing string from 67712 to 136448 bytes
> Resizing string from 136448 to 273920 bytes
> Resizing string from 273920 to 548864 bytes
> Resizing string from 548864 to 1098752 bytes
> Resizing string from 1098752 to 2198528 bytes
> Resizing string from 2198528 to 4398080 bytes
> Resizing string from 4398080 to 8797184 bytes
> Resizing string from 8797184 to 17595392 bytes
> Resizing string from 17595392 to 19794816 bytes
> Resizing string from 19794816 to 22269168 bytes
> Resizing string from 22269168 to 25052814 bytes
> Resizing string from 25052814 to 28184415 bytes
> Resizing string from 28184415 to 31707466 bytes
>
> Every corruption point occurs exactly three bytes above an extension
> point (rounded to the nearest word for the last two). This clearly
> isn't a coincidence, but I can't see where there could be a problem.
> I'd be grateful for any pointers.
>
I haven't found the cause, but I have found something else I'm
suspicious of in the source for Python 3.2.

In marshal.c there's a function "w_object", and within that function is
this:

     else if (PyAnySet_CheckExact(v)) {
         PyObject *value, *it;

         if (PyObject_TypeCheck(v, &PySet_Type))
             w_byte(TYPE_SET, p);
         else
             w_byte(TYPE_FROZENSET, p);

"w_byte" is a macro which includes an if-statement, not a function.
Doesn't it need some braces? (There's are braces in the other places
they're needed.)

From guido at python.org  Thu Mar  3 19:04:15 2011
From: guido at python.org (Guido van Rossum)
Date: Thu, 3 Mar 2011 10:04:15 -0800
Subject: [Python-Dev] Strange occasional marshal error
In-Reply-To: <4D6FD298.3040904@mrabarnett.plus.com>
References: <09f6f042-daee-4067-a32d-4dc5caad346f@v31g2000vbs.googlegroups.com>
	<93db1a69-5b83-4df2-aa98-50e987e1d09b@a28g2000vbo.googlegroups.com>
	<4D6FD298.3040904@mrabarnett.plus.com>
Message-ID: <AANLkTi=1VBi02xwAebFTPgByoRMyXD3-8Y+qdNZpMig-@mail.gmail.com>

On Thu, Mar 3, 2011 at 9:40 AM, MRAB <python at mrabarnett.plus.com> wrote:
> On 03/03/2011 15:09, Graham Stratton wrote:
>>
>> On Mar 2, 3:01 pm, Graham Stratton<grahamstrat... at gmail.com> ?wrote:
>>>
>>> We are using marshal for serialising objects before distributing them
>>> around the cluster, and extremely occasionally a corrupted marshal is
>>> produced. The current workaround is to serialise everything twice and
>>> check that the serialisations are the same. On the rare occasions that
>>> they are not, I have dumped the files for comparison. It turns out
>>> that there are a few positions within the serialisation where
>>> corruption tends to occur (these positions seem to be independent of
>>> the data of the size of the complete serialisation). These are:
>>>
>>> 4 bytes starting at 548867 (0x86003)
>>> 4 bytes starting at 4398083 (0x431c03)
>>> 4 bytes starting at 17595395 (0x10c7c03)
>>> 4 bytes starting at 19794819 (0x12e0b83)
>>> 4 bytes starting at 22269171 (0x153ccf3)
>>> 2 bytes starting at 25052819 (0x17e4693)
>>> 3 bytes starting at 28184419 (0x1ae0f63)
>>
>> I modified marshal.c to print when it extends the string used to write
>> the marshal to. This gave me these results:
>>
>>>>> s = marshal.dumps(list((i, str(i)) for i in range(1400000)))
>>
>> Resizing string from 50 to 1124 bytes
>> Resizing string from 1124 to 3272 bytes
>> Resizing string from 3272 to 7568 bytes
>> Resizing string from 7568 to 16160 bytes
>> Resizing string from 16160 to 33344 bytes
>> Resizing string from 33344 to 67712 bytes
>> Resizing string from 67712 to 136448 bytes
>> Resizing string from 136448 to 273920 bytes
>> Resizing string from 273920 to 548864 bytes
>> Resizing string from 548864 to 1098752 bytes
>> Resizing string from 1098752 to 2198528 bytes
>> Resizing string from 2198528 to 4398080 bytes
>> Resizing string from 4398080 to 8797184 bytes
>> Resizing string from 8797184 to 17595392 bytes
>> Resizing string from 17595392 to 19794816 bytes
>> Resizing string from 19794816 to 22269168 bytes
>> Resizing string from 22269168 to 25052814 bytes
>> Resizing string from 25052814 to 28184415 bytes
>> Resizing string from 28184415 to 31707466 bytes
>>
>> Every corruption point occurs exactly three bytes above an extension
>> point (rounded to the nearest word for the last two). This clearly
>> isn't a coincidence, but I can't see where there could be a problem.
>> I'd be grateful for any pointers.

This bug report doesn't mention the Python version nor the platform --
it could in theory be a bug in the platform compiler or memory
allocator. It would also be nice to provide the test program that
reproduces the issue. It would also be useful to start tracking it in
the issue tracker at bugs.python.org

Assuming it's 3.2, I would audit _PyBytes_Resize() and whatever it
uses -- if your hunch is right and there is a problem with resizing
that's where it's done.

> I haven't found the cause, but I have found something else I'm
> suspicious of in the source for Python 3.2.
>
> In marshal.c there's a function "w_object", and within that function is
> this:
>
> ? ?else if (PyAnySet_CheckExact(v)) {
> ? ? ? ?PyObject *value, *it;
>
> ? ? ? ?if (PyObject_TypeCheck(v, &PySet_Type))
> ? ? ? ? ? ?w_byte(TYPE_SET, p);
> ? ? ? ?else
> ? ? ? ? ? ?w_byte(TYPE_FROZENSET, p);
>
> "w_byte" is a macro which includes an if-statement, not a function.
> Doesn't it need some braces? (There's are braces in the other places
> they're needed.)

That macro looks fine to me; looking at the definition of w_byte() it
has matched if/else clauses:

#define w_byte(c, p) if (((p)->fp)) putc((c), (p)->fp); \
                      else if ((p)->ptr != (p)->end) *(p)->ptr++ = (c); \
                           else w_more(c, p)

Although traditionally, just to be sure, we've enclosed similar macros
inside do { ... } while (0). Also it would be nice to call out its
macro-status by renaming it to W_BYTE -- I suppose at one point in the
past it was a plain function...

-- 
--Guido van Rossum (python.org/~guido)

From dmalcolm at redhat.com  Thu Mar  3 20:17:44 2011
From: dmalcolm at redhat.com (David Malcolm)
Date: Thu, 03 Mar 2011 14:17:44 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D6D8BE8.7020808@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
Message-ID: <1299179864.15972.5.camel@radiator.bos.redhat.com>

On Wed, 2011-03-02 at 01:14 +0100, "Martin v. L?wis" wrote:
> > I think a PEP would help, but in this case I would request that before
> > the PEP gets written (it can be a really short one!) somebody actually
> > go out and get consensus from a number of important distros. Besides
> > Barry, do we have any representatives of distros here?
> 
> Matthias Klose represents Debian, Dave Malcolm represents Redhat,
> and Dirkjan Ochtman represents Gentoo.

Current status within RHEL and Fedora:
  The "python" rpm package has:
    - a "/usr/bin/python", which is the "system" build of Python 2
    - hardlinked with "/usr/bin/python2.N" (where N is the appropriate
minor release number; currently 2.7 for Fedora 14 onwards)
    - a symlink "/usr/bin/python2", pointing at "/usr/bin/python"

  There are a number of other rpm packages with names matching "*py*",
which use the system build of Python 3

  There is a "python3" package on Fedora 13 onwards with:
    - a "/usr/bin/python3", which is the "system" build of Python 3
    - hardlinked with "/usr/bin/python3.N" (where N is the appropriate
minor release number; will be 3.2 as of Fedora 15)

  There are number of add-on rpm packages containing 3rd-party Python 3
code with names of the form "python3-*".

  Some more status on our pre-packaged Python 3 stack can be seen here:
     https://fedoraproject.org/wiki/Python3

  I've also added "python-debug" and "python3-debug" binaries,
containing --with-pydebug builds of the same code.

On a related note, we have a number of scripts packaged across the
distributions with a shebang line that reads:
   #!/usr/bin/env python
which AIUI follows upstream recommendations.

There was a proposal to change these when packaging them to hardcode the
specific python binary:

https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
on the grounds that a packaged system script is expecting (and has been
tested against) a specific python build.

That proposal has not yet been carried out.  Ideally if we did this,
we'd implement it as a postprocessing phase within "rpmbuild", rather
than manually patching hundreds of files.

Note that this would only cover shebang lines at the tops of scripts.

If a 3rd-party program launches python directly, that could fail, and I
don't see a convenient way of fixing every reference in all code in all
packages (without, say, running a SystemTap script to monitor for
programs exec-ing "/usr/bin/python")

For example, I wonder what the automake macro for detecting python would
make of a /usr/bin/python that's python 3:
  http://www.gnu.org/software/hello/manual/automake/Python.html
I've seen a few hand-coded makefiles for Python extension modules that
were broken by the SOABI changes in PEP 3149.  To be fair, thouse
makefiles were badly written, but I think that changing the meaning
of /usr/bin/python would break a lot of things.

FWIW, I don't see the harm in providing a /usr/bin/python2 symlink, but
I don't plan to change /usr/bin/python at this time.


Hope this is helpful
Dave



From dmalcolm at redhat.com  Thu Mar  3 20:27:01 2011
From: dmalcolm at redhat.com (David Malcolm)
Date: Thu, 03 Mar 2011 14:27:01 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <1299179864.15972.5.camel@radiator.bos.redhat.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
Message-ID: <1299180421.15972.10.camel@radiator.bos.redhat.com>

On Thu, 2011-03-03 at 14:17 -0500, David Malcolm wrote:
> On Wed, 2011-03-02 at 01:14 +0100, "Martin v. L?wis" wrote:

>   There are a number of other rpm packages with names matching "*py*",
> which use the system build of Python 3
Gah; I meant Python 2 here.


(Must proofread my screeds before posting them)


From techtonik at gmail.com  Thu Mar  3 21:31:18 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 3 Mar 2011 22:31:18 +0200
Subject: [Python-Dev] unittest.main() --catch parameter
Message-ID: <AANLkTint=RD2boqoeeoWQMqG_vRUF1xhpWMgC45vsLSS@mail.gmail.com>

I am looking at --help of test runner and asking the question: what is
the use case for -c, --catch option? It doesn't look like it should be
present in generic runner. I also can't find reasons to waste short
option for it. There will be big problems with people complaining
about BC break even if this option is not used by anyone.

Usage: tests.py [options] [test] [...]

Options:
  -h, --help       Show this message
  -v, --verbose    Verbose output
  -q, --quiet      Minimal output
  -f, --failfast   Stop on first failure
  -c, --catch      Catch control-C and display results
  -b, --buffer     Buffer stdout and stderr during test runs


--
anatoly t.

From fuzzyman at voidspace.org.uk  Thu Mar  3 21:44:06 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 03 Mar 2011 20:44:06 +0000
Subject: [Python-Dev] unittest.main() --catch parameter
In-Reply-To: <AANLkTint=RD2boqoeeoWQMqG_vRUF1xhpWMgC45vsLSS@mail.gmail.com>
References: <AANLkTint=RD2boqoeeoWQMqG_vRUF1xhpWMgC45vsLSS@mail.gmail.com>
Message-ID: <4D6FFD96.3010809@voidspace.org.uk>

On 03/03/2011 20:31, anatoly techtonik wrote:
> I am looking at --help of test runner and asking the question: what is
> the use case for -c, --catch option?
It catches keyboard interrupt and instead of just bombing out of the 
test run it reports all the results collected so far.

Without this option interrupting a test run with a ctrl-c kills the run 
and reports nothing. Seeing an unexpected failure or error during a long 
test run and having to wait to the end of the test run to see the 
traceback can be annoying, this feature solves that problem.

> It doesn't look like it should be
> present in generic runner. I also can't find reasons to waste short
> option for it.

Nose, django and other test runners provide this option, so it is 
functionality that people seem to value.

> There will be big problems with people complaining
> about BC break even if this option is not used by anyone.
>

I don't understand this sentence, sorry.

All the best,

Michael Foord
> Usage: tests.py [options] [test] [...]
>
> Options:
>    -h, --help       Show this message
>    -v, --verbose    Verbose output
>    -q, --quiet      Minimal output
>    -f, --failfast   Stop on first failure
>    -c, --catch      Catch control-C and display results
>    -b, --buffer     Buffer stdout and stderr during test runs
>
>
> --
> anatoly t.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From solipsis at pitrou.net  Thu Mar  3 22:43:02 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 3 Mar 2011 22:43:02 +0100
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into
	Python 3.3)
References: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
	<97D7A72F-198C-409B-A684-0AA851A9E438@gmail.com>
Message-ID: <20110303224302.4a847d3e@pitrou.net>

On Thu, 3 Mar 2011 09:24:29 -0800
Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
> 
> On Mar 3, 2011, at 4:40 AM, anatoly techtonik wrote:
> 
> > How about official RoadMap? There is no visibility into what's going
> > on in Python development. New people can' t jump in and help do bring
> > some features faster. http://dungeonhack.sourceforge.net/Roadmap
> 
> Thanks for the link.  Their roadmap made my day:
> 
>    High priority: code to spawn spiders in the forest
>    Medium priority: write pet rat fetch quest
> 
> And best of all, the "animate rat" task is assigned to "Musk of Ephesus".

You need quite some musk to animate a rat.

PS: this isn't meant to be a statement about distutils




From techtonik at gmail.com  Thu Mar  3 22:54:35 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 3 Mar 2011 23:54:35 +0200
Subject: [Python-Dev] unittest.main() --catch parameter
In-Reply-To: <4D6FFD96.3010809@voidspace.org.uk>
References: <AANLkTint=RD2boqoeeoWQMqG_vRUF1xhpWMgC45vsLSS@mail.gmail.com>
	<4D6FFD96.3010809@voidspace.org.uk>
Message-ID: <AANLkTikmFkzXhEquSFcSEXCHNPh6hzuBogOunYV+Siie@mail.gmail.com>

On Thu, Mar 3, 2011 at 10:44 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 03/03/2011 20:31, anatoly techtonik wrote:
>>
>> I am looking at --help of test runner and asking the question: what is
>> the use case for -c, --catch option?
>
> It catches keyboard interrupt and instead of just bombing out of the test
> run it reports all the results collected so far.
>
> Without this option interrupting a test run with a ctrl-c kills the run and
> reports nothing. Seeing an unexpected failure or error during a long test
> run and having to wait to the end of the test run to see the traceback can
> be annoying, this feature solves that problem.

Why not just leave this behavior by default and just return -1 if the
Ctrl-C was pressed?

>> It doesn't look like it should be
>> present in generic runner. I also can't find reasons to waste short
>> option for it.
>
> Nose, django and other test runners provide this option, so it is
> functionality that people seem to value.
>
>> There will be big problems with people complaining
>> about BC break even if this option is not used by anyone.
>>
>
> I don't understand this sentence, sorry.

If the option is useless, people won't allow to remove it, because it
will break "backward compatibility" (BC), even if they don't use this
option themselves.

> All the best,
>
> Michael Foord
>>
>> Usage: tests.py [options] [test] [...]
>>
>> Options:
>> ? -h, --help ? ? ? Show this message
>> ? -v, --verbose ? ?Verbose output
>> ? -q, --quiet ? ? ?Minimal output
>> ? -f, --failfast ? Stop on first failure
>> ? -c, --catch ? ? ?Catch control-C and display results
>> ? -b, --buffer ? ? Buffer stdout and stderr during test runs
>>
>>
>> --
>> anatoly t.
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at 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
>
>

From foom at fuhm.net  Thu Mar  3 22:57:49 2011
From: foom at fuhm.net (James Y Knight)
Date: Thu, 3 Mar 2011 16:57:49 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110303085525.GQ30982@piotro.eu>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
Message-ID: <4F6CD200-2661-458C-B9E7-9202A6F4413A@fuhm.net>

On Mar 3, 2011, at 3:55 AM, Piotr O?arowski wrote:
> I don't really mind adding /usr/bin/python2 symlink just to clean Arch mess

Is there any chance you would add the symlink in the next Debian stable point release? If both Debian and Python upstream added the python2 symlink in the next stable update rather than waiting for the next major release (which for Python itself is of course "never"), that could reduce the problem of systems not having the symlink installed quite significantly.

James

From fuzzyman at voidspace.org.uk  Thu Mar  3 22:58:21 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 03 Mar 2011 21:58:21 +0000
Subject: [Python-Dev] unittest.main() --catch parameter
In-Reply-To: <AANLkTikmFkzXhEquSFcSEXCHNPh6hzuBogOunYV+Siie@mail.gmail.com>
References: <AANLkTint=RD2boqoeeoWQMqG_vRUF1xhpWMgC45vsLSS@mail.gmail.com>
	<4D6FFD96.3010809@voidspace.org.uk>
	<AANLkTikmFkzXhEquSFcSEXCHNPh6hzuBogOunYV+Siie@mail.gmail.com>
Message-ID: <4D700EFD.4080700@voidspace.org.uk>

On 03/03/2011 21:54, anatoly techtonik wrote:
> On Thu, Mar 3, 2011 at 10:44 PM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>> On 03/03/2011 20:31, anatoly techtonik wrote:
>>> I am looking at --help of test runner and asking the question: what is
>>> the use case for -c, --catch option?
>> It catches keyboard interrupt and instead of just bombing out of the test
>> run it reports all the results collected so far.
>>
>> Without this option interrupting a test run with a ctrl-c kills the run and
>> reports nothing. Seeing an unexpected failure or error during a long test
>> run and having to wait to the end of the test run to see the traceback can
>> be annoying, this feature solves that problem.
> Why not just leave this behavior by default and just return -1 if the
> Ctrl-C was pressed?
>

Because it means installing a signal handler which is not necessarily 
appropriate for all test systems. We *could* make it the default in the 
future (for the test runner only - not when unittest is used via the api).

>>> It doesn't look like it should be
>>> present in generic runner. I also can't find reasons to waste short
>>> option for it.
>> Nose, django and other test runners provide this option, so it is
>> functionality that people seem to value.
>>
>>> There will be big problems with people complaining
>>> about BC break even if this option is not used by anyone.
>>>
>> I don't understand this sentence, sorry.
> If the option is useless, people won't allow to remove it, because it
> will break "backward compatibility" (BC), even if they don't use this
> option themselves.

So you want it on by default but are also worried about the backwards 
compatibility issues of it even existing as an option? Anyway, your 
assertion that the option is or may be useless is unfounded. Don't worry 
about it.

All the best,

Michael Foord

>> All the best,
>>
>> Michael Foord
>>> Usage: tests.py [options] [test] [...]
>>>
>>> Options:
>>>    -h, --help       Show this message
>>>    -v, --verbose    Verbose output
>>>    -q, --quiet      Minimal output
>>>    -f, --failfast   Stop on first failure
>>>    -c, --catch      Catch control-C and display results
>>>    -b, --buffer     Buffer stdout and stderr during test runs
>>>
>>>
>>> --
>>> anatoly t.
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at 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
>>
>>


-- 
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


From techtonik at gmail.com  Thu Mar  3 23:12:35 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 4 Mar 2011 00:12:35 +0200
Subject: [Python-Dev] contributors survey?
In-Reply-To: <87wrki8dn9.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<AANLkTi=4Vn4E4sgmS3bs6TpPDDJTX6g3=bFhSLtu1Zu9@mail.gmail.com>
	<20110301233210.5d6206e6@pitrou.net>
	<87wrki8dn9.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTinVh6O+heJThKSr07aWUCWdkv25NMrgxJyNL5ni@mail.gmail.com>

On Wed, Mar 2, 2011 at 4:22 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Antoine Pitrou writes:
>
> ?> Following the example given in the original article, I was considering
> ?> a single freeform question: "why did you stop contributing after your
> ?> last patch to CPython?" (of course, that text should be decorated with
> ?> a greeting and an introduction and the wording can be improved).
>
> Does anybody ever stop contributing? ?Occasionally, yes, but in most
> cases it's just that this interval between explicit contributions
> (usually patches, but also reviews, PEPs, mailing list posting, bug
> reports, ...) is longer than the period since the last one. :-)
>
> How about
>
> ? ?Hello. ?We [the PSF?] would like to thank you for your past
> ? ?patches to CPython, and take this opportunity to learn something
> ? ?about how to improve our workflow. ?We would appreciate your
> ? ?cooperation in answering the following question.
>
> ? ?It has been more than one year since your last patch to CPython.
> ? ?We would like to understand why it's been so long [, and if there
> ? ?is anything we could do to help you contribute patches more
> ? ?frequently].
>
> The clause in brackets is outside the scope of Antoine's wording, but
> I assume that's where we're going with this.

Unpythonic, without human touch, dull and boring, sounds like a letter
from some executive, who was pushed for bad performance. Such letters
are bad for digestion and not tasty to reply. How about making it more
personal? Why the distinction of "we" and "you"? How about s/we/BDFL/
and take the tone appropriate?

  Hi there. BDFL was watching you, and now wants to know why
  are you not contributing patches anymore? If there is something
  for you to say, please tell everyone, or else we all may be in
  trouble! Thanks for being the part of Python Community. Sigh.


Your English may vary.
-- 
anatoly t.

From techtonik at gmail.com  Thu Mar  3 23:13:49 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 4 Mar 2011 00:13:49 +0200
Subject: [Python-Dev] contributors survey?
In-Reply-To: <1299036300.3153.1.camel@localhost.localdomain>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
Message-ID: <AANLkTi=xprC_DTU52XqSMkhFH1uzaNAcN7hzAnOsk+jL@mail.gmail.com>

On Wed, Mar 2, 2011 at 5:25 AM, Westley Mart?nez <anikom15 at gmail.com> wrote:
> If I got a message like that in my mailbox I would be rather annoyed,
> mark it as spam, and be less likely to contribute again.
>
> Just my point of view.

+1
--
anatoly t.

From techtonik at gmail.com  Fri Mar  4 00:38:09 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 4 Mar 2011 01:38:09 +0200
Subject: [Python-Dev] contributors survey?
In-Reply-To: <AANLkTikh9ETJUFAEfA46AsL7KpuDY+Z4AH2=CjS2i6GE@mail.gmail.com>
References: <1299014648.3709.16.camel@localhost.localdomain>
	<1299036300.3153.1.camel@localhost.localdomain>
	<20110302130805.3ca921fc@pitrou.net>
	<AANLkTinmN_1JbG0XsqH_a=EvUSbiQS3crarHCdHqD-8i@mail.gmail.com>
	<20110302133957.22d36065@pitrou.net>
	<AANLkTikh9ETJUFAEfA46AsL7KpuDY+Z4AH2=CjS2i6GE@mail.gmail.com>
Message-ID: <AANLkTin_Jpv7mt5JRS=48NPBwHZxubMAUDzqpOTJ55e+@mail.gmail.com>

On Wed, Mar 2, 2011 at 2:54 PM, Andrew Svetlov <andrew.svetlov at gmail.com> wrote:
>>
>> Will Mercurial make things more attractive?
>>
> Definitely yes! I welcome upcoming migration.
>
>>> And, of course, very long lifecycle of the most issues greatly reduces
>>> enthusisasm.
>>
>> True. I believe we are improving that, but perhaps that's a
>> misperception on my part.
>>
>
> I understand reasons for that situation and really doubt if process
> can be significantly accelerated.
> But it just very unconvenient.

Actually, it can. Many people are actually interested in helping
specific parts of Python, but the only way they currently have in
participating in the process is to monitor the whole flow and filter
interesting parts manually. No one has time for that. But it is not
impossible to do - I've created an issue in case somebody would like
to work with me on this
http://code.google.com/p/pydotorg/issues/detail?id=8
-- 
anatoly t.

From victor.stinner at haypocalc.com  Fri Mar  4 01:58:05 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 04 Mar 2011 01:58:05 +0100
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
Message-ID: <1299200285.14313.7.camel@marge>

Hi,

Some months ago, I proposed a patch to display the Python backtrace on a
segfault. The API was not stable, it was too for Python 3.2, and it was
enabled by default. I wrote a module instead of a patch so it can be
used on any version of Python, and it has a better API. And now I would
like to include the module into Python directly to use it more easily.
See http://bugs.python.org/issue11393 for the details. The module:

   https://github.com/haypo/faulthandler

It is now possible to dump the backtrace on an user signal (eg. SIGUSR1)
or after a delay in seconds (it may be useful for buildbot hangs without
user interaction). You can choose to display the current thread or all
threads, and in which file the trace is written.

So, what do you think?

Victor


From techtonik at gmail.com  Fri Mar  4 02:33:14 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 4 Mar 2011 03:33:14 +0200
Subject: [Python-Dev] unittest.main() --catch parameter
In-Reply-To: <4D700EFD.4080700@voidspace.org.uk>
References: <AANLkTint=RD2boqoeeoWQMqG_vRUF1xhpWMgC45vsLSS@mail.gmail.com>
	<4D6FFD96.3010809@voidspace.org.uk>
	<AANLkTikmFkzXhEquSFcSEXCHNPh6hzuBogOunYV+Siie@mail.gmail.com>
	<4D700EFD.4080700@voidspace.org.uk>
Message-ID: <AANLkTim_MeDkmtOULUZGiu1NaEU_r-mSYMKpDbO=yKz6@mail.gmail.com>

On Thu, Mar 3, 2011 at 11:58 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
>>>
>>> Without this option interrupting a test run with a ctrl-c kills the run
>>> and
>>> reports nothing. Seeing an unexpected failure or error during a long test
>>> run and having to wait to the end of the test run to see the traceback
>>> can
>>> be annoying, this feature solves that problem.
>>
>> Why not just leave this behavior by default and just return -1 if the
>> Ctrl-C was pressed?
>>
>
> Because it means installing a signal handler which is not necessarily
> appropriate for all test systems. We *could* make it the default in the
> future (for the test runner only - not when unittest is used via the api).

What does it mean - "not approriate"? Do signal handlers crash or kill
people on some test systems? If tests are run with output buffering
then it's reasonable to turn off handling of Ctrl-C. If they are
executed by buildbots, I don't see how it hurts the test process. In
any case there should be a way to turn Ctrl-C handing using some
internal flag, but moving it into user command doesn't seem like a
good idea to me.

By the way, is calling unittest.main() is using unittest via api?

> So you want it on by default but are also worried about the backwards
> compatibility issues of it even existing as an option? Anyway, your
> assertion that the option is or may be useless is unfounded. Don't worry
> about it.

I am worried that I won't have space to add more useful options to the
runner or they will be lost for users in the abundance of highly
technical parameters that runner provides. I am concerned that users
will never ever understand the true Awesomeness of the New Runner
(tm). ;)
-- 
anatoly t.

From barry at python.org  Fri Mar  4 03:04:18 2011
From: barry at python.org (Barry Warsaw)
Date: Thu, 3 Mar 2011 21:04:18 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110303085525.GQ30982@piotro.eu>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
Message-ID: <20110303210418.11070708@neurotica.wooz.org>

On Mar 03, 2011, at 09:55 AM, Piotr O?arowski wrote:

>I don't really mind adding /usr/bin/python2 symlink just to clean Arch
>mess, but I do mind changing /usr/bin/python to point to python3 (and I
>can use the same argument - "Explicit is better than implicit" - if you
>need Python 3, say so in the shebang, right?). What I'm afraid of is
>when we'll add /usr/bin/python2, we'll start getting a lot of scripts
>that will have to be checked manually every time new upstream version is
>released because we cannot assume what upstream author is using at given
>point.
>
>If /usr/bin/python will be disallowed in shebangs on the other hand
>(and all scripts will use /usr/bin/python2, /usr/bin/python3,
>/usr/bin/python4 or /usr/bin/python2.6 etc.) I don't see a problem with
>letting administrators choose /usr/bin/python (right now not only
>changing it from python2.X to python3.X will break the system but also
>changing it from /usr/bin/pytohn2.X to /usr/bin/python2.Y will break it,
>and believe me, I know what I'm talking about (one of the guys at work
>did something like this once))
>
>[all IMHO, dunno if other Debian's python-defaults maintainers agree
>with me]

This all seems reasonable to me, except that I think it would be good at some
point -- which might be in several years -- to point /usr/bin/python to
python3.  We are not there now, but I do think we will be there one day.

I also don't think we have to worry about a Python 4.  I'm skeptical it will
ever happen, because really, how many big warts in Python 3 do you think we'll
need to break in a backward incompatible way?  If it does, and history holds
true, it'll be 15 years from now.  Then all you whippersnappers can do
whatever you like. :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/85a7679d/attachment.pgp>

From barry at python.org  Fri Mar  4 03:11:40 2011
From: barry at python.org (Barry Warsaw)
Date: Thu, 3 Mar 2011 21:11:40 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <1299179864.15972.5.camel@radiator.bos.redhat.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
Message-ID: <20110303211140.1e2280fd@neurotica.wooz.org>

On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:

>On a related note, we have a number of scripts packaged across the
>distributions with a shebang line that reads:
>   #!/usr/bin/env python
>which AIUI follows upstream recommendations.

Actually, I think this is *not* a good idea for distro provided scripts.  For
any Python scripts released by the distro, you know exactly which Python it
should run on, so it's better to hard code it.  That way, if someone installs
Python from source, or installs an experimental version of a new distro
Python, it won't break their system.  Yes, this has happened to me.  Also,
note that distutils/setuptools/distribute rewrite the shebang line when they
install scripts.

>There was a proposal to change these when packaging them to hardcode the
>specific python binary:
>
>https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
>on the grounds that a packaged system script is expecting (and has been
>tested against) a specific python build.
>
>That proposal has not yet been carried out.  Ideally if we did this,
>we'd implement it as a postprocessing phase within "rpmbuild", rather
>than manually patching hundreds of files.
>
>Note that this would only cover shebang lines at the tops of scripts.

JFDI!

FWIW, a quick grep reveals about two dozen such scripts in /usr/bin on
Ubuntu.  We should fix these. ;)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/920014c5/attachment.pgp>

From barry at python.org  Fri Mar  4 03:46:23 2011
From: barry at python.org (Barry Warsaw)
Date: Thu, 3 Mar 2011 21:46:23 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110303170804.GD3275@unaka.lan>
References: <4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
	<20110303170804.GD3275@unaka.lan>
Message-ID: <20110303214623.64e880ba@neurotica.wooz.org>

On Mar 03, 2011, at 09:08 AM, Toshio Kuratomi wrote:

>Thinking outside of the box, I can think of something that would satisfy
>your requirements but I don't know how appropriate it is for upstream python
>to ship with.  Stop shipping /usr/bin/python.  Ship "python" in an alternate
>location like $LIBEXECDIR/python2.7/bin (I think this would be
>/usr/lib/python2.7/bin on Debian and /usr/libexec/python2.7/bin on Fedora
>which would both be appropriate) then configure which python version is
>invoked by the user typing "python" by configuring PATH (a shell alias might
>also work).  You could configure this with environment-modules[1]_ if Debian
>supports using that in packaging.

I wonder if Debian's alternatives system would be appropriate for this?

http://wiki.debian.org/DebianAlternatives

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/7c4dedb4/attachment.pgp>

From a.badger at gmail.com  Fri Mar  4 05:09:54 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 3 Mar 2011 20:09:54 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110303211140.1e2280fd@neurotica.wooz.org>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
Message-ID: <20110304040954.GE3275@unaka.lan>

On Thu, Mar 03, 2011 at 09:11:40PM -0500, Barry Warsaw wrote:
> On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:
> 
> >On a related note, we have a number of scripts packaged across the
> >distributions with a shebang line that reads:
> >   #!/usr/bin/env python
> >which AIUI follows upstream recommendations.
> 
> Actually, I think this is *not* a good idea for distro provided scripts.  For
> any Python scripts released by the distro, you know exactly which Python it
> should run on, so it's better to hard code it.  That way, if someone installs
> Python from source, or installs an experimental version of a new distro
> Python, it won't break their system.  Yes, this has happened to me.  Also,
> note that distutils/setuptools/distribute rewrite the shebang line when they
> install scripts.
> 
> >There was a proposal to change these when packaging them to hardcode the
> >specific python binary:
> >
> >https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
> >on the grounds that a packaged system script is expecting (and has been
> >tested against) a specific python build.
> >
> >That proposal has not yet been carried out.  Ideally if we did this,
> >we'd implement it as a postprocessing phase within "rpmbuild", rather
> >than manually patching hundreds of files.
> >
> >Note that this would only cover shebang lines at the tops of scripts.
> 
> JFDI!
> 
> FWIW, a quick grep reveals about two dozen such scripts in /usr/bin on
> Ubuntu.  We should fix these. ;)
> 
Note, we were unable to pass Guideline changes to do this in Fedora.  Gory
details of the FPC meeting are at 16:15:03 (abadger1999 == me):
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.log.html

The mailing list thread where this was discussed is here:
http://lists.fedoraproject.org/pipermail/packaging/2009-July/006248.html

Note to dmalcolm: IIRC, that also means that the Feature page you point to
isn't going to happen either.  Barry -- if other distros adopted stronger
policies, then that might justify me taking this back to the Packaging
Committee.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/c2edb995/attachment.pgp>

From a.badger at gmail.com  Fri Mar  4 05:37:07 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 3 Mar 2011 20:37:07 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110303214623.64e880ba@neurotica.wooz.org>
References: <4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
	<20110303170804.GD3275@unaka.lan>
	<20110303214623.64e880ba@neurotica.wooz.org>
Message-ID: <20110304043707.GF3275@unaka.lan>

On Thu, Mar 03, 2011 at 09:46:23PM -0500, Barry Warsaw wrote:
> On Mar 03, 2011, at 09:08 AM, Toshio Kuratomi wrote:
> 
> >Thinking outside of the box, I can think of something that would satisfy
> >your requirements but I don't know how appropriate it is for upstream python
> >to ship with.  Stop shipping /usr/bin/python.  Ship "python" in an alternate
> >location like $LIBEXECDIR/python2.7/bin (I think this would be
> >/usr/lib/python2.7/bin on Debian and /usr/libexec/python2.7/bin on Fedora
> >which would both be appropriate) then configure which python version is
> >invoked by the user typing "python" by configuring PATH (a shell alias might
> >also work).  You could configure this with environment-modules[1]_ if Debian
> >supports using that in packaging.
> 
> I wonder if Debian's alternatives system would be appropriate for this?
> 
> http://wiki.debian.org/DebianAlternatives
> 


No, alternatives is really only useful for a very small class of problems
[1]_ and [2]_.  For this discussion there's an additional problem which is
that alternatives works by creating symlinks.  Piotr O?arowski wants to make
/usr/bin/python not exist so that scripts would have to use either
/usr/bin/python3 or /usr/bin/python2.  If alternatives places a symlink
there, it defeats the purpose of avoiding that path in the package itself.

I will note, though that scripts that have /usr/bin/env and take the route
of setting the PATH would still fall victim to this.  I think that
environment-modules can also set up aliases.  If so, that wouldbe better
than setting PATH for finding and removing "python" without a version in
scripts.

One further note on this since one of the other messages here had
a reference to this that kinda rains on this parade:
http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Languages/LSB-Languages/pylocation.html

The LSB is a standard that Linux distributions may or may not follow --
unlike the FHS, the LSB goes beyond encoding what most distros already do to
things that they think people should do.  For instance, Debian derivatives
might find the software installation section of LSB[3]_ to be a bit... hard
to swallow.  Fedora provides a package which aims to make a fedora system
lsb compliant but doesn't install it by default since it drags in gobs of
packages that are otherwise not necessary on many systems.

However, it does specify /usr/bin/python so getting rid of /usr/bin/python
at the Linux distribution level might not reach universal aclaim.  A united
front from upstream python through the python package maintainers on the
Linux distros would probably be needed to get people thinking about making
this change... and we still would likely have the ability to add
/usr/bin/python back onto a system (for instance, as part of that lsb
package I mentioned earlier.)

.. [1]:
https://fedoraproject.org/wiki/Packaging:EnvironmentModules#Introduction
.. [2]:
http://fedoraproject.org/wiki/Packaging:Alternatives#Recommended_usage

.. [3]:
http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110303/417dcf9c/attachment.pgp>

From mail at kerrickstaley.com  Fri Mar  4 08:35:44 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Fri, 4 Mar 2011 01:35:44 -0600
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110304040954.GE3275@unaka.lan>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
Message-ID: <AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>

> LGTM. Please specify what /usr/bin/python is supposed to be also
> (rather: the "python" utility). I'd like it ruled out that
> installations *only* provide python2 and python3 - "python" could
> be either one, but should be present "normally" (i.e. SHOULD
> in the RFC 2119 sense).
>
> Nitpickingly, I'd add that scripts can, of course, also specify
> python2.7 (or some such). Actually, scripts can do whatever they
> want - it's more about what they then can expect to happen.
Good points--I've taken them into account in the revised PEP, which I will
send to this list shortly.
> OTOH, my
> cynical side doubts that script authors read PEPs so it'll take either
> upstream python shipping without /usr/bin/python or consensus among the
> distros to ship without /usr/bin/python to reach the point where script
> authors realize that they need to use /usr/bin/python{2,3} instead of
> /usr/bin/python.
I don't see this as an issue: all it will take is for one user with a
different "python" to contact a developer once, referring the developer to
the PEP, and then every program that that developer ever writes in the
future will be fixed (and, if the developer's worth anything, every program
he's already written, as well). Word of mouth tends to pass these things
around quickly.
> Actually, I think this is *not* a good idea for distro provided scripts.
 For
> any Python scripts released by the distro, you know exactly which Python
it
> should run on, so it's better to hard code it.  That way, if someone
installs
> Python from source, or installs an experimental version of a new distro
> Python, it won't break their system.
I agree. I would personally like it if distributions would provide a python
utility that can be changed by the sysadmin without breaking anything, but
implementing such a thing would be too much to ask from many distros, so I
left it out of the first draft of the PEP. I'll put into the Notes in the
second draft, though.

Again, I think that the nature of the "python" utility is a decision that
belongs squarely to the distributions (it'll likely evolve into an "everyone
else is doing it" sort of issue for distros like Debian that don't like to
change without good reason). On the other hand, ensuring that cross-platform
support exists is an issue that should be handled by a central authority.

I almost added provisions to the second draft of the PEP for things like
"python2.6", since the same issue basically exists with them, so it would be
logical to also address their support. However, since there are far fewer
cases where minor version changes break code, and far more cases where a
specific minor version of the Python interpreter isn't and doesn't need to
be installed, I imagine a problem will occur if we make "pythonX.X"
standard: developers will use the "pythonX.X" invocations instead of
ensuring their code works on all (recent) versions of the interpreter, and
much larger issues will arise when users are forced to repeatedly install
different minor versions of the interpreter. I instead addressed this topic
in the "Notes" section.

-Kerrick Staley

On Thu, Mar 3, 2011 at 10:09 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:

> On Thu, Mar 03, 2011 at 09:11:40PM -0500, Barry Warsaw wrote:
> > On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:
> >
> > >On a related note, we have a number of scripts packaged across the
> > >distributions with a shebang line that reads:
> > >   #!/usr/bin/env python
> > >which AIUI follows upstream recommendations.
> >
> > Actually, I think this is *not* a good idea for distro provided scripts.
>  For
> > any Python scripts released by the distro, you know exactly which Python
> it
> > should run on, so it's better to hard code it.  That way, if someone
> installs
> > Python from source, or installs an experimental version of a new distro
> > Python, it won't break their system.  Yes, this has happened to me.
>  Also,
> > note that distutils/setuptools/distribute rewrite the shebang line when
> they
> > install scripts.
> >
> > >There was a proposal to change these when packaging them to hardcode the
> > >specific python binary:
> > >
> > >
> https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
> > >on the grounds that a packaged system script is expecting (and has been
> > >tested against) a specific python build.
> > >
> > >That proposal has not yet been carried out.  Ideally if we did this,
> > >we'd implement it as a postprocessing phase within "rpmbuild", rather
> > >than manually patching hundreds of files.
> > >
> > >Note that this would only cover shebang lines at the tops of scripts.
> >
> > JFDI!
> >
> > FWIW, a quick grep reveals about two dozen such scripts in /usr/bin on
> > Ubuntu.  We should fix these. ;)
> >
> Note, we were unable to pass Guideline changes to do this in Fedora.  Gory
> details of the FPC meeting are at 16:15:03 (abadger1999 == me):
>
> http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.log.html
>
> The mailing list thread where this was discussed is here:
> http://lists.fedoraproject.org/pipermail/packaging/2009-July/006248.html
>
> Note to dmalcolm: IIRC, that also means that the Feature page you point to
> isn't going to happen either.  Barry -- if other distros adopted stronger
> policies, then that might justify me taking this back to the Packaging
> Committee.
>
> -Toshio
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/dd9307ca/attachment-0001.html>

From mail at kerrickstaley.com  Fri Mar  4 08:44:00 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Fri, 4 Mar 2011 01:44:00 -0600
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
Message-ID: <AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>

PEP: ???
Title: The python Utility on Unix-Like Systems
Version: ???
Last-Modified: ???
Author: Kerrick Staley <mail at kerrickstaley.com>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: ???

Abstract
==========
This PEP provides a convention to ensure that Python scripts can continue to
be portable across *nix systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the "python" utility).

Recommendation
================

* ``*nix`` software distributions should install the "python2" utility into
the default path whenever a version of the Python 2 interpreter is
installed, and the same for "python3" and the Python 3 interpreter. When
invoked, "python2" should run some version of the Python 2 interpreter, and
"python3" should run some version of the Python 3 interpreter. The same
applies for the more general "python" command, which should should be
installed whenever any version of Python is installed and should invoke some
Python interpreter.
* All new 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).
This distinction should be made in shebangs, when invoking from a shell
script, when invoking via the system() call, or when invoking in any other
context.

Rationale
===========

This is needed because some distributions alias the "python" command to
Python 3, while others alias it to Python 2. Some of the latter also do not
provide a "python2" command; hence, there is no way for Python 2 code (or
any code that invokes the Python 2 interpreter) to reliably run on all
systems without modification, because both the "python" and the "python2"
commands will fail on some systems. The recommendations in this PEP provide
a very simple mechanism to restore cross-platform support, with very little
additional work required on the part of distribution maintainers.

Notes
=======

* Distributions can alias the "python" command to whichever version of the
Python interpreter they choose.
* The "pythonX.X" (e.g. "python2.6") utilities exist on some systems, on
which they invoke specific minor versions of the Python interpreter. It
would be wise for distribution-specific packages to take advantage of these
utilities if they exist, since it will prevent code breakage if the default
minor version of a given major version is changed. However, scripts
intending to be cross-platform should not rely on the presence of these
utilities, but rather should be tested on several recent minor versions of
the target major version, compensating, if necessary, for the small
differences that exist between minor versions. This prevents the need for
sysadmins to install many very similar versions of the interpreter.
* It would be wise for distribution-specific packages to always follow the
"python2"/"python3" convention, even in code that is not intended to operate
on other distributions. This will prevent problems if the distribution
decides to upgrade the version of the Python interpreter that the "python"
command invokes, or if the sysadmin installs a custom "python" utility with
a different major version than the distribution default. Distributions can
test whether they are fully following this convention by changing the
"python" interpreter on a test box and checking to see if anything breaks.
* If the above point is adhered to and sysadmins are permitted to change the
"python" utility, then the "python" utility should always be implemented as
link to the interpreter binary (or a link to a link) and not vice versa.
That way, if the sysadmin does decide to replace the installed "python"
file, he can do so without inadvertently deleting the previously installed
binary.
* The first recommendation can be ignored for systems on which the "python"
command itself has traditionally been left undefined and users have always
had the responsibility of linking the "python" command to the Python
interpreter.
* 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
is released.
* If these conventions are adhered to, it will be the case that the "python"
utility is only executed in an interactive manner.

Backwards Compatibility
=========================
A potential problem can arise if a script adhering to the
"python2"/"python3" convention is executed on a system not supporting these
commands. This is mostly a non-issue, since the sysadmin can simply create
these symbolic links and avoid further problems.

Copyright
===========
This document has been placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/9a69c33f/attachment.html>

From martin at v.loewis.de  Fri Mar  4 09:35:38 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 04 Mar 2011 09:35:38 +0100
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
Message-ID: <4D70A45A.5090609@v.loewis.de>

Google Summer of Code is coming up again, and we will again
be participating. Arc Riley will setup infrastructure later
today, and we need to start thinking about possible projects.

Traditionally, people (students and other projects) have been willing
to give the Python Core the highest attention in SoC, as improvements
to Python will help the whole community. Also traditionally, there has
been a shortage of project ideas and mentors for Python Core. My guess
is that the project shortage stems from the assumption that many of the
projects are so tricky that you can't give them to a newcomer. I found
this view both confirmed and rebutted in the past - it all depends on
which students we can attract.

The shortage of mentors is probably more inherent, and reflects the
shortage of volunteers for other tasks. As a long-time mentor, I'd
like to encourage all of you to consider mentoring this year. GSoC/PSF
will have a strict rule "one student per mentor", co-mentorship
is encouraged.

Feel free to discuss Python-Core-GSoC here or on the GSoC mailing
list(s) (soon to appear).

One last cautioning: recently, people started proposing that admin
tasks be done in GSoC. While that indeed may help python-dev most,
they called it summer of *code* deliberately - so the project idea
should be about programming (the hope being, of course, that the
students stay in the project, or at least in open source, when the
summer is over. some do, some don't.).

Regards,
Martin



From aaron.devore at gmail.com  Fri Mar  4 09:54:40 2011
From: aaron.devore at gmail.com (Aaron DeVore)
Date: Fri, 4 Mar 2011 00:54:40 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
Message-ID: <AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>

On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley <mail at kerrickstaley.com> wrote:
> That way, if the sysadmin does decide to replace the installed "python" file, he can do so without inadvertently deleting the previously installed binary.

Nit pick: Change "he" to "they" to be gender neutral.

-Aaron DeVore

From piotr at debian.org  Fri Mar  4 09:56:42 2011
From: piotr at debian.org (Piotr =?utf-8?Q?O=C5=BCarowski?=)
Date: Fri, 4 Mar 2011 09:56:42 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110303170804.GD3275@unaka.lan>
References: <20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
	<20110303170804.GD3275@unaka.lan>
Message-ID: <20110304085642.GR30982@piotro.eu>

[Toshio Kuratomi, 2011-03-03]
> On Thu, Mar 03, 2011 at 09:55:25AM +0100, Piotr O?arowski wrote:
> > If /usr/bin/python will be disallowed in shebangs on the other hand
> > (and all scripts will use /usr/bin/python2, /usr/bin/python3,
> > /usr/bin/python4 or /usr/bin/python2.6 etc.) I don't see a problem with
> > letting administrators choose /usr/bin/python (right now not only
> > changing it from python2.X to python3.X will break the system but also
> > changing it from /usr/bin/python2.X to /usr/bin/python2.Y will break it,
> > and believe me, I know what I'm talking about (one of the guys at work
> > did something like this once))
> > 
> > [all IMHO, dunno if other Debian's python-defaults maintainers agree
> > with me]
> >
> Thinking outside of the box, I can think of something that would satisfy
> your requirements but I don't know how appropriate it is for upstream python
> to ship with.  Stop shipping /usr/bin/python.  Ship "python" in an alternate
> location

to be honest, I didn't want to be so radical, a clear policy (PEP?)
would be enough for me - we'd then replace all /usr/bin/python shebangs
with /usr/bin/python2 at build time (with a warning to report bug
upstream) and forward all complainers to this PEP)
-- 
Piotr O?arowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

From fijall at gmail.com  Fri Mar  4 11:38:54 2011
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 4 Mar 2011 12:38:54 +0200
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
In-Reply-To: <4D70A45A.5090609@v.loewis.de>
References: <4D70A45A.5090609@v.loewis.de>
Message-ID: <AANLkTin261KPx6WTv7OThjm1ivEO-7eF6X6ACst_MGkA@mail.gmail.com>

On Fri, Mar 4, 2011 at 10:35 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Google Summer of Code is coming up again, and we will again
> be participating. Arc Riley will setup infrastructure later
> today, and we need to start thinking about possible projects.
>
> Traditionally, people (students and other projects) have been willing
> to give the Python Core the highest attention in SoC, as improvements
> to Python will help the whole community. Also traditionally, there has
> been a shortage of project ideas and mentors for Python Core. My guess
> is that the project shortage stems from the assumption that many of the
> projects are so tricky that you can't give them to a newcomer. I found
> this view both confirmed and rebutted in the past - it all depends on
> which students we can attract.
>
> The shortage of mentors is probably more inherent, and reflects the
> shortage of volunteers for other tasks. As a long-time mentor, I'd
> like to encourage all of you to consider mentoring this year. GSoC/PSF
> will have a strict rule "one student per mentor", co-mentorship
> is encouraged.
>
> Feel free to discuss Python-Core-GSoC here or on the GSoC mailing
> list(s) (soon to appear).

Hi Martin.

Would you consider working on benchmarking (http://speed.pypy.org but
also infrastructure for running it) a part of core GSoC work? I can
imagine this to be useful not only for pypy and preferably also
running CPython trunk on benchmarks.

>
> One last cautioning: recently, people started proposing that admin
> tasks be done in GSoC. While that indeed may help python-dev most,
> they called it summer of *code* deliberately - so the project idea
> should be about programming (the hope being, of course, that the
> students stay in the project, or at least in open source, when the
> summer is over. some do, some don't.).
>
> Regards,
> Martin
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

From ncoghlan at gmail.com  Fri Mar  4 12:04:14 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Mar 2011 21:04:14 +1000
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into
	Python 3.3)
In-Reply-To: <AANLkTim-0eT8Ph+99Hhfoy8XkxxTLxCs+ACmKkabLhpE@mail.gmail.com>
References: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
	<AANLkTimkQHFEPXa9gkLb8b+ubTzQfhuw+kt9B+uE8HAC@mail.gmail.com>
	<AANLkTim-0eT8Ph+99Hhfoy8XkxxTLxCs+ACmKkabLhpE@mail.gmail.com>
Message-ID: <AANLkTikMs2fFmFcY9Dmf1t5jA6chfJrV66CXwwA4pjqR@mail.gmail.com>

On Fri, Mar 4, 2011 at 3:26 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> Yes, there can (or even should) be a way for everybody with Python
> account to vote on items in the Roadmap and subscribe to updates (like
> commits, messages, code reviews, tweets and other stuff related to one
> item). This will give Jesse and teams a better picture, what sprints
> need funding. Tracker doesn't allow this - even though users can
> subscribe to Roundup issues, it just doesn't work for them. And the
> last distinction between Roadmap and Tracker is that the former gives
> you a quick overview of each item without going into the gory details
> of lengthy discussions.

But again, this is yet-another-tool that requires substantial
maintenance and curating. Anyone is free to create such a tool if they
want, and try to convince people to use it, and then try to convince
python-dev that feedback in that form is worth paying attention to.
You could even try to convince the PSF they should fund it. But coming
in and talking about what other people *should* do in an all-volunteer
environment is counterproductive.

Would such a tool really be a huge improvement over the python-ideas
mailing list (which is pretty freewheeling compared to what we
consider on-topic for python-dev itself), anyway? Sure, the tool would
provide more fancy features, but the barriers to participation would
also be much higher. Already, the number of people participating in
even python-list (let alone -ideas or -dev) is utterly dwarfed by the
total number of people using Python. Would a voting mechanism amongst
such a non-representative sample actually mean anything? Or is it
better to stick with the long-standing maxim of rough consensus and
running code?

All that said, if you really want a Roadmap, look at the list of
accepted, open and deferred PEPs in PEP 0. Those are the ideas that
someone has cared enough about to submit a PEP, and it hasn't been
summarily rejected by Guido (or his delegate).

For a nearer term Roadmap, you can look at the release PEP for the
upcoming release (although that is in such an early stage for 3.3 that
not only doesn't it exist yet, we don't even officially have an RM who
is going to write it).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar  4 12:10:13 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Mar 2011 21:10:13 +1000
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <1299200285.14313.7.camel@marge>
References: <1299200285.14313.7.camel@marge>
Message-ID: <AANLkTin1Nf8nHNE50ffOCp0JcdbooDs6i5Zk8tm6Bc4g@mail.gmail.com>

On Fri, Mar 4, 2011 at 10:58 AM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> Hi,
>
> Some months ago, I proposed a patch to display the Python backtrace on a
> segfault. The API was not stable, it was too for Python 3.2, and it was
> enabled by default. I wrote a module instead of a patch so it can be
> used on any version of Python, and it has a better API. And now I would
> like to include the module into Python directly to use it more easily.
> See http://bugs.python.org/issue11393 for the details. The module:
>
> ? https://github.com/haypo/faulthandler
>
> It is now possible to dump the backtrace on an user signal (eg. SIGUSR1)
> or after a delay in seconds (it may be useful for buildbot hangs without
> user interaction). You can choose to display the current thread or all
> threads, and in which file the trace is written.
>
> So, what do you think?

+1

It's a very helpful capability, and getting it in early in the 3.3
cycle will give us more time to refine the API and functionality.

Something we may want to consider is enabling it by default in
interactive mode, and also when `-i` is specified on the command line.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From victor.stinner at haypocalc.com  Fri Mar  4 12:30:47 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 04 Mar 2011 12:30:47 +0100
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <AANLkTin1Nf8nHNE50ffOCp0JcdbooDs6i5Zk8tm6Bc4g@mail.gmail.com>
References: <1299200285.14313.7.camel@marge>
	<AANLkTin1Nf8nHNE50ffOCp0JcdbooDs6i5Zk8tm6Bc4g@mail.gmail.com>
Message-ID: <1299238247.19672.5.camel@marge>

Le vendredi 04 mars 2011 ? 21:10 +1000, Nick Coghlan a ?crit :
> > Some months ago, I proposed a patch to display the Python backtrace on a
> > segfault. The API was not stable, it was too for Python 3.2, and it was
> > enabled by default. I wrote a module instead of a patch so it can be
> > used on any version of Python, and it has a better API. And now I would
> > like to include the module into Python directly to use it more easily.
> > See http://bugs.python.org/issue11393 for the details. The module:
> >
> >   https://github.com/haypo/faulthandler
> >
> > It is now possible to dump the backtrace on an user signal (eg. SIGUSR1)
> > or after a delay in seconds (it may be useful for buildbot hangs without
> > user interaction). You can choose to display the current thread or all
> > threads, and in which file the trace is written.
> >
> > So, what do you think?
> 
> +1
> 
> It's a very helpful capability, and getting it in early in the 3.3
> cycle will give us more time to refine the API and functionality.

Even if it has a complete test suite (for all features), it would be
nice to test it as much as possible. So introduce it quickly into Python
3.3 would be nice.

The API can be completly changed, I don't care of the API :-)

But I will try to continue to maintain the project as a third party
module for older Python versions.

> Something we may want to consider is enabling it by default in
> interactive mode, and also when `-i` is specified on the command line.

In the issue, I proposed:

 * an option on the command line, eg. python -x faulthandler script.py
 * an environment variable, eg. PYTHONFAULTHANDLER=y python script.py

Both have different usages: the command line option can be used once to
try to get more information when trying to reproduce a crash, the
environment variable can be used to always enable it by default on your
computer.

I also would like to enable it by default in regrtest.py.

Victor


From scott+python-dev at scottdial.com  Fri Mar  4 12:32:17 2011
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Fri, 04 Mar 2011 06:32:17 -0500
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <AANLkTin1Nf8nHNE50ffOCp0JcdbooDs6i5Zk8tm6Bc4g@mail.gmail.com>
References: <1299200285.14313.7.camel@marge>
	<AANLkTin1Nf8nHNE50ffOCp0JcdbooDs6i5Zk8tm6Bc4g@mail.gmail.com>
Message-ID: <4D70CDC1.2000000@scottdial.com>

On 3/4/2011 6:10 AM, Nick Coghlan wrote:
> On Fri, Mar 4, 2011 at 10:58 AM, Victor Stinner
> <victor.stinner at haypocalc.com> wrote:
>> So, what do you think?
> 
> Something we may want to consider is enabling it by default in
> interactive mode, and also when `-i` is specified on the command line.

I am still bothered by the fact that,

>>> import faulthandler
>>> faulthandler.enable()
>>> import sys
>>> sys.stderr.close()
>>> sys.stderr = open('logs/error.log', 'wb')
>>> faulthandler.sigsegv()

, does the wrong thing. In this incantation, it's easy to say that it's
programmer error, but I think this still precludes it from being on by
default (where the first two statement are implicitly executed by the
interpreter). It's probably uncommon enough to close stderr from an
interactive interpreter session that it doesn't bother me (although I am
not sure the utility of that), but I would hesitate to say that is true
for using '-i'.

Otherwise, the functionality seems generally useful and it's on my list
of things to integrate into my application, and having it in the stdlib
is one less external dependency for me to manage.

-Scott

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From fuzzyman at voidspace.org.uk  Fri Mar  4 12:54:24 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 04 Mar 2011 11:54:24 +0000
Subject: [Python-Dev] unittest.main() --catch parameter
In-Reply-To: <AANLkTim_MeDkmtOULUZGiu1NaEU_r-mSYMKpDbO=yKz6@mail.gmail.com>
References: <AANLkTint=RD2boqoeeoWQMqG_vRUF1xhpWMgC45vsLSS@mail.gmail.com>
	<4D6FFD96.3010809@voidspace.org.uk>
	<AANLkTikmFkzXhEquSFcSEXCHNPh6hzuBogOunYV+Siie@mail.gmail.com>
	<4D700EFD.4080700@voidspace.org.uk>
	<AANLkTim_MeDkmtOULUZGiu1NaEU_r-mSYMKpDbO=yKz6@mail.gmail.com>
Message-ID: <4D70D2F0.4010201@voidspace.org.uk>

On 04/03/2011 01:33, anatoly techtonik wrote:
> On Thu, Mar 3, 2011 at 11:58 PM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>>>> Without this option interrupting a test run with a ctrl-c kills the run
>>>> and
>>>> reports nothing. Seeing an unexpected failure or error during a long test
>>>> run and having to wait to the end of the test run to see the traceback
>>>> can
>>>> be annoying, this feature solves that problem.
>>> Why not just leave this behavior by default and just return -1 if the
>>> Ctrl-C was pressed?
>>>
>> Because it means installing a signal handler which is not necessarily
>> appropriate for all test systems. We *could* make it the default in the
>> future (for the test runner only - not when unittest is used via the api).
> What does it mean - "not approriate"? Do signal handlers crash or kill
> people on some test systems?

Because the system under test may use its own signal handlers.
> If tests are run with output buffering
> then it's reasonable to turn off handling of Ctrl-C. If they are
> executed by buildbots, I don't see how it hurts the test process. In
> any case there should be a way to turn Ctrl-C handing using some
> internal flag, but moving it into user command doesn't seem like a
> good idea to me.

What's more relevant are the following two facts:

* It isn't guaranteed to work, the keyboard interrupt can interrupt code 
at any arbitrary point so the system *could* be in an unstable state and 
result reporting may then fail.

* It changes the default behaviour of pressing control-c which normally 
stops code immediately. This continues to execute an arbitrary amount of 
code after pressing control-c.

For all these reasons I think it is better to make it a user option than 
on by default. Besides which it is already done and released in two 
major versions of Python (2.7 & 3.2).

(The behaviour *is* configurable / controllable via the api - which I 
guess is what you mean by "some internal flag". The command line option 
is the way to control it when using the default runner and not the api.)

> By the way, is calling unittest.main() is using unittest via api?
>

Not really, that's the standard test runner. Perhaps slightly debatable.

>> So you want it on by default but are also worried about the backwards
>> compatibility issues of it even existing as an option? Anyway, your
>> assertion that the option is or may be useless is unfounded. Don't worry
>> about it.
> I am worried that I won't have space to add more useful options to the
> runner or they will be lost for users in the abundance of highly
> technical parameters that runner provides. I am concerned that users
> will never ever understand the true Awesomeness of the New Runner
> (tm). ;)

:-)

Well there are only 52 short alphabetical options available, but yes we 
should be careful with them and I'm not proposing adding any more at the 
moment.

All the best,

Michael Foord

-- 
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


From ncoghlan at gmail.com  Fri Mar  4 13:10:11 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Mar 2011 22:10:11 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
Message-ID: <AANLkTi=dajHVy+J3y=D-5jAw72Gxs5k-JHLHVtU7mw6z@mail.gmail.com>

On Fri, Mar 4, 2011 at 5:44 PM, Kerrick Staley <mail at kerrickstaley.com> wrote:
> PEP: ???
> Title: The python Utility on Unix-Like Systems

With a few adjustments (formatting, additional info, correction of
typos), I've now added Kerrick's PEP as a proposal on python.org:

http://www.python.org/dev/peps/pep-0394

The full text is included below as well.

Cheers,
Nick.

PEP: 394
Title: The "python" command on Unix-Like Systems
Version: $Revision: 88743 $
Last-Modified: $Date: 2011-03-04 22:04:22 +1000 (Fri, 04 Mar 2011) $
Author: Kerrick Staley <mail at kerrickstaley.com>,
        Nick Coghlan <ncoghlan at gmail.com>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: 04-Mar-2011


Abstract
========

This PEP provides a convention to ensure that Python scripts can continue to
be portable across ``*nix`` systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the ``python`` command).

* ``python2`` will refer to some version of Python 2.x
* ``python3`` will refer to some version of Python 3.x
* ``python`` may refer to either, depending on distribution and system


Recommendation
==============

* ``*nix`` software distributions should install the ``python2`` command into
  the default path whenever a version of the Python 2 interpreter is
  installed, and the same for ``python3`` and the Python 3 interpreter. When
  invoked, ``python2`` should run some version of the Python 2 interpreter,
  and ``python3`` should run some version of the Python 3 interpreter. The
  same applies for the more general ``python`` command, which should be
  installed whenever any version of Python is installed and should invoke
  some Python interpreter.
* All new 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).
  This distinction should be made in shebangs, when invoking from a shell
  script, when invoking via the system() call, or when invoking in any other
  context. Note that, when reinvoking the interpreter from a Python script,
  querying ``sys.executable`` remains the preferred approach.


Rationale
=========

This is needed as, even though the majority of distributions still alias the
``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) to reliably run on all systems without modification, because both
the ``python`` and the ``python2`` commands will fail on some systems. The
recommendations in this PEP provide a very simple mechanism to restore
cross-platform support, with minimal additional work required on the part
of distribution maintainers.


Notes
=====

* Distributions can alias the ``python`` command to whichever version of the
  Python interpreter they choose (noting that, in the near term, most 3rd
  party scripts will still expect this command to refer to Python 2.x).
* The ``pythonX.X`` (e.g. ``python2.6``) utilities exist on some systems, on
  which they invoke specific minor versions of the Python interpreter. It
  would be wise for distribution-specific packages to take advantage of these
  utilities if they exist, since it will prevent code breakage if the default
  minor version of a given major version is changed. However, scripts
  intending to be cross-platform should not rely on the presence of these
  utilities, but rather should be tested on several recent minor versions of
  the target major version, compensating, if necessary, for the small
  differences that exist between minor versions. This prevents the need for
  sysadmins to install many very similar versions of the interpreter.
* It would be wise for distribution-specific packages to always follow the
  ``python2``/``python3`` convention, even in code that is not intended to
  operate on other distributions. This will prevent problems if the
  distribution later decides to upgrade the version of the Python interpreter
  that the ``python`` command invokes, or if a sysadmin installs a custom
  ``python`` command with a different major version than the distribution
  default. Distributions can test whether they are fully following this
  convention by changing the ``python`` interpreter on a test box and checking
  to see if anything breaks.
* If the above point is adhered to and sysadmins are permitted to change the
  ``python`` command, then the ``python`` command should always be implemented
  as a link to the interpreter binary (or a link to a link) and not vice
  versa. That way, if a sysadmin does decide to replace the installed
  ``python`` file, they can do so without inadvertently deleting the
  previously installed binary.
* The first recommendation can be ignored for systems on which the ``python``
  command itself has traditionally been left undefined and users have always
  had the responsibility of linking the ``python`` command to the Python
  interpreter.
* 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
  is released.
* If these conventions are adhered to, it will be the case that the ``python``
  command is only executed in an interactive manner.


Backwards Compatibility
=========================

A potential problem can arise if a script adhering to the
``python2``/``python3`` convention is executed on a system not supporting
these commands. This is mostly a non-issue, since the sysadmin can simply
create these symbolic links and avoid further problems.

Application to the CPython Reference Interpreter
================================================

While technically a new feature, the ``make install`` command of the 2.7
version of CPython will be adjusted to create the ``python2`` symlink in
addition to the existing ``python`` symlink. This feature will first appear in
CPython 2.7.2.

The ``make install`` command in the CPython 3.x series will continue to
install only the ``python3`` symlink for the foreseeable future.

Copyright
===========
This document has been placed in the public domain.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar  4 13:23:16 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Mar 2011 22:23:16 +1000
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
In-Reply-To: <4D70A45A.5090609@v.loewis.de>
References: <4D70A45A.5090609@v.loewis.de>
Message-ID: <AANLkTinqUjPNL1L8Jv8KT1gdwA_y6cPam0DFO6jV+-np@mail.gmail.com>

On Fri, Mar 4, 2011 at 6:35 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Google Summer of Code is coming up again, and we will again
> be participating. Arc Riley will setup infrastructure later
> today, and we need to start thinking about possible projects.
>
> Traditionally, people (students and other projects) have been willing
> to give the Python Core the highest attention in SoC, as improvements
> to Python will help the whole community. Also traditionally, there has
> been a shortage of project ideas and mentors for Python Core. My guess
> is that the project shortage stems from the assumption that many of the
> projects are so tricky that you can't give them to a newcomer. I found
> this view both confirmed and rebutted in the past - it all depends on
> which students we can attract.
>
> The shortage of mentors is probably more inherent, and reflects the
> shortage of volunteers for other tasks. As a long-time mentor, I'd
> like to encourage all of you to consider mentoring this year. GSoC/PSF
> will have a strict rule "one student per mentor", co-mentorship
> is encouraged.
>
> Feel free to discuss Python-Core-GSoC here or on the GSoC mailing
> list(s) (soon to appear).

Are proof-of-concept projects acceptable as GSoC projects? I've long
had the belief that Python's import semantics could be bundled up into
an "import engine" object to get away from the process globals in the
sys module (i.e. modules, path, meta_path, path_hooks,
path_importer_cache) as well as the global import lock. The "default
engine" could then be implemented as a subclass that replaced the
essential attributes with properties that read from and wrote through
to the standard locations.

Experimenting with this idea became significantly more feasible since
Brett wrote importlib, but would still require a strong understanding
of Python's import system. I suspect even a proof of concept that was
tested against just filesystem imports and zipimport would prove quite
tricky.

Once the concept has been proven... I'm sure we could figure out
*something* useful to do with the idea. It would depend on the details
of what actually turns out to be feasible.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar  4 13:26:00 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Mar 2011 22:26:00 +1000
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <4D70CDC1.2000000@scottdial.com>
References: <1299200285.14313.7.camel@marge>
	<AANLkTin1Nf8nHNE50ffOCp0JcdbooDs6i5Zk8tm6Bc4g@mail.gmail.com>
	<4D70CDC1.2000000@scottdial.com>
Message-ID: <AANLkTikuX+7iMh6eT06bE_HBofVGE3xKmeF2g+ACqzmo@mail.gmail.com>

On Fri, Mar 4, 2011 at 9:32 PM, Scott Dial
<scott+python-dev at scottdial.com> wrote:
> I am still bothered by the fact that,
>
>>>> import faulthandler
>>>> faulthandler.enable()
>>>> import sys
>>>> sys.stderr.close()
>>>> sys.stderr = open('logs/error.log', 'wb')
>>>> faulthandler.sigsegv()
>
> , does the wrong thing. In this incantation, it's easy to say that it's
> programmer error, but I think this still precludes it from being on by
> default (where the first two statement are implicitly executed by the
> interpreter). It's probably uncommon enough to close stderr from an
> interactive interpreter session that it doesn't bother me (although I am
> not sure the utility of that), but I would hesitate to say that is true
> for using '-i'.

Perhaps the module should be using sys.__stderr__ instead? If anyone
is messing with that, on their own heads be it.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar  4 13:33:42 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Mar 2011 22:33:42 +1000
Subject: [Python-Dev] [Python-checkins] r88729 -
	python/branches/py3k/Modules/posixmodule.c
In-Reply-To: <20110303161058.15BDFEE98B@mail.python.org>
References: <20110303161058.15BDFEE98B@mail.python.org>
Message-ID: <AANLkTinFkgEOb_OyH6JXLUmZMzNrC8pG8mTRzS==M1L+@mail.gmail.com>

On Fri, Mar 4, 2011 at 2:10 AM, giampaolo.rodola
<python-checkins at python.org> wrote:
> Author: giampaolo.rodola
> Date: Thu Mar ?3 17:10:51 2011
> New Revision: 88729
>
> Log:
> Issue 11351 - apply patch by Steffen Daode Nurpmeso which should fix TestSendfile.test_headers failure on OSX.
>
> Modified:
> ? python/branches/py3k/Modules/posixmodule.c

NEWS entry and a new name in ACKS?

(the query regarding the lack of a NEWS entry applies to your other
recent commits as well).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Fri Mar  4 13:35:49 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 4 Mar 2011 13:35:49 +0100
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
References: <4D70A45A.5090609@v.loewis.de>
Message-ID: <20110304133549.31ee15be@pitrou.net>

On Fri, 04 Mar 2011 09:35:38 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> Google Summer of Code is coming up again, and we will again
> be participating. Arc Riley will setup infrastructure later
> today, and we need to start thinking about possible projects.

We've had a couple of people asking questions about GSoC on
#python-dev. Each time I redirected them to Arc's personal email, since
there seems to be no dedicated mailing-list for that. Is there a better
way to inform them?

Regards

Antoine.



From ncoghlan at gmail.com  Fri Mar  4 13:40:05 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Mar 2011 22:40:05 +1000
Subject: [Python-Dev] [Python-checkins] r88729 -
	python/branches/py3k/Modules/posixmodule.c
In-Reply-To: <AANLkTinFkgEOb_OyH6JXLUmZMzNrC8pG8mTRzS==M1L+@mail.gmail.com>
References: <20110303161058.15BDFEE98B@mail.python.org>
	<AANLkTinFkgEOb_OyH6JXLUmZMzNrC8pG8mTRzS==M1L+@mail.gmail.com>
Message-ID: <AANLkTi=2j2ZsLWrtTw=iLCOJFuFtfkx3uPGvrdrttUof@mail.gmail.com>

On Fri, Mar 4, 2011 at 10:33 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Mar 4, 2011 at 2:10 AM, giampaolo.rodola
> <python-checkins at python.org> wrote:
>> Author: giampaolo.rodola
>> Date: Thu Mar ?3 17:10:51 2011
>> New Revision: 88729
>>
>> Log:
>> Issue 11351 - apply patch by Steffen Daode Nurpmeso which should fix TestSendfile.test_headers failure on OSX.
>>
>> Modified:
>> ? python/branches/py3k/Modules/posixmodule.c
>
> NEWS entry and a new name in ACKS?
>
> (the query regarding the lack of a NEWS entry applies to your other
> recent commits as well).

Oops, one of them did have an entry, and a second was just a tweak to
the first one. So the NEWS query only applies to this one and the NNTP
change.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From victor.stinner at haypocalc.com  Fri Mar  4 13:40:16 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 04 Mar 2011 13:40:16 +0100
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <4D70CDC1.2000000@scottdial.com>
References: <1299200285.14313.7.camel@marge>
	<AANLkTin1Nf8nHNE50ffOCp0JcdbooDs6i5Zk8tm6Bc4g@mail.gmail.com>
	<4D70CDC1.2000000@scottdial.com>
Message-ID: <1299242416.21701.20.camel@marge>

Le vendredi 04 mars 2011 ? 06:32 -0500, Scott Dial a ?crit :
> On 3/4/2011 6:10 AM, Nick Coghlan wrote:
> > On Fri, Mar 4, 2011 at 10:58 AM, Victor Stinner
> > <victor.stinner at haypocalc.com> wrote:
> >> So, what do you think?
> > 
> > Something we may want to consider is enabling it by default in
> > interactive mode, and also when `-i` is specified on the command line.
> 
> I am still bothered by the fact that,
> 
> >>> import faulthandler
> >>> faulthandler.enable()
> >>> import sys
> >>> sys.stderr.close()
> >>> sys.stderr = open('logs/error.log', 'wb')
> >>> faulthandler.sigsegv()
> 
> , does the wrong thing.

faulthandler.enable() uses sys.stderr by default: it keeps a reference
on this object and stores its descriptor (should be 2). If you close the
file descriptor (eg. sys.stderr.close()), the faulthandler will write
into a closed file, which is not a problem (it doesn't crash or do
something dangerous) except that the backtrace is not displayed.

... in this particulier example, the new opened file (sys.stderr) may
also get the file descriptor 2 (which is a specific value, it is usually
the highest file descriptor at startup on Linux) and so the backtrace
may be written to this file. It is a problem if the new file is a socket
or a critical file. But you enabled explicitly the faulthandler, so you
know what you are doing :-)

>  In this incantation, it's easy to say that it's
> programmer error, but I think this still precludes it from being on by
> default (where the first two statement are implicitly executed by the
> interpreter). It's probably uncommon enough to close stderr from an
> interactive interpreter session that it doesn't bother me (although I am
> not sure the utility of that), but I would hesitate to say that is true
> for using '-i'.

I forgot to give my opinion about enabling faulthandler with -i. I vote
-1 because we have to be careful with this new feature and its side
effects. But we may change that later when I will be more confident in
my own code :-)

Your example is a corner case. Having a segfault after changing
sys.stderr in an interpreter is unlikely. Anyway, if someone had such
problem, it is still possible to workaround it. Call again
faulthandler.enable() after changing sys.stderr: the new call to
enable() will just update the file descriptor variable and so the
backtrace is written to the right file.

crier project (similar to faulthandler) creates the
file /tmp/crier-<pid> to dump the backtrace. The tiper projects creates
also a temporary file to dump the backtrace.

But I prefer sys.stderr just because it's enough for me, and I don't
really want to generate a filename or create a new file in the SIGSEGV
handler.

crier dumps the backtrace when a file is created in a specific directory
and tiper dumps the backtrace when a SIGUSR is received. faulthandler
may creates a file after a delay in seconds or on SIGUSR1, but not on a
segmentation fault.

> Otherwise, the functionality seems generally useful and it's on my list
> of things to integrate into my application, and having it in the stdlib
> is one less external dependency for me to manage.

You can already have an optional support of this module. For example:

try:
   import faulthandler
except ImportError:
   pass
else:
   faulthandler.enable()

Integrate it directly into Python should just help users to report more
informations to our bug tracker (don't need to install an extra module
just to report a bug).

Victor


From solipsis at pitrou.net  Fri Mar  4 13:54:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 4 Mar 2011 13:54:25 +0100
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
References: <1299200285.14313.7.camel@marge>
	<AANLkTin1Nf8nHNE50ffOCp0JcdbooDs6i5Zk8tm6Bc4g@mail.gmail.com>
	<4D70CDC1.2000000@scottdial.com> <1299242416.21701.20.camel@marge>
Message-ID: <20110304135425.66d8d51d@pitrou.net>

On Fri, 04 Mar 2011 13:40:16 +0100
Victor Stinner <victor.stinner at haypocalc.com> wrote:
> > I am still bothered by the fact that,
> > 
> > >>> import faulthandler
> > >>> faulthandler.enable()
> > >>> import sys
> > >>> sys.stderr.close()
> > >>> sys.stderr = open('logs/error.log', 'wb')
> > >>> faulthandler.sigsegv()
> > 
> > , does the wrong thing.
> 
> faulthandler.enable() uses sys.stderr by default: it keeps a reference
> on this object and stores its descriptor (should be 2). If you close the
> file descriptor (eg. sys.stderr.close())

sys.stderr.close() doesn't close the file descriptor under Python 3:

>>> import sys, os
>>> sys.stderr.close()
>>> os.write(2, b"foo\n")
foo
4

Regards

Antoine.



From g.rodola at gmail.com  Fri Mar  4 13:55:21 2011
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Fri, 4 Mar 2011 13:55:21 +0100
Subject: [Python-Dev] [Python-checkins] r88729 -
	python/branches/py3k/Modules/posixmodule.c
In-Reply-To: <AANLkTi=2j2ZsLWrtTw=iLCOJFuFtfkx3uPGvrdrttUof@mail.gmail.com>
References: <20110303161058.15BDFEE98B@mail.python.org>
	<AANLkTinFkgEOb_OyH6JXLUmZMzNrC8pG8mTRzS==M1L+@mail.gmail.com>
	<AANLkTi=2j2ZsLWrtTw=iLCOJFuFtfkx3uPGvrdrttUof@mail.gmail.com>
Message-ID: <AANLkTim=0k7nb-onu_yXhsNY9ooEcjzoJGniY4VyH+yP@mail.gmail.com>

Thanks.
I'll try to remember ACKS and NEWS in the future. =)
Fixed in r88744 and r88745.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/

2011/3/4 Nick Coghlan <ncoghlan at gmail.com>:
> On Fri, Mar 4, 2011 at 10:33 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Fri, Mar 4, 2011 at 2:10 AM, giampaolo.rodola
>> <python-checkins at python.org> wrote:
>>> Author: giampaolo.rodola
>>> Date: Thu Mar ?3 17:10:51 2011
>>> New Revision: 88729
>>>
>>> Log:
>>> Issue 11351 - apply patch by Steffen Daode Nurpmeso which should fix TestSendfile.test_headers failure on OSX.
>>>
>>> Modified:
>>> ? python/branches/py3k/Modules/posixmodule.c
>>
>> NEWS entry and a new name in ACKS?
>>
>> (the query regarding the lack of a NEWS entry applies to your other
>> recent commits as well).
>
> Oops, one of them did have an entry, and a second was just a tweak to
> the first one. So the NEWS query only applies to this one and the NNTP
> change.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
>

From fuzzyman at voidspace.org.uk  Fri Mar  4 13:59:23 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 04 Mar 2011 12:59:23 +0000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTi=dajHVy+J3y=D-5jAw72Gxs5k-JHLHVtU7mw6z@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTi=dajHVy+J3y=D-5jAw72Gxs5k-JHLHVtU7mw6z@mail.gmail.com>
Message-ID: <4D70E22B.8080006@voidspace.org.uk>

On 04/03/2011 12:10, Nick Coghlan wrote:
> On Fri, Mar 4, 2011 at 5:44 PM, Kerrick Staley<mail at kerrickstaley.com>  wrote:
>> PEP: ???
>> Title: The python Utility on Unix-Like Systems
> With a few adjustments (formatting, additional info, correction of
> typos), I've now added Kerrick's PEP as a proposal on python.org:
>
> http://www.python.org/dev/peps/pep-0394
>
> The full text is included below as well.

Should any of this also apply to Mac OS X and Windows?

Note that we *do* have alternative distributors [1] of Python for these 
platforms who may wish to follow any recommendations we have for 2.7, 
even if we don't modify those installers for our own distributions.

All the best,

Michael Foord

[1] Activestate and Enthought in particular. Plus possibly others I'm 
not aware of.

> Cheers,
> Nick.
>
> PEP: 394
> Title: The "python" command on Unix-Like Systems
> Version: $Revision: 88743 $
> Last-Modified: $Date: 2011-03-04 22:04:22 +1000 (Fri, 04 Mar 2011) $
> Author: Kerrick Staley<mail at kerrickstaley.com>,
>          Nick Coghlan<ncoghlan at gmail.com>
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 02-Mar-2011
> Post-History: 04-Mar-2011
>
>
> Abstract
> ========
>
> This PEP provides a convention to ensure that Python scripts can continue to
> be portable across ``*nix`` systems, regardless of the default version of the
> Python interpreter (i.e. the version invoked by the ``python`` command).
>
> * ``python2`` will refer to some version of Python 2.x
> * ``python3`` will refer to some version of Python 3.x
> * ``python`` may refer to either, depending on distribution and system
>
>
> Recommendation
> ==============
>
> * ``*nix`` software distributions should install the ``python2`` command into
>    the default path whenever a version of the Python 2 interpreter is
>    installed, and the same for ``python3`` and the Python 3 interpreter. When
>    invoked, ``python2`` should run some version of the Python 2 interpreter,
>    and ``python3`` should run some version of the Python 3 interpreter. The
>    same applies for the more general ``python`` command, which should be
>    installed whenever any version of Python is installed and should invoke
>    some Python interpreter.
> * All new 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).
>    This distinction should be made in shebangs, when invoking from a shell
>    script, when invoking via the system() call, or when invoking in any other
>    context. Note that, when reinvoking the interpreter from a Python script,
>    querying ``sys.executable`` remains the preferred approach.
>
>
> Rationale
> =========
>
> This is needed as, even though the majority of distributions still alias the
> ``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) to reliably run on all systems without modification, because both
> the ``python`` and the ``python2`` commands will fail on some systems. The
> recommendations in this PEP provide a very simple mechanism to restore
> cross-platform support, with minimal additional work required on the part
> of distribution maintainers.
>
>
> Notes
> =====
>
> * Distributions can alias the ``python`` command to whichever version of the
>    Python interpreter they choose (noting that, in the near term, most 3rd
>    party scripts will still expect this command to refer to Python 2.x).
> * The ``pythonX.X`` (e.g. ``python2.6``) utilities exist on some systems, on
>    which they invoke specific minor versions of the Python interpreter. It
>    would be wise for distribution-specific packages to take advantage of these
>    utilities if they exist, since it will prevent code breakage if the default
>    minor version of a given major version is changed. However, scripts
>    intending to be cross-platform should not rely on the presence of these
>    utilities, but rather should be tested on several recent minor versions of
>    the target major version, compensating, if necessary, for the small
>    differences that exist between minor versions. This prevents the need for
>    sysadmins to install many very similar versions of the interpreter.
> * It would be wise for distribution-specific packages to always follow the
>    ``python2``/``python3`` convention, even in code that is not intended to
>    operate on other distributions. This will prevent problems if the
>    distribution later decides to upgrade the version of the Python interpreter
>    that the ``python`` command invokes, or if a sysadmin installs a custom
>    ``python`` command with a different major version than the distribution
>    default. Distributions can test whether they are fully following this
>    convention by changing the ``python`` interpreter on a test box and checking
>    to see if anything breaks.
> * If the above point is adhered to and sysadmins are permitted to change the
>    ``python`` command, then the ``python`` command should always be implemented
>    as a link to the interpreter binary (or a link to a link) and not vice
>    versa. That way, if a sysadmin does decide to replace the installed
>    ``python`` file, they can do so without inadvertently deleting the
>    previously installed binary.
> * The first recommendation can be ignored for systems on which the ``python``
>    command itself has traditionally been left undefined and users have always
>    had the responsibility of linking the ``python`` command to the Python
>    interpreter.
> * 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
>    is released.
> * If these conventions are adhered to, it will be the case that the ``python``
>    command is only executed in an interactive manner.
>
>
> Backwards Compatibility
> =========================
>
> A potential problem can arise if a script adhering to the
> ``python2``/``python3`` convention is executed on a system not supporting
> these commands. This is mostly a non-issue, since the sysadmin can simply
> create these symbolic links and avoid further problems.
>
> Application to the CPython Reference Interpreter
> ================================================
>
> While technically a new feature, the ``make install`` command of the 2.7
> version of CPython will be adjusted to create the ``python2`` symlink in
> addition to the existing ``python`` symlink. This feature will first appear in
> CPython 2.7.2.
>
> The ``make install`` command in the CPython 3.x series will continue to
> install only the ``python3`` symlink for the foreseeable future.
>
> Copyright
> ===========
> This document has been placed in the public domain.
>


-- 
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


From victor.stinner at haypocalc.com  Fri Mar  4 13:59:28 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 04 Mar 2011 13:59:28 +0100
Subject: [Python-Dev] rXXX links in the bug tracker after the migration to
	Mercurial
Message-ID: <1299243568.21701.23.camel@marge>

Hi,

Does the bug tracker will continue to support rXXXXX links after the
migration to Mercurial? 

Victor


From hodgestar+pythondev at gmail.com  Fri Mar  4 14:05:04 2011
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Fri, 4 Mar 2011 15:05:04 +0200
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <1299200285.14313.7.camel@marge>
References: <1299200285.14313.7.camel@marge>
Message-ID: <AANLkTikmkCQD8GFY2xn-NGBBwi2bGpOZ859x9Oof_Yca@mail.gmail.com>

On Fri, Mar 4, 2011 at 2:58 AM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> Some months ago, I proposed a patch to display the Python backtrace on a
> segfault. The API was not stable, it was too for Python 3.2, and it was
> enabled by default. I wrote a module instead of a patch so it can be
> used on any version of Python, and it has a better API. And now I would
> like to include the module into Python directly to use it more easily.
> See http://bugs.python.org/issue11393 for the details. The module:

While I like this module I'm against it going into the standard
library so soon. Modules need time to mature, develop and gain wide
adoption outside the standard library where they are less constrained
by maintaining compatibility with old versions and can enjoy shorter
release cycles.

There may be reasons for including a shiny new module in the standard
library despite the drawbacks (the rest of the standard library might
wish to use the new feature, for example). If there are such reasons
it would be nice to see them stated and discussed here.

Schiavo
Simon

From techtonik at gmail.com  Fri Mar  4 14:07:38 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 4 Mar 2011 15:07:38 +0200
Subject: [Python-Dev] rXXX links in the bug tracker after the migration
	to Mercurial
In-Reply-To: <1299243568.21701.23.camel@marge>
References: <1299243568.21701.23.camel@marge>
Message-ID: <AANLkTinS08ktGmGOXEmK9iw+E6B=Z0KuENZh_PWdtgxj@mail.gmail.com>

We need a mapping for previous commits.
--
anatoly t.



On Fri, Mar 4, 2011 at 2:59 PM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> Hi,
>
> Does the bug tracker will continue to support rXXXXX links after the
> migration to Mercurial?
>
> Victor
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com
>

From ncoghlan at gmail.com  Fri Mar  4 14:21:23 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Mar 2011 23:21:23 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D70E22B.8080006@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTi=dajHVy+J3y=D-5jAw72Gxs5k-JHLHVtU7mw6z@mail.gmail.com>
	<4D70E22B.8080006@voidspace.org.uk>
Message-ID: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>

On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Should any of this also apply to Mac OS X and Windows?

Any platform that considers itself "unix-like" in this context can
decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
aspects of OS X). The main point of the PEP is to get a consensus
recommendation out of python-dev as to the best way forward (and I
think Kerrick did a good job of summarising the position that has been
expressed in this thread).

More generally, Windows and Mac OS X developers seem to be happier
with the idea of bundling a Python interpreter inside the application
than traditional *nix style platforms. This is a PITA for the system
maintainer when it comes time to handle security vulnerabilites, but
certainly more convenient when upgrading the default Python install.

> Note that we *do* have alternative distributors [1] of Python for these
> platforms who may wish to follow any recommendations we have for 2.7, even
> if we don't modify those installers for our own distributions.

The really tricky part on Windows is handling file associations. I
think we're just doomed on that front, unless we want to start
supporting separate .py2 and .py3 extensions (and adding *that* in a
maintenance release would be a far cry from just adding another
symlink).

The lack of near-universal symlink support on Windows filesystems is
also an issue - we would have to duplicate files like python.exe and
pythonw.exe on non-NTFS filesystems in order to provide them under
alternative names.

For *nix, I think there is a simple way forward that is an improvement
over where things stand now. For Windows, I don't think we can do much
better than the status quo and for Mac OS X... I think Apple will do
whatever Apple feel like doing :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From victor.stinner at haypocalc.com  Fri Mar  4 14:26:16 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 04 Mar 2011 14:26:16 +0100
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <AANLkTikmkCQD8GFY2xn-NGBBwi2bGpOZ859x9Oof_Yca@mail.gmail.com>
References: <1299200285.14313.7.camel@marge>
	<AANLkTikmkCQD8GFY2xn-NGBBwi2bGpOZ859x9Oof_Yca@mail.gmail.com>
Message-ID: <1299245176.21701.35.camel@marge>

Le vendredi 04 mars 2011 ? 15:05 +0200, Simon Cross a ?crit :
> While I like this module I'm against it going into the standard
> library so soon. Modules need time to mature, develop and gain wide
> adoption outside the standard library where they are less constrained
> by maintaining compatibility with old versions and can enjoy shorter
> release cycles.
> 
> There may be reasons for including a shiny new module in the standard
> library despite the drawbacks (the rest of the standard library might
> wish to use the new feature, for example). If there are such reasons
> it would be nice to see them stated and discussed here.

faulthandler is not so new. I am working on it since september 2008
(issue #3999). It was first an hack to convert a SIGSEGV into a classic
Python exception. I started a reimplementation to just display the
backtrace in may 2010, and I wrote 11 versions to fix all remarks. But
ok, the module itself was created at christmas 2010. Before the
conversion of the patch to module, there was very few options. With the
module, I added new functions with more options.

The module is also small: it has 8 functions (+ 4 functions dedicated to
tests).

faulthandler is also a little bit special, because it is very specific
to CPython: it is based on CPython internal structures. Integrate it
directly into Python would simplify its maintenance, but it would also
help to add more hooks like dumping the backtrace at a fatal error, and
maybe have a finer control on the module (eg. handle child processes
correctly?). (Well, there is a recent addition to Python 3.2 to choose
the function used to display the fatal error message, but I didn't tried
it yet).

Victor


From ncoghlan at gmail.com  Fri Mar  4 14:29:34 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Mar 2011 23:29:34 +1000
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <AANLkTikmkCQD8GFY2xn-NGBBwi2bGpOZ859x9Oof_Yca@mail.gmail.com>
References: <1299200285.14313.7.camel@marge>
	<AANLkTikmkCQD8GFY2xn-NGBBwi2bGpOZ859x9Oof_Yca@mail.gmail.com>
Message-ID: <AANLkTikbdHPboqThex5mEFMu4SpZin8iyCZjsV06ugwN@mail.gmail.com>

On Fri, Mar 4, 2011 at 11:05 PM, Simon Cross
<hodgestar+pythondev at gmail.com> wrote:
> There may be reasons for including a shiny new module in the standard
> library despite the drawbacks (the rest of the standard library might
> wish to use the new feature, for example). If there are such reasons
> it would be nice to see them stated and discussed here.

Basically, we would like easy access to crash tracebacks on our own
buildbots, and to be able to easily request them on the issue tracker
when someone reports a crash bug that we can't readily reproduce.

Even when the Python traceback isn't enough on its own to pinpoint the
problem, it should help greatly in isolating the cause sufficiently to
reproduce the crash under a C level debugger.

It may be worth installing this as _faulthandler for 3.3 though, at
least initially. We'll still be able to enable it by default in
regrtest, as well as provide a command line option to switch it on,
but there would be a clear indication that the Python facing API may
not be stable yet.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From fuzzyman at voidspace.org.uk  Fri Mar  4 14:44:36 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 04 Mar 2011 13:44:36 +0000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<AANLkTi=dajHVy+J3y=D-5jAw72Gxs5k-JHLHVtU7mw6z@mail.gmail.com>	<4D70E22B.8080006@voidspace.org.uk>
	<AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
Message-ID: <4D70ECC4.7090307@voidspace.org.uk>

On 04/03/2011 13:21, Nick Coghlan wrote:
> On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>> Should any of this also apply to Mac OS X and Windows?
> Any platform that considers itself "unix-like" in this context can
> decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
> aspects of OS X). The main point of the PEP is to get a consensus
> recommendation out of python-dev as to the best way forward (and I
> think Kerrick did a good job of summarising the position that has been
> expressed in this thread).
>
Right, but the pep doesn't address those issues for some fairly major 
platforms.

> More generally, Windows and Mac OS X developers seem to be happier
> with the idea of bundling a Python interpreter inside the application
> than traditional *nix style platforms. This is a PITA for the system
> maintainer when it comes time to handle security vulnerabilites, but
> certainly more convenient when upgrading the default Python install.
>

However on Mac OS X at least *scripts* have the same issue (what to put 
in the shebang line).

>> Note that we *do* have alternative distributors [1] of Python for these
>> platforms who may wish to follow any recommendations we have for 2.7, even
>> if we don't modify those installers for our own distributions.
> The really tricky part on Windows is handling file associations. I
> think we're just doomed on that front, unless we want to start
> supporting separate .py2 and .py3 extensions (and adding *that* in a
> maintenance release would be a far cry from just adding another
> symlink).
>
> The lack of near-universal symlink support on Windows filesystems is
> also an issue - we would have to duplicate files like python.exe and
> pythonw.exe on non-NTFS filesystems in order to provide them under
> alternative names.
>
> For *nix, I think there is a simple way forward that is an improvement
> over where things stand now. For Windows, I don't think we can do much
> better than the status quo and for Mac OS X... I think Apple will do
> whatever Apple feel like doing :)
>

Right, but on Mac OS X we do put a "python3" on the path but not a 
"python2". We also create "python2.x" and "python3.x" variants. So the 
same issues exist yet the pep

On Windows we only have a "python.exe" I believe, but if the user does 
put their Python installs on the path then we *could* usefully create 
"python2.exe" and "python3.exe" for them. I don't see that duplicating 
these binaries on the filesystem is an issue. File associations is just 
unsolvable on Windows, so it isn't something we can address or should 
worry about. (Actually a stub python.exe that looks at the shebang line 
and then delegates to the appropriate pythonX.Y.exe would be a 
possibility but I'm not volunteering to write it.)

All the best,

Michael

> Cheers,
> Nick.
>


-- 
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


From rdmurray at bitdance.com  Fri Mar  4 14:57:23 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 04 Mar 2011 08:57:23 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
Message-ID: <20110304135723.F3307249609@kimball.webabinitio.net>

On Fri, 04 Mar 2011 01:44:00 -0600, Kerrick Staley <mail at kerrickstaley.com> wrote:
> * All new 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).
> This distinction should be made in shebangs, when invoking from a shell
> script, when invoking via the system() call, or when invoking in any other
> context.

If one target for this PEP is script implementors who hadn't thought
about this issue before, it is probably worth mentioning sys.executable
somewhere (a footnote?).

But another issue here (and this speaks against the proposal of not
shipping a /usr/bin/python link) is that it is quite possible to write
a script that will run on either python2 or python3. 

--
R. David Murray                                      www.bitdance.com

From hodgestar+pythondev at gmail.com  Fri Mar  4 15:02:14 2011
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Fri, 4 Mar 2011 16:02:14 +0200
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <1299245176.21701.35.camel@marge>
References: <1299200285.14313.7.camel@marge>
	<AANLkTikmkCQD8GFY2xn-NGBBwi2bGpOZ859x9Oof_Yca@mail.gmail.com>
	<1299245176.21701.35.camel@marge>
Message-ID: <AANLkTik+me4Hz_2_Omo527EaAXw_62PudNJk9HnPmMWr@mail.gmail.com>

On Fri, Mar 4, 2011 at 3:26 PM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> faulthandler is also a little bit special, because it is very specific
> to CPython: it is based on CPython internal structures.

If faulthandler is a public part of the standard library, what should
other Python implementations do about implementing it?

Schiavo
Simon

From benjamin at python.org  Fri Mar  4 15:03:35 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 4 Mar 2011 08:03:35 -0600
Subject: [Python-Dev] Integrate the faulthandler module into Python 3.3?
In-Reply-To: <AANLkTik+me4Hz_2_Omo527EaAXw_62PudNJk9HnPmMWr@mail.gmail.com>
References: <1299200285.14313.7.camel@marge>
	<AANLkTikmkCQD8GFY2xn-NGBBwi2bGpOZ859x9Oof_Yca@mail.gmail.com>
	<1299245176.21701.35.camel@marge>
	<AANLkTik+me4Hz_2_Omo527EaAXw_62PudNJk9HnPmMWr@mail.gmail.com>
Message-ID: <AANLkTinS3pa3h_oC7N009pXOTL+LzekktCK6eOBacizv@mail.gmail.com>

2011/3/4 Simon Cross <hodgestar+pythondev at gmail.com>:
> On Fri, Mar 4, 2011 at 3:26 PM, Victor Stinner
> <victor.stinner at haypocalc.com> wrote:
>> faulthandler is also a little bit special, because it is very specific
>> to CPython: it is based on CPython internal structures.
>
> If faulthandler is a public part of the standard library, what should
> other Python implementations do about implementing it?

Ignore it as they're free to ignore any other implementation detail.



-- 
Regards,
Benjamin

From kalman.gergely at duodecad.hu  Fri Mar  4 15:03:50 2011
From: kalman.gergely at duodecad.hu (=?ISO-8859-1?Q?K=E1lm=E1n_Gergely?=)
Date: Fri, 04 Mar 2011 15:03:50 +0100
Subject: [Python-Dev] 16:30-tol lesz a pajton
Message-ID: <4D70F146.3030308@duodecad.hu>

DD nagytargyalo ebben az idoben. Bocsi a keveresert.

synapse

From anikom15 at gmail.com  Fri Mar  4 16:03:08 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Fri, 04 Mar 2011 07:03:08 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>
Message-ID: <1299250988.8766.2.camel@localhost.localdomain>

On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
> On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley <mail at kerrickstaley.com> wrote:
> > That way, if the sysadmin does decide to replace the installed "python" file, he can do so without inadvertently deleting the previously installed binary.
> 
> Nit pick: Change "he" to "they" to be gender neutral.

Nit pick: Change "they" to "he" to be grammatically correct. If we
really have to be gender neutral, change "he" to "he or she".


From barry at python.org  Fri Mar  4 16:10:57 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 4 Mar 2011 10:10:57 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
 upstream
In-Reply-To: <20110304135723.F3307249609@kimball.webabinitio.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
Message-ID: <20110304101057.6b16622e@neurotica.wooz.org>

Folks, please stop CC'ing peps at python.org for non-PEP submissions.  They all
get held for moderator approval.  I've approved a few of them, but I'm going
to start rejecting them (so you get a bounce :) unless the message actually
contains a PEP.

cheerfully-co-editing-peps-ly y'rs,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/64e93b69/attachment.pgp>

From rdmurray at bitdance.com  Fri Mar  4 16:17:12 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 04 Mar 2011 10:17:12 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <1299250988.8766.2.camel@localhost.localdomain>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>
	<1299250988.8766.2.camel@localhost.localdomain>
Message-ID: <20110304151712.4ADF8249917@kimball.webabinitio.net>

On Fri, 04 Mar 2011 07:03:08 -0800, Westley =?ISO-8859-1?Q?Mart=EDnez?= <anikom15 at gmail.com> wrote:
> On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
> > On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley <mail at kerrickstaley.com> wrote:
> > > That way, if the sysadmin does decide to replace the installed "python" file, he can do so without inadvertently deleting the previously installed binary.
> > 
> > Nit pick: Change "he" to "they" to be gender neutral.
> 
> Nit pick: Change "they" to "he" to be grammatically correct. If we
> really have to be gender neutral, change "he" to "he or she".

English is evolving.  I vote for "they".

--David

From ijmorlan at uwaterloo.ca  Fri Mar  4 16:28:16 2011
From: ijmorlan at uwaterloo.ca (Isaac Morland)
Date: Fri, 4 Mar 2011 10:28:16 -0500 (EST)
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110304151712.4ADF8249917@kimball.webabinitio.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>
	<1299250988.8766.2.camel@localhost.localdomain>
	<20110304151712.4ADF8249917@kimball.webabinitio.net>
Message-ID: <Pine.GSO.4.64.1103041022370.16728@core.cs.uwaterloo.ca>

On Fri, 4 Mar 2011, R. David Murray wrote:

>>> Nit pick: Change "he" to "they" to be gender neutral.
>>
>> Nit pick: Change "they" to "he" to be grammatically correct. If we
>> really have to be gender neutral, change "he" to "he or she".
>
> English is evolving.  I vote for "they".

Sorry, can't resist a further nitpick:  English has not been evolving in 
this particular case, in the sense that "they" has been used as a singular 
since before English was English:

http://motivatedgrammar.wordpress.com/2009/09/10/singular-they-and-the-many-reasons-why-its-correct/

Also interesting:

http://en.wikipedia.org/wiki/Singular_they

Attention "he or she"ists:  Singular "they" won before any of us was born. 
You may want to divert your energies to a more worthy cause, such as 
ensuring proper use of "whom".

Isaac Morland			CSCF Web Guru
DC 2554C, x36650		WWW Software Specialist

From ncoghlan at gmail.com  Fri Mar  4 16:30:54 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 01:30:54 +1000
Subject: [Python-Dev] PEP 395: Module Aliasing
Message-ID: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>

There are a bunch of quirks that relate to main modules and
pseudo-packages (like the Python 2.7 and 3.2 style unittest) that
really don't need to be as annoying as they are. This PEP proposes a
few different tricks that should together allow most of those
annoyances to be eliminated.

Full text below, or you can read a nicely formatted version in the usual place:
http://www.python.org/dev/peps/pep-0395/

Cheers,
Nick.


PEP: 395
Title: Module Aliasing
Version: $Revision: 88748 $
Last-Modified: $Date: 2011-03-05 01:26:35 +1000 (Sat, 05 Mar 2011) $
Author: Nick Coghlan <ncoghlan at gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 4-Mar-2011
Python-Version: 3.3
Post-History: N/A


Abstract
========

This PEP proposes new mechanisms that eliminate some longstanding traps for
the unwary when dealing with Python's import system, the pickle module and
introspection interfaces.

<This will be fleshed out into a better summary once the PEP has been
discussed further>


What's in a ``__name__``?
=========================

Over time, a module's ``__name__`` attribute has come to be used to handle a
number of different tasks.

The key use cases identified for this module attribute are:

1. Flagging the main module in a program, using the ``if __name__ ==
   "__main__":`` convention.
2. As the starting point for relative imports
3. To identify the location of function and class definitions within the
   running application
4. To identify the location of classes for serialisation into pickle objects
   which may be shared with other interpreter instances


Traps for the Unwary
====================

The overloading of the semantics of ``__name__`` have resulted in several
traps for the unwary. These traps can be quite annoying in practice, as
they are highly unobvious and can cause quite confusing behaviour. A lot of
the time, you won't even notice them, which just makes them all the more
surprising when they do come up.


Importing the main module twice
-------------------------------

The most venerable of these traps is the issue of (effectively) importing
``__main__`` twice. This occurs when the main module is also imported under
its real name, effectively creating two instances of the same module under
different names.

This problem used to be significantly worse due to implicit relative imports
from the main module, but the switch to allowing only absolute imports and
explicit relative imports means this issue is now restricted to affecting the
main module itself.


Why are my relative imports broken?
-----------------------------------

PEP 366 defines a mechanism that allows relative imports to work correctly
when a module inside a package is executed via the ``-m`` switch.

Unfortunately, many users still attempt to directly execute scripts inside
packages. While this no longer silently does the wrong thing by
creating duplicate copies of peer modules due to implicit relative imports, it
now fails noisily at the first explicit relative import, even though the
interpreter actually has sufficient information available on the filesystem to
make it work properly.

<TODO: Anyone want to place bets on how many StackOverflow links I could find
to put here if I really went looking?>


In a bit of a pickle
--------------------

Something many users may not realise is that the ``pickle`` module serialises
objects based on the ``__name__`` of the containing module. So objects
defined in ``__main__`` are pickled that way, and won't be unpickled
correctly by another python instance that only imported that module instead
of running it directly. Thus the advice from many Python veterans to do as
little as possible in the ``__main__`` module in any application that
involves any form of object serialisation and persistence.

Similarly, when creating a pseudo-module\*, pickles rely on the name of the
module where a class is actually defined, rather than the officially
documented location for that class in the module hierarchy.

While this PEP focuses specifically on ``pickle`` as the principal
serialisation scheme in the standard library, this issue may also affect
other mechanisms that support serialisation of arbitrary class instances.

\*For the purposes of this PEP, a "pseudo-module" is a package designed like
the Python 3.2 ``unittest`` and ``concurrent.futures`` packages. These
packages are documented as if they were single modules, but are in fact
internally implemented as a package. This is *supposed* to be an
implementation detail that users and other implementations don't need to worry
about, but, thanks to ``pickle``, the details are exposed and effectively
become part of the public API.


Where's the source?
-------------------

Some sophisticated users of the pseudo-module technique described
above recognise the problem with implementation details leaking out via the
``pickle`` module, and choose to address it by altering ``__name__`` to refer
to the public location for the module before defining any functions or classes
(or else by modifying the ``__module__`` attributes of those objects after
they have been defined).

This approach is effective at eliminating the leakage of information via
pickling, but comes at the cost of breaking introspection for functions and
classes (as their ``__module__`` attribute now points to the wrong place).


Forkless Windows
----------------

To get around the lack of ``os.fork`` on Windows, the ``multiprocessing``
module attempts to re-execute Python with the same main module, but skipping
over any code guarded by ``if __name__ == "__main__":`` checks. It does the
best it can with the information it has, but is forced to make assumptions
that simply aren't valid whenever the main module isn't an ordinary directly
executed script or top-level module. Packages and non-top-level modules
executed via the ``-m`` switch, as well as directly executed zipfiles or
directories, are likely to make multiprocessing on Windows do the wrong thing
(either quietly or noisily) when spawning a new process.


Proposed Changes
================

The following changes are interrelated and make the most sense when
considered together. They collectively either completely eliminate the traps
for the unwary noted above, or else provide straightforward mechanisms for
dealing with them.

A rough draft of some of the concepts presented here was first posted on the
python-ideas list [1], but they have evolved considerably since first being
discussed in that thread.


Fixing dual imports of the main module
--------------------------------------

Two simple changes are proposed to fix this problem:

1. In ``runpy``, modify the implementation of the ``-m`` switch handling to
   install the specified module in ``sys.modules`` under both its real name
   and the name ``__main__``. (Currently it is only installed as the latter)
2. When directly executing a module, install it in ``sys.modules`` under
   ``os.path.splitext(os.path.basename(__file__))[0]`` as well as under
   ``__main__``.

With the main module also stored under its "real" name, imports will pick it
up from the ``sys.modules`` cache rather than reimporting it under a new name.


Fixing direct execution inside packages
---------------------------------------

To fix this problem, it is proposed that an additional filesystem check be
performed before proceeding with direct execution of a ``PY_SOURCE`` or
``PY_COMPILED`` file that has been named on the command line.

This additional check would look for an ``__init__`` file that is a peer to
the specified file with a matching extension (either ``.py``, ``.pyc`` or
``.pyo``, depending what was passed on the command line).

If this check fails to find anything, direct execution proceeds as usual.

If, however, it finds something, execution is handed over to a
helper function in the ``runpy`` module that ``runpy.run_path`` also invokes
in the same circumstances. That function will walk back up the
directory hierarchy from the supplied path, looking for the first directory
that doesn't contain an ``__init__`` file. Once that directory is found, it
will be set to ``sys.path[0]``, ``sys.argv[0]`` will be set to ``-m`` and
``runpy._run_module_as_main`` will be invoked with the appropriate module
name (as calculated based on the original filename and the directories
traversed while looking for a directory without an ``__init__`` file.


Fixing pickling without breaking introspection
----------------------------------------------

To fix this problem, it is proposed to add two optional module level
attributes: ``__source_name__`` and ``__pickle_name__``.

When setting the ``__module__`` attribute on a function or class, the
interpreter will be updated to use ``__source_name__`` if defined, falling
back to ``__name__`` otherwise.

``__source_name__`` will automatically be set to the main module's "real" name
(as described above under the fix to prevent duplicate imports of the main
module) by the interpreter. This will fix both pickling and introspection for
the main module.

It is also proposed that the pickling mechanism for classes and functions be
updated to use an optional ``__pickle_module__`` attribute when deciding how
to pickle these objects (falling back to the existing ``__module__``
attribute if the optional attribute is not defined). When a class or function
is defined, this optional attribute will be defined if ``__pickle_name__`` is
defined at the module level, and left out otherwise. This will allow
pseudo-modules to fix pickling without breaking introspection.

Other serialisation schemes could add support for this new attribute
relatively easily by replacing ``x.__module__`` with ``getattr(x,
"__pickle_module__", x.__module__)``.

``pydoc`` and ``inspect`` would also be updated to make appropriate use of
the new attributes for any cases not already covered by the above rules for
setting ``__module__``.

Fixing multiprocessing on Windows
---------------------------------

With ``__source_name__`` now available to tell ``multiprocessing`` the real
name of the main module, it should be able to simply include it in the
serialised information passed to the child process, eliminating the dubious
reverse engineering of the ``__file__`` attribute.


Reference Implementation
========================

None as yet. I'll probably be sprinting on this after Pycon.


References
==========

.. [1] Module aliases and/or "real names"
   (http://mail.python.org/pipermail/python-ideas/2011-January/008983.html)


Copyright
=========

This document has been placed in the public domain.


-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar  4 16:33:53 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 01:33:53 +1000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <20110304101057.6b16622e@neurotica.wooz.org>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
Message-ID: <AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>

On Sat, Mar 5, 2011 at 1:10 AM, Barry Warsaw <barry at python.org> wrote:
> Folks, please stop CC'ing peps at python.org for non-PEP submissions. ?They all
> get held for moderator approval. ?I've approved a few of them, but I'm going
> to start rejecting them (so you get a bounce :) unless the message actually
> contains a PEP.

Sorry, I didn't even notice that was on the CC list. Don't add the
PEP, I already created PEP 394 for it :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar  4 16:36:42 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 01:36:42 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110304135723.F3307249609@kimball.webabinitio.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
Message-ID: <AANLkTi=2esrruwVbUj8+vTZL=tZ6ByTvXELUhOHZne7n@mail.gmail.com>

On Fri, Mar 4, 2011 at 11:57 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Fri, 04 Mar 2011 01:44:00 -0600, Kerrick Staley <mail at kerrickstaley.com> wrote:
>> * All new 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).
>> This distinction should be made in shebangs, when invoking from a shell
>> script, when invoking via the system() call, or when invoking in any other
>> context.
>
> If one target for this PEP is script implementors who hadn't thought
> about this issue before, it is probably worth mentioning sys.executable
> somewhere (a footnote?).

Including a mention of sys.executable is actually one of the changes I
made to Kerrick's text before uploading it as PEP 394.

> But another issue here (and this speaks against the proposal of not
> shipping a /usr/bin/python link) is that it is quite possible to write
> a script that will run on either python2 or python3.

Good point, the PEP should probably mention that.

Sleep is calling me right now, though :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From exarkun at twistedmatrix.com  Fri Mar  4 16:59:59 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Fri, 04 Mar 2011 15:59:59 -0000
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
Message-ID: <20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>

On 03:30 pm, ncoghlan at gmail.com wrote:
>
>
>Fixing dual imports of the main module
>--------------------------------------
>
>Two simple changes are proposed to fix this problem:
>
>1. In ``runpy``, modify the implementation of the ``-m`` switch 
>handling to
>   install the specified module in ``sys.modules`` under both its real 
>name
>   and the name ``__main__``. (Currently it is only installed as the 
>latter)
>2. When directly executing a module, install it in ``sys.modules`` 
>under
>   ``os.path.splitext(os.path.basename(__file__))[0]`` as well as under
>   ``__main__``.
>
>With the main module also stored under its "real" name, imports will 
>pick it
>up from the ``sys.modules`` cache rather than reimporting it under a 
>new name.

Something to consider here is how this will interact with Python files 
which are _not_ modules.  I'm a little uneasy about having 
sys.modules["trial"] refer to the module defined by /usr/bin/trial.

Jean-Paul

From skip at pobox.com  Fri Mar  4 17:05:39 2011
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 4 Mar 2011 10:05:39 -0600
Subject: [Python-Dev] Rietveld or Review Board use?
Message-ID: <19825.3539.996141.703453@montanaro.dyndns.org>

Is Rietveld or Review Board being used within the Python core development
community?  I looked at the dev guide but didn't see anything obvious about
code reviews.  I don't see how to search the Rietveld instance at
codereview.appspot.com looking just for Python core review requests.

My aim here is to provide some examples to a colleague at work.  I wanted to
give him some examples related to code with which I'm familiar.

Thx,

Skip

From victor.stinner at haypocalc.com  Fri Mar  4 17:19:46 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 04 Mar 2011 17:19:46 +0100
Subject: [Python-Dev] Rietveld or Review Board use?
In-Reply-To: <19825.3539.996141.703453@montanaro.dyndns.org>
References: <19825.3539.996141.703453@montanaro.dyndns.org>
Message-ID: <1299255586.27406.1.camel@marge>

Le vendredi 04 mars 2011 ? 10:05 -0600, skip at pobox.com a ?crit :
> Is Rietveld or Review Board being used within the Python core development
> community?  I looked at the dev guide but didn't see anything obvious about
> code reviews.  I don't see how to search the Rietveld instance at
> codereview.appspot.com looking just for Python core review requests.
> 
> My aim here is to provide some examples to a colleague at work.  I wanted to
> give him some examples related to code with which I'm familiar.

I used it at least twice.

Issue #9425: http://codereview.appspot.com/1874048
Issue #3080: http://codereview.appspot.com/3972045

Victor



From fdrake at acm.org  Fri Mar  4 17:22:07 2011
From: fdrake at acm.org (Fred Drake)
Date: Fri, 4 Mar 2011 11:22:07 -0500
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
Message-ID: <AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>

On Fri, Mar 4, 2011 at 10:59 AM,  <exarkun at twistedmatrix.com> wrote:
> Something to consider here is how this will interact with Python files which
> are _not_ modules. ?I'm a little uneasy about having sys.modules["trial"]
> refer to the module defined by /usr/bin/trial.

I've long held the position that modules and scripts are distinct, and
should never share a source file.  All the work that's going into
dealing with this just reinforces my position.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein

From steve at pearwood.info  Fri Mar  4 17:27:45 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 05 Mar 2011 03:27:45 +1100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <1299250988.8766.2.camel@localhost.localdomain>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>
	<1299250988.8766.2.camel@localhost.localdomain>
Message-ID: <4D711301.3090507@pearwood.info>

Westley Mart?nez wrote:
> On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
>> On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley <mail at kerrickstaley.com> wrote:
>>> That way, if the sysadmin does decide to replace the installed "python" file, he can do so without inadvertently deleting the previously installed binary.
>> Nit pick: Change "he" to "they" to be gender neutral.
> 
> Nit pick: Change "they" to "he" to be grammatically correct. If we
> really have to be gender neutral, change "he" to "he or she".

Actually, that's a hyper-correction imposed by grammarians in the 18th 
century who were overly influenced by Latin. The use of "they" as a 
generic singular and indeterminate pronoun in written English goes back 
at least to Chaucer in the 14th century, and very likely as long back as 
before English was English, and remains in common use today. Despite the 
distaste for it among (mostly American) grammarians, it is 
linguistically sound and widely accepted in most of the English-speaking 
world, particularly England itself. The use of singular they is 
widespread, natural, and grammatically correct.

http://www.worldwidewords.org/qa/qa-the2.htm
http://en.wikipedia.org/wiki/Singular_they
http://itre.cis.upenn.edu/~myl/languagelog/archivs/005423.html

But for the sake of not upsetting our nuclear-armed cousins on the wrong 
side of the Atlantic *wink*, perhaps the sentence could be reworded to 
refer to system administrators plural, and thus satisfy everyone?

"That way, if sysadmins decide to replace the installed "python" file, 
they can do so without inadvertently deleting the previously installed 
binary."



-- 
Steven

From brian.curtin at gmail.com  Fri Mar  4 17:30:11 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Fri, 4 Mar 2011 10:30:11 -0600
Subject: [Python-Dev] Rietveld or Review Board use?
In-Reply-To: <19825.3539.996141.703453@montanaro.dyndns.org>
References: <19825.3539.996141.703453@montanaro.dyndns.org>
Message-ID: <AANLkTin9=PuahJSnMvZRs=eA_hsTRJYAUTur4MCGmu1o@mail.gmail.com>

On Fri, Mar 4, 2011 at 10:05, <skip at pobox.com> wrote:

> Is Rietveld or Review Board being used within the Python core development
> community?  I looked at the dev guide but didn't see anything obvious about
> code reviews.  I don't see how to search the Rietveld instance at
> codereview.appspot.com looking just for Python core review requests.
>
> My aim here is to provide some examples to a colleague at work.  I wanted
> to
> give him some examples related to code with which I'm familiar.
>
> Thx,
>
> Skip


I can't find an accompanying issue on Roundup, but participated in a review
of signalmodule.c changes [0] that resulted in a bunch of comments and
subsequent changes, which might be a decent example.

[0] http://codereview.appspot.com/1132041/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/d2377c74/attachment.html>

From steve at pearwood.info  Fri Mar  4 17:48:17 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 05 Mar 2011 03:48:17 +1100
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
Message-ID: <4D7117D1.6060201@pearwood.info>

Fred Drake wrote:
> On Fri, Mar 4, 2011 at 10:59 AM,  <exarkun at twistedmatrix.com> wrote:
>> Something to consider here is how this will interact with Python files which
>> are _not_ modules.  I'm a little uneasy about having sys.modules["trial"]
>> refer to the module defined by /usr/bin/trial.
> 
> I've long held the position that modules and scripts are distinct, and
> should never share a source file.  All the work that's going into
> dealing with this just reinforces my position.


Perhaps I've misunderstood something, but it seems to me that three out 
of the five problems described in the PEP have nothing to do with 
modules and scripts sharing the same file.



-- 
Steven


From ronaldoussoren at mac.com  Fri Mar  4 16:50:01 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 04 Mar 2011 15:50:01 +0000 (GMT)
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
Message-ID: <78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>



On 04 Mar, 2011,at 02:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

For *nix, I think there is a simple way forward that is an improvement
over where things stand now. For Windows, I don't think we can do much
better than the status quo and for Mac OS X... I think Apple will do
whatever Apple feel like doing :)
?
Apple will generally follow what we decide to do for the base install.?

Anyway, I'd say that OSX should do the same as Unix platforms here and support '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.

Ronald

P.S. I'm a bit confused about this discussion though, wouldn't adding python2 to the installation be a feature change and as such not something that can be done in a maintenance branch?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/bf134115/attachment.html>

From thomas at python.org  Fri Mar  4 17:59:40 2011
From: thomas at python.org (Thomas Wouters)
Date: Fri, 4 Mar 2011 08:59:40 -0800
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
Message-ID: <AANLkTikjU2yyia1-vWr55d3nUeT2e4uiQ1HLoypyPLhu@mail.gmail.com>

On Fri, Mar 4, 2011 at 07:30, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Fixing dual imports of the main module
> --------------------------------------
>
> Two simple changes are proposed to fix this problem:
>
> 1. In ``runpy``, modify the implementation of the ``-m`` switch handling to
>   install the specified module in ``sys.modules`` under both its real name
>   and the name ``__main__``. (Currently it is only installed as the latter)
> 2. When directly executing a module, install it in ``sys.modules`` under
>   ``os.path.splitext(os.path.basename(__file__))[0]`` as well as under
>   ``__main__``.
>
> With the main module also stored under its "real" name, imports will pick
> it
> up from the ``sys.modules`` cache rather than reimporting it under a new
> name.
>

This does nothing to fix another common error: *unwittingly* importing the
main module under its real name -- for example when you intended to import,
say, a standard library module of the same name. ('socket.py' is a
surprisingly common name for a script to experiment with socket
functionality. Likewise, nowadays, 'twitter.py'.) While the proposed change
would make it less *broken* to import the main module again, does it make it
any more *sensible*? Is there really a need to support this? A clear warning
-- or even error -- would seem much more in place. Doing so is not
particularly hard: keep a mapping of modules by canonical filename along
with by modulename, and refuse to add the same file twice. (I'm not talking
about executing a module inside a package, mind, since that can't shadow a
stdlib module by accident anymore.)

Fixing direct execution inside packages
> ---------------------------------------
>
> To fix this problem, it is proposed that an additional filesystem check be
> performed before proceeding with direct execution of a ``PY_SOURCE`` or
> ``PY_COMPILED`` file that has been named on the command line.
>

This should only happen if the file is a valid import target.


> This additional check would look for an ``__init__`` file that is a peer to
> the specified file with a matching extension (either ``.py``, ``.pyc`` or
> ``.pyo``, depending what was passed on the command line).
>

I assume you mean for this to match the normal import rules for packages;
why not just say that? Also, should this consider situations other than the
vanilla run/import-from-filesystem? Should meta-importers and such get a
crack at solving this?


> If this check fails to find anything, direct execution proceeds as usual.
>
> If, however, it finds something, execution is handed over to a
> helper function in the ``runpy`` module that ``runpy.run_path`` also
> invokes
> in the same circumstances. That function will walk back up the
> directory hierarchy from the supplied path, looking for the first directory
> that doesn't contain an ``__init__`` file. Once that directory is found, it
> will be set to ``sys.path[0]``, ``sys.argv[0]`` will be set to ``-m`` and
> ``runpy._run_module_as_main`` will be invoked with the appropriate module
> name (as calculated based on the original filename and the directories
> traversed while looking for a directory without an ``__init__`` file.
>
>
> Fixing pickling without breaking introspection
> ----------------------------------------------
>
> To fix this problem, it is proposed to add two optional module level
> attributes: ``__source_name__`` and ``__pickle_name__``.
>
> When setting the ``__module__`` attribute on a function or class, the
> interpreter will be updated to use ``__source_name__`` if defined, falling
> back to ``__name__`` otherwise.
>
> ``__source_name__`` will automatically be set to the main module's "real"
> name
> (as described above under the fix to prevent duplicate imports of the main
> module) by the interpreter. This will fix both pickling and introspection
> for
> the main module.
>
> It is also proposed that the pickling mechanism for classes and functions
> be
> updated to use an optional ``__pickle_module__`` attribute when deciding
> how
> to pickle these objects (falling back to the existing ``__module__``
> attribute if the optional attribute is not defined). When a class or
> function
> is defined, this optional attribute will be defined if ``__pickle_name__``
> is
> defined at the module level, and left out otherwise. This will allow
> pseudo-modules to fix pickling without breaking introspection.
>
> Other serialisation schemes could add support for this new attribute
> relatively easily by replacing ``x.__module__`` with ``getattr(x,
> "__pickle_module__", x.__module__)``.
>
> ``pydoc`` and ``inspect`` would also be updated to make appropriate use of
> the new attributes for any cases not already covered by the above rules for
> setting ``__module__``.
>

Is this cornercase really worth polluting the module namespace with more
confusing __*__ names? It seems more sensible to me to simply make pickle
refuse to operate on classes and functions defined in __main__. It wouldn't
even be the least understandable restriction in pickle. The
'__source_name__' attribute would read better as '__modulename__' (although
I'm not convinced of its need for the other reasons, either.)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/3ca8b7e0/attachment-0001.html>

From steve at pearwood.info  Fri Mar  4 18:04:20 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 05 Mar 2011 04:04:20 +1100
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
Message-ID: <4D711B94.2030502@pearwood.info>

Nick Coghlan wrote:

> Fixing direct execution inside packages
> ---------------------------------------
> 
> To fix this problem, it is proposed that an additional filesystem check be
> performed before proceeding with direct execution of a ``PY_SOURCE`` or
> ``PY_COMPILED`` file that has been named on the command line.
> 
> This additional check would look for an ``__init__`` file that is a peer to
> the specified file with a matching extension (either ``.py``, ``.pyc`` or
> ``.pyo``, depending what was passed on the command line).
> 
> If this check fails to find anything, direct execution proceeds as usual.
> 
> If, however, it finds something, execution is handed over to a
> helper function in the ``runpy`` module that ``runpy.run_path`` also invokes
> in the same circumstances. That function will walk back up the
> directory hierarchy from the supplied path, looking for the first directory
> that doesn't contain an ``__init__`` file. Once that directory is found, it
> will be set to ``sys.path[0]``,

I think you mean that sys.path[0] will be set to the directory path.

Should the current working directory continue to be included in the path 
when running a sub-package module?


-- 
Steven

From status at bugs.python.org  Fri Mar  4 18:07:03 2011
From: status at bugs.python.org (Python tracker)
Date: Fri,  4 Mar 2011 18:07:03 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20110304170703.8B9FB1CC5B@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2011-02-25 - 2011-03-04)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    2691 ( +9)
  closed 20487 (+65)
  total  23178 (+74)

Open issues with patches: 1143 


Issues opened (50)
==================

#11258: ctypes: Speed up find_library() on Linux by 500%
http://bugs.python.org/issue11258  reopened by pitrou

#11324: ConfigParser(interpolation=None) doesn't work
http://bugs.python.org/issue11324  opened by tbrink

#11329: PyEval_InitThreads() not safe before Py_Initialize()
http://bugs.python.org/issue11329  opened by Juraj.Ivancic

#11332: Increase logging/__init__.py coverage to 97%
http://bugs.python.org/issue11332  opened by drakeol

#11333: Add empty __slots__ to collections.abc abstract base classes
http://bugs.python.org/issue11333  opened by durban

#11335: Memory leak after key function failure in sort
http://bugs.python.org/issue11335  opened by stutzbach

#11337: Nothing refers to footnote [1] on page "6. Simple Statements" 
http://bugs.python.org/issue11337  opened by MLModel

#11338: No list of Python hg repositories
http://bugs.python.org/issue11338  opened by blokeley

#11339: annotation for class being defined
http://bugs.python.org/issue11339  opened by andyharrington

#11342: ResourceWarning: unclosed file <_io.TextIOWrapper
http://bugs.python.org/issue11342  opened by cjejuni2000

#11343: Make errors due to full parser stack identifiable
http://bugs.python.org/issue11343  opened by Trundle

#11344: Add height argument to os.path.dirname()
http://bugs.python.org/issue11344  opened by blokeley

#11346: Generator object should be mentioned in gc module document
http://bugs.python.org/issue11346  opened by ishimoto

#11347: libpython3.so: Broken soname and linking
http://bugs.python.org/issue11347  opened by Arfrever

#11349: _pickle should implement the module finalisation protocol
http://bugs.python.org/issue11349  opened by ncoghlan

#11350: __setitem__()'s problem of dbm.dumb object pointed out by comm
http://bugs.python.org/issue11350  opened by ysj.ray

#11352: Bug in cgi module doc
http://bugs.python.org/issue11352  opened by quentel

#11354: argparse: nargs could accept range of options count
http://bugs.python.org/issue11354  opened by wm

#11355: os.mkdir() and os.mkdirat() don't apply SUID/SGID permissions
http://bugs.python.org/issue11355  opened by Arfrever

#11357: Add support for PEP 381 -- Mirror Authenticity
http://bugs.python.org/issue11357  opened by kelseyhightower

#11361: suggestion for os.kill(pid,CTRL_C_EVENT)
http://bugs.python.org/issue11361  opened by iigor

#11362: image/webp missing from mimetypes.py
http://bugs.python.org/issue11362  opened by Richard.Rabbat

#11363: Curses - add missing functions to doc
http://bugs.python.org/issue11363  opened by sandro.tosi

#11364: Move from distutils.sysconfig to sysconfig in test_osx_env
http://bugs.python.org/issue11364  opened by eric.araujo

#11365: Integrate Buildroot patches (cross-compilation)
http://bugs.python.org/issue11365  opened by haypo

#11366: xml.etree.ElementTree.Element: docs should mention immediate s
http://bugs.python.org/issue11366  opened by techtonik

#11367: xml.etree.ElementTree.find(all): docs are wrong
http://bugs.python.org/issue11367  opened by techtonik

#11368: Document why xml.etree.ElementTree.Element has no reference to
http://bugs.python.org/issue11368  opened by techtonik

#11369: Add caching for the isEnabledFor() computation
http://bugs.python.org/issue11369  opened by William.Hart

#11370: Fix distutils to carry configure's LIBS through to extension m
http://bugs.python.org/issue11370  opened by jszakmeister

#11371: Localization of error messages in getopt
http://bugs.python.org/issue11371  opened by gruszczy

#11373: Fix 2 new typos in the docs
http://bugs.python.org/issue11373  opened by Retro

#11374: pkgutil.extend_path do not recognize py{c,o} file
http://bugs.python.org/issue11374  opened by Alexandre.Badez

#11375: urllib2 over SOCKS doesn't use proxy for DNS
http://bugs.python.org/issue11375  opened by OJW

#11376: Solaris/GCC/shared lib problem
http://bugs.python.org/issue11376  opened by dabrahams

#11379: Remove "lightweight" from minidom description
http://bugs.python.org/issue11379  opened by scoder

#11380: "close failed in file object destructor" when "Broken pipe" ha
http://bugs.python.org/issue11380  opened by ulidtko

#11382: some posix module functions unnecessarily release the GIL
http://bugs.python.org/issue11382  opened by neologix

#11383: compilation seg faults on insanely large expressions
http://bugs.python.org/issue11383  opened by ncoghlan

#11385: TextTestRunner methods are not documented
http://bugs.python.org/issue11385  opened by techtonik

#11387: Tkinter, callback functions
http://bugs.python.org/issue11387  opened by Nikolay.Fomichev

#11388: Implement MutableSequence.clear()
http://bugs.python.org/issue11388  opened by eli.bendersky

#11389: unittest: no way to control verbosity of doctests from cmd
http://bugs.python.org/issue11389  opened by techtonik

#11390: doctest: add cmdline parameters
http://bugs.python.org/issue11390  opened by techtonik

#11391: mmap write segfaults if PROT_WRITE bit is not set in prot
http://bugs.python.org/issue11391  opened by neologix

#11392: Turtle - better explain 'chaos' demo
http://bugs.python.org/issue11392  opened by sandro.tosi

#11393: Integrate faulthandler module into Python 3.3
http://bugs.python.org/issue11393  opened by haypo

#11394: No Tools/demo on Windows
http://bugs.python.org/issue11394  opened by techtonik

#11395: print(s) fails on Windows with long strings
http://bugs.python.org/issue11395  opened by casevh

#11340: test_distutils fails
http://bugs.python.org/issue11340  opened by anikom15



Most recent 15 issues with no replies (15)
==========================================

#11392: Turtle - better explain 'chaos' demo
http://bugs.python.org/issue11392

#11390: doctest: add cmdline parameters
http://bugs.python.org/issue11390

#11389: unittest: no way to control verbosity of doctests from cmd
http://bugs.python.org/issue11389

#11387: Tkinter, callback functions
http://bugs.python.org/issue11387

#11385: TextTestRunner methods are not documented
http://bugs.python.org/issue11385

#11380: "close failed in file object destructor" when "Broken pipe" ha
http://bugs.python.org/issue11380

#11376: Solaris/GCC/shared lib problem
http://bugs.python.org/issue11376

#11375: urllib2 over SOCKS doesn't use proxy for DNS
http://bugs.python.org/issue11375

#11367: xml.etree.ElementTree.find(all): docs are wrong
http://bugs.python.org/issue11367

#11361: suggestion for os.kill(pid,CTRL_C_EVENT)
http://bugs.python.org/issue11361

#11343: Make errors due to full parser stack identifiable
http://bugs.python.org/issue11343

#11337: Nothing refers to footnote [1] on page "6. Simple Statements" 
http://bugs.python.org/issue11337

#11319: Command line option -t (and -tt) does not work for a particula
http://bugs.python.org/issue11319

#11312: Confusing sentence in file.readline() doc
http://bugs.python.org/issue11312

#11310: Document byte[s|array]() and byte[s|array](count) in docstring
http://bugs.python.org/issue11310



Most recent 15 issues waiting for review (15)
=============================================

#11392: Turtle - better explain 'chaos' demo
http://bugs.python.org/issue11392

#11391: mmap write segfaults if PROT_WRITE bit is not set in prot
http://bugs.python.org/issue11391

#11382: some posix module functions unnecessarily release the GIL
http://bugs.python.org/issue11382

#11374: pkgutil.extend_path do not recognize py{c,o} file
http://bugs.python.org/issue11374

#11373: Fix 2 new typos in the docs
http://bugs.python.org/issue11373

#11371: Localization of error messages in getopt
http://bugs.python.org/issue11371

#11370: Fix distutils to carry configure's LIBS through to extension m
http://bugs.python.org/issue11370

#11365: Integrate Buildroot patches (cross-compilation)
http://bugs.python.org/issue11365

#11364: Move from distutils.sysconfig to sysconfig in test_osx_env
http://bugs.python.org/issue11364

#11363: Curses - add missing functions to doc
http://bugs.python.org/issue11363

#11361: suggestion for os.kill(pid,CTRL_C_EVENT)
http://bugs.python.org/issue11361

#11357: Add support for PEP 381 -- Mirror Authenticity
http://bugs.python.org/issue11357

#11355: os.mkdir() and os.mkdirat() don't apply SUID/SGID permissions
http://bugs.python.org/issue11355

#11354: argparse: nargs could accept range of options count
http://bugs.python.org/issue11354

#11350: __setitem__()'s problem of dbm.dumb object pointed out by comm
http://bugs.python.org/issue11350



Top 10 most discussed issues (10)
=================================

#9276: pickle should support methods
http://bugs.python.org/issue9276  15 msgs

#11342: ResourceWarning: unclosed file <_io.TextIOWrapper
http://bugs.python.org/issue11342  15 msgs

#11395: print(s) fails on Windows with long strings
http://bugs.python.org/issue11395  13 msgs

#8841: getopt errors should be specialized
http://bugs.python.org/issue8841  10 msgs

#11382: some posix module functions unnecessarily release the GIL
http://bugs.python.org/issue11382  10 msgs

#11284: slow close file descriptors in subprocess, popen2, os.popen*
http://bugs.python.org/issue11284   8 msgs

#11321: 9th import of module _pickle always crashes
http://bugs.python.org/issue11321   8 msgs

#11299: Allow deepcopying and pickling paused generators
http://bugs.python.org/issue11299   7 msgs

#11332: Increase logging/__init__.py coverage to 97%
http://bugs.python.org/issue11332   7 msgs

#11335: Memory leak after key function failure in sort
http://bugs.python.org/issue11335   7 msgs



Issues closed (62)
==================

#4761: create Python wrappers for openat() and others
http://bugs.python.org/issue4761  closed by pitrou

#6064: Add "daemon" argument to threading.Thread constructor
http://bugs.python.org/issue6064  closed by pitrou

#7322: Socket timeout can cause file-like readline() method to lose d
http://bugs.python.org/issue7322  closed by pitrou

#8594: Add a "source_address" option to ftplib
http://bugs.python.org/issue8594  closed by giampaolo.rodola

#8923: Remove unused "errors" argument	from	_PyUnicode_AsDefaultEncod
http://bugs.python.org/issue8923  closed by haypo

#8967: Create PyErr_GetWindowsMessage() function
http://bugs.python.org/issue8967  closed by haypo

#9197: Crash when importing an extension after Py_Initialize, Py_Fina
http://bugs.python.org/issue9197  closed by ncoghlan

#9373: pulldom has low code coverage
http://bugs.python.org/issue9373  closed by benjamin.peterson

#9795: nntplib.NNTP should support the context protocol
http://bugs.python.org/issue9795  closed by giampaolo.rodola

#9931: test_ttk_guionly hangs on XP5
http://bugs.python.org/issue9931  closed by pitrou

#10228: Refleak run of test_dbm fails when several dbm modules are ava
http://bugs.python.org/issue10228  closed by orsenthil

#10338: test_lib2to3 failure on buildbot x86 debian parallel 3.x: node
http://bugs.python.org/issue10338  closed by haypo

#10755: Add posix.fdlistdir
http://bugs.python.org/issue10755  closed by pitrou

#10784: os.getpriority() and os.setpriority()
http://bugs.python.org/issue10784  closed by giampaolo.rodola

#10829: PyUnicode_FromFormatV() bugs with "%" and "%%" format strings
http://bugs.python.org/issue10829  closed by haypo

#10831: PyUnicode_FromFormatV() doesn't support %li, %lli, %zi
http://bugs.python.org/issue10831  closed by haypo

#10866: Add sethostname()
http://bugs.python.org/issue10866  closed by pitrou

#10900: bz2 module fails to uncompress large files
http://bugs.python.org/issue10900  closed by pitrou

#10911: cgi: add more tests
http://bugs.python.org/issue10911  closed by haypo

#10956: file.write and file.read don't handle EINTR
http://bugs.python.org/issue10956  closed by pitrou

#11114: TextIOWrapper.tell extremely slow
http://bugs.python.org/issue11114  closed by pitrou

#11140: threading.Lock().release() raises _thread.error, not RuntimeEr
http://bugs.python.org/issue11140  closed by pitrou

#11172: Avoid '.' as runpath on AIX
http://bugs.python.org/issue11172  closed by pitrou

#11177: Set asyncore create_socket default argument
http://bugs.python.org/issue11177  closed by giampaolo.rodola

#11214: test_asyncore fails on AIX
http://bugs.python.org/issue11214  closed by giampaolo.rodola

#11246: PyUnicode_FromFormat("%V") decodes the byte string from ISO-88
http://bugs.python.org/issue11246  closed by haypo

#11250: 2to3 truncates files at formfeed character
http://bugs.python.org/issue11250  closed by benjamin.peterson

#11265: asyncore does not check for EAGAIN and EPIPE errno
http://bugs.python.org/issue11265  closed by giampaolo.rodola

#11291: poplib suppresses exception on QUIT
http://bugs.python.org/issue11291  closed by giampaolo.rodola

#11293: Distutils - read the file when using it in long_description
http://bugs.python.org/issue11293  closed by eric.araujo

#11297: Make ChainMap() public in the collections module.
http://bugs.python.org/issue11297  closed by rhettinger

#11303: b'x'.decode('latin1')	is	much	slower	than	b'x'.decode('latin-1
http://bugs.python.org/issue11303  closed by belopolsky

#11306: mailbox should test for errno.EROFS
http://bugs.python.org/issue11306  closed by r.david.murray

#11307: re engine exhaustively explores more than necessary
http://bugs.python.org/issue11307  closed by terry.reedy

#11314: Subprocess suffers 40% process creation overhead penalty
http://bugs.python.org/issue11314  closed by haypo

#11318: Python 3.2 FAQ example code typo?
http://bugs.python.org/issue11318  closed by georg.brandl

#11323: os.sendfile() bo failure on solaris
http://bugs.python.org/issue11323  closed by pitrou

#11325: compilation warning with sendfile
http://bugs.python.org/issue11325  closed by pitrou

#11326: connect_ex() implementation missing for SSL sockets
http://bugs.python.org/issue11326  closed by pitrou

#11327: Running test_time.py in python27 caused python to unexpectedly
http://bugs.python.org/issue11327  closed by brett.cannon

#11328: NESTED WHILE CYCLES ERROR
http://bugs.python.org/issue11328  closed by pitrou

#11330: logging doesn't support format flags for asctime keyword, but 
http://bugs.python.org/issue11330  closed by vinay.sajip

#11331: unused line in the logging-cookbook example
http://bugs.python.org/issue11331  closed by vinay.sajip

#11334: Failed to build _multiprocessing on Mac OS X
http://bugs.python.org/issue11334  closed by dev66

#11336: Typo in patch.rst
http://bugs.python.org/issue11336  closed by brett.cannon

#11341: test_os fails
http://bugs.python.org/issue11341  closed by pitrou

#11345: Fix a link in library/json docs
http://bugs.python.org/issue11345  closed by benjamin.peterson

#11348: test_os: test_set_get_priority() fails when high niceness is s
http://bugs.python.org/issue11348  closed by giampaolo.rodola

#11351: Mac OS X os.sendfile()
http://bugs.python.org/issue11351  closed by sdaoden

#11353: Python 2.7.1 cannot be built by 2.x baselines of Python
http://bugs.python.org/issue11353  closed by pitrou

#11356: Include module name on ImportError
http://bugs.python.org/issue11356  closed by georg.brandl

#11358: Please replace the use of pickle in multiprocessing with json.
http://bugs.python.org/issue11358  closed by r.david.murray

#11359: Please replace the use of pickle in subprocess with json.
http://bugs.python.org/issue11359  closed by ezio.melotti

#11360: In documentation of getopt, advertise argparse instead of optp
http://bugs.python.org/issue11360  closed by eric.araujo

#11372: Remove xrange from argparse docs
http://bugs.python.org/issue11372  closed by fdrake

#11377: Deprecate (remove?) platform.popen()
http://bugs.python.org/issue11377  closed by haypo

#11378: os.path.join when second  argument starts with '/' (linux/unix
http://bugs.python.org/issue11378  closed by amaury.forgeotdarc

#11381: pretending the "not" operator is a function behaves surprising
http://bugs.python.org/issue11381  closed by georg.brandl

#11384: Deprecate, remove or document (correctly) os.popen
http://bugs.python.org/issue11384  closed by haypo

#11386: Fix exception thrown by bytearray.pop() for empty bytearrays
http://bugs.python.org/issue11386  closed by eli.bendersky

#11396: add format handler to bytes object
http://bugs.python.org/issue11396  closed by eric.smith

#1720250: PyGILState_Ensure does not acquires GIL
http://bugs.python.org/issue1720250  closed by pitrou

From barry at python.org  Fri Mar  4 17:52:19 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 4 Mar 2011 11:52:19 -0500
Subject: [Python-Dev] Rietveld or Review Board use?
In-Reply-To: <1299255586.27406.1.camel@marge>
References: <19825.3539.996141.703453@montanaro.dyndns.org>
	<1299255586.27406.1.camel@marge>
Message-ID: <20110304115219.6ecb6689@neurotica.wooz.org>

On Mar 04, 2011, at 05:19 PM, Victor Stinner wrote:

>Le vendredi 04 mars 2011 ? 10:05 -0600, skip at pobox.com a ?crit :
>> Is Rietveld or Review Board being used within the Python core development
>> community?  I looked at the dev guide but didn't see anything obvious about
>> code reviews.  I don't see how to search the Rietveld instance at
>> codereview.appspot.com looking just for Python core review requests.
>> 
>> My aim here is to provide some examples to a colleague at work.  I wanted to
>> give him some examples related to code with which I'm familiar.
>
>I used it at least twice.
>
>Issue #9425: http://codereview.appspot.com/1874048
>Issue #3080: http://codereview.appspot.com/3972045

Yep, I used Rietveld for the PEP 3147/3149 patches and it was pretty nice.
It's not completely well integrated into our workflow, but it's cool enough
that I think we should promote it more.  Will that be easier once we're
permanently on Mercurial?

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/4aed4298/attachment.pgp>

From martin at v.loewis.de  Fri Mar  4 18:12:25 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 04 Mar 2011 18:12:25 +0100
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
In-Reply-To: <AANLkTin261KPx6WTv7OThjm1ivEO-7eF6X6ACst_MGkA@mail.gmail.com>
References: <4D70A45A.5090609@v.loewis.de>
	<AANLkTin261KPx6WTv7OThjm1ivEO-7eF6X6ACst_MGkA@mail.gmail.com>
Message-ID: <4D711D79.8020101@v.loewis.de>

> Would you consider working on benchmarking (http://speed.pypy.org but
> also infrastructure for running it) a part of core GSoC work? I can
> imagine this to be useful not only for pypy and preferably also
> running CPython trunk on benchmarks.

IMO, the question really is if this is "primarily" about coding.
If it is merely setting up software that already exists, it doesn't
convey the feeling of open source programming.

So unless the task is to come up with additional benchmarks (or some
such), I'd be opposed, I think. OTOH, PyPy is its own subgroup within
the PSF GSoC, so this is not for me to decide.

There is also the issue with greenfield projects - if the task is to
come up with a new webapp, it may not well integrate with an existing
code base. However, having that integration is (or should be, IMO)
also a requirement for GSoC.

Regards,
Martin

From g.brandl at gmx.net  Fri Mar  4 18:17:49 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 04 Mar 2011 18:17:49 +0100
Subject: [Python-Dev] rXXX links in the bug tracker after the migration
	to Mercurial
In-Reply-To: <1299243568.21701.23.camel@marge>
References: <1299243568.21701.23.camel@marge>
Message-ID: <ikr6tu$n6b$1@dough.gmane.org>

On 04.03.2011 13:59, Victor Stinner wrote:
> Hi,
> 
> Does the bug tracker will continue to support rXXXXX links after the
> migration to Mercurial? 

Yes.  They will link to http://hg.python.org/lookup/rXXXXX, which uses
the conversion metadata to find the correct hg revision.

The syntax for changeset hash links from now on is [hash], e.g.
[1a1ed76a6ae2].

Georg



From martin at v.loewis.de  Fri Mar  4 18:19:27 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 04 Mar 2011 18:19:27 +0100
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
In-Reply-To: <AANLkTinqUjPNL1L8Jv8KT1gdwA_y6cPam0DFO6jV+-np@mail.gmail.com>
References: <4D70A45A.5090609@v.loewis.de>
	<AANLkTinqUjPNL1L8Jv8KT1gdwA_y6cPam0DFO6jV+-np@mail.gmail.com>
Message-ID: <4D711F1F.1030009@v.loewis.de>

> Are proof-of-concept projects acceptable as GSoC projects?

I'd say so. It's more rewarding (both for the student and the project)
if the code has a chance to be integrated, at least in principle.
However, doing a project and then finding out that the real solution
should be similar but different is perfectly fine, IMO - it gives some
motivation for the student to do the real thing afterwards.

> Experimenting with this idea became significantly more feasible since
> Brett wrote importlib, but would still require a strong understanding
> of Python's import system. I suspect even a proof of concept that was
> tested against just filesystem imports and zipimport would prove quite
> tricky.

That, of course, makes it a difficult GSoC project. Ideally, the student
should have a clear vision of what needs to be done. Failing that, the
mentor should have a clear vision, and would then need frequent
communication with the student.

> Once the concept has been proven... I'm sure we could figure out
> *something* useful to do with the idea. It would depend on the details
> of what actually turns out to be feasible.

It can't hurt to post that idea on the wiki page, with detail as to
what might constitute success of the project. Students are expected
to write proposals elaborating what it is that they want to do, and
a decision on accepting projects is only taken after we have the
proposals (and ideally after the potential mentor had communication
with the student).

Regards,
Martin

From barry at python.org  Fri Mar  4 18:07:43 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 4 Mar 2011 12:07:43 -0500
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
Message-ID: <20110304120743.22042ded@neurotica.wooz.org>

On Mar 04, 2011, at 11:22 AM, Fred Drake wrote:

>On Fri, Mar 4, 2011 at 10:59 AM,  <exarkun at twistedmatrix.com> wrote:
>> Something to consider here is how this will interact with Python files which
>> are _not_ modules. ?I'm a little uneasy about having sys.modules["trial"]
>> refer to the module defined by /usr/bin/trial.
>
>I've long held the position that modules and scripts are distinct, and
>should never share a source file.  All the work that's going into
>dealing with this just reinforces my position.

I agree.  In fact, so do the distribution tools.  I don't even include actual
scripts in my packages any more, I just add the right goo to setup.py and let
distutils DTRT:


setup(
    # ...
    entry_points    = {
        'console_scripts' : list(scripts),
        },
    # ...
    )

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/f15ae21d/attachment.pgp>

From martin at v.loewis.de  Fri Mar  4 18:31:09 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 04 Mar 2011 18:31:09 +0100
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
In-Reply-To: <20110304133549.31ee15be@pitrou.net>
References: <4D70A45A.5090609@v.loewis.de> <20110304133549.31ee15be@pitrou.net>
Message-ID: <4D7121DD.9040208@v.loewis.de>

Am 04.03.2011 13:35, schrieb Antoine Pitrou:
> On Fri, 04 Mar 2011 09:35:38 +0100
> "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Google Summer of Code is coming up again, and we will again
>> be participating. Arc Riley will setup infrastructure later
>> today, and we need to start thinking about possible projects.
> 
> We've had a couple of people asking questions about GSoC on
> #python-dev. Each time I redirected them to Arc's personal email, since
> there seems to be no dedicated mailing-list for that. Is there a better
> way to inform them?

Not yet. The students worry too much: there is still plenty of time :-)
However, if they want to start contacting developers, and start
discussing ideas, and if they see Python core as a potential field of
activity, they should actually start talking on python-dev. The idea
is that they do not only bond with the mentor, but with the project.

In principle, talking on IRC is also a good idea, assuming any potential
mentors are listening there. Google recommends students to contact the
IRC channels. I personally don't use instant messaging usually, so
somebody else would need to give them his view on GSoC.

Likewise, if they want to contribute to some other project under the PSF
umbrella, they can start talking to the respective developers on the
respective channels.

Regards,
Martin

From martin at v.loewis.de  Fri Mar  4 18:33:31 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 04 Mar 2011 18:33:31 +0100
Subject: [Python-Dev] rXXX links in the bug tracker after the migration
 to Mercurial
In-Reply-To: <ikr6tu$n6b$1@dough.gmane.org>
References: <1299243568.21701.23.camel@marge> <ikr6tu$n6b$1@dough.gmane.org>
Message-ID: <4D71226B.7000800@v.loewis.de>

Am 04.03.2011 18:17, schrieb Georg Brandl:
> On 04.03.2011 13:59, Victor Stinner wrote:
>> Hi,
>>
>> Does the bug tracker will continue to support rXXXXX links after the
>> migration to Mercurial? 
> 
> Yes.  They will link to http://hg.python.org/lookup/rXXXXX, which uses
> the conversion metadata to find the correct hg revision.
> 
> The syntax for changeset hash links from now on is [hash], e.g.
> [1a1ed76a6ae2].

Is it really necessary to have the square brackets? ISTM that
the syntax of the short or long hash is unambiguous enough.

Regards,
Martin

From fuzzyman at voidspace.org.uk  Fri Mar  4 18:35:13 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 04 Mar 2011 17:35:13 +0000
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <20110304120743.22042ded@neurotica.wooz.org>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
	<20110304120743.22042ded@neurotica.wooz.org>
Message-ID: <4D7122D1.30505@voidspace.org.uk>

On 04/03/2011 17:07, Barry Warsaw wrote:
> On Mar 04, 2011, at 11:22 AM, Fred Drake wrote:
>
>> On Fri, Mar 4, 2011 at 10:59 AM,<exarkun at twistedmatrix.com>  wrote:
>>> Something to consider here is how this will interact with Python files which
>>> are _not_ modules.  I'm a little uneasy about having sys.modules["trial"]
>>> refer to the module defined by /usr/bin/trial.
>> I've long held the position that modules and scripts are distinct, and
>> should never share a source file.  All the work that's going into
>> dealing with this just reinforces my position.
> I agree.  In fact, so do the distribution tools.  I don't even include actual
> scripts in my packages any more, I just add the right goo to setup.py and let
> distutils DTRT:
>
>

That (below) is not distutils it is setuptools. distutils just uses 
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.

Michael Foord

> setup(
>      # ...
>      entry_points    = {
>          'console_scripts' : list(scripts),
>          },
>      # ...
>      )
>
> -Barry
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/9abc0601/attachment-0001.html>

From barry at python.org  Fri Mar  4 18:24:06 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 4 Mar 2011 12:24:06 -0500
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <4D7122D1.30505@voidspace.org.uk>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
	<20110304120743.22042ded@neurotica.wooz.org>
	<4D7122D1.30505@voidspace.org.uk>
Message-ID: <20110304122406.642c9bcc@neurotica.wooz.org>

On Mar 04, 2011, at 05:35 PM, Michael Foord wrote:

>That (below) is not distutils it is setuptools. distutils just uses `scripts=[...]`, which annoyingly *doesn't* work with setuptools.

Sure, but that'll all be moot when distutils2 is integrated into Python
3.3, right? :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/291b5224/attachment.pgp>

From fuzzyman at voidspace.org.uk  Fri Mar  4 18:45:00 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 04 Mar 2011 17:45:00 +0000
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <20110304122406.642c9bcc@neurotica.wooz.org>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>	<20110304120743.22042ded@neurotica.wooz.org>	<4D7122D1.30505@voidspace.org.uk>
	<20110304122406.642c9bcc@neurotica.wooz.org>
Message-ID: <4D71251C.9040209@voidspace.org.uk>

On 04/03/2011 17:24, Barry Warsaw wrote:
> On Mar 04, 2011, at 05:35 PM, Michael Foord wrote:
>
>> That (below) is not distutils it is setuptools. distutils just uses `scripts=[...]`, which annoyingly *doesn't* work with setuptools.
> Sure, but that'll all be moot when distutils2 is integrated into Python
> 3.3, right? :)
>

Nope. :-) It's still setuptools and not distutils2 format.

Michael

> -Barry


-- 
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


From mail at kerrickstaley.com  Fri Mar  4 18:45:14 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Fri, 4 Mar 2011 11:45:14 -0600
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
Message-ID: <AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>

> Right, but on Mac OS X we do put a "python3" on the path but not a
"python2". We also
> create "python2.x" and "python3.x" variants.

The PEP makes a recommendation for all *nix platform, which includes Mac OS
X. I was not aware that Apple preinstalled Python on OS X, but it doesn't
really matter: Apple is the "distribution maintainer", and they will be
expected to follow the recommendations of this PEP. Even if Apple is
sluggish in getting this change pushed out, it can be resolved on a
per-system basis by the sysadmin.

> On Windows we only have a "python.exe" I believe, but if the user does put
their Python
> installs on the path then we *could* usefully create "python2.exe" and
"python3.exe" for
> them. I don't see that duplicating these binaries on the filesystem is an
issue. File
> associations is just unsolvable on Windows, so it isn't something we can
address or should
> worry about. (Actually a stub python.exe that looks at the shebang line
and then
> delegates to the appropriate pythonX.Y.exe would be a possibility but I'm
not
> volunteering to write it.)

I like your idea for Windows, but it would take time to implement this
solution, and we won't be able to finalize the solution for *nix as quickly
if we also provide a provision for Windows in this same PEP.

We should keep the use of the singular "they"; it's more popular than the
universal "he" (I intended the universal, rather than gender-specific,
meaning in the drafts of the PEP).

-Kerrick Staley

On Fri, Mar 4, 2011 at 9:50 AM, Ronald Oussoren <ronaldoussoren at mac.com>wrote:

>
>
> On 04 Mar, 2011,at 02:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>
> For *nix, I think there is a simple way forward that is an improvement
> over where things stand now. For Windows, I don't think we can do much
> better than the status quo and for Mac OS X... I think Apple will do
> whatever Apple feel like doing :)
>
>
> Apple will generally follow what we decide to do for the base install.
>
> Anyway, I'd say that OSX should do the same as Unix platforms here and
> support '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.
>
> Ronald
>
> P.S. I'm a bit confused about this discussion though, wouldn't adding
> python2 to the installation be a feature change and as such not something
> that can be done in a maintenance branch?
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/a751e42d/attachment.html>

From martin at v.loewis.de  Fri Mar  4 18:51:49 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 04 Mar 2011 18:51:49 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D70ECC4.7090307@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<AANLkTi=dajHVy+J3y=D-5jAw72Gxs5k-JHLHVtU7mw6z@mail.gmail.com>	<4D70E22B.8080006@voidspace.org.uk>	<AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
	<4D70ECC4.7090307@voidspace.org.uk>
Message-ID: <4D7126B5.8090205@v.loewis.de>

>>> Should any of this also apply to Mac OS X and Windows?
>> Any platform that considers itself "unix-like" in this context can
>> decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
>> aspects of OS X). The main point of the PEP is to get a consensus
>> recommendation out of python-dev as to the best way forward (and I
>> think Kerrick did a good job of summarising the position that has been
>> expressed in this thread).
>>
> Right, but the pep doesn't address those issues for some fairly major
> platforms.

Correct. IIUC (i.e. from the viewpoint of the PEP author), that's
deliberate. He just doesn't care about Windows, and, as a PEP author,
he clearly has the right to do so :-)

> 
>> More generally, Windows and Mac OS X developers seem to be happier
>> with the idea of bundling a Python interpreter inside the application
>> than traditional *nix style platforms. This is a PITA for the system
>> maintainer when it comes time to handle security vulnerabilites, but
>> certainly more convenient when upgrading the default Python install.
>>
> 
> However on Mac OS X at least *scripts* have the same issue (what to put
> in the shebang line).

IMO, MacOS does fall under the rule of the PEP - it is unixish.
I agree with all things that Nick said, in particular with the
observation that Apple will do what Apple will do, no matter how
many PEPs we write. Our own "make install", for OSX, should clearly
do something similar to what it does on other Unix systems.

> On Windows we only have a "python.exe" I believe, but if the user does
> put their Python installs on the path then we *could* usefully create
> "python2.exe" and "python3.exe" for them. I don't see that duplicating
> these binaries on the filesystem is an issue. File associations is just
> unsolvable on Windows, so it isn't something we can address or should
> worry about. (Actually a stub python.exe that looks at the shebang line
> and then delegates to the appropriate pythonX.Y.exe would be a
> possibility but I'm not volunteering to write it.)

Here I also agree with Nick: the binary file name might be the least
issue. We had one bug report about 2.x and 3.x interference so far that
was difficult to track down - it seems that many Python users on Windows
set PYTHONPATH, and that is going to break Python 3 installations.

With that problem, and the extension problem, solving the exe name issue
doesn't actually resolve real problems.

Regards,
Martin

From fdrake at acm.org  Fri Mar  4 18:56:16 2011
From: fdrake at acm.org (Fred Drake)
Date: Fri, 4 Mar 2011 12:56:16 -0500
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <4D7122D1.30505@voidspace.org.uk>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
	<20110304120743.22042ded@neurotica.wooz.org>
	<4D7122D1.30505@voidspace.org.uk>
Message-ID: <AANLkTim9-uAhY0xoBqZ=KCcO+v8c0hjYCJoOdv7BBuv2@mail.gmail.com>

On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> That (below) is not distutils it is setuptools. distutils just uses
> `scripts=[...]`, which annoyingly *doesn't* work with setuptools.

Right; distutils scripts are just sad.

OTOH, entry-point based scripts are something setuptools got very,
very right.  Probably not perfect, but... I've not yet needed anything
different in practice.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein

From martin at v.loewis.de  Fri Mar  4 18:56:26 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 04 Mar 2011 18:56:26 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
References: <78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
Message-ID: <4D7127CA.4080307@v.loewis.de>

> P.S. I'm a bit confused about this discussion though, wouldn't adding
> python2 to the installation be a feature change and as such not
> something that can be done in a maintenance branch?

Correct. However, IMO, a PEP could propose to break that rule. Having
such a proposal may cause rejection of the PEP (or conditional
acceptance only if that change is not carried out). If the PEP is
accepted, a special case may be special enough to break the rules.

In addition, distributions can add all symlinks they like in their
packages, even if "make install" doesn't create them. Whether or not
*that* is a feature change depends on the distribution policy. For
example, for Debian, it would likely be perfectly reasonable to do
that in the 2.7 installation, since 2.7 will be a new feature for
Debian, anyway.

Regards,
Martin

From barry at python.org  Fri Mar  4 18:46:00 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 4 Mar 2011 12:46:00 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110304040954.GE3275@unaka.lan>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
Message-ID: <20110304124600.76c6446d@neurotica.wooz.org>

On Mar 03, 2011, at 08:09 PM, Toshio Kuratomi wrote:

>Note to dmalcolm: IIRC, that also means that the Feature page you point to
>isn't going to happen either.  Barry -- if other distros adopted stronger
>policies, then that might justify me taking this back to the Packaging
>Committee.

I know Scott Kitterman has talked about updating the Debian policy for various
issues.  Other Debian devs are on this list, but I'll bring it up over there
and get it on the radar.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/61d3408b/attachment.pgp>

From g.brandl at gmx.net  Fri Mar  4 19:06:41 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 04 Mar 2011 19:06:41 +0100
Subject: [Python-Dev] rXXX links in the bug tracker after the migration
	to Mercurial
In-Reply-To: <4D71226B.7000800@v.loewis.de>
References: <1299243568.21701.23.camel@marge> <ikr6tu$n6b$1@dough.gmane.org>
	<4D71226B.7000800@v.loewis.de>
Message-ID: <ikr9pd$66t$1@dough.gmane.org>

On 04.03.2011 18:33, "Martin v. L?wis" wrote:
> Am 04.03.2011 18:17, schrieb Georg Brandl:
>> On 04.03.2011 13:59, Victor Stinner wrote:
>>> Hi,
>>>
>>> Does the bug tracker will continue to support rXXXXX links after the
>>> migration to Mercurial? 
>> 
>> Yes.  They will link to http://hg.python.org/lookup/rXXXXX, which uses
>> the conversion metadata to find the correct hg revision.
>> 
>> The syntax for changeset hash links from now on is [hash], e.g.
>> [1a1ed76a6ae2].
> 
> Is it really necessary to have the square brackets? ISTM that
> the syntax of the short or long hash is unambiguous enough.

It's not really needed; but since it works with 6+ hex digits there might
be false positives.

Also, since the hashes can look deceptively like words to the eye I find
that they read better when marked clearly.

But of course this is not set in stone yet.

Georg


From fuzzyman at voidspace.org.uk  Fri Mar  4 19:10:13 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 04 Mar 2011 18:10:13 +0000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
	<AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>
Message-ID: <4D712B05.2020607@voidspace.org.uk>

On 04/03/2011 17:45, Kerrick Staley wrote:
> > Right, but on Mac OS X we do put a "python3" on the path but not a 
> "python2". We also
> > create "python2.x" and "python3.x" variants.
>
> The PEP makes a recommendation for all *nix platform, which includes 
> Mac OS X. I was not aware that Apple preinstalled Python on OS X, but 
> it doesn't really matter: Apple is the "distribution maintainer", and 
> they will be expected to follow the recommendations of this PEP. Even 
> if Apple is sluggish in getting this change pushed out, it can be 
> resolved on a per-system basis by the sysadmin.
>

So there are three issues:

* What Apple does with the system install - out of our control but we 
can make recommendations
* What `make install` does on Mac OS X
* What the standard Mac OS X installer does

The last two of these are in our control. If we actually make changes to 
the build/install scripts of 2.7, rather than just recommendations for 
distributions, then it would be nice to see the changes in the installer 
as well as the build script. This would ultimately be up to Ronald or 
Ned who do the Mac OS X work of course.

> > On Windows we only have a "python.exe" I believe, but if the user 
> does put their Python
> > installs on the path then we *could* usefully create "python2.exe" 
> and "python3.exe" for
> > them. I don't see that duplicating these binaries on the filesystem 
> is an issue. File
> > associations is just unsolvable on Windows, so it isn't something we 
> can address or should
> > worry about. (Actually a stub python.exe that looks at the shebang 
> line and then
> > delegates to the appropriate pythonX.Y.exe would be a possibility but 
> I'm not
> > volunteering to write it.)
>
> I like your idea for Windows, but it would take time to implement this 
> solution, and we won't be able to finalize the solution for *nix as 
> quickly if we also provide a provision for Windows in this same PEP.

I don't think duplicating python.exe as python2.exe or python3.exe would 
be very much work at all, if we decide it is a good thing. Sure it 
doesn't resolve all the myriad problems of Python on Windows but I don't 
think that is a good reason not to consider it. Up to Martin on this one 
though and again depends if we just make recommendations or actually 
change Python 2.7.

All the best,

Michael

>
> We should keep the use of the singular "they"; it's more popular than 
> the universal "he" (I intended the universal, rather than 
> gender-specific, meaning in the drafts of the PEP).
>
> -Kerrick Staley
>
> On Fri, Mar 4, 2011 at 9:50 AM, Ronald Oussoren 
> <ronaldoussoren at mac.com <mailto:ronaldoussoren at mac.com>> wrote:
>
>
>
>     On 04 Mar, 2011,at 02:21 PM, Nick Coghlan <ncoghlan at gmail.com
>     <mailto:ncoghlan at gmail.com>> wrote:
>>
>>     For *nix, I think there is a simple way forward that is an
>>     improvement
>>     over where things stand now. For Windows, I don't think we can do
>>     much
>>     better than the status quo and for Mac OS X... I think Apple will do
>>     whatever Apple feel like doing :)
>     Apple will generally follow what we decide to do for the base
>     install.
>
>     Anyway, I'd say that OSX should do the same as Unix platforms here
>     and support '#!/usr/bin/env python2'. Adding another symlink is
>     fairly trivial.
>
>     Ronald
>
>     P.S. I'm a bit confused about this discussion though, wouldn't
>     adding python2 to the installation be a feature change and as such
>     not something that can be done in a maintenance branch?
>
>     _______________________________________________
>     Python-Dev mailing list
>     Python-Dev at python.org <mailto:Python-Dev at python.org>
>     http://mail.python.org/mailman/listinfo/python-dev
>     Unsubscribe:
>     http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/c728dd7e/attachment-0001.html>

From barry at python.org  Fri Mar  4 19:31:27 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 4 Mar 2011 13:31:27 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
 upstream
In-Reply-To: <AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
Message-ID: <20110304133127.554716a0@neurotica.wooz.org>

On Mar 05, 2011, at 01:33 AM, Nick Coghlan wrote:

>On Sat, Mar 5, 2011 at 1:10 AM, Barry Warsaw <barry at python.org> wrote:
>> Folks, please stop CC'ing peps at python.org for non-PEP submissions. ?They all
>> get held for moderator approval. ?I've approved a few of them, but I'm going
>> to start rejecting them (so you get a bounce :) unless the message actually
>> contains a PEP.
>
>Sorry, I didn't even notice that was on the CC list. Don't add the
>PEP, I already created PEP 394 for it :)

Thanks!
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/9f3fd155/attachment.pgp>

From rdmurray at bitdance.com  Fri Mar  4 19:56:45 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 04 Mar 2011 13:56:45 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
References: <78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
Message-ID: <20110304185645.7DB6424778F@kimball.webabinitio.net>

On Fri, 04 Mar 2011 15:50:01 +0000, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> On 04 Mar, 2011,at 02:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> For *nix, I think there is a simple way forward that is an improvement
> over where things stand now. For Windows, I don't think we can do much
> better than the status quo and for Mac OS X... I think Apple will do
> whatever Apple feel like doing :)
> 
> Apple will generally follow what we decide to do for the base install.
> 
> Anyway, I'd say that OSX should do the same as Unix platforms here and support
> '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.

FYI, Ronald, the text version of your emails looses all quoting
information.  It would be nice if you could use standard email
quoting (leading '>' characters).

> P.S. I'm a bit confused about this discussion though, wouldn't adding python2 to
> the installation be a feature change and as such not something that can be done
> in a maintenance branch?

The purpose of the "no new features" rule is to prevent the situation
where a piece of code written for X.X.2 fails to run on X.X.1 because
it relies on a feature introduced in X.X.2.  In this situation, we
*already* have failures because scripts using /usr/bin/python2 that
run on one distro won't run on a different distro where that symlink
isn't defined.  In this case I don't think the "no new features" rule
can be applied blindly, because the feature has *already been introduced*
by third parties.  What we are attempting to do is make it *more* likely
that things will work in the future.

You can argue that having /usr/bin/python2 installed by 2.7.2 means
that code written for 2.7.2 that relies on it won't run on a vanilla
user-install of 2.7.1 or 2.7.  But how likely is that scenario compared
to the scenario where a script written for another distro fails to run
because /usr/bin/python2 doesn't exist?  I think the balance of the
argument comes down in favor of making the change, personally.

--
R. David Murray                                      www.bitdance.com

From barry at python.org  Fri Mar  4 19:56:39 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 4 Mar 2011 13:56:39 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110304043707.GF3275@unaka.lan>
References: <4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
	<20110303170804.GD3275@unaka.lan>
	<20110303214623.64e880ba@neurotica.wooz.org>
	<20110304043707.GF3275@unaka.lan>
Message-ID: <20110304135639.2bef9975@neurotica.wooz.org>

On Mar 03, 2011, at 08:37 PM, Toshio Kuratomi wrote:

>No, alternatives is really only useful for a very small class of problems
>[1]_ and [2]_.

Thanks for the clarification.  I was on the fence about making the suggestion
in the first place. ;)

>For this discussion there's an additional problem which is that alternatives
>works by creating symlinks.  Piotr O?arowski wants to make /usr/bin/python
>not exist so that scripts would have to use either /usr/bin/python3 or
>/usr/bin/python2.  If alternatives places a symlink there, it defeats the
>purpose of avoiding that path in the package itself.

I don't agree that /usr/bin/python should not be installed.  The draft PEP
language hits the right tone IMHO, and I would favor /usr/bin/python pointing
to /usr/bin/python2 on Debian, but primarily used only for the interactive
interpreter.

Or IOW, I still want users to be able to type 'python' at a shell prompt and
get the interpreter.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/5f2dcede/attachment.pgp>

From guido at python.org  Fri Mar  4 20:14:35 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Mar 2011 11:14:35 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <20110304133127.554716a0@neurotica.wooz.org>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
Message-ID: <AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>

Is there any discussion still going on about the details of the PEP
(now PEP 394)? I'm in favor of the general idea. What about Windows? I
think it should be the same there if possible.

The only thing I note is that the PEP doesn't explicitly state (unless
I missed it) that "python" should invoke the same Python binary as
either "python2" or "python3" and not some other version of Python
{2,3}.x (at least not until python4 is being considered :-).
Similarly, python2 and python3 should refer to one of the existing
python2.x or python3.x binary and not some other one.

-- 
--Guido van Rossum (python.org/~guido)

From skip at pobox.com  Fri Mar  4 20:18:38 2011
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 4 Mar 2011 13:18:38 -0600
Subject: [Python-Dev] Rietveld or Review Board use?
In-Reply-To: <20110304115219.6ecb6689@neurotica.wooz.org>
References: <19825.3539.996141.703453@montanaro.dyndns.org>
	<1299255586.27406.1.camel@marge>
	<20110304115219.6ecb6689@neurotica.wooz.org>
Message-ID: <19825.15118.372470.558984@montanaro.dyndns.org>

Thanks for the examples.  I've passed them along to my colleague.  The two
which Victor posted are (I think) particularly instructive because the
changes to support Unicode were so pervasive.  I don't see how you could
easily (if at all) get a decent review of those changes without support from
tools like Rietveld or Review Board.  At the very least it would take a huge
amount of dedication and effort to keep everything straight.

Skip


From albrecht.andi at googlemail.com  Fri Mar  4 20:53:08 2011
From: albrecht.andi at googlemail.com (Andi Albrecht)
Date: Fri, 4 Mar 2011 20:53:08 +0100
Subject: [Python-Dev] Rietveld or Review Board use?
In-Reply-To: <20110304115219.6ecb6689@neurotica.wooz.org>
References: <19825.3539.996141.703453@montanaro.dyndns.org>
	<1299255586.27406.1.camel@marge>
	<20110304115219.6ecb6689@neurotica.wooz.org>
Message-ID: <AANLkTin7yNXTBBe4jK9=Hc8P79+uFir5Ex_LSg91q=Lw@mail.gmail.com>

On Fri, Mar 4, 2011 at 5:52 PM, Barry Warsaw <barry at python.org> wrote:
> On Mar 04, 2011, at 05:19 PM, Victor Stinner wrote:
>
>>Le vendredi 04 mars 2011 ? 10:05 -0600, skip at pobox.com a ?crit :
>>> Is Rietveld or Review Board being used within the Python core development
>>> community? ?I looked at the dev guide but didn't see anything obvious about
>>> code reviews. ?I don't see how to search the Rietveld instance at
>>> codereview.appspot.com looking just for Python core review requests.
>>>
>>> My aim here is to provide some examples to a colleague at work. ?I wanted to
>>> give him some examples related to code with which I'm familiar.
>>
>>I used it at least twice.
>>
>>Issue #9425: http://codereview.appspot.com/1874048
>>Issue #3080: http://codereview.appspot.com/3972045
>
> Yep, I used Rietveld for the PEP 3147/3149 patches and it was pretty nice.
> It's not completely well integrated into our workflow, but it's cool enough
> that I think we should promote it more. ?Will that be easier once we're
> permanently on Mercurial?

FWIW there's a nice section in the contribution guidelines for the Go
language about code reviews and how they integrate Rietveld into their
development process: http://golang.org/doc/contribute.html#Code_review
They're using a wrapper around the upload.py script bundled as a
Mercurial extension.

And IIRC there's already some Roundup integration done.

-Andi

>
> -Barry
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/albrecht.andi%40googlemail.com
>
>

From a.badger at gmail.com  Fri Mar  4 21:00:43 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 4 Mar 2011 12:00:43 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110304135639.2bef9975@neurotica.wooz.org>
References: <4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
	<20110303170804.GD3275@unaka.lan>
	<20110303214623.64e880ba@neurotica.wooz.org>
	<20110304043707.GF3275@unaka.lan>
	<20110304135639.2bef9975@neurotica.wooz.org>
Message-ID: <20110304200043.GG3275@unaka.lan>

On Fri, Mar 04, 2011 at 01:56:39PM -0500, Barry Warsaw wrote:
> 
> I don't agree that /usr/bin/python should not be installed.  The draft PEP
> language hits the right tone IMHO, and I would favor /usr/bin/python pointing
> to /usr/bin/python2 on Debian, but primarily used only for the interactive
> interpreter.
> 
> Or IOW, I still want users to be able to type 'python' at a shell prompt and
> get the interpreter.
> 
Actually, my post was saying that these two can be decoupled.  ie: It's
possible to not have /usr/bin/python while still allowing users to type
python at a shell prompt and get the interpreter.

This is done by either redefining the PATH to include the directory that the
interpreter named "python" is in or by creating an alias for python to the
proper interpreter.

Using the environment-modules tools is one solution that operated in this
way.  It also, incidentally, would let each user of a system choose whether
python invoked python2 or python3 (and on Debian, which sub-version of
those).  A more hardcoded approach is to have the python package drop some
configuration into /etc/profile.d/ style directories where the distribution
places files that are run by default by the user's shell with the default
startup files.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/456d00ec/attachment.pgp>

From glyph at twistedmatrix.com  Fri Mar  4 21:48:33 2011
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Fri, 4 Mar 2011 15:48:33 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <1299250988.8766.2.camel@localhost.localdomain>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>
	<1299250988.8766.2.camel@localhost.localdomain>
Message-ID: <AANLkTi=3B4e+K9Q-n3TkfEWYv3LsecbyA8n9SxgEk2qG@mail.gmail.com>

On Fri, Mar 4, 2011 at 10:03 AM, Westley Mart?nez <anikom15 at gmail.com>wrote:

> On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
> > On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley <mail at kerrickstaley.com>
> wrote:
> > > That way, if the sysadmin does decide to replace the installed "python"
> file, he can do so without inadvertently deleting the previously installed
> binary.
> >
> > Nit pick: Change "he" to "they" to be gender neutral.
>
> Nit pick: Change "they" to "he" to be grammatically correct. If we
> really have to be gender neutral, change "he" to "he or she".


This grammatical "rule" is a modern fiction with no particular utility.  Go
ahead and use singular "they" as a gender-neutral pronoun; it was good
enough for Shakespeare, Twain, Austen and Shaw, it should be good enough for
Python.

http://en.wikipedia.org/wiki/Singular_they#Examples_of_generic_they
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/813e2973/attachment.html>

From santoso.wijaya at gmail.com  Fri Mar  4 22:01:02 2011
From: santoso.wijaya at gmail.com (Santoso Wijaya)
Date: Fri, 4 Mar 2011 13:01:02 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110228221034.53ebe810@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<4D67E9A5.5030203@cadifra.com>
	<20110225144315.3eebcafc@limelight.wooz.org>
	<4D684E2A.90005@netwok.org>
	<20110226154939.41972d08@limelight.wooz.org>
	<ikduo2$qm2$1@dough.gmane.org>
	<20110228100826.6812ad30@limelight.wooz.org>
	<20110228161538.36b825ac@pitrou.net>
	<20110228160748.1be8b814@limelight.wooz.org>
	<20110228221034.53ebe810@pitrou.net>
Message-ID: <AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>

Hi,

As a mercurial user, I thank you for this effort! One question, where/how do
I send suggestion to what to add into .hgignore file? In particular, I found
these dynamically generated files after a build in Windows (3.2) that
probably should be entered as .hgignore entries:

? PC/python_nt_d.h
? PC/pythonnt_rc_d.h



~/santa


On Mon, Feb 28, 2011 at 1:10 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Mon, 28 Feb 2011 16:07:48 -0500
> Barry Warsaw <barry at python.org> wrote:
> > On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote:
> >
> > >On Mon, 28 Feb 2011 10:08:26 -0500
> > >Barry Warsaw <barry at python.org> wrote:
> > >>
> > >> >BTW, I had not heard of hgeditor before, and wrote a small hg
> extension to
> > >> >do what you want (with HG: prefix :) before I saw that others had
> already
> > >> >replied with hgeditor.  The extension had 10 lines of code.
> > >>
> > >> We should find a place (i.e. repository) to stash these useful add-ons
> and
> > >> hacks so that all Python developers can find them.
> > >
> > >I think you can simply add them somewhere on the hg wiki:
> > >http://mercurial.selenic.com/wiki/
> > >and then link to the pages from our own wiki, or the developer's FAQ.
> >
> > If they're of general use to the hg community, sure.  Otherwise, it might
> be
> > good to have a place of our own for our own repository tools.
>
> Well, your diff-in-the-commit-editor-window is certainly not
> CPython-specific ;)
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/5fe80b00/attachment.html>

From martin at v.loewis.de  Fri Mar  4 22:15:17 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 04 Mar 2011 22:15:17 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<4D6763C0.3030904@v.loewis.de>	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>	<20110225111253.2f34357e@limelight.wooz.org>	<4D67E9A5.5030203@cadifra.com>	<20110225144315.3eebcafc@limelight.wooz.org>	<4D684E2A.90005@netwok.org>	<20110226154939.41972d08@limelight.wooz.org>	<ikduo2$qm2$1@dough.gmane.org>	<20110228100826.6812ad30@limelight.wooz.org>	<20110228161538.36b825ac@pitrou.net>	<20110228160748.1be8b814@limelight.wooz.org>	<20110228221034.53ebe810@pitrou.net>
	<AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
Message-ID: <4D715665.6060900@v.loewis.de>

> As a mercurial user, I thank you for this effort! One question,
> where/how do I send suggestion to what to add into .hgignore file? In
> particular, I found these dynamically generated files after a build in
> Windows (3.2) that probably should be entered as .hgignore entries:

All patches should go to the bug tracker. If you host a clone somewhere,
you could start publishing patches by referring to a remote repository,
rather than uploading the diff. I'm curious how this DVCS thing works
out for contributors.

Regards,
Martin

From martin at v.loewis.de  Fri Mar  4 22:21:48 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 04 Mar 2011 22:21:48 +0100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
Message-ID: <4D7157EC.5090709@v.loewis.de>

Am 04.03.2011 20:14, schrieb Guido van Rossum:
> Is there any discussion still going on about the details of the PEP
> (now PEP 394)? I'm in favor of the general idea. What about Windows? I
> think it should be the same there if possible.

I think a key issue is whether to change future 2.7 bug fix releases or
not. People have been opposed to the very notion of adding this feature
in a bug fix release; not sure how they feel if the change is
PEP-sanctioned.

As for Windows support: we currently don't install a python3.exe binary,
let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
adjust the installer if the PEP asks me to. For the reasons discussed,
I'm -0 on the change (i.e. double-clicking .py will continue to launch
the most-recently installed Python, rather than the "right" one, and
setting PYTHONPATH will continue to break installations).

Regards,
Martin



From foom at fuhm.net  Fri Mar  4 22:27:02 2011
From: foom at fuhm.net (James Y Knight)
Date: Fri, 4 Mar 2011 16:27:02 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D7157EC.5090709@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de>
Message-ID: <912B6B02-EF6E-4239-A7DA-22921820B1B1@fuhm.net>

On Mar 4, 2011, at 4:21 PM, Martin v. L?wis wrote:
> and setting PYTHONPATH will continue to break installations).

Indeed, it's really *quite* unfortunate that the proposal to make python3 use PYTHON3PATH instead of PYTHONPATH was rejected.

James

From martin at v.loewis.de  Fri Mar  4 22:35:43 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 04 Mar 2011 22:35:43 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D712B05.2020607@voidspace.org.uk>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>	<AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>
	<4D712B05.2020607@voidspace.org.uk>
Message-ID: <4D715B2F.7070501@v.loewis.de>

> I don't think duplicating python.exe as python2.exe or python3.exe would
> be very much work at all, if we decide it is a good thing. Sure it
> doesn't resolve all the myriad problems of Python on Windows but I don't
> think that is a good reason not to consider it. Up to Martin on this one
> though and again depends if we just make recommendations or actually
> change Python 2.7.

Changing the installer should be easy - there is a DuplicateFile table
in MSI (*) for this kind of installation task.

I'd still like the PEP to tell me whether it's python3w.exe or
pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
me). It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows (with the related question of
whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe)

Regards,
Martin

(*) http://msdn.microsoft.com/en-us/library/aa368335(v=vs.85).aspx

From martin at v.loewis.de  Fri Mar  4 22:45:24 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 04 Mar 2011 22:45:24 +0100
Subject: [Python-Dev] rXXX links in the bug tracker after the migration
 to Mercurial
In-Reply-To: <ikr9pd$66t$1@dough.gmane.org>
References: <1299243568.21701.23.camel@marge>
	<ikr6tu$n6b$1@dough.gmane.org>	<4D71226B.7000800@v.loewis.de>
	<ikr9pd$66t$1@dough.gmane.org>
Message-ID: <4D715D74.1060403@v.loewis.de>

> It's not really needed; but since it works with 6+ hex digits there might
> be false positives.

I searched the messages, and it turns out that primarily long numbers
would give false positives:

 Python 1.6a2 (#7, Apr 24 2000, 23:02:54)  [GCC pgcc-2.91.66 19990314
 minidom (as the proposed documentation in patch 101821 explains) does
 Closed as Duplicate; see bug 435026 for details.  It's an
 the test is extended to 2000000 objects on my machine
 IRIX rattler 6.5 10120734 IP32
 hash("DNSSEC") == 8704052292078464
 [New Thread 2305843009213881680 (LWP 23166)]

So I guess mandating square brackets is reasonable - alternatively,
mandating a fixed length could have worked as well, I guess.

Regards,
Martin

From dmalcolm at redhat.com  Fri Mar  4 22:51:15 2011
From: dmalcolm at redhat.com (David Malcolm)
Date: Fri, 04 Mar 2011 16:51:15 -0500
Subject: [Python-Dev] rXXX links in the bug tracker after the
	migration	to Mercurial
In-Reply-To: <ikr6tu$n6b$1@dough.gmane.org>
References: <1299243568.21701.23.camel@marge> <ikr6tu$n6b$1@dough.gmane.org>
Message-ID: <1299275475.20016.6.camel@radiator.bos.redhat.com>

On Fri, 2011-03-04 at 18:17 +0100, Georg Brandl wrote:
> On 04.03.2011 13:59, Victor Stinner wrote:
> > Hi,
> > 
> > Does the bug tracker will continue to support rXXXXX links after the
> > migration to Mercurial? 
> 
> Yes.  They will link to http://hg.python.org/lookup/rXXXXX, which uses
> the conversion metadata to find the correct hg revision.

Are these destinations meant to work yet?

I just tried one of these:
  http://hg.python.org/lookup/r81488
and it's giving me an "Internal Server Error"

FWIW, the above is a commit to release26-maint:
  http://svn.python.org/view?view=revision&revision=81488


Thanks
Dave


From solipsis at pitrou.net  Fri Mar  4 22:56:39 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 4 Mar 2011 22:56:39 +0100
Subject: [Python-Dev] rXXX links in the bug tracker after the migration
	to Mercurial
References: <1299243568.21701.23.camel@marge> <ikr6tu$n6b$1@dough.gmane.org>
	<4D71226B.7000800@v.loewis.de> <ikr9pd$66t$1@dough.gmane.org>
	<4D715D74.1060403@v.loewis.de>
Message-ID: <20110304225639.068cc9b4@pitrou.net>

On Fri, 04 Mar 2011 22:45:24 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> > It's not really needed; but since it works with 6+ hex digits there might
> > be false positives.
> 
> I searched the messages, and it turns out that primarily long numbers
> would give false positives:
> 
>  Python 1.6a2 (#7, Apr 24 2000, 23:02:54)  [GCC pgcc-2.91.66 19990314
>  minidom (as the proposed documentation in patch 101821 explains) does
>  Closed as Duplicate; see bug 435026 for details.  It's an
>  the test is extended to 2000000 objects on my machine
>  IRIX rattler 6.5 10120734 IP32
>  hash("DNSSEC") == 8704052292078464
>  [New Thread 2305843009213881680 (LWP 23166)]
> 
> So I guess mandating square brackets is reasonable - alternatively,
> mandating a fixed length could have worked as well, I guess.

The two forms used in hg's output are 10-digit and 40-digit ids
(the latter only with --debug, IIUC). The only reason to use another
form (especially shorter) is if you type the changeset id by hand
rather than paste it, which must not be very common.

And if there are false positives from time to time, well they'll just
link to 404s (unknown ids). I don't think that's an important issue.

Regards

Antoine.



From santoso.wijaya at gmail.com  Fri Mar  4 23:03:48 2011
From: santoso.wijaya at gmail.com (Santoso Wijaya)
Date: Fri, 4 Mar 2011 14:03:48 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D715665.6060900@v.loewis.de>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<4D67E9A5.5030203@cadifra.com>
	<20110225144315.3eebcafc@limelight.wooz.org>
	<4D684E2A.90005@netwok.org>
	<20110226154939.41972d08@limelight.wooz.org>
	<ikduo2$qm2$1@dough.gmane.org>
	<20110228100826.6812ad30@limelight.wooz.org>
	<20110228161538.36b825ac@pitrou.net>
	<20110228160748.1be8b814@limelight.wooz.org>
	<20110228221034.53ebe810@pitrou.net>
	<AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
	<4D715665.6060900@v.loewis.de>
Message-ID: <AANLkTimfeodCyBgzOZ_atKZxXdGs1AAHiTjesZObs1k-@mail.gmail.com>

>
> [...] publishing patches by referring to a remote repository,
>
rather than uploading the diff.
>

Is this a recommended workflow at this point, or should we generate/attach
patch files still? Both, for experimentation?

~/santa


On Fri, Mar 4, 2011 at 1:15 PM, "Martin v. L?wis" <martin at v.loewis.de>wrote:

> > As a mercurial user, I thank you for this effort! One question,
> > where/how do I send suggestion to what to add into .hgignore file? In
> > particular, I found these dynamically generated files after a build in
> > Windows (3.2) that probably should be entered as .hgignore entries:
>
> All patches should go to the bug tracker. If you host a clone somewhere,
> you could start publishing patches by referring to a remote repository,
> rather than uploading the diff. I'm curious how this DVCS thing works
> out for contributors.
>
> Regards,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/ddcd00d4/attachment.html>

From solipsis at pitrou.net  Fri Mar  4 23:09:36 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 04 Mar 2011 23:09:36 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTimfeodCyBgzOZ_atKZxXdGs1AAHiTjesZObs1k-@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<4D67E9A5.5030203@cadifra.com>
	<20110225144315.3eebcafc@limelight.wooz.org>
	<4D684E2A.90005@netwok.org>
	<20110226154939.41972d08@limelight.wooz.org>
	<ikduo2$qm2$1@dough.gmane.org>
	<20110228100826.6812ad30@limelight.wooz.org>
	<20110228161538.36b825ac@pitrou.net>
	<20110228160748.1be8b814@limelight.wooz.org>
	<20110228221034.53ebe810@pitrou.net>
	<AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
	<4D715665.6060900@v.loewis.de>
	<AANLkTimfeodCyBgzOZ_atKZxXdGs1AAHiTjesZObs1k-@mail.gmail.com>
Message-ID: <1299276576.3721.7.camel@localhost.localdomain>

Le vendredi 04 mars 2011 ? 14:03 -0800, Santoso Wijaya a ?crit :
>         [...] publishing patches by referring to a remote repository,
>         rather than uploading the diff.
> 
> 
> Is this a recommended workflow at this point, or should we
> generate/attach patch files still? Both, for experimentation? 

Pragmatically, I think we would still prefer patches, but Mercurial
should make it much easier to maintain them - e.g. you can use mq (which
is what Mercurial devs themselves use, actually).

We can also experiment with other forms of publishing changes, but I
think that would require the publisher to somehow collapses their own
changesets, so that it finally amounts to reviewing a patch.  In my
opinion at least, it would be bad if we started integrating intermediate
changesets leading to a final patch just because Mercurial allows us to
do it. I think it's better if the public history line doesn't get
obscured with work-in-progress changesets.

Regards

Antoine.



From v+python at g.nevcal.com  Fri Mar  4 23:04:50 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Fri, 04 Mar 2011 14:04:50 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<AANLkTi=dajHVy+J3y=D-5jAw72Gxs5k-JHLHVtU7mw6z@mail.gmail.com>	<4D70E22B.8080006@voidspace.org.uk>
	<AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
Message-ID: <4D716202.4090000@g.nevcal.com>

On 3/4/2011 5:21 AM, Nick Coghlan wrote:
> On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>> Should any of this also apply to Mac OS X and Windows?
> Any platform that considers itself "unix-like" in this context can
> decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
> aspects of OS X). The main point of the PEP is to get a consensus
> recommendation out of python-dev as to the best way forward (and I
> think Kerrick did a good job of summarising the position that has been
> expressed in this thread).
>
> More generally, Windows and Mac OS X developers seem to be happier
> with the idea of bundling a Python interpreter inside the application
> than traditional *nix style platforms. This is a PITA for the system
> maintainer when it comes time to handle security vulnerabilites, but
> certainly more convenient when upgrading the default Python install.

Probably because Windows itself is so bloated -- so what is the problem 
with a few extra copies of Python, one per application?

I'm a Windows developer by necessity, rather than choice, but I still 
say ICK to bundling a Python inside my 50-100K Python scripts... bloats 
them to several MB each.


>> Note that we *do* have alternative distributors [1] of Python for these
>> platforms who may wish to follow any recommendations we have for 2.7, even
>> if we don't modify those installers for our own distributions.
> The really tricky part on Windows is handling file associations. I
> think we're just doomed on that front, unless we want to start
> supporting separate .py2 and .py3 extensions (and adding *that* in a
> maintenance release would be a far cry from just adding another
> symlink).

Supporting .py2 and .py3 extensions is not much harder than adding a 
symlink.  Easier, on versions of windows without symlinks :)

Sadly, Vista (I think) and 7 (for sure) restrict the  "assoc" and 
"ftype" commands with = signs, to being functional only in "Run as 
Administrator" shells, so on those versions, it is harder for the na?ve 
to do the reconfigurations themselves.

The extra ftypes and assoc definitions can simply be copied from the 
existing ones, adding or changing a version number.  Would be much nicer 
if the installer did it for the na?ve Windows user.


> The lack of near-universal symlink support on Windows filesystems is
> also an issue - we would have to duplicate files like python.exe and
> pythonw.exe on non-NTFS filesystems in order to provide them under
> alternative names.

Cheaper to make a couple copies of Python at install, than to bundle the 
whole Python environment in each application.

> For *nix, I think there is a simple way forward that is an improvement
> over where things stand now. For Windows, I don't think we can do much
> better than the status quo and for Mac OS X... I think Apple will do
> whatever Apple feel like doing :)

For Windows the status quo is pretty bad, so doing nothing is also 
pretty bad.  I agree the changes are "harder than an extra symlink" on 
Windows, but for someone that understand the installer, adding extra 
ftype and assoc is no harder, as it already knows how to install/replace 
that for .py files.

Sadly, there seems to be strong resistance to the idea of putting the 
Python install directory on the Windows path, of course, without some 
additional solutions (python2.exe, python3.exe, etc.), that doesn't help 
the multi-version install, only the single version install.

It would be _nice_, but harder, and harder to get consensus on, to write 
a little "python launcher" (in a compiled language, not Python, as that 
would double the startup time) to do some grunge on Windows.  Some 
possibilities, not all would be needed.

* Take over the Python.File ftype, look at the Unix #! line, extract the 
version, and run that version of Python from the installed Windows 
location for that version.

* Add .py2 & .py3 assoc and ftype for people that want to use 
Windows-like conventions to launch specific versions of Python.

* Could also add .py24, .py31, or even .py262, .py301, etc., assoc and 
ftype, depending on how many versions of Windows Python are installed.

* Support PYTHONxPATH, and convert to PYTHONPATH before launching 
pythonX.  Only needed if there are is a mix of python major versions 
installed, or PYTHONxPATH is defined in the environment.

* Implement a "Windows #! line" a line just after the "Unix #! line" 
that would specify what Windows executable should be run.  In this case, 
the first item should be adjusted, to use the Windows #! line when it 
exists, instead of extracting the version from the Unix #! line.  In the 
limit, this could be a general utility not limited to Python, that would 
provide Unix like execution of "Windows #! line"-aware applications, 
with or even without, file extensions (without is a little trickier, but 
apparently possible).  This would even allow the use of pythonw.exe to 
be specified for some scripts and not others... the script could choose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/c1f1313e/attachment.html>

From v+python at g.nevcal.com  Fri Mar  4 23:11:22 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Fri, 04 Mar 2011 14:11:22 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D715B2F.7070501@v.loewis.de>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>	<AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>	<4D712B05.2020607@voidspace.org.uk>
	<4D715B2F.7070501@v.loewis.de>
Message-ID: <4D71638A.1030409@g.nevcal.com>

On 3/4/2011 1:35 PM, "Martin v. L?wis" wrote:
> I'd still like the PEP to tell me whether it's python3w.exe or
> pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
> me). It would also be good if the PEP took a position on providing
> pythonXY.exe binaries on Windows (with the related question of
> whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe)

I agree the PEP should address these issues.  And since it is 
bikeshedding, as you say, I'm happy to just follow along.

I see no particular advantage to any of the choices, except that both 
"w", and ".exe" are Windows-only things, so making it "just like Unix" + 
Windows-only things would seem more convenient, in some ways.  So I'll 
start the voting for

python VERSION [w] .exe

as the windows sequence.  Whatever form of VERSION, with or without 
dots, is done for Unix seems good for Windows too, as far as I can tell.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/de8b28c9/attachment.html>

From barry at python.org  Fri Mar  4 23:39:17 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 4 Mar 2011 17:39:17 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D7157EC.5090709@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de>
Message-ID: <63B99AE5-557B-407D-93FD-713F88894483@python.org>

On Mar 4, 2011, at 4:21 PM, Martin v. L?wis wrote:

> Am 04.03.2011 20:14, schrieb Guido van Rossum:
>> Is there any discussion still going on about the details of the PEP
>> (now PEP 394)? I'm in favor of the general idea. What about Windows? I
>> think it should be the same there if possible.
> 
> I think a key issue is whether to change future 2.7 bug fix releases or
> not. People have been opposed to the very notion of adding this feature
> in a bug fix release; not sure how they feel if the change is
> PEP-sanctioned.

I personally don't think it's necessary to change Python 2's build.  Distros can easily do it, pointing to the PEP for justification.  But I'm also not strongly opposed, so -0 from me.

-Barry


From solipsis at pitrou.net  Sat Mar  5 00:23:35 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 5 Mar 2011 00:23:35 +0100
Subject: [Python-Dev] rXXX links in the bug tracker after the
	migration	to Mercurial
References: <1299243568.21701.23.camel@marge> <ikr6tu$n6b$1@dough.gmane.org>
	<1299275475.20016.6.camel@radiator.bos.redhat.com>
Message-ID: <20110305002335.4d8e75e7@pitrou.net>

On Fri, 04 Mar 2011 16:51:15 -0500
David Malcolm <dmalcolm at redhat.com> wrote:
> On Fri, 2011-03-04 at 18:17 +0100, Georg Brandl wrote:
> > On 04.03.2011 13:59, Victor Stinner wrote:
> > > Hi,
> > > 
> > > Does the bug tracker will continue to support rXXXXX links after the
> > > migration to Mercurial? 
> > 
> > Yes.  They will link to http://hg.python.org/lookup/rXXXXX, which uses
> > the conversion metadata to find the correct hg revision.
> 
> Are these destinations meant to work yet?
> 
> I just tried one of these:
>   http://hg.python.org/lookup/r81488
> and it's giving me an "Internal Server Error"

Should be fixed now.

cheers

Antoine.



From guido at python.org  Sat Mar  5 00:35:26 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Mar 2011 15:35:26 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D7157EC.5090709@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de>
Message-ID: <AANLkTingen0C7ATUr8HTA71M4UYzKgLi0YMwwBdctnVY@mail.gmail.com>

On Fri, Mar 4, 2011 at 1:21 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 04.03.2011 20:14, schrieb Guido van Rossum:
>> Is there any discussion still going on about the details of the PEP
>> (now PEP 394)? I'm in favor of the general idea. What about Windows? I
>> think it should be the same there if possible.
>
> I think a key issue is whether to change future 2.7 bug fix releases or
> not. People have been opposed to the very notion of adding this feature
> in a bug fix release; not sure how they feel if the change is
> PEP-sanctioned.

Personally I think this is fine -- it 's not like this is affecting
language or library compatibility, but doing this from now on
emphasizes that this is what we want distros to do. As far as I'm
concerned we could go further and add creation of the python2 symlink
to the "make install" target for new bugfix releases of older versions
too.

> As for Windows support: we currently don't install a python3.exe binary,
> let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
> adjust the installer if the PEP asks me to. For the reasons discussed,
> I'm -0 on the change (i.e. double-clicking .py will continue to launch
> the most-recently installed Python, rather than the "right" one, and
> setting PYTHONPATH will continue to break installations).

I'm not a Windows user so I'll leave this part to the group of
interested developers to reach consensus.

-- 
--Guido van Rossum (python.org/~guido)

From anikom15 at gmail.com  Sat Mar  5 00:41:48 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Fri, 04 Mar 2011 15:41:48 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
 upstream
In-Reply-To: <4D7157EC.5090709@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de>
Message-ID: <1299282108.21521.3.camel@localhost.localdomain>

On Fri, 2011-03-04 at 22:21 +0100, "Martin v. L?wis" wrote:
> As for Windows support: we currently don't install a python3.exe binary,
> let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
> adjust the installer if the PEP asks me to. For the reasons discussed,
> I'm -0 on the change (i.e. double-clicking .py will continue to launch
> the most-recently installed Python, rather than the "right" one, and
> setting PYTHONPATH will continue to break installations).

I think the python2.exe or python3.exe (or both) for Windows would be a
good idea. I also think we need to seriously consider fixing the
double-click action for Windows. .py2 and .py3 extensions could work,
but seems clumsy.


From brian.curtin at gmail.com  Sat Mar  5 00:52:26 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Fri, 4 Mar 2011 17:52:26 -0600
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D716202.4090000@g.nevcal.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTi=dajHVy+J3y=D-5jAw72Gxs5k-JHLHVtU7mw6z@mail.gmail.com>
	<4D70E22B.8080006@voidspace.org.uk>
	<AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
	<4D716202.4090000@g.nevcal.com>
Message-ID: <AANLkTim8gy3zNweZLYhD=p8gi7hLCK1nhJCmNp5myrLM@mail.gmail.com>

On Fri, Mar 4, 2011 at 16:04, Glenn Linderman <v+python at g.nevcal.com> wrote:
>
> Sadly, there seems to be strong resistance to the idea of putting the
> Python install directory on the Windows path, of course, without some
> additional solutions (python2.exe, python3.exe, etc.), that doesn't help the
> multi-version install, only the single version install.
>

FWIW, I plan on spending time on the PATH issue for 3.3. It seems like much
of the resistance could be quelled with actual code.

It would be _nice_, but harder, and harder to get consensus on, to write a
> little "python launcher" (in a compiled language, not Python, as that would
> double the startup time) to do some grunge on Windows.  Some possibilities,
> not all would be needed.
> <SNIP>
>
* Could also add .py24, .py31, or even .py262, .py301, etc., assoc and
> ftype, depending on how many versions of Windows Python are installed.
>

-INF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110304/2c5deb93/attachment.html>

From anikom15 at gmail.com  Sat Mar  5 01:10:29 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Fri, 04 Mar 2011 16:10:29 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D711301.3090507@pearwood.info>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>
	<1299250988.8766.2.camel@localhost.localdomain>
	<4D711301.3090507@pearwood.info>
Message-ID: <1299283829.21521.15.camel@localhost.localdomain>

On Sat, 2011-03-05 at 03:27 +1100, Steven D'Aprano wrote:
> Westley Mart?nez wrote:
> > On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
> >> On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley <mail at kerrickstaley.com> wrote:
> >>> That way, if the sysadmin does decide to replace the installed "python" file, he can do so without inadvertently deleting the previously installed binary.
> >> Nit pick: Change "he" to "they" to be gender neutral.
> > 
> > Nit pick: Change "they" to "he" to be grammatically correct. If we
> > really have to be gender neutral, change "he" to "he or she".
> 
> Actually, that's a hyper-correction imposed by grammarians in the 18th 
> century who were overly influenced by Latin. The use of "they" as a 
> generic singular and indeterminate pronoun in written English goes back 
> at least to Chaucer in the 14th century, and very likely as long back as 
> before English was English, and remains in common use today. Despite the 
> distaste for it among (mostly American) grammarians, it is 
> linguistically sound and widely accepted in most of the English-speaking 
> world, particularly England itself. The use of singular they is 
> widespread, natural, and grammatically correct.
> 
> http://www.worldwidewords.org/qa/qa-the2.htm
> http://en.wikipedia.org/wiki/Singular_they
> http://itre.cis.upenn.edu/~myl/languagelog/archivs/005423.html
> 
> But for the sake of not upsetting our nuclear-armed cousins on the wrong 
> side of the Atlantic *wink*, perhaps the sentence could be reworded to 
> refer to system administrators plural, and thus satisfy everyone?
> 
> "That way, if sysadmins decide to replace the installed "python" file, 
> they can do so without inadvertently deleting the previously installed 
> binary."
> 
> 

All right I have to reply to all these "singular they" remarks. Just
because the singular they has been used for a long time doesn't make it
right. It sounds unnatural, at least to me, and I've always been taught
to use "he or she" which I despise. So all my life I've used the generic
"he". Anyways, I remember reading somewhere that for Python Strunk and
White apply, and neither Strunk nor White like singular theys.


From ncoghlan at gmail.com  Sat Mar  5 01:14:31 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 10:14:31 +1000
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
In-Reply-To: <4D711F1F.1030009@v.loewis.de>
References: <4D70A45A.5090609@v.loewis.de>
	<AANLkTinqUjPNL1L8Jv8KT1gdwA_y6cPam0DFO6jV+-np@mail.gmail.com>
	<4D711F1F.1030009@v.loewis.de>
Message-ID: <AANLkTimpfa4K2ALp+kNBuQSdNMjmtA9EVS5CJ0Pa4GhF@mail.gmail.com>

On Sat, Mar 5, 2011 at 3:19 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Experimenting with this idea became significantly more feasible since
>> Brett wrote importlib, but would still require a strong understanding
>> of Python's import system. I suspect even a proof of concept that was
>> tested against just filesystem imports and zipimport would prove quite
>> tricky.
>
> That, of course, makes it a difficult GSoC project. Ideally, the student
> should have a clear vision of what needs to be done. Failing that, the
> mentor should have a clear vision, and would then need frequent
> communication with the student.

I have a reasonably clear vision of what I would like to see. I'm just
not sure if some of the assumptions underlying PEP 302 will make it
unworkable in practice given the current conventions (e.g. there is a
*lot* of code that accesses sys.modules directly. Accommodating such
code without modification would require some reasonably fancy footwork
with either thread local storage or stack frame inspection). If the
issues can't be worked around via TLS or frame inspection, I suspect
several of the PEP 302 interfaces would need to be modified to make
the system work with arbitrary importers and loaders, but actually
implementing something based on importlib (or a fork, if it turns out
interfaces need to change) would be the best way to find out.

I'm a little confused by the
http://wiki.python.org/moin/SummerOfCode/2011 page though. If I'm a
*member* of an approved project (CPython in this case), can I just add
an entry to the table? Or do I need to do something first to be
approved as a prospective mentor?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar  5 01:38:38 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 10:38:38 +1000
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
Message-ID: <AANLkTiktVFrf=FPUbYAWU==0Qn36Sp_7oM03Gd-u4UhZ@mail.gmail.com>

On Sat, Mar 5, 2011 at 2:22 AM, Fred Drake <fdrake at acm.org> wrote:
> On Fri, Mar 4, 2011 at 10:59 AM, ?<exarkun at twistedmatrix.com> wrote:
>> Something to consider here is how this will interact with Python files which
>> are _not_ modules. ?I'm a little uneasy about having sys.modules["trial"]
>> refer to the module defined by /usr/bin/trial.
>
> I've long held the position that modules and scripts are distinct, and
> should never share a source file. ?All the work that's going into
> dealing with this just reinforces my position.

While I actually have a lot of respect for that point of view (the
traps in PEP 395 can be read as a list of justifications for it!),
"python -m timeit", "python -m test", "python -m site" and assorted
other instances in the stdlib disagree with it. I don't think a purity
argument is going to fly here, because the practice of allowing
executable modules is just so damn useful for utility functionality
where a developer doesn't want to worry about global namespace
collisions on the system path . If we turned every module we have in
the stdlib with a little snippet of directly executable functionality
at the bottom into an installed script, I assume the distro packagers
would either outright ignore us or howl the place down with cries of
namespace pollution (and they'd be right to do so - the "-m" switch
*originated* in a discussion about making timeit easier to invoke on
different parallel Python installations without running into namespace
collision problems on the system path).

Besides, this particular ship really sailed way back in the early days
of Python's history when the "if __name__ == '__main__':" convention
was established to allow the same source file to behave differently
depending on how it was invoked (either as a module or as a script).
All PEP 395 is about is trying to make the way that works line up more
closely with people's intuitions.

However, as a slight tangent, note that one of the positive side
effects of the __main__.py file approach to directory and package
execution is that it *does* promote keeping the script behaviour and
the module behaviour in separate files.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From guido at python.org  Sat Mar  5 01:40:21 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Mar 2011 16:40:21 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <1299283829.21521.15.camel@localhost.localdomain>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>
	<1299250988.8766.2.camel@localhost.localdomain>
	<4D711301.3090507@pearwood.info>
	<1299283829.21521.15.camel@localhost.localdomain>
Message-ID: <AANLkTi=8sTFvN44FpZQqTU2x1iDFHLL+DG-aWwPcLat-@mail.gmail.com>

On Fri, Mar 4, 2011 at 4:10 PM, Westley Mart?nez <anikom15 at gmail.com>
> All right I have to reply to all these "singular they" remarks. Just
> because the singular they has been used for a long time doesn't make it
> right. It sounds unnatural, at least to me, and I've always been taught
> to use "he or she" which I despise. So all my life I've used the generic
> "he". Anyways, I remember reading somewhere that for Python Strunk and
> White apply, and neither Strunk nor White like singular theys.

That's how I felt 20 years ago. But since then I've come to appreciate
they as a much better alternative to either "he or she" or "he". Just
get used to it.

-- 
--Guido van Rossum (python.org/~guido)

From techtonik at gmail.com  Sat Mar  5 01:41:35 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 5 Mar 2011 02:41:35 +0200
Subject: [Python-Dev] Rietveld or Review Board use?
In-Reply-To: <AANLkTin7yNXTBBe4jK9=Hc8P79+uFir5Ex_LSg91q=Lw@mail.gmail.com>
References: <19825.3539.996141.703453@montanaro.dyndns.org>
	<1299255586.27406.1.camel@marge>
	<20110304115219.6ecb6689@neurotica.wooz.org>
	<AANLkTin7yNXTBBe4jK9=Hc8P79+uFir5Ex_LSg91q=Lw@mail.gmail.com>
Message-ID: <AANLkTinrKik0J5ikO-EXc6+3L6+Pua5oexU1T=9Re-xX@mail.gmail.com>

On Fri, Mar 4, 2011 at 9:53 PM, Andi Albrecht
<albrecht.andi at googlemail.com> wrote:
> On Fri, Mar 4, 2011 at 5:52 PM, Barry Warsaw <barry at python.org> wrote:
>> On Mar 04, 2011, at 05:19 PM, Victor Stinner wrote:
>>
>>>Le vendredi 04 mars 2011 ? 10:05 -0600, skip at pobox.com a ?crit :
>>>> Is Rietveld or Review Board being used within the Python core development
>>>> community? ?I looked at the dev guide but didn't see anything obvious about
>>>> code reviews. ?I don't see how to search the Rietveld instance at
>>>> codereview.appspot.com looking just for Python core review requests.
>>>>
>>>> My aim here is to provide some examples to a colleague at work. ?I wanted to
>>>> give him some examples related to code with which I'm familiar.
>>>
>>>I used it at least twice.
>>>
>>>Issue #9425: http://codereview.appspot.com/1874048
>>>Issue #3080: http://codereview.appspot.com/3972045
>>
>> Yep, I used Rietveld for the PEP 3147/3149 patches and it was pretty nice.
>> It's not completely well integrated into our workflow, but it's cool enough
>> that I think we should promote it more. ?Will that be easier once we're
>> permanently on Mercurial?
>
> FWIW there's a nice section in the contribution guidelines for the Go
> language about code reviews and how they integrate Rietveld into their
> development process: http://golang.org/doc/contribute.html#Code_review
> They're using a wrapper around the upload.py script bundled as a
> Mercurial extension.

Chromium uses tweaked upload.py script too.

> And IIRC there's already some Roundup integration done.

Yes, you should ask Martin about it. I believe he told about some
performance problems, but I don't remember if he tried to investigate
the source of the problem. Probably he doesn't have enough time.

-- 
anatoly t.

From techtonik at gmail.com  Sat Mar  5 01:44:08 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 5 Mar 2011 02:44:08 +0200
Subject: [Python-Dev] rXXX links in the bug tracker after the migration
	to Mercurial
In-Reply-To: <20110305002335.4d8e75e7@pitrou.net>
References: <1299243568.21701.23.camel@marge> <ikr6tu$n6b$1@dough.gmane.org>
	<1299275475.20016.6.camel@radiator.bos.redhat.com>
	<20110305002335.4d8e75e7@pitrou.net>
Message-ID: <AANLkTi=zE0XZjoviDkdC7eD=UDpshxhS75vGexwax=FH@mail.gmail.com>

On Sat, Mar 5, 2011 at 1:23 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Fri, 04 Mar 2011 16:51:15 -0500
> David Malcolm <dmalcolm at redhat.com> wrote:
>> On Fri, 2011-03-04 at 18:17 +0100, Georg Brandl wrote:
>> > On 04.03.2011 13:59, Victor Stinner wrote:
>> > > Hi,
>> > >
>> > > Does the bug tracker will continue to support rXXXXX links after the
>> > > migration to Mercurial?
>> >
>> > Yes. ?They will link to http://hg.python.org/lookup/rXXXXX, which uses
>> > the conversion metadata to find the correct hg revision.
>>
>> Are these destinations meant to work yet?
>>
>> I just tried one of these:
>> ? http://hg.python.org/lookup/r81488
>> and it's giving me an "Internal Server Error"
>
> Should be fixed now.
>
> cheers

We need some service monitor for all this stuff.
--
anatoly t.

From mhammond at skippinet.com.au  Sat Mar  5 01:47:18 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 05 Mar 2011 11:47:18 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D7157EC.5090709@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de>
Message-ID: <4D718816.20304@skippinet.com.au>

On 5/03/2011 8:21 AM, "Martin v. L?wis" wrote:
...
> As for Windows support: we currently don't install a python3.exe binary,
> let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
> adjust the installer if the PEP asks me to. For the reasons discussed,
> I'm -0 on the change (i.e. double-clicking .py will continue to launch
> the most-recently installed Python, rather than the "right" one, and
> setting PYTHONPATH will continue to break installations).

I agree with the -0 - I simply don't think it will, in practice, make 
anyone's life much easier.  To run python2 and python3 based scripts in 
the same environment already requires some manual work by the machine 
owner (both directories will need to be added to the path) so the 
additional burden of some other steps (eg, .bat files, doskey alaises 
etc) doesn't seem that great.  There is also a small risk of confusion - 
people may believe python.exe and python2.exe/python3.exe have different 
purposes and be confused about when to use which.

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" :)

Cheers,

Mark

From martin at v.loewis.de  Sat Mar  5 01:59:49 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 05 Mar 2011 01:59:49 +0100
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
In-Reply-To: <AANLkTimpfa4K2ALp+kNBuQSdNMjmtA9EVS5CJ0Pa4GhF@mail.gmail.com>
References: <4D70A45A.5090609@v.loewis.de>	<AANLkTinqUjPNL1L8Jv8KT1gdwA_y6cPam0DFO6jV+-np@mail.gmail.com>	<4D711F1F.1030009@v.loewis.de>
	<AANLkTimpfa4K2ALp+kNBuQSdNMjmtA9EVS5CJ0Pa4GhF@mail.gmail.com>
Message-ID: <4D718B05.5060205@v.loewis.de>

> I'm a little confused by the
> http://wiki.python.org/moin/SummerOfCode/2011 page though. If I'm a
> *member* of an approved project (CPython in this case), can I just add
> an entry to the table? Or do I need to do something first to be
> approved as a prospective mentor?

It's a wiki, so feel free to edit it. If it gets too unorganized, I'm
sure Arc will post more specific rules. Telling him that you are a
prospective member (with the information he asked for) can't hurt,
though.

Regards,
Martin

From ncoghlan at gmail.com  Sat Mar  5 02:10:15 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 11:10:15 +1000
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <4D711B94.2030502@pearwood.info>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<4D711B94.2030502@pearwood.info>
Message-ID: <AANLkTi=eOPetOrxyFOrZ3FTK-knm0=HE=6OFEeSTr1Os@mail.gmail.com>

On Sat, Mar 5, 2011 at 3:04 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> I think you mean that sys.path[0] will be set to the directory path.

Indeed I did.

> Should the current working directory continue to be included in the path
> when running a sub-package module?

No, it would be similar to the current difference between "python
foo.py" and "python -m foo", with the former forcing path[0] to a
specific directory, while the latter follows the vagaries of the
current working directory.

~/devel$ cat > foo.py
import sys
print (repr(sys.path[0]))
~/devel$ python foo.py
'/home/ncoghlan/devel'
~/devel$ python -m foo
''

I'll elaborate on that point in the next update.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From tjreedy at udel.edu  Sat Mar  5 02:27:51 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 04 Mar 2011 20:27:51 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTi=8sTFvN44FpZQqTU2x1iDFHLL+DG-aWwPcLat-@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<AANLkTikEYNGePhDv6mVf6292+JfDy55JNm-7GFbyjZ2U@mail.gmail.com>	<1299250988.8766.2.camel@localhost.localdomain>	<4D711301.3090507@pearwood.info>	<1299283829.21521.15.camel@localhost.localdomain>
	<AANLkTi=8sTFvN44FpZQqTU2x1iDFHLL+DG-aWwPcLat-@mail.gmail.com>
Message-ID: <iks3il$lq7$1@dough.gmane.org>

On 3/4/2011 7:40 PM, Guido van Rossum wrote:
> On Fri, Mar 4, 2011 at 4:10 PM, Westley Mart?nez<anikom15 at gmail.com>
>> All right I have to reply to all these "singular they" remarks. Just
>> because the singular they has been used for a long time doesn't make it
>> right. It sounds unnatural, at least to me, and I've always been taught
>> to use "he or she" which I despise. So all my life I've used the generic
>> "he". Anyways, I remember reading somewhere that for Python Strunk and
>> White apply, and neither Strunk nor White like singular theys.
>
> That's how I felt 20 years ago.

I still feel that way ...

> But since then I've come to appreciate
> they as a much better alternative to either "he or she" or "he". Just
> get used to it.

But I discovered long ago that abstract singulars can nearly always be 
pluralized, as the statement is nearly always about people rather than 
any particular person.

-- 
Terry Jan Reedy



From ncoghlan at gmail.com  Sat Mar  5 02:42:05 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 11:42:05 +1000
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTikjU2yyia1-vWr55d3nUeT2e4uiQ1HLoypyPLhu@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<AANLkTikjU2yyia1-vWr55d3nUeT2e4uiQ1HLoypyPLhu@mail.gmail.com>
Message-ID: <AANLkTi=5_3_=m5ZciEs+wgYDbdd5gSCDPuZZ9p8QqPi2@mail.gmail.com>

On Sat, Mar 5, 2011 at 2:59 AM, Thomas Wouters <thomas at python.org> wrote:
> This does nothing to fix another common error: *unwittingly* importing the
> main module under its real name -- for example when you intended to import,
> say, a standard library module of the same name. ('socket.py' is a
> surprisingly common name for a script to experiment with socket
> functionality. Likewise, nowadays, 'twitter.py'.) While the proposed change
> would make it less *broken* to import the main module again, does it make it
> any more *sensible*? Is there really a need to support this? A clear warning
> -- or even error -- would seem much more in place. Doing so is not
> particularly hard: keep a mapping of modules by canonical filename along
> with by modulename, and refuse to add the same file twice.?(I'm not talking
> about executing a module inside a package, mind, since that can't shadow a
> stdlib module by accident anymore.)

The proposed behaviour for the top level direct execution is actually
mainly for consistency with the proposed behaviour for direct
execution inside a package.

Your "simple" solution wouldn't work though - several parts of
Python's own test suite would fall in a screaming heap if we did that
(we fiddle with modules a lot in order to exercise various fallback
behaviours, and that fiddling includes importing the same module more
than once with various other modules disabled)

To address the inadvertent shadowing in a more permanent, perhaps we
should aim towards someday making importing the current module via the
usual import syntax an ImportError (or at least an end-user visible
warning), with the advice to use "x = sys.modules[__name__]" instead
if you really intended to do it? Having __source_name__ available in
the main module would greatly simplify that approach.

>> Fixing direct execution inside packages
>> ---------------------------------------
>>
>> To fix this problem, it is proposed that an additional filesystem check be
>> performed before proceeding with direct execution of a ``PY_SOURCE`` or
>> ``PY_COMPILED`` file that has been named on the command line.
>
> This should only happen if the file is a valid import target.

True, things like "foo-test.py" can't be imported (Is that what you
meant by "valid import target"?). This would potentially apply to the
proposed top level change as well.

>> This additional check would look for an ``__init__`` file that is a peer
>> to
>> the specified file with a matching extension (either ``.py``, ``.pyc`` or
>> ``.pyo``, depending what was passed on the command line).
>
> I assume you mean for this to match the normal import rules for packages;
> why not just say that?

I was going back and forth as to whether we should accept an __init__
variant, or only one that matched the exact extension of the file
passed on the command line. On further reflection, just using normal
import semantics makes sense, so I'll revert to that.

> Also, should this consider situations other than the
> vanilla run/import-from-filesystem? Should meta-importers and such get a
> crack at solving this?

No, direct execution is all about vanilla import from the filesystem.
If people want to invoke those other mechanisms, that's what the "-m"
switch and zipfile and directory execution are for (since the latter
two are technically handled as "valid sys.path entry execution", so
the whole path_hooks machinery gets to have a look at them)

>> Fixing pickling without breaking introspection
>> ----------------------------------------------
>>
>> To fix this problem, it is proposed to add two optional module level
>> attributes: ``__source_name__`` and ``__pickle_name__``.
>>
>> When setting the ``__module__`` attribute on a function or class, the
>> interpreter will be updated to use ``__source_name__`` if defined, falling
>> back to ``__name__`` otherwise.
>>
>> ``__source_name__`` will automatically be set to the main module's "real"
>> name
>> (as described above under the fix to prevent duplicate imports of the main
>> module) by the interpreter. This will fix both pickling and introspection
>> for
>> the main module.
>>
>> It is also proposed that the pickling mechanism for classes and functions
>> be
>> updated to use an optional ``__pickle_module__`` attribute when deciding
>> how
>> to pickle these objects (falling back to the existing ``__module__``
>> attribute if the optional attribute is not defined). When a class or
>> function
>> is defined, this optional attribute will be defined if ``__pickle_name__``
>> is
>> defined at the module level, and left out otherwise. This will allow
>> pseudo-modules to fix pickling without breaking introspection.
>>
>> Other serialisation schemes could add support for this new attribute
>> relatively easily by replacing ``x.__module__`` with ``getattr(x,
>> "__pickle_module__", x.__module__)``.
>>
>> ``pydoc`` and ``inspect`` would also be updated to make appropriate use of
>> the new attributes for any cases not already covered by the above rules
>> for
>> setting ``__module__``.
>
> Is this cornercase really worth polluting the module namespace with more
> confusing __*__ names? It seems more sensible to me to simply make pickle
> refuse to operate on classes and functions defined in __main__. It wouldn't
> even be the least understandable restriction in pickle.

But why give up and fail, when the interpreter actually has the
information it needs to make the situation work?

>?The
> '__source_name__' attribute would read better as '__modulename__' (although
> I'm not convinced of its need for the other reasons, either.)

I deliberately avoided "__module_name__" (or variants thereof) because
it is utterly enlightening as to how it differs from "__name__".
Having "__package__", "__source_name__" and "__pickle_name__" to cover
the 3 use cases for __name__ that are broken by the "if __name__ ==
'__main__':" convention, as well as those that are broken by the
practice of using packages as "pseudo-modules" is definitely a little
messy, but would fix some known problems in standard library modules
(specifically multiprocessing, unittest and concurrent.futures).

__source_name__ could technically be reconstructed by hacking around
with __package__ and __file__, but it seems cleaner to just make the
information the interpreter already has available for use by programs.

It's another case where we lost the option of "simple" long ago, so
I'm proposing that we upgrade from the current complicated situation
to a complex one instead.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From orsenthil at gmail.com  Sat Mar  5 03:45:35 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Sat, 5 Mar 2011 10:45:35 +0800
Subject: [Python-Dev] Summer of Code: call for ideas and mentors
In-Reply-To: <4D7121DD.9040208@v.loewis.de>
References: <4D70A45A.5090609@v.loewis.de> <20110304133549.31ee15be@pitrou.net>
	<4D7121DD.9040208@v.loewis.de>
Message-ID: <20110305024535.GA2488@kevin>

On Fri, Mar 04, 2011 at 06:31:09PM +0100, "Martin v. L?wis" wrote:
> Likewise, if they want to contribute to some other project under the PSF
> umbrella, they can start talking to the respective developers on the
> respective channels.

We could have a landing page listed in the topic of IRC pointing out
things to do as they wait for official GSoC start.

That would be.

1. Join python-dev mailing list or their project's relevant mailing
list.
2. Hang around the #python-dev (or respective project's channel) and
ask 'technical' questions. Keep the administrative questions on hold.
3. Contribute to fixing bugs in the area which they have identified to
submit a proposal on.

This page could be set at #python and linked to python.org page too.

As GSoC is in it's 5th year, students have an idea of what to do
(there is plenty of information in the Internet) and they do all these
if they are interested.

-- 
Senthil

From rrr at ronadam.com  Sat Mar  5 05:40:09 2011
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 04 Mar 2011 22:40:09 -0600
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
Message-ID: <4D71BEA9.80103@ronadam.com>



On 03/04/2011 09:30 AM, Nick Coghlan wrote:

> Fixing dual imports of the main module
> --------------------------------------
>
> Two simple changes are proposed to fix this problem:
>
> 1. In ``runpy``, modify the implementation of the ``-m`` switch handling to
>    install the specified module in ``sys.modules`` under both its real name
>    and the name ``__main__``. (Currently it is only installed as the latter)
> 2. When directly executing a module, install it in ``sys.modules`` under
>    ``os.path.splitext(os.path.basename(__file__))[0]`` as well as under
>    ``__main__``.
>
> With the main module also stored under its "real" name, imports will pick it
> up from the ``sys.modules`` cache rather than reimporting it under a new name.


 > Fixing direct execution inside packages

+1 on both of these.

I don't see any major problems with these.  Any minor issues can be worked out.

I suggest separating these two items out into their own PEP, and doing them 
first.


Cheers,
    Ron



From ncoghlan at gmail.com  Sat Mar  5 06:28:38 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 15:28:38 +1000
Subject: [Python-Dev] Rietveld or Review Board use?
In-Reply-To: <19825.3539.996141.703453@montanaro.dyndns.org>
References: <19825.3539.996141.703453@montanaro.dyndns.org>
Message-ID: <AANLkTi=Mq45499Ess5=wQ0hUrw-JfasaJCKFZdTon_yE@mail.gmail.com>

On Sat, Mar 5, 2011 at 2:05 AM,  <skip at pobox.com> wrote:
> Is Rietveld or Review Board being used within the Python core development
> community? ?I looked at the dev guide but didn't see anything obvious about
> code reviews. ?I don't see how to search the Rietveld instance at
> codereview.appspot.com looking just for Python core review requests.

http://bugs.python.org/issue6626 is another one with a fairly
substantive linked review at http://codereview.appspot.com/107042.

The "review" links on that tracker item also show the initial attempt
at automatic integration with a locally hosted copy of Rietveld. I
believe the integration effort stalled because the "auto-review" setup
was leaking memory like a sieve and MvL wasn't able to figure out why
(it was something along those lines, anyway).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar  5 06:51:56 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 15:51:56 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D716202.4090000@g.nevcal.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<AANLkTi=dajHVy+J3y=D-5jAw72Gxs5k-JHLHVtU7mw6z@mail.gmail.com>
	<4D70E22B.8080006@voidspace.org.uk>
	<AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
	<4D716202.4090000@g.nevcal.com>
Message-ID: <AANLkTikogr9_TjHOCy=gG60XnqgJTSs_ZeMLGUaQswsp@mail.gmail.com>

On Sat, Mar 5, 2011 at 8:04 AM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> The really tricky part on Windows is handling file associations. I
> think we're just doomed on that front, unless we want to start
> supporting separate .py2 and .py3 extensions (and adding *that* in a
> maintenance release would be a far cry from just adding another
> symlink).
>
> Supporting .py2 and .py3 extensions is not much harder than adding a
> symlink.? Easier, on versions of windows without symlinks :)
>
> Sadly, Vista (I think) and 7 (for sure) restrict the? "assoc" and "ftype"
> commands with = signs, to being functional only in "Run as Administrator"
> shells, so on those versions, it is harder for the na?ve to do the
> reconfigurations themselves.
>
> The extra ftypes and assoc definitions can simply be copied from the
> existing ones, adding or changing a version number.? Would be much nicer if
> the installer did it for the na?ve Windows user.

That's not the tricky part I was talking about - if .py2 and .py3 work
as scripts, the question arises as to whether or not they should work
as modules as well. The precedent set by .pyw is that they would, but
that then runs headling into Martin's question of how to spell
combinations of "w" with "2" and "3".

> For Windows the status quo is pretty bad, so doing nothing is also pretty
> bad.? I agree the changes are "harder than an extra symlink" on Windows, but
> for someone that understand the installer, adding extra ftype and assoc is
> no harder, as it already knows how to install/replace that for .py files.

The key point for me is that the changes needed to significantly alter
the situation on Windows are far too invasive to be considered in a
maintenance release. A separate PEP proposing changes in this area for
Python 3.3 and later may be acceptable (especially if MvL is willing
to act as BDFOP*), but there really isn't a lot we can do for older
versions that is sufficiently low impact to justify breaking the "no
new features" rule.

Cheers,
Nick.

* Benevolent Dictator For One PEP, Guido's scheme where he delegates
the "accept or reject" decision for a given PEP to someone else.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar  5 07:00:13 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 16:00:13 +1000
Subject: [Python-Dev] Vagaries of "their" in English (was Re: Support the
 /usr/bin/python2 symlink upstream)
Message-ID: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>

On Sat, Mar 5, 2011 at 10:40 AM, Guido van Rossum <guido at python.org> wrote:
> That's how I felt 20 years ago. But since then I've come to appreciate
> they as a much better alternative to either "he or she" or "he". Just
> get used to it.

If anyone wants to further explore this question, the Stack Exchange
on English usage is a decent place to start:
http://english.stackexchange.com/questions/192/is-it-correct-to-use-their-instead-of-his-or-her

What it boils down to is that "their" is the least bad of all of the
available options.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From jackdied at gmail.com  Sat Mar  5 07:25:18 2011
From: jackdied at gmail.com (Jack Diederich)
Date: Sat, 5 Mar 2011 01:25:18 -0500
Subject: [Python-Dev] Vagaries of "their" in English (was Re: Support
 the /usr/bin/python2 symlink upstream)
In-Reply-To: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>
References: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>
Message-ID: <AANLkTimmG8LPFTmRQ0GPbGGdOMszgr_iwYe1xBzjco=V@mail.gmail.com>

On Sat, Mar 5, 2011 at 1:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, Mar 5, 2011 at 10:40 AM, Guido van Rossum <guido at python.org> wrote:
>> That's how I felt 20 years ago. But since then I've come to appreciate
>> they as a much better alternative to either "he or she" or "he". Just
>> get used to it.
>
> If anyone wants to further explore this question, the Stack Exchange
> on English usage is a decent place to start:
> http://english.stackexchange.com/questions/192/is-it-correct-to-use-their-instead-of-his-or-her
>
> What it boils down to is that "their" is the least bad of all of the
> available options.

No wonder that thread went to 100+ replies.

Can we cut English some slack here?  Unlike most other languages we
don't assign nouns, like rocks and sofas, a gender.  Personally I'd be
happier if everyone switched to using "she," instead of revolting
against the old default of using "he" by using the ear jarring "he or
she," or the dissonant "their."  For an amusing take on how a well
intentioned attempt to make the written law more pleasingly "correct"
see this post[1] (the ambiguous pronouns resulted in an ambiguous
statute).

English is highly mutable so I expect this will all shake out in a
generation or two.  Or maybe not - we still don't have a common word
that means a positive answer to a negative question despite centuries
of want.

-Jack

[1] http://volokh.com/2011/03/04/the-strange-glitch-in-the-rhode-island-rules-of-evidence/

From ncoghlan at gmail.com  Sat Mar  5 08:02:57 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 17:02:57 +1000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D718816.20304@skippinet.com.au>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
Message-ID: <AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>

On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammond <mhammond at 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.

I believe the only remaining decision to be made is whether we
actually change the "make install" command and the Mac OS X installers
for Python 2.7.2, or leave them alone and tell the distro folks to fix
it on their side of the fence. My own vote is a +1 for both, since
changing "make install" is fairly easy, and Ronald indicated earlier
in the thread that not only is the change to the Mac OS X installer
pretty trivial, but that Apple are likely to follow the lead of
whatever our default installer does.

Full PEP: http://www.python.org/dev/peps/pep-0394/
Diff to previous version:
http://svn.python.org/view/peps/trunk/pep-0394.txt?r1=88743&r2=88753

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar  5 08:14:07 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 5 Mar 2011 17:14:07 +1000
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <4D71BEA9.80103@ronadam.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<4D71BEA9.80103@ronadam.com>
Message-ID: <AANLkTinzrL=QQqzEBqAbjnfOFzpugkrUtdhyxi4UtNH2@mail.gmail.com>

On Sat, Mar 5, 2011 at 2:40 PM, Ron Adam <rrr at ronadam.com> wrote:
>> Fixing direct execution inside packages
>
> +1 on both of these.
>
> I don't see any major problems with these. ?Any minor issues can be worked
> out.
>
> I suggest separating these two items out into their own PEP, and doing them
> first.

This first draft includes everything I *want* to do. If I have to
scale the proposal back to get it accepted because I can't convince
enough other people it's a good idea... well, even Guido isn't immune
to that part of the PEP process (cf. PEP 340). It wouldn't be the
first PEP to have a "Rejected Ideas" section, and I'm sure it wouldn't
be the last.

I definitely intend to implement this in a few different pieces,
though - the order of the 4 different fixes in the PEP also summarises
what I consider to be a reasonable development strategy as well.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From rrr at ronadam.com  Sat Mar  5 05:40:09 2011
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 04 Mar 2011 22:40:09 -0600
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
Message-ID: <4D71BEA9.80103@ronadam.com>



On 03/04/2011 09:30 AM, Nick Coghlan wrote:

> Fixing dual imports of the main module
> --------------------------------------
>
> Two simple changes are proposed to fix this problem:
>
> 1. In ``runpy``, modify the implementation of the ``-m`` switch handling to
>    install the specified module in ``sys.modules`` under both its real name
>    and the name ``__main__``. (Currently it is only installed as the latter)
> 2. When directly executing a module, install it in ``sys.modules`` under
>    ``os.path.splitext(os.path.basename(__file__))[0]`` as well as under
>    ``__main__``.
>
> With the main module also stored under its "real" name, imports will pick it
> up from the ``sys.modules`` cache rather than reimporting it under a new name.


 > Fixing direct execution inside packages

+1 on both of these.

I don't see any major problems with these.  Any minor issues can be worked out.

I suggest separating these two items out into their own PEP, and doing them 
first.


Cheers,
    Ron


From martin at v.loewis.de  Sat Mar  5 08:59:17 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 05 Mar 2011 08:59:17 +0100
Subject: [Python-Dev] [Python-checkins] pymigr: The peps repo is the
 only other one that	seems relevant
In-Reply-To: <E1Pvfym-0001XY-US@dinsdale.python.org>
References: <E1Pvfym-0001XY-US@dinsdale.python.org>
Message-ID: <4D71ED55.8020609@v.loewis.de>

>   The peps repo is the only other one that seems relevant

Actually, the stackless people also requested that their repository
gets converted.

Regards,
Martin

From a.badger at gmail.com  Sat Mar  5 09:08:39 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 5 Mar 2011 00:08:39 -0800
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTim9-uAhY0xoBqZ=KCcO+v8c0hjYCJoOdv7BBuv2@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
	<20110304120743.22042ded@neurotica.wooz.org>
	<4D7122D1.30505@voidspace.org.uk>
	<AANLkTim9-uAhY0xoBqZ=KCcO+v8c0hjYCJoOdv7BBuv2@mail.gmail.com>
Message-ID: <20110305080839.GH3275@unaka.lan>

On Fri, Mar 04, 2011 at 12:56:16PM -0500, Fred Drake wrote:
> On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
> > That (below) is not distutils it is setuptools. distutils just uses
> > `scripts=[...]`, which annoyingly *doesn't* work with setuptools.
> 
> Right; distutils scripts are just sad.
> 
> OTOH, entry-point based scripts are something setuptools got very,
> very right.  Probably not perfect, but... I've not yet needed anything
> different in practice.
> 
Some of them can be annoying as hell when dealing with a system that also
installs multiple versions of a module.  But one could argue that's the
fault of setuptools' version handling rather than the entry-points
handling.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110305/6ab3da23/attachment.pgp>

From fdrake at acm.org  Sat Mar  5 13:49:06 2011
From: fdrake at acm.org (Fred Drake)
Date: Sat, 5 Mar 2011 07:49:06 -0500
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <20110305080839.GH3275@unaka.lan>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
	<20110304120743.22042ded@neurotica.wooz.org>
	<4D7122D1.30505@voidspace.org.uk>
	<AANLkTim9-uAhY0xoBqZ=KCcO+v8c0hjYCJoOdv7BBuv2@mail.gmail.com>
	<20110305080839.GH3275@unaka.lan>
Message-ID: <AANLkTinLPbGznz5BvSt6PmLsPSqipKgA7c1umDCAFkz5@mail.gmail.com>

On Sat, Mar 5, 2011 at 3:08 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> Some of them can be annoying as hell when dealing with a system that also
> installs multiple versions of a module. ?But one could argue that's the
> fault of setuptools' version handling rather than the entry-points
> handling.

Agreed; I don't use setuptools to manage versions of packages.  I've
found zc.buildout much nicer to work with, and entirely predictable
when applied properly.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein

From fuzzyman at voidspace.org.uk  Sat Mar  5 14:37:20 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 05 Mar 2011 13:37:20 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
Message-ID: <4D723C90.6090307@voidspace.org.uk>

On 05/03/2011 07:02, Nick Coghlan wrote:
> On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammond<mhammond at 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.

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.

I don't think it would be good (or necessary) to split this into a 
separate PEP. PyCon (sprints or language summit) would be a good place 
to talk about this.

> I believe the only remaining decision to be made is whether we
> actually change the "make install" command and the Mac OS X installers
> for Python 2.7.2, or leave them alone and tell the distro folks to fix
> it on their side of the fence. My own vote is a +1 for both, since
> changing "make install" is fairly easy, and Ronald indicated earlier
> in the thread that not only is the change to the Mac OS X installer
> pretty trivial, but that Apple are likely to follow the lead of
> whatever our default installer does.
>

Martin has also indicated that making appropriate changes to the Windows 
installer would not be difficult if we agree that changing the 2.7 
maintenance branch in this way is appropriate.

All the best,

Michael Foord
> Full PEP: http://www.python.org/dev/peps/pep-0394/
> Diff to previous version:
> http://svn.python.org/view/peps/trunk/pep-0394.txt?r1=88743&r2=88753
>
> Cheers,
> Nick.
>


-- 
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


From rdmurray at bitdance.com  Sat Mar  5 14:44:58 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 05 Mar 2011 08:44:58 -0500
Subject: [Python-Dev] .hgignore (was: Mercurial conversion repositories)
In-Reply-To: <AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<4D67E9A5.5030203@cadifra.com>
	<20110225144315.3eebcafc@limelight.wooz.org>
	<4D684E2A.90005@netwok.org>
	<20110226154939.41972d08@limelight.wooz.org>
	<ikduo2$qm2$1@dough.gmane.org>
	<20110228100826.6812ad30@limelight.wooz.org>
	<20110228161538.36b825ac@pitrou.net>
	<20110228160748.1be8b814@limelight.wooz.org>
	<20110228221034.53ebe810@pitrou.net>
	<AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
Message-ID: <20110305134458.1FE0D249088@kimball.webabinitio.net>

On Fri, 04 Mar 2011 13:01:02 -0800, Santoso Wijaya <santoso.wijaya at gmail.com> wrote:
> As a mercurial user, I thank you for this effort! One question, where/how do
> I send suggestion to what to add into .hgignore file? In particular, I found
> these dynamically generated files after a build in Windows (3.2) that
> probably should be entered as .hgignore entries:
> 
> ? PC/python_nt_d.h
> ? PC/pythonnt_rc_d.h

I, on the other hand, would like to see .rej and .orig removed from
the ignore list.  I don't like having these polluting my working
directory, and 'hg status' is the easiest way to find them (if
they aren't ignored).

Or if there's some way to configure my personal .hgrc to ignore
those particular ignore lines, that would be fine too :)

--
R. David Murray                                      www.bitdance.com

From timothy.c.delaney at gmail.com  Sat Mar  5 14:54:39 2011
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Sun, 6 Mar 2011 00:54:39 +1100
Subject: [Python-Dev] .hgignore (was: Mercurial conversion repositories)
In-Reply-To: <20110305134458.1FE0D249088@kimball.webabinitio.net>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<4D67E9A5.5030203@cadifra.com>
	<20110225144315.3eebcafc@limelight.wooz.org>
	<4D684E2A.90005@netwok.org>
	<20110226154939.41972d08@limelight.wooz.org>
	<ikduo2$qm2$1@dough.gmane.org>
	<20110228100826.6812ad30@limelight.wooz.org>
	<20110228161538.36b825ac@pitrou.net>
	<20110228160748.1be8b814@limelight.wooz.org>
	<20110228221034.53ebe810@pitrou.net>
	<AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
	<20110305134458.1FE0D249088@kimball.webabinitio.net>
Message-ID: <AANLkTikpw+Uv0KsZH-pBjVV2eYV5yJBN=tP5pPy+BeAa@mail.gmail.com>

On 6 March 2011 00:44, R. David Murray <rdmurray at bitdance.com> wrote:

> On Fri, 04 Mar 2011 13:01:02 -0800, Santoso Wijaya <
> santoso.wijaya at gmail.com> wrote:
> > As a mercurial user, I thank you for this effort! One question, where/how
> do
> > I send suggestion to what to add into .hgignore file? In particular, I
> found
> > these dynamically generated files after a build in Windows (3.2) that
> > probably should be entered as .hgignore entries:
> >
> > ? PC/python_nt_d.h
> > ? PC/pythonnt_rc_d.h
>
> I, on the other hand, would like to see .rej and .orig removed from
> the ignore list.  I don't like having these polluting my working
> directory, and 'hg status' is the easiest way to find them (if
> they aren't ignored).
>
> Or if there's some way to configure my personal .hgrc to ignore
> those particular ignore lines, that would be fine too :)


If those were to be removed from .hgignore then there would be a high
likelihood of someone doing "hg addremove" and inadvertently tracking them.
The purpose of .hgignore is to prevent inadventently tracking files that
shouldn't be tracked.

"hg status  -i" will list all ignored files that are present in your working
directory. For other options, "hg help status".

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/419c69ef/attachment.html>

From ncoghlan at gmail.com  Sat Mar  5 15:22:20 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Mar 2011 00:22:20 +1000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D723C90.6090307@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk>
Message-ID: <AANLkTimNwernMgXcAWkevd0JG0KLtDdVVWpD1mWTt77T@mail.gmail.com>

On Sat, Mar 5, 2011 at 11:37 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> I don't think it would be good (or necessary) to split this into a separate
> PEP. PyCon (sprints or language summit) would be a good place to talk about
> this.

Sure. With a PEP to record decisions this time, we shouldn't get a
repeat of the last naming discussion where

>> I believe the only remaining decision to be made is whether we
>> actually change the "make install" command and the Mac OS X installers
>> for Python 2.7.2, or leave them alone and tell the distro folks to fix
>> it on their side of the fence. My own vote is a +1 for both, since
>> changing "make install" is fairly easy, and Ronald indicated earlier
>> in the thread that not only is the change to the Mac OS X installer
>> pretty trivial, but that Apple are likely to follow the lead of
>> whatever our default installer does.
>>
>
> Martin has also indicated that making appropriate changes to the Windows
> installer would not be difficult if we agree that changing the 2.7
> maintenance branch in this way is appropriate.

True, it's only the more exotic ideas (like trying to do something
about the PYTHON* variables or file associations) that become an
issue. Simply supporting having a python3 version and a python2
version on PATH at the same time could work by duplicating the main
executables (using "python2w" and "python3w" for the non-console
variants), with the sysadmin effectively choosing the preferred
version of the installed versions based on the directory order in
PATH.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar  5 15:23:28 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Mar 2011 00:23:28 +1000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTimNwernMgXcAWkevd0JG0KLtDdVVWpD1mWTt77T@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk>
	<AANLkTimNwernMgXcAWkevd0JG0KLtDdVVWpD1mWTt77T@mail.gmail.com>
Message-ID: <AANLkTi=Z0m4r0+rfA_csYAkpnu8HOJLU1pStGf9hP4k-@mail.gmail.com>

On Sun, Mar 6, 2011 at 12:22 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, Mar 5, 2011 at 11:37 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>> I don't think it would be good (or necessary) to split this into a separate
>> PEP. PyCon (sprints or language summit) would be a good place to talk about
>> this.
>
> Sure. With a PEP to record decisions this time, we shouldn't get a
> repeat of the last naming discussion where

... people forgot precisely which decisions were made and their rationale.

Oops :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From fuzzyman at voidspace.org.uk  Sat Mar  5 15:27:54 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 05 Mar 2011 14:27:54 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTimNwernMgXcAWkevd0JG0KLtDdVVWpD1mWTt77T@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>
	<AANLkTimNwernMgXcAWkevd0JG0KLtDdVVWpD1mWTt77T@mail.gmail.com>
Message-ID: <4D72486A.4010201@voidspace.org.uk>

On 05/03/2011 14:22, Nick Coghlan wrote:
> [snip...]
>> Martin has also indicated that making appropriate changes to the Windows
>> installer would not be difficult if we agree that changing the 2.7
>> maintenance branch in this way is appropriate.
> True, it's only the more exotic ideas (like trying to do something
> about the PYTHON* variables or file associations) that become an
> issue.

Right. But those are issues *anyway* and are orthogonal to this 
particular one. (And in the case of PYTHON* environment variables not 
restricted to windows and not addressed by this PEP for any platform.)


> Simply supporting having a python3 version and a python2
> version on PATH at the same time could work by duplicating the main
> executables (using "python2w" and "python3w" for the non-console
> variants), with the sysadmin effectively choosing the preferred
> version of the installed versions based on the directory order in
> PATH.
Yes. I would also like to see python27.exe and python32.exe (etc) but 
that may be a step too far (although Martin was open to it we'll have to 
see what final agreement we come to).

All the best,

Michael
> Cheers,
> Nick.
>


-- 
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


From fuzzyman at voidspace.org.uk  Sat Mar  5 16:05:49 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 05 Mar 2011 15:05:49 +0000
Subject: [Python-Dev] [PEPs] Support the
	/usr/bin/python2	symlink	upstream
In-Reply-To: <4D718816.20304@skippinet.com.au>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>
Message-ID: <4D72514D.5060908@voidspace.org.uk>

On 05/03/2011 00:47, Mark Hammond wrote:
> On 5/03/2011 8:21 AM, "Martin v. L?wis" wrote:
> ...
>> As for Windows support: we currently don't install a python3.exe binary,
>> let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
>> adjust the installer if the PEP asks me to. For the reasons discussed,
>> I'm -0 on the change (i.e. double-clicking .py will continue to launch
>> the most-recently installed Python, rather than the "right" one, and
>> setting PYTHONPATH will continue to break installations).
>
> I agree with the -0 - I simply don't think it will, in practice, make 
> anyone's life much easier.  To run python2 and python3 based scripts 
> in the same environment already requires some manual work by the 
> machine owner (both directories will need to be added to the path) so 
> the additional burden of some other steps (eg, .bat files, doskey 
> alaises etc) doesn't seem that great.  There is also a small risk of 
> confusion - people may believe python.exe and python2.exe/python3.exe 
> have different purposes and be confused about when to use which.
>

In order to follow the most basic of Python tutorials new users do have 
to manually add their Python install to the PATH. This is unfortunate 
and should be addressed as a separate issue.

I don't see this as a good reason for not taking additional steps to 
support multiple versions side-by-side on Windows.

Having python2.x / python3.x binaries isn't as confusing for users on 
other platforms I don't see why it should be on Windows.

If we add "versioned binaries" then users manually adding their Python 
install to the PATH see a benefit; they can specify the version of 
Python without additional work on their part. If we later add support 
for automatically adding Python installs to the PATH (optionally - 
preferably on by default) then all users who use the command line see a 
benefit.

All the best,

Michael Foord



> 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" :)
>
> Cheers,
>
> Mark
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From fuzzyman at voidspace.org.uk  Sat Mar  5 16:09:02 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 05 Mar 2011 15:09:02 +0000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D715B2F.7070501@v.loewis.de>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>	<AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>
	<4D712B05.2020607@voidspace.org.uk> <4D715B2F.7070501@v.loewis.de>
Message-ID: <4D72520E.1070906@voidspace.org.uk>

On 04/03/2011 21:35, "Martin v. L?wis" wrote:
>> I don't think duplicating python.exe as python2.exe or python3.exe would
>> be very much work at all, if we decide it is a good thing. Sure it
>> doesn't resolve all the myriad problems of Python on Windows but I don't
>> think that is a good reason not to consider it. Up to Martin on this one
>> though and again depends if we just make recommendations or actually
>> change Python 2.7.
> Changing the installer should be easy - there is a DuplicateFile table
> in MSI (*) for this kind of installation task.
>
> I'd still like the PEP to tell me whether it's python3w.exe or
> pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
> me).
python3w.exe

> It would also be good if the PEP took a position on providing
> pythonXY.exe binaries on Windows (with the related question of
> whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe)
>

I would really like to see this. We do it on other platforms, it is 
useful there, it would be useful on Windows for the same reasons.

All the best,

Michael Foord

> Regards,
> Martin
>
> (*) http://msdn.microsoft.com/en-us/library/aa368335(v=vs.85).aspx


-- 
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


From skip at pobox.com  Sat Mar  5 17:14:54 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 5 Mar 2011 10:14:54 -0600
Subject: [Python-Dev] hg pull failed
Message-ID: <19826.24958.821162.983186@montanaro.dyndns.org>

Yesterday I cloned the hg cpython repository and made several local copies
for various maintenance releases.  This morning I tried to hg pull my
cpython repo to get any changes (not really expecting any), but got this
output:

    % hg pull
    pulling from http://hg.python.org/cpython
    searching for changes
    abort: repository is unrelated

What did I do wrong?

Thx,

Skip

From rdmurray at bitdance.com  Sat Mar  5 17:24:46 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 05 Mar 2011 11:24:46 -0500
Subject: [Python-Dev] .hgignore (was: Mercurial conversion repositories)
In-Reply-To: <AANLkTikpw+Uv0KsZH-pBjVV2eYV5yJBN=tP5pPy+BeAa@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<4D67E9A5.5030203@cadifra.com>
	<20110225144315.3eebcafc@limelight.wooz.org>
	<4D684E2A.90005@netwok.org>
	<20110226154939.41972d08@limelight.wooz.org>
	<ikduo2$qm2$1@dough.gmane.org>
	<20110228100826.6812ad30@limelight.wooz.org>
	<20110228161538.36b825ac@pitrou.net>
	<20110228160748.1be8b814@limelight.wooz.org>
	<20110228221034.53ebe810@pitrou.net>
	<AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
	<20110305134458.1FE0D249088@kimball.webabinitio.net>
	<AANLkTikpw+Uv0KsZH-pBjVV2eYV5yJBN=tP5pPy+BeAa@mail.gmail.com>
Message-ID: <20110305162446.D5C46249FB1@kimball.webabinitio.net>

On Sun, 06 Mar 2011 00:54:39 +1100, Tim Delaney <timothy.c.delaney at gmail.com> wrote:
> If those were to be removed from .hgignore then there would be a high
> likelihood of someone doing "hg addremove" and inadvertently tracking them.
> The purpose of .hgignore is to prevent inadventently tracking files that
> shouldn't be tracked.

Ah, well, I don't like that UI.  The purpose for me of .hgignore (and
similar ignore files) is to make the status command show any files that
have been modified or aren't normal build/run products.  I'd rather add
and remove files individually by hand (except when adding or removing
a directory).  I also want a --strict option for the commit command
that refuses to commit if there are unignored unadded or missing files.
(--strict is the bzr spelling; I don't care about the spelling :)

> "hg status  -i" will list all ignored files that are present in your working
> directory. For other options, "hg help status".

hg status -i is useless because there are a *lot* of ignored files in
a working directory where python has been built.  I'd have to do a
distclean first, which would mean I'd have to do a rebuild after...and
all of that just takes too long :)

I guess I have some hg hacking in my future, unless someone has already
written extensions for this stuff.

--
R. David Murray                                      www.bitdance.com

From g.brandl at gmx.net  Sat Mar  5 17:24:09 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 05 Mar 2011 17:24:09 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <19826.24958.821162.983186@montanaro.dyndns.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
Message-ID: <ikto58$dbt$1@dough.gmane.org>

On 05.03.2011 17:14, skip at pobox.com wrote:
> Yesterday I cloned the hg cpython repository and made several local copies
> for various maintenance releases.  This morning I tried to hg pull my
> cpython repo to get any changes (not really expecting any), but got this
> output:
> 
>     % hg pull
>     pulling from http://hg.python.org/cpython
>     searching for changes
>     abort: repository is unrelated
> 
> What did I do wrong?

Yesterday's repository was still the test repository, now it's the real one.
You'll need to clone again.

Georg


From g.brandl at gmx.net  Sat Mar  5 17:26:53 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 05 Mar 2011 17:26:53 +0100
Subject: [Python-Dev] rXXX links in the bug tracker after the migration
	to Mercurial
In-Reply-To: <20110304225639.068cc9b4@pitrou.net>
References: <1299243568.21701.23.camel@marge> <ikr6tu$n6b$1@dough.gmane.org>
	<4D71226B.7000800@v.loewis.de> <ikr9pd$66t$1@dough.gmane.org>
	<4D715D74.1060403@v.loewis.de> <20110304225639.068cc9b4@pitrou.net>
Message-ID: <iktoac$dbt$2@dough.gmane.org>

On 04.03.2011 22:56, Antoine Pitrou wrote:
> On Fri, 04 Mar 2011 22:45:24 +0100
> "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> > It's not really needed; but since it works with 6+ hex digits there might
>> > be false positives.
>> 
>> I searched the messages, and it turns out that primarily long numbers
>> would give false positives:
>> 
>>  Python 1.6a2 (#7, Apr 24 2000, 23:02:54)  [GCC pgcc-2.91.66 19990314
>>  minidom (as the proposed documentation in patch 101821 explains) does
>>  Closed as Duplicate; see bug 435026 for details.  It's an
>>  the test is extended to 2000000 objects on my machine
>>  IRIX rattler 6.5 10120734 IP32
>>  hash("DNSSEC") == 8704052292078464
>>  [New Thread 2305843009213881680 (LWP 23166)]
>> 
>> So I guess mandating square brackets is reasonable - alternatively,
>> mandating a fixed length could have worked as well, I guess.
> 
> The two forms used in hg's output are 10-digit and 40-digit ids
> (the latter only with --debug, IIUC). The only reason to use another
> form (especially shorter) is if you type the changeset id by hand
> rather than paste it, which must not be very common.
> 
> And if there are false positives from time to time, well they'll just
> link to 404s (unknown ids). I don't think that's an important issue.

OK, I changed the code to only allow 12 (not 10) or 40 hex digits, but
without parentheses.

Georg



From stutzbach at google.com  Sat Mar  5 17:36:04 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sat, 5 Mar 2011 08:36:04 -0800
Subject: [Python-Dev] .hgignore (was: Mercurial conversion repositories)
In-Reply-To: <AANLkTikpw+Uv0KsZH-pBjVV2eYV5yJBN=tP5pPy+BeAa@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<4D67E9A5.5030203@cadifra.com>
	<20110225144315.3eebcafc@limelight.wooz.org>
	<4D684E2A.90005@netwok.org>
	<20110226154939.41972d08@limelight.wooz.org>
	<ikduo2$qm2$1@dough.gmane.org>
	<20110228100826.6812ad30@limelight.wooz.org>
	<20110228161538.36b825ac@pitrou.net>
	<20110228160748.1be8b814@limelight.wooz.org>
	<20110228221034.53ebe810@pitrou.net>
	<AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
	<20110305134458.1FE0D249088@kimball.webabinitio.net>
	<AANLkTikpw+Uv0KsZH-pBjVV2eYV5yJBN=tP5pPy+BeAa@mail.gmail.com>
Message-ID: <AANLkTin-qYUJs7au9ubPXXbh7UNddVZpPjyLqWE7H4Qf@mail.gmail.com>

On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney <timothy.c.delaney at gmail.com>wrote:

> If those were to be removed from .hgignore then there would be a high
> likelihood of someone doing "hg addremove" and inadvertently tracking them.
> The purpose of .hgignore is to prevent inadventently tracking files that
> shouldn't be tracked.
>

If the goal is to prevent something from being committed, shouldn't the
check go in a pre-commit hook instead?

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110305/c9f3cfe8/attachment.html>

From solipsis at pitrou.net  Sat Mar  5 17:44:04 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 5 Mar 2011 17:44:04 +0100
Subject: [Python-Dev] .hgignore (was: Mercurial conversion repositories)
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<4D67E9A5.5030203@cadifra.com>
	<20110225144315.3eebcafc@limelight.wooz.org>
	<4D684E2A.90005@netwok.org>
	<20110226154939.41972d08@limelight.wooz.org>
	<ikduo2$qm2$1@dough.gmane.org>
	<20110228100826.6812ad30@limelight.wooz.org>
	<20110228161538.36b825ac@pitrou.net>
	<20110228160748.1be8b814@limelight.wooz.org>
	<20110228221034.53ebe810@pitrou.net>
	<AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
	<20110305134458.1FE0D249088@kimball.webabinitio.net>
	<AANLkTikpw+Uv0KsZH-pBjVV2eYV5yJBN=tP5pPy+BeAa@mail.gmail.com>
	<AANLkTin-qYUJs7au9ubPXXbh7UNddVZpPjyLqWE7H4Qf@mail.gmail.com>
Message-ID: <20110305174404.68ad6598@pitrou.net>

On Sat, 5 Mar 2011 08:36:04 -0800
Daniel Stutzbach <stutzbach at google.com> wrote:

> On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney <timothy.c.delaney at gmail.com>wrote:
> 
> > If those were to be removed from .hgignore then there would be a high
> > likelihood of someone doing "hg addremove" and inadvertently tracking them.
> > The purpose of .hgignore is to prevent inadventently tracking files that
> > shouldn't be tracked.
> >
> 
> If the goal is to prevent something from being committed, shouldn't the
> check go in a pre-commit hook instead?

Well, it's more user-friendly to help "hg addremove" work as expected,
rather than add hooks down the line to forbid pushing any mistakes.

Regards

Antoine.



From g.brandl at gmx.net  Sat Mar  5 18:39:52 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 05 Mar 2011 18:39:52 +0100
Subject: [Python-Dev] CPython hg transition complete
Message-ID: <iktsh9$1fl$1@dough.gmane.org>

I'm very happy to announce that the core Python repository switch
to Mercurial is complete and the new repository at
http://hg.python.org/cpython/ is now officially open for cloning,
and for commits by those who had commit access to SVN.

The developers' guide at http://docs.python.org/devguide/ has
been updated to talk about Mercurial and should be enough to
get anyone started with a clone.

We'll work on extracting active feature branches into separate
clones next; please let us know which branches these are (we
already know of py3k-cdecimal, pep-3151 and pep-382).

To make new feature "branches" (ie. clones) that are to be
available at hg.python.org, best use the "server side clone"
feature that is available at http://hg.python.org/cpython/
in order to create the new repository.

To look up SVN revisions, use hg.python.org/lookup/rXXXXX.
The tracker has also been updated to link to hg.python.org
for files and revisions.  For the future, it will recognize
hg changeset hashes as well (without brackets, see the recent
thread).

The buildbots should also now be building from the hg repositories.

Please let me know if you notice any disruptions, or anything
else that needs fixing, or any other question.  Also please
redirect praise to Antoine Pitrou and Dirkjan Ochtman who did
most of the actual work.

Georg


From p.f.moore at gmail.com  Sat Mar  5 18:44:55 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 5 Mar 2011 17:44:55 +0000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D72520E.1070906@voidspace.org.uk>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
	<AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>
	<4D712B05.2020607@voidspace.org.uk> <4D715B2F.7070501@v.loewis.de>
	<4D72520E.1070906@voidspace.org.uk>
Message-ID: <AANLkTikNOzkLJRJBFJomGy3rDa5YwCkHQ+DmHyJO_BYx@mail.gmail.com>

On 5 March 2011 15:09, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 04/03/2011 21:35, "Martin v. L?wis" wrote:
>> It would also be good if the PEP took a position on providing
>> pythonXY.exe binaries on Windows (with the related question of
>> whether it's python32w.exe, python3.2w.exe, pythonw32.exe or
>> pythonw3.2.exe)
>>
>
> I would really like to see this. We do it on other platforms, it is useful
> there, it would be useful on Windows for the same reasons.

+1. And I'm OK with python3w and python32w as a colour for the bikeshed...

Paul.

From techtonik at gmail.com  Sat Mar  5 19:07:20 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 5 Mar 2011 20:07:20 +0200
Subject: [Python-Dev] rXXX links in the bug tracker after the migration
	to Mercurial
In-Reply-To: <20110304225639.068cc9b4@pitrou.net>
References: <1299243568.21701.23.camel@marge> <ikr6tu$n6b$1@dough.gmane.org>
	<4D71226B.7000800@v.loewis.de> <ikr9pd$66t$1@dough.gmane.org>
	<4D715D74.1060403@v.loewis.de> <20110304225639.068cc9b4@pitrou.net>
Message-ID: <AANLkTi=g2sbSvUx+3TvmcaUiF9O_OAQ5R1WhM=dJeu9F@mail.gmail.com>

On Fri, Mar 4, 2011 at 11:56 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Fri, 04 Mar 2011 22:45:24 +0100
> "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> > It's not really needed; but since it works with 6+ hex digits there might
>> > be false positives.
>>
>> I searched the messages, and it turns out that primarily long numbers
>> would give false positives:
>>
>> ?Python 1.6a2 (#7, Apr 24 2000, 23:02:54) ?[GCC pgcc-2.91.66 19990314
>> ?minidom (as the proposed documentation in patch 101821 explains) does
>> ?Closed as Duplicate; see bug 435026 for details. ?It's an
>> ?the test is extended to 2000000 objects on my machine
>> ?IRIX rattler 6.5 10120734 IP32
>> ?hash("DNSSEC") == 8704052292078464
>> ?[New Thread 2305843009213881680 (LWP 23166)]
>>
>> So I guess mandating square brackets is reasonable - alternatively,
>> mandating a fixed length could have worked as well, I guess.
>
> The two forms used in hg's output are 10-digit and 40-digit ids
> (the latter only with --debug, IIUC). The only reason to use another
> form (especially shorter) is if you type the changeset id by hand
> rather than paste it, which must not be very common.

To me this sounds like "it is common, but this practice should be
abandoned at all costs", which is not too user friendly. =) Both
10-digit ids and 40-digits ids can be autolinked provided that they
have at least one hexadecimal letter. The probability of getting all
digits in 10-digit sequence is less than 1%. But for manual typing I'd
still prefer to have square bracket type of links.

--
anatoly t.

From rrr at ronadam.com  Sat Mar  5 19:11:14 2011
From: rrr at ronadam.com (Ron Adam)
Date: Sat, 05 Mar 2011 12:11:14 -0600
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTinzrL=QQqzEBqAbjnfOFzpugkrUtdhyxi4UtNH2@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>	<4D71BEA9.80103@ronadam.com>
	<AANLkTinzrL=QQqzEBqAbjnfOFzpugkrUtdhyxi4UtNH2@mail.gmail.com>
Message-ID: <4D727CC2.9000104@ronadam.com>



On 03/05/2011 01:14 AM, Nick Coghlan wrote:
> On Sat, Mar 5, 2011 at 2:40 PM, Ron Adam<rrr at ronadam.com>  wrote:
>>> Fixing direct execution inside packages
>>
>> +1 on both of these.
>>
>> I don't see any major problems with these.  Any minor issues can be worked
>> out.
>>
>> I suggest separating these two items out into their own PEP, and doing them
>> first.
>
> This first draft includes everything I *want* to do. If I have to
> scale the proposal back to get it accepted because I can't convince
> enough other people it's a good idea... well, even Guido isn't immune
> to that part of the PEP process (cf. PEP 340). It wouldn't be the
> first PEP to have a "Rejected Ideas" section, and I'm sure it wouldn't
> be the last.

Right, All of the reasons are good and some solution should be implemented 
for each of the issues you pointed out. The PEP process will help us figure 
out the best way to do that.


> I definitely intend to implement this in a few different pieces,
> though - the order of the 4 different fixes in the PEP also summarises
> what I consider to be a reasonable development strategy as well.

Sounds good.

I haven't formed a good opinion on the last 2 items yet which was why I 
didn't comment on them.




This morning I did have some interesting thoughts.*

*It seems I'm starting to wake up with python code in my head.  (Is that 
good?)  In some cases, it's outside of the box solutions, but not always 
good ones. <shrug> ;-)


Anyway... this mornings fuzzy python thoughts were along the lines of...


On one hand, Python tries to make it so each objects source/parent info  is 
reachable from the object when possible.  The nice thing about that is, it 
can be used to create a tree of where everything is.  That doesn't work 
*easily* at the module level due to modules being external OS entities that 
can be reused in different contexts.

On the other hand, a modules import order is somewhat more dynamic compared 
to class inheritance order, so would it be better to have that info in a 
separate place rather than with each module?


Adding a second references to the '__main__' module begins to blur the 
purpose of sys.modules from being a place to keep imported modules to a 
place that also has some ordering information.  (Practicality over purity?, 
Or an indication of what direction to go in?)

And, if you ask for keys, items, or values, you will need to filter out 
'__main__' to avoid the double reference.


So I was thinking, what if we make sys.modules a little smarter.  The 
negative of that is, it would no longer be a simple dictionary object.


First idea ...

Add a __main__ attribute to sys.modules to hold the name of the main module.

Override modules.__setitem__, so it will catch '__main__' and set 
modules.__main__ to the name of the module, and put the module in under its 
real name instead of '__main__'.

Override modules.__getitem__, so it will catch '__main__' and return 
self[self.__main__].

Then keys(), values(), and items(), will not have the doubled main module 
references in them.

The name of the main module is easy to get.  ie... sys.modules.__main__

sys.modules[__name__] will still return the correct module if __name__ == 
"__main__".



Second (more ambitious and less thought out) idea ...

Extend sys.modules so it is actually is a tree structure. The '__main__' 
module would be at the top of the tree.


Cheers,
    Ron


From fuzzyman at voidspace.org.uk  Sat Mar  5 19:14:49 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 05 Mar 2011 18:14:49 +0000
Subject: [Python-Dev] contributors survey?
In-Reply-To: <20110302160504.146D8241727@kimball.webabinitio.net>
References: <1299014648.3709.16.camel@localhost.localdomain>	<1299036300.3153.1.camel@localhost.localdomain>	<20110302130805.3ca921fc@pitrou.net>	<AANLkTinmN_1JbG0XsqH_a=EvUSbiQS3crarHCdHqD-8i@mail.gmail.com>	<20110302133957.22d36065@pitrou.net>	<AANLkTikh9ETJUFAEfA46AsL7KpuDY+Z4AH2=CjS2i6GE@mail.gmail.com>	<AANLkTi=GBbci+vbPiWxpfyJbQqMdkrDgH-seX9s52yHX@mail.gmail.com>
	<20110302160504.146D8241727@kimball.webabinitio.net>
Message-ID: <4D727D99.8080303@voidspace.org.uk>

On 02/03/2011 16:05, R. David Murray wrote:
> On Wed, 02 Mar 2011 13:10:04 +0000, Mark Smith<mark.smith at practicalpoetry.co.uk>  wrote:
>> The following is going to sound bitter...
>>
>> I was fired with enthusiasm for working on Python after the sprints at
>> EuroPython last year. I submitted 3 (I think) patches for pulldom - a test
>> suite (it has 0% code coverage at present), documentation for the module
>> (there isn't any at present), and a patch deprecating a function that is
>> broken. They're all still open, and the patches are getting staler by the
>> month.
>>
>> The point of this level of detail is: I was new to the project; I submitted
>> some relatively uncomplicated patches that trivially, visibly, and (mostly)
>> uncontroversially improve Python - one of them was a /documentation/ patch.
>> Then nothing happened, apart from the odd comment from people who commented
>> on the tickets - and I responded to their queries. So now I'm of the opinion
>> that it's not worth submitting patches to the Python project at all, because
>> they'll never be accepted. I'll dedicate my time to something else instead.
>>
>> Mercurial /will/ make it easier to contribute code, but if it doesn't get
>> accepted into a release branch, then that makes no real difference to me.
>>
>> Seriously guys - fix the issue lifecycle; I'll come back.
This is really valuable feedback. Thanks Mark.

> After running a core sprint at PyOhio I realized that one thing that is
> *seriously* needed is more followup after a sprint (and probably after
> bug days as well).  I didn't gather the information at the sprint that
> I would have needed to do that followup (who exactly did submit patches
> during the sprint and which patches?).
>
> I'd like to suggest that we collect such information one way or another
> for the PyCon sprint, and pay special attention to those patches in the
> weeks following PyCon.

Yes. There is little point in putting effort (and money) into finding 
new contributors if we can't retain them and don't make use of the work 
they do.

Mark - if the patches you provided are still outstanding can you let us 
know what the issue numbers are?

All the best,

Michael Foord

> The other issue with the pulldom patches, Mark, is that unfortunately
> you fell into one of the black holes:  I don't think there are any active
> committers who know much, if anything, about pulldom.
>
> As with everything else, it comes down to lack of people hours.  People pay
> attention to what interests them, and some attention to other stuff,
> and there aren't enough people for that "some attention to other stuff"
> to cover all the patches that are submitted.
>
> There are probably ways to improve patch lifecycle management, but I don't
> think there is any *fix* other than more people.  So, doing followup after
> sprints/bug days to help keep contributor enthusiasm going and get some of
> them converted into committers is perhaps the best "fix" we could apply.
> Of course, doing that followup requires people-time.......
>
> --
> R. David Murray                                      www.bitdance.com
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From fuzzyman at voidspace.org.uk  Sat Mar  5 19:26:29 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 05 Mar 2011 18:26:29 +0000
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <4D6C1ACF.3030503@v.loewis.de>
References: <loom.20110225T190113-46@post.gmane.org>	<4D67F959.8080701@voidspace.org.uk>	<20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain>
	<4D68FD31.70901@voidspace.org.uk> <4D6C1ACF.3030503@v.loewis.de>
Message-ID: <4D728055.1060201@voidspace.org.uk>

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. If Jean-Paul is willing / able to help and is around for the 
pycon sprints then it would be a good opportunity.

All the best,

Michael Foord

> 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


From tjreedy at udel.edu  Sat Mar  5 19:52:39 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 05 Mar 2011 13:52:39 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTikNOzkLJRJBFJomGy3rDa5YwCkHQ+DmHyJO_BYx@mail.gmail.com>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>	<AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>	<4D712B05.2020607@voidspace.org.uk>
	<4D715B2F.7070501@v.loewis.de>	<4D72520E.1070906@voidspace.org.uk>
	<AANLkTikNOzkLJRJBFJomGy3rDa5YwCkHQ+DmHyJO_BYx@mail.gmail.com>
Message-ID: <iku0pk$n8p$1@dough.gmane.org>

On 3/5/2011 12:44 PM, Paul Moore wrote:
> On 5 March 2011 15:09, Michael Foord<fuzzyman at voidspace.org.uk>  wrote:
>> On 04/03/2011 21:35, "Martin v. L?wis" wrote:
>>> It would also be good if the PEP took a position on providing
>>> pythonXY.exe binaries on Windows (with the related question of
>>> whether it's python32w.exe, python3.2w.exe, pythonw32.exe or
>>> pythonw3.2.exe)
>>>
>>
>> I would really like to see this. We do it on other platforms, it is useful
>> there, it would be useful on Windows for the same reasons.
>
> +1. And I'm OK with python3w and python32w as a colour for the bikeshed...

Except for the the spelling of color ;-)
I agree. Let 'w' always be the last suffix.

With that settled, there is the issue of Start menu shortcuts. I thought 
we had agreed to put version specific labels on them so we would not 
have, for instance, identical 'IDLE (Python GUI)' items in the 
frequently used list. I guess that got lost without a PEP to put it on. 
Now there is?

-- 
Terry Jan Reedy



From fuzzyman at voidspace.org.uk  Sat Mar  5 19:59:11 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 05 Mar 2011 18:59:11 +0000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <iku0pk$n8p$1@dough.gmane.org>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>	<AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>	<4D712B05.2020607@voidspace.org.uk>	<4D715B2F.7070501@v.loewis.de>	<4D72520E.1070906@voidspace.org.uk>	<AANLkTikNOzkLJRJBFJomGy3rDa5YwCkHQ+DmHyJO_BYx@mail.gmail.com>
	<iku0pk$n8p$1@dough.gmane.org>
Message-ID: <4D7287FF.8080503@voidspace.org.uk>

On 05/03/2011 18:52, Terry Reedy wrote:
> On 3/5/2011 12:44 PM, Paul Moore wrote:
>> On 5 March 2011 15:09, Michael Foord<fuzzyman at voidspace.org.uk>  wrote:
>>> On 04/03/2011 21:35, "Martin v. L?wis" wrote:
>>>> It would also be good if the PEP took a position on providing
>>>> pythonXY.exe binaries on Windows (with the related question of
>>>> whether it's python32w.exe, python3.2w.exe, pythonw32.exe or
>>>> pythonw3.2.exe)
>>>>
>>>
>>> I would really like to see this. We do it on other platforms, it is 
>>> useful
>>> there, it would be useful on Windows for the same reasons.
>>
>> +1. And I'm OK with python3w and python32w as a colour for the 
>> bikeshed...
>
> Except for the the spelling of color ;-)
> I agree. Let 'w' always be the last suffix.
>
Yep. (Me too, me too.)

> With that settled, there is the issue of Start menu shortcuts. I 
> thought we had agreed to put version specific labels on them so we 
> would not have, for instance, identical 'IDLE (Python GUI)' items in 
> the frequently used list. I guess that got lost without a PEP to put 
> it on. Now there is?
>
Whilst there is much we would (and possibly should) do, other issues for 
the Windows installer are out of scope for this PEP. Let's just deal 
with the issue at hand. :-)

All the best,

Michael

-- 
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


From raymond.hettinger at gmail.com  Sat Mar  5 20:20:14 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 5 Mar 2011 11:20:14 -0800
Subject: [Python-Dev] .hgignore (was: Mercurial conversion repositories)
In-Reply-To: <20110305174404.68ad6598@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<4D67E9A5.5030203@cadifra.com>
	<20110225144315.3eebcafc@limelight.wooz.org>
	<4D684E2A.90005@netwok.org>
	<20110226154939.41972d08@limelight.wooz.org>
	<ikduo2$qm2$1@dough.gmane.org>
	<20110228100826.6812ad30@limelight.wooz.org>
	<20110228161538.36b825ac@pitrou.net>
	<20110228160748.1be8b814@limelight.wooz.org>
	<20110228221034.53ebe810@pitrou.net>
	<AANLkTi=-4JgovpMGWtRENjJnhQEk2J2P2xs7FzPpyZ5Y@mail.gmail.com>
	<20110305134458.1FE0D249088@kimball.webabinitio.net>
	<AANLkTikpw+Uv0KsZH-pBjVV2eYV5yJBN=tP5pPy+BeAa@mail.gmail.com>
	<AANLkTin-qYUJs7au9ubPXXbh7UNddVZpPjyLqWE7H4Qf@mail.gmail.com>
	<20110305174404.68ad6598@pitrou.net>
Message-ID: <A01A74F3-6113-4A05-8BE6-07BEE6BFCA43@gmail.com>


On Mar 5, 2011, at 8:44 AM, Antoine Pitrou wrote:

> On Sat, 5 Mar 2011 08:36:04 -0800
> Daniel Stutzbach <stutzbach at google.com> wrote:
> 
>> On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney <timothy.c.delaney at gmail.com>wrote:
>> 
>>> If those were to be removed from .hgignore then there would be a high
>>> likelihood of someone doing "hg addremove" and inadvertently tracking them.
>>> The purpose of .hgignore is to prevent inadventently tracking files that
>>> shouldn't be tracked.
>>> 
>> 
>> If the goal is to prevent something from being committed, shouldn't the
>> check go in a pre-commit hook instead?
> 
> Well, it's more user-friendly to help "hg addremove" work as expected,
> rather than add hooks down the line to forbid pushing any mistakes.

I concur.


Raymond


From dawelty at shinyhat.org  Sat Mar  5 20:26:38 2011
From: dawelty at shinyhat.org (Daniel A. Welty)
Date: Sat, 5 Mar 2011 14:26:38 -0500
Subject: [Python-Dev] Vagaries of "their" in English (was Re: Support
 the /usr/bin/python2 symlink upstream)
In-Reply-To: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>
References: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>
Message-ID: <AANLkTimAP1GsLvu4BHqJ8cvpfHPF8t8tLzhX+zrdb1qk@mail.gmail.com>

I'm sorry, but I can't just "get used to it", nor do I think it's the "least
bad of all available options".

I'll just summarise briefly what the incorrect ways of addressing this
problem are, and why:

*  "he or she" and "his or her" are cumbersome constructions introduced by
politically correct zealots who are trying to politicise something that's
not political. It's grammatically acceptable, but cumbersome and pointless.
Please avoid doing this. If you really absolutely have to bow to the
pressure of politically correct idiocy though, this might be the best choice
since at least it's grammatically sound.

*  "they" and "their" are plural, and should never be used in the singular.
This has become the leading contender thanks to the same politically correct
zealots named above (and also because it's not cumbersome), but that makes
it no less wrong. Please don't do this. Ever. In addition to being
pointlessly (and annoyingly) politicised, it's grammatically incorrect.



The correct way to address this problem (that is, how it had always been
addressed before politically correct zealots started butchering the
language) is for the speaker to assume that the person of unknown gender is
the same gender as they are. In other words, if a woman is speaking or
writing, she should use "she" and "her", and if a man is speaking or
writing, he should use "he" and "his". This is the correct usage, and always
has been.

In the event that it is necessary to avoid giving the wrong impression about
gender, it might be necessary to make a different substitution. For example,
it you've witnessed a hit and run, but only saw the car and not the driver,
and you're trying to tell the police what you saw, you don't want to give
the impression that you know the gender of the driver when you don't. Thus,
instead of saying "and then *he* took off down Maple street." or "and then
*they* took off down Maple street." (which also would give the possibly
erroneous impression that multiple people were in the car), you should say
something like "and then *the car* took off..." or  "and then *the driver*
took off..."

As this relates to Python and it's documentation (which I'll assume is where
this is discussion originated, not having read the originating thread),
given that there are multiple authors, some male and some female, we should
just standardise on either "he" or "she" (or, if you prefer: "the
programmer"). I don't care which one, as long as it's used consistently
throughout. But please, please, whatever you do, don't use "they" and
"their" to refer to a singular. Out of all the possible options that's the
one that's actually *wrong*. Far from being the "least bad of all available
options", it's actually the worst of all available options.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110305/fbd63be5/attachment.html>

From jnoller at gmail.com  Sat Mar  5 22:25:24 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Sat, 5 Mar 2011 16:25:24 -0500
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <iktsh9$1fl$1@dough.gmane.org>
References: <iktsh9$1fl$1@dough.gmane.org>
Message-ID: <AANLkTimqvweK5v9CKcMuZo-m7mpayVYMJHJb+Xb+mND9@mail.gmail.com>

On Sat, Mar 5, 2011 at 12:39 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> I'm very happy to announce that the core Python repository switch
> to Mercurial is complete and the new repository at
> http://hg.python.org/cpython/ is now officially open for cloning,
> and for commits by those who had commit access to SVN.
>
> The developers' guide at http://docs.python.org/devguide/ has
> been updated to talk about Mercurial and should be enough to
> get anyone started with a clone.
>
> We'll work on extracting active feature branches into separate
> clones next; please let us know which branches these are (we
> already know of py3k-cdecimal, pep-3151 and pep-382).
>
> To make new feature "branches" (ie. clones) that are to be
> available at hg.python.org, best use the "server side clone"
> feature that is available at http://hg.python.org/cpython/
> in order to create the new repository.
>
> To look up SVN revisions, use hg.python.org/lookup/rXXXXX.
> The tracker has also been updated to link to hg.python.org
> for files and revisions. ?For the future, it will recognize
> hg changeset hashes as well (without brackets, see the recent
> thread).
>
> The buildbots should also now be building from the hg repositories.
>
> Please let me know if you notice any disruptions, or anything
> else that needs fixing, or any other question. ?Also please
> redirect praise to Antoine Pitrou and Dirkjan Ochtman who did
> most of the actual work.
>
> Georg

Thanks to all of you for doing this.

From solipsis at pitrou.net  Sat Mar  5 22:37:52 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 5 Mar 2011 22:37:52 +0100
Subject: [Python-Dev] Finding buildbot failures
References: <loom.20110225T190113-46@post.gmane.org>
	<4D67F959.8080701@voidspace.org.uk>
	<20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain>
	<4D68FD31.70901@voidspace.org.uk> <4D6C1ACF.3030503@v.loewis.de>
	<4D728055.1060201@voidspace.org.uk>
Message-ID: <20110305223752.4970ea4e@pitrou.net>

On Sat, 05 Mar 2011 18:26:29 +0000
Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> 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.

It shouldn't be difficult to acquire the skills. Buildbot is pure
Python (even its configuration file).

Regards

Antoine.



From nyamatongwe at gmail.com  Sat Mar  5 22:51:01 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sun, 6 Mar 2011 08:51:01 +1100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <iktsh9$1fl$1@dough.gmane.org>
References: <iktsh9$1fl$1@dough.gmane.org>
Message-ID: <AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>

Georg Brandl:

> I'm very happy to announce that the core Python repository switch
> to Mercurial is complete and the new repository at
> http://hg.python.org/cpython/ is now officially open for cloning,

   OK, I just performed a clone OK. It seems wrong to me that the
*.vcproj and *.vsprops files in PCBuild use Unix line ends. These
extensions are marked BIN in .hgeol. This machine does not have VS
2008 installed so I can't really check if that is OK.

   Just in case it is not all files, here are two with this issue
cpython\PCbuild\kill_python.vcproj
cpython\PCbuild\debug.vsprops

   Neil

From solipsis at pitrou.net  Sat Mar  5 23:03:35 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 5 Mar 2011 23:03:35 +0100
Subject: [Python-Dev] CPython hg transition complete
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
Message-ID: <20110305230335.7505a5e4@pitrou.net>

On Sun, 6 Mar 2011 08:51:01 +1100
Neil Hodgson <nyamatongwe at gmail.com> wrote:
> Georg Brandl:
> 
> > I'm very happy to announce that the core Python repository switch
> > to Mercurial is complete and the new repository at
> > http://hg.python.org/cpython/ is now officially open for cloning,
> 
>    OK, I just performed a clone OK. It seems wrong to me that the
> *.vcproj and *.vsprops files in PCBuild use Unix line ends. These
> extensions are marked BIN in .hgeol. This machine does not have VS
> 2008 installed so I can't really check if that is OK.

It mimicks their settings in the SVN repository, so it should be ok.
Thanks for reporting this.

Regards

Antoine.



From martin at v.loewis.de  Sat Mar  5 23:18:37 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 05 Mar 2011 23:18:37 +0100
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <4D728055.1060201@voidspace.org.uk>
References: <loom.20110225T190113-46@post.gmane.org>	<4D67F959.8080701@voidspace.org.uk>	<20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain>
	<4D68FD31.70901@voidspace.org.uk> <4D6C1ACF.3030503@v.loewis.de>
	<4D728055.1060201@voidspace.org.uk>
Message-ID: <4D72B6BD.4050506@v.loewis.de>

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).

I'd be also willing to help you getting started, especially assuming
you would want to sprint on that during PyCon.

Regards,
Martin

From nyamatongwe at gmail.com  Sat Mar  5 23:27:10 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sun, 6 Mar 2011 09:27:10 +1100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <20110305230335.7505a5e4@pitrou.net>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
Message-ID: <AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>

Antoine Pitrou:

> It mimicks their settings in the SVN repository, so it should be ok.

   It doesn't match how they are checked out by svn since they have
the property svn:eol-style set to 'native'. Therefore these files are
checked out by svn with Windows \r\n line ends.

   Neil

From solipsis at pitrou.net  Sat Mar  5 23:33:50 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 05 Mar 2011 23:33:50 +0100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
Message-ID: <1299364430.3692.7.camel@localhost.localdomain>

Le dimanche 06 mars 2011 ? 09:27 +1100, Neil Hodgson a ?crit :
> Antoine Pitrou:
> 
> > It mimicks their settings in the SVN repository, so it should be ok.
> 
>    It doesn't match how they are checked out by svn since they have
> the property svn:eol-style set to 'native'. Therefore these files are
> checked out by svn with Windows \r\n line ends.

Some of these files (MSVC project files) had that property, but some
hadn't. I had to make them all consistent so that the .hgeol file work
fine.

Regards

Antoine.



From martin at v.loewis.de  Sat Mar  5 23:40:05 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 05 Mar 2011 23:40:05 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D7287FF.8080503@voidspace.org.uk>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>	<AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>	<4D712B05.2020607@voidspace.org.uk>	<4D715B2F.7070501@v.loewis.de>	<4D72520E.1070906@voidspace.org.uk>	<AANLkTikNOzkLJRJBFJomGy3rDa5YwCkHQ+DmHyJO_BYx@mail.gmail.com>	<iku0pk$n8p$1@dough.gmane.org>
	<4D7287FF.8080503@voidspace.org.uk>
Message-ID: <4D72BBC5.4050002@v.loewis.de>

>> With that settled, there is the issue of Start menu shortcuts. I
>> thought we had agreed to put version specific labels on them so we
>> would not have, for instance, identical 'IDLE (Python GUI)' items in
>> the frequently used list. I guess that got lost without a PEP to put
>> it on. Now there is?

That would be a bug tracker level issue. I know that I'm bad at wording
things (not having English as my native language), so I need somebody
to tell me every little detail (preferably by means of a patch). The
bug tracker is the right place for that. Agreements on python-dev are
quickly forgotten.

Regards,
Martin

From martin at v.loewis.de  Sat Mar  5 23:42:50 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 05 Mar 2011 23:42:50 +0100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <1299364430.3692.7.camel@localhost.localdomain>
References: <iktsh9$1fl$1@dough.gmane.org>	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>	<20110305230335.7505a5e4@pitrou.net>	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
Message-ID: <4D72BC6A.8080409@v.loewis.de>

Am 05.03.2011 23:33, schrieb Antoine Pitrou:
> Le dimanche 06 mars 2011 ? 09:27 +1100, Neil Hodgson a ?crit :
>> Antoine Pitrou:
>>
>>> It mimicks their settings in the SVN repository, so it should be ok.
>>
>>    It doesn't match how they are checked out by svn since they have
>> the property svn:eol-style set to 'native'. Therefore these files are
>> checked out by svn with Windows \r\n line ends.
> 
> Some of these files (MSVC project files) had that property, but some
> hadn't. I had to make them all consistent so that the .hgeol file work
> fine.

Actually, the status that they had was deliberate. The vcproj files can
be in "native" EOL mode, and should have CRLF when checked out on
Windows. The solution file must have CRLF always.

The vcproj files where not in binary mode in subversion since that
wouldn't allow for easy textual diffs.

Regards,
Martin

From martin at v.loewis.de  Sun Mar  6 00:14:37 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 00:14:37 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <19826.24958.821162.983186@montanaro.dyndns.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
Message-ID: <4D72C3DD.7080800@v.loewis.de>

Am 05.03.2011 17:14, schrieb skip at pobox.com:
> Yesterday I cloned the hg cpython repository and made several local copies
> for various maintenance releases.  This morning I tried to hg pull my
> cpython repo to get any changes (not really expecting any), but got this
> output:
> 
>     % hg pull
>     pulling from http://hg.python.org/cpython
>     searching for changes
>     abort: repository is unrelated
> 
> What did I do wrong?

Since Georg didn't actually answer the question: you started using the
infrastructure before it was ready. Interestingly, I remember you making
the same mistake when we switched to Subversion: you continued to use
the test repository, and then found that subversion complains :-)

Regards,
Martin

From steve at pearwood.info  Sun Mar  6 00:25:28 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 06 Mar 2011 10:25:28 +1100
Subject: [Python-Dev] Vagaries of "their" in English (was Re: Support
 the /usr/bin/python2 symlink upstream)
In-Reply-To: <AANLkTimAP1GsLvu4BHqJ8cvpfHPF8t8tLzhX+zrdb1qk@mail.gmail.com>
References: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>
	<AANLkTimAP1GsLvu4BHqJ8cvpfHPF8t8tLzhX+zrdb1qk@mail.gmail.com>
Message-ID: <4D72C668.8010805@pearwood.info>

Daniel A. Welty wrote:

> *  "they" and "their" are plural, and should never be used in the singular.

Thank you for sharing your option here, but you are not a linguist and 
you are simply wrong.

At least two people in this thread have already linked to Wikipedia's 
article on singular-they, which has extensive discussion about its 
validity, complete with references, as well as more accessible 
discussions written by professional language experts like Michael 
Quinion or Geoffrey Pullum. In case you missed them the first few times, 
here they are again:

http://en.wikipedia.org/wiki/Singular_they
http://www.worldwidewords.org/qa/qa-the2.htm
http://itre.cis.upenn.edu/~myl/languagelog/archives/005423.html
(corrected broken link given earlier)
http://motivatedgrammar.wordpress.com/2009/09/10/singular-they-and-the-many-reasons-why-its-correct/
http://english.stackexchange.com/questions/192/is-it-correct-to-use-their-instead-of-his-or-her

As for your prescription for solving this problem:

> is for the speaker to assume that the person of unknown gender is
> the same gender as they are.

As *they* are?

Thank you for your accidental demonstration that the use of singular 
they is a natural and unobjectionable part of English language.


-- 
Steven


From nyamatongwe at gmail.com  Sun Mar  6 00:27:14 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sun, 6 Mar 2011 10:27:14 +1100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <1299364430.3692.7.camel@localhost.localdomain>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
Message-ID: <AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>

   To minimize differences from previous behaviour, it is probably
best to mimic svn more closely by changing .hgeol to either have all
the project files as native or allow fall through to the default ** =
native.

   Another possibility is to set Visual Studio project files to CRLF
but this is less compatible with how svn has been used. The advantage
to explicit CRLF is that if you clone onto a Unix system and then
share that disk with Windows or create an archive that is expanded on
Windows (in binary mode) then you have the expected line ends.
Similarly for sharing from Windows to Unix where the main problem is
that bash can be upset by CRLF line ends since it assumes that the CR
is part of the line and if the line ends with a file name (like "cat
.profile\r") will treat the CR as part of the file name.

   Neil

From solipsis at pitrou.net  Sun Mar  6 00:33:50 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 00:33:50 +0100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
Message-ID: <20110306003350.57f502b5@pitrou.net>

On Sun, 6 Mar 2011 10:27:14 +1100
Neil Hodgson <nyamatongwe at gmail.com> wrote:
>    To minimize differences from previous behaviour, it is probably
> best to mimic svn more closely by changing .hgeol to either have all
> the project files as native or allow fall through to the default ** =
> native.

If it's only cosmetic, I think anyone can commit and push the desired
changes.
(there doesn't seem to be any report of breakage of the build process
under Windows)

Regards

Antoine.

From martin at v.loewis.de  Sun Mar  6 00:37:32 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 00:37:32 +0100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
References: <iktsh9$1fl$1@dough.gmane.org>	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>	<20110305230335.7505a5e4@pitrou.net>	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
Message-ID: <4D72C93C.60705@v.loewis.de>

>    Another possibility is to set Visual Studio project files to CRLF
> but this is less compatible with how svn has been used. The advantage
> to explicit CRLF is that if you clone onto a Unix system and then
> share that disk with Windows or create an archive that is expanded on
> Windows (in binary mode) then you have the expected line ends.
> Similarly for sharing from Windows to Unix where the main problem is
> that bash can be upset by CRLF line ends since it assumes that the CR
> is part of the line and if the line ends with a file name (like "cat
> .profile\r") will treat the CR as part of the file name.

I recall that there were problems with subversion when we didn't use
native (but I think we used binary before that, and never tried CRLF).
It may be that the problems don't exist anymore, so I recommend that
we try fresh with CRLF, and reconsider if something actually breaks.

What is the recommended merge flow if I want to make this change to
all branches?

Regards,
Martin

From anikom15 at gmail.com  Sun Mar  6 00:38:02 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Sat, 05 Mar 2011 15:38:02 -0800
Subject: [Python-Dev] Vagaries of "their" in English (was Re: Support
 the /usr/bin/python2 symlink upstream)
In-Reply-To: <4D72C668.8010805@pearwood.info>
References: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>
	<AANLkTimAP1GsLvu4BHqJ8cvpfHPF8t8tLzhX+zrdb1qk@mail.gmail.com>
	<4D72C668.8010805@pearwood.info>
Message-ID: <1299368282.14254.2.camel@localhost.localdomain>

On Sun, 2011-03-06 at 10:25 +1100, Steven D'Aprano wrote:
> Daniel A. Welty wrote:
> 
> > *  "they" and "their" are plural, and should never be used in the singular.
> 
> Thank you for sharing your option here, but you are not a linguist and 
> you are simply wrong.
> 
> At least two people in this thread have already linked to Wikipedia's 
> article on singular-they, which has extensive discussion about its 
> validity, complete with references, as well as more accessible 
> discussions written by professional language experts like Michael 
> Quinion or Geoffrey Pullum. In case you missed them the first few times, 
> here they are again:
> 
> http://en.wikipedia.org/wiki/Singular_they
> http://www.worldwidewords.org/qa/qa-the2.htm
> http://itre.cis.upenn.edu/~myl/languagelog/archives/005423.html
> (corrected broken link given earlier)
> http://motivatedgrammar.wordpress.com/2009/09/10/singular-they-and-the-many-reasons-why-its-correct/
> http://english.stackexchange.com/questions/192/is-it-correct-to-use-their-instead-of-his-or-her
> 
> As for your prescription for solving this problem:
> 
> > is for the speaker to assume that the person of unknown gender is
> > the same gender as they are.
> 
> As *they* are?
> 
> Thank you for your accidental demonstration that the use of singular 
> they is a natural and unobjectionable part of English language.

Is playing gotcha REALLY necessary?

I believe singular they should not be used in formal writing. So what if
you use it in an email?


From martin at v.loewis.de  Sun Mar  6 00:44:03 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 00:44:03 +0100
Subject: [Python-Dev] hg merge flow
Message-ID: <4D72CAC3.5020709@v.loewis.de>

How should patches be applied to the cpython repository if they
land in more than one branch?

More specifically, assuming I want to patch all of 2.7, 3.1, 3.2, and
default - how do I apply the patches and how do I merge?

Regards,
Martin

From solipsis at pitrou.net  Sun Mar  6 00:44:49 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 00:44:49 +0100
Subject: [Python-Dev] CPython hg transition complete
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
	<4D72C93C.60705@v.loewis.de>
Message-ID: <20110306004449.088cf2f0@pitrou.net>

On Sun, 06 Mar 2011 00:37:32 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> What is the recommended merge flow if I want to make this change to
> all branches?

- on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain 2.5)
- on the other hand: 3.1 -> 3.2 -> default

Regards

Antoine.



From martin at v.loewis.de  Sun Mar  6 00:46:02 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 00:46:02 +0100
Subject: [Python-Dev] hg diff
Message-ID: <4D72CB3A.5090006@v.loewis.de>

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.

So I would rather like people not to use the --git option.

Regards,
Martin

From solipsis at pitrou.net  Sun Mar  6 00:57:56 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 00:57:56 +0100
Subject: [Python-Dev] hg merge flow
References: <4D72CAC3.5020709@v.loewis.de>
Message-ID: <20110306005756.1e2286ba@pitrou.net>

On Sun, 06 Mar 2011 00:44:03 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> How should patches be applied to the cpython repository if they
> land in more than one branch?
> 
> More specifically, assuming I want to patch all of 2.7, 3.1, 3.2, and
> default - how do I apply the patches and how do I merge?

(reposting my answer from another thread)

- on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain 2.5)
- on the other hand: 3.1 -> 3.2 -> default

Whether you start with 2.x or 3.x is unimportant.

Regards

Antoine.



From steve at pearwood.info  Sun Mar  6 01:18:34 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 06 Mar 2011 11:18:34 +1100
Subject: [Python-Dev] Vagaries of "their" in English (was Re: Support
 the /usr/bin/python2 symlink upstream)
In-Reply-To: <1299368282.14254.2.camel@localhost.localdomain>
References: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>	<AANLkTimAP1GsLvu4BHqJ8cvpfHPF8t8tLzhX+zrdb1qk@mail.gmail.com>	<4D72C668.8010805@pearwood.info>
	<1299368282.14254.2.camel@localhost.localdomain>
Message-ID: <4D72D2DA.1060905@pearwood.info>

Westley Mart?nez wrote:

> I believe singular they should not be used in formal writing. So what if
> you use it in an email?

If you, personally, dislike it, then don't use it. But if you (generic 
you) say that it is grammatically incorrect to do so, then you are 
simply *wrong*. Some things are a matter of taste and individual 
opinion, but the validity of singular-they is not one of them.

And if you (generic you) insist that a grammatical feature which goes 
back to Chaucer in written English, most likely a thousand years in 
spoken English, and that is used by the King James Bible, is politically 
correct zealotry created by feminists, well, that's just laughable.

This is off-topic and we've put enough noise on the dev list about this. 
If anyone wishes to continue a serious, good-faith discussion, I'm happy 
to talk off-list.



-- 
Steven


From ncoghlan at gmail.com  Sun Mar  6 01:33:28 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Mar 2011 10:33:28 +1000
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <4D727CC2.9000104@ronadam.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<4D71BEA9.80103@ronadam.com>
	<AANLkTinzrL=QQqzEBqAbjnfOFzpugkrUtdhyxi4UtNH2@mail.gmail.com>
	<4D727CC2.9000104@ronadam.com>
Message-ID: <AANLkTimUURXKjcWbCp+7tB5F3vn1C7ah6bbhLNMrwOoV@mail.gmail.com>

On Sun, Mar 6, 2011 at 4:11 AM, Ron Adam <rrr at ronadam.com> wrote:
> Adding a second references to the '__main__' module begins to blur the
> purpose of sys.modules from being a place to keep imported modules to a
> place that also has some ordering information. ?(Practicality over purity?,
> Or an indication of what direction to go in?)
>
> And, if you ask for keys, items, or values, you will need to filter out
> '__main__' to avoid the double reference.
>
> So I was thinking, what if we make sys.modules a little smarter. ?The
> negative of that is, it would no longer be a simple dictionary object.
>
> First idea ...
>
> Add a __main__ attribute to sys.modules to hold the name of the main module.
>
> Override modules.__setitem__, so it will catch '__main__' and set
> modules.__main__ to the name of the module, and put the module in under its
> real name instead of '__main__'.
>
> Override modules.__getitem__, so it will catch '__main__' and return
> self[self.__main__].
>
> Then keys(), values(), and items(), will not have the doubled main module
> references in them.
>
> The name of the main module is easy to get. ?ie... sys.modules.__main__
>
> sys.modules[__name__] will still return the correct module if __name__ ==
> "__main__".

That's quite an interesting idea - I hadn't even considered the
implications of double counting the affected module when iterating
over sys.modules in some fashion. That said, dropping `__main__` from
the iteration might confuse existing code, so it may be better to have
the lookup go the other way (i.e. define __missing__ on the dict
subclass and return sys.modules['__main__'] if the key matches
sys.modules.__main__).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Sun Mar  6 01:37:42 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 01:37:42 +0100
Subject: [Python-Dev] hgeol
Message-ID: <4D72D756.6000609@v.loewis.de>

I am trying to fix the hgeol settings for the vcproj files, with little
success so far. I created

http://hg.python.org/sandbox/hgeol/

which merely changes the .hgeol file. Now, if you enable the eol
extension, and check this branch out, you immediately get a report
(from hg status) that you have modified all these files. That is
surprising, since you didn't change any file at all.

So how can I fix this properly: so that all files have CRLF, but
are still attributed to whoever last modified them, rather than
having them attributed to me?

Regards,
Martin

From nyamatongwe at gmail.com  Sun Mar  6 02:05:13 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sun, 6 Mar 2011 12:05:13 +1100
Subject: [Python-Dev] hgeol
In-Reply-To: <4D72D756.6000609@v.loewis.de>
References: <4D72D756.6000609@v.loewis.de>
Message-ID: <AANLkTikTmsajJAkHf2wu2qssPHcqpm4t8uw-fYOC+eUS@mail.gmail.com>

Martin v. L?wis:

> So how can I fix this properly: so that all files have CRLF, but
> are still attributed to whoever last modified them, rather than
> having them attributed to me?

   I don't think this is possible from the current state. It may be
possible to change the conversion process to 'rewrite history' to
produce clean annotations. On other projects, I've just changed the
files and accepted a degraded history.

   Neil

From eric at trueblade.com  Sun Mar  6 02:09:09 2011
From: eric at trueblade.com (Eric Smith)
Date: Sat, 05 Mar 2011 20:09:09 -0500
Subject: [Python-Dev] hgeol
In-Reply-To: <4D72D756.6000609@v.loewis.de>
References: <4D72D756.6000609@v.loewis.de>
Message-ID: <4D72DEB5.3000207@trueblade.com>

On 3/5/2011 7:37 PM, "Martin v. L?wis" wrote:
> I am trying to fix the hgeol settings for the vcproj files, with little
> success so far. I created
>
> http://hg.python.org/sandbox/hgeol/
>
> which merely changes the .hgeol file. Now, if you enable the eol
> extension, and check this branch out, you immediately get a report
> (from hg status) that you have modified all these files. That is
> surprising, since you didn't change any file at all.
>
> So how can I fix this properly: so that all files have CRLF, but
> are still attributed to whoever last modified them, rather than
> having them attributed to me?

I'm not sure it's possible. If you look at Antoine's changes to 
Lib/email/test/data/msg_26.txt in 2.7 earlier today where he changed the 
line endings, it appears he changed every line so it will be attributed 
to him.

Eric.

From solipsis at pitrou.net  Sun Mar  6 02:38:58 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 02:38:58 +0100
Subject: [Python-Dev] hooks: Hopefully fix the issue where notification
 of merges to buildbot
References: <E1Pw2tV-0006IH-Us@dinsdale.python.org>
Message-ID: <20110306023858.5f067b8e@pitrou.net>


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".

Regards

Antoine.



On Sun, 06 Mar 2011 02:36:25 +0100
dirkjan.ochtman <python-checkins at python.org> wrote:
> http://hg.python.org/hooks/rev/d2aca4834bb9
> changeset:   48:d2aca4834bb9
> user:        Antoine Pitrou <solipsis at pitrou.net>
> date:        Sun Mar 06 02:36:25 2011 +0100
> summary:
>   Hopefully fix the issue where notification of merges to buildbot
> wouldn't notify all changed files (because they are copied from
> the second parent). Untested still.
> 
> files:
>   hgbuildbot.py
> 
> diff --git a/hgbuildbot.py b/hgbuildbot.py
> --- a/hgbuildbot.py
> +++ b/hgbuildbot.py
> @@ -84,9 +84,18 @@
>          manifest, user, (time, timezone), files, desc, extra = repo.changelog.read(node)
>          parents = [p for p in repo.changelog.parents(node) if p != nullid]
>          branch = extra['branch']
> -        # merges don't always contain files, but at least one file is required by buildbot
> -        if len(parents) > 1 and not files:
> -            files = ["merge"]
> +        if len(parents) > 1:
> +            # Explicitly compare current with its first parent (otherwise
> +            # some files might be "forgotten" if they are copied as-is from the
> +            # second parent).
> +            modified, added, removed, deleted = repo.status(rev, p[0])[:4]
> +            files = set()
> +            for l in (modified, added, removed, deleted):
> +                files.extend(l)
> +            files = sorted(files)
> +            if not files:
> +                # dummy merge, but at least one file is required by buildbot
> +                files.append("Misc/merge")
>          # add artificial prefix if configured
>          files = [prefix + f for f in files]
>          changes.append({
> 
> -- 
> Repository URL: http://hg.python.org/hooks



From guido at python.org  Sun Mar  6 02:44:44 2011
From: guido at python.org (Guido van Rossum)
Date: Sat, 5 Mar 2011 17:44:44 -0800
Subject: [Python-Dev] Vagaries of "their" in English (was Re: Support
 the /usr/bin/python2 symlink upstream)
In-Reply-To: <4D72D2DA.1060905@pearwood.info>
References: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>
	<AANLkTimAP1GsLvu4BHqJ8cvpfHPF8t8tLzhX+zrdb1qk@mail.gmail.com>
	<4D72C668.8010805@pearwood.info>
	<1299368282.14254.2.camel@localhost.localdomain>
	<4D72D2DA.1060905@pearwood.info>
Message-ID: <AANLkTimU=n_N6nFwPz2vBTagnK4dpXjmddyfe0Bh0b+-@mail.gmail.com>

Enough already. If anyone still disagrees, they can discuss it in the
comments page on wikipedia
(http://en.wikipedia.org/wiki/Talk:Singular_they).

Seriously, this is off-topic for python-dev.

-- 
--Guido van Rossum (python.org/~guido)

From skippy.hammond at gmail.com  Sun Mar  6 03:33:11 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Sun, 06 Mar 2011 13:33:11 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D723C90.6090307@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk>
Message-ID: <4D72F267.3050204@gmail.com>

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
>> Hammond<mhammond at 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.  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.

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'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.

Cheers,

Mark

From jcea at jcea.es  Sun Mar  6 04:54:06 2011
From: jcea at jcea.es (Jesus Cea)
Date: Sun, 06 Mar 2011 04:54:06 +0100
Subject: [Python-Dev] Devguide: "Can I make commits from machines other than
 the one I generated the keys on?"
Message-ID: <4D73055E.1020902@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In
<http://docs.python.org/devguide/faq.html#can-i-make-commits-from-machines-other-than-the-one-i-generated-the-keys-on>
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.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTXMFXplgi5GaxT1NAQJz1wP/d9sE3aJT8T9da5v7rBUcQY+7W5TupxvH
5hwvYnTgaTELH6AkxG45/yQzuP3OLppxquKlbQvLAMSpK/463UL7ip2xyihNGgo6
kAaRh0HaHal1JqosvXIs2tMj/qT7fZ61i5yW09fRFBg+fMWm1LE8kthqFfPujyNO
zLYjpCO853Y=
=VZI1
-----END PGP SIGNATURE-----

From anikom15 at gmail.com  Sun Mar  6 05:37:09 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Sat, 05 Mar 2011 20:37:09 -0800
Subject: [Python-Dev] Vagaries of "their" in English (was Re: Support
 the /usr/bin/python2 symlink upstream)
In-Reply-To: <4D72D2DA.1060905@pearwood.info>
References: <AANLkTikS6c5N_UQWik4OicnMYMc1Mq2qW342R8VWFra0@mail.gmail.com>
	<AANLkTimAP1GsLvu4BHqJ8cvpfHPF8t8tLzhX+zrdb1qk@mail.gmail.com>
	<4D72C668.8010805@pearwood.info>
	<1299368282.14254.2.camel@localhost.localdomain>
	<4D72D2DA.1060905@pearwood.info>
Message-ID: <1299386229.16298.8.camel@localhost.localdomain>

On Sun, 2011-03-06 at 11:18 +1100, Steven D'Aprano wrote:
> Westley Mart?nez wrote:
> 
> > I believe singular they should not be used in formal writing. So what if
> > you use it in an email?
> 
> If you, personally, dislike it, then don't use it. But if you (generic 
> you) say that it is grammatically incorrect to do so, then you are 
> simply *wrong*. Some things are a matter of taste and individual 
> opinion, but the validity of singular-they is not one of them.
> 
> And if you (generic you) insist that a grammatical feature which goes 
> back to Chaucer in written English, most likely a thousand years in 
> spoken English, and that is used by the King James Bible, is politically 
> correct zealotry created by feminists, well, that's just laughable.
> 
> This is off-topic and we've put enough noise on the dev list about this. 
> If anyone wishes to continue a serious, good-faith discussion, I'm happy 
> to talk off-list.

For the record, I never said anything about politically correct
zealotry.


From rrr at ronadam.com  Sun Mar  6 05:54:02 2011
From: rrr at ronadam.com (Ron Adam)
Date: Sat, 05 Mar 2011 22:54:02 -0600
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTimUURXKjcWbCp+7tB5F3vn1C7ah6bbhLNMrwOoV@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>	<4D71BEA9.80103@ronadam.com>	<AANLkTinzrL=QQqzEBqAbjnfOFzpugkrUtdhyxi4UtNH2@mail.gmail.com>	<4D727CC2.9000104@ronadam.com>
	<AANLkTimUURXKjcWbCp+7tB5F3vn1C7ah6bbhLNMrwOoV@mail.gmail.com>
Message-ID: <4D73136A.8030103@ronadam.com>



On 03/05/2011 06:33 PM, Nick Coghlan wrote:
> On Sun, Mar 6, 2011 at 4:11 AM, Ron Adam<rrr at ronadam.com>  wrote:
>> Adding a second references to the '__main__' module begins to blur the
>> purpose of sys.modules from being a place to keep imported modules to a
>> place that also has some ordering information.  (Practicality over purity?,
>> Or an indication of what direction to go in?)
>>
>> And, if you ask for keys, items, or values, you will need to filter out
>> '__main__' to avoid the double reference.
>>
>> So I was thinking, what if we make sys.modules a little smarter.  The
>> negative of that is, it would no longer be a simple dictionary object.
>>
>> First idea ...
>>
>> Add a __main__ attribute to sys.modules to hold the name of the main module.
>>
>> Override modules.__setitem__, so it will catch '__main__' and set
>> modules.__main__ to the name of the module, and put the module in under its
>> real name instead of '__main__'.
>>
>> Override modules.__getitem__, so it will catch '__main__' and return
>> self[self.__main__].
>>
>> Then keys(), values(), and items(), will not have the doubled main module
>> references in them.
>>
>> The name of the main module is easy to get.  ie... sys.modules.__main__
>>
>> sys.modules[__name__] will still return the correct module if __name__ ==
>> "__main__".
>
> That's quite an interesting idea - I hadn't even considered the
> implications of double counting the affected module when iterating
> over sys.modules in some fashion. That said, dropping `__main__` from
> the iteration might confuse existing code, so it may be better to have
> the lookup go the other way (i.e. define __missing__ on the dict
> subclass and return sys.modules['__main__'] if the key matches
> sys.modules.__main__).

     ... if the key matches sys.modules.__missing__

Works for me. ;-)

We can find a better name than __missing__ later.  (minor detail)

Cheers,
    Ron


From ncoghlan at gmail.com  Sun Mar  6 06:04:32 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Mar 2011 15:04:32 +1000
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <4D73136A.8030103@ronadam.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<4D71BEA9.80103@ronadam.com>
	<AANLkTinzrL=QQqzEBqAbjnfOFzpugkrUtdhyxi4UtNH2@mail.gmail.com>
	<4D727CC2.9000104@ronadam.com>
	<AANLkTimUURXKjcWbCp+7tB5F3vn1C7ah6bbhLNMrwOoV@mail.gmail.com>
	<4D73136A.8030103@ronadam.com>
Message-ID: <AANLkTinNzsyi8vz95TNY=11WKfOdwFDKQhoy9-LYrf4k@mail.gmail.com>

On Sun, Mar 6, 2011 at 2:54 PM, Ron Adam <rrr at ronadam.com> wrote:
>
> ? ?... if the key matches sys.modules.__missing__
>
> Works for me. ;-)
>
> We can find a better name than __missing__ later. ?(minor detail)

__missing__ is a dict method. I was merely noting it would make more
sense to override that rather than __setitem__ to avoid slowing down
normal lookups in sys.modules.

However, I'll still advocate the simple approach (two entries) for
now. Assuming uniqueness of values in a dictionary is invalid in
general, so code assuming it for sys.modules is arguably already
incorrect. Definitely a point deserving of more discussion in the PEP,
though.

Cheers,
Nick.


-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From rrr at ronadam.com  Sun Mar  6 05:54:02 2011
From: rrr at ronadam.com (Ron Adam)
Date: Sat, 05 Mar 2011 22:54:02 -0600
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTimUURXKjcWbCp+7tB5F3vn1C7ah6bbhLNMrwOoV@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>	<4D71BEA9.80103@ronadam.com>	<AANLkTinzrL=QQqzEBqAbjnfOFzpugkrUtdhyxi4UtNH2@mail.gmail.com>	<4D727CC2.9000104@ronadam.com>
	<AANLkTimUURXKjcWbCp+7tB5F3vn1C7ah6bbhLNMrwOoV@mail.gmail.com>
Message-ID: <4D73136A.8030103@ronadam.com>



On 03/05/2011 06:33 PM, Nick Coghlan wrote:
> On Sun, Mar 6, 2011 at 4:11 AM, Ron Adam<rrr at ronadam.com>  wrote:
>> Adding a second references to the '__main__' module begins to blur the
>> purpose of sys.modules from being a place to keep imported modules to a
>> place that also has some ordering information.  (Practicality over purity?,
>> Or an indication of what direction to go in?)
>>
>> And, if you ask for keys, items, or values, you will need to filter out
>> '__main__' to avoid the double reference.
>>
>> So I was thinking, what if we make sys.modules a little smarter.  The
>> negative of that is, it would no longer be a simple dictionary object.
>>
>> First idea ...
>>
>> Add a __main__ attribute to sys.modules to hold the name of the main module.
>>
>> Override modules.__setitem__, so it will catch '__main__' and set
>> modules.__main__ to the name of the module, and put the module in under its
>> real name instead of '__main__'.
>>
>> Override modules.__getitem__, so it will catch '__main__' and return
>> self[self.__main__].
>>
>> Then keys(), values(), and items(), will not have the doubled main module
>> references in them.
>>
>> The name of the main module is easy to get.  ie... sys.modules.__main__
>>
>> sys.modules[__name__] will still return the correct module if __name__ ==
>> "__main__".
>
> That's quite an interesting idea - I hadn't even considered the
> implications of double counting the affected module when iterating
> over sys.modules in some fashion. That said, dropping `__main__` from
> the iteration might confuse existing code, so it may be better to have
> the lookup go the other way (i.e. define __missing__ on the dict
> subclass and return sys.modules['__main__'] if the key matches
> sys.modules.__main__).

     ... if the key matches sys.modules.__missing__

Works for me. ;-)

We can find a better name than __missing__ later.  (minor detail)

Cheers,
    Ron

From rrr at ronadam.com  Sat Mar  5 19:11:14 2011
From: rrr at ronadam.com (Ron Adam)
Date: Sat, 05 Mar 2011 12:11:14 -0600
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <AANLkTinzrL=QQqzEBqAbjnfOFzpugkrUtdhyxi4UtNH2@mail.gmail.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>	<4D71BEA9.80103@ronadam.com>
	<AANLkTinzrL=QQqzEBqAbjnfOFzpugkrUtdhyxi4UtNH2@mail.gmail.com>
Message-ID: <4D727CC2.9000104@ronadam.com>



On 03/05/2011 01:14 AM, Nick Coghlan wrote:
> On Sat, Mar 5, 2011 at 2:40 PM, Ron Adam<rrr at ronadam.com>  wrote:
>>> Fixing direct execution inside packages
>>
>> +1 on both of these.
>>
>> I don't see any major problems with these.  Any minor issues can be worked
>> out.
>>
>> I suggest separating these two items out into their own PEP, and doing them
>> first.
>
> This first draft includes everything I *want* to do. If I have to
> scale the proposal back to get it accepted because I can't convince
> enough other people it's a good idea... well, even Guido isn't immune
> to that part of the PEP process (cf. PEP 340). It wouldn't be the
> first PEP to have a "Rejected Ideas" section, and I'm sure it wouldn't
> be the last.

Right, All of the reasons are good and some solution should be implemented 
for each of the issues you pointed out. The PEP process will help us figure 
out the best way to do that.


> I definitely intend to implement this in a few different pieces,
> though - the order of the 4 different fixes in the PEP also summarises
> what I consider to be a reasonable development strategy as well.

Sounds good.

I haven't formed a good opinion on the last 2 items yet which was why I 
didn't comment on them.




This morning I did have some interesting thoughts.*

*It seems I'm starting to wake up with python code in my head.  (Is that 
good?)  In some cases, it's outside of the box solutions, but not always 
good ones. <shrug> ;-)


Anyway... this mornings fuzzy python thoughts were along the lines of...


On one hand, Python tries to make it so each objects source/parent info  is 
reachable from the object when possible.  The nice thing about that is, it 
can be used to create a tree of where everything is.  That doesn't work 
*easily* at the module level due to modules being external OS entities that 
can be reused in different contexts.

On the other hand, a modules import order is somewhat more dynamic compared 
to class inheritance order, so would it be better to have that info in a 
separate place rather than with each module?


Adding a second references to the '__main__' module begins to blur the 
purpose of sys.modules from being a place to keep imported modules to a 
place that also has some ordering information.  (Practicality over purity?, 
Or an indication of what direction to go in?)

And, if you ask for keys, items, or values, you will need to filter out 
'__main__' to avoid the double reference.


So I was thinking, what if we make sys.modules a little smarter.  The 
negative of that is, it would no longer be a simple dictionary object.


First idea ...

Add a __main__ attribute to sys.modules to hold the name of the main module.

Override modules.__setitem__, so it will catch '__main__' and set 
modules.__main__ to the name of the module, and put the module in under its 
real name instead of '__main__'.

Override modules.__getitem__, so it will catch '__main__' and return 
self[self.__main__].

Then keys(), values(), and items(), will not have the doubled main module 
references in them.

The name of the main module is easy to get.  ie... sys.modules.__main__

sys.modules[__name__] will still return the correct module if __name__ == 
"__main__".



Second (more ambitious and less thought out) idea ...

Extend sys.modules so it is actually is a tree structure. The '__main__' 
module would be at the top of the tree.


Cheers,
    Ron

From greg at krypto.org  Sun Mar  6 08:17:04 2011
From: greg at krypto.org (Gregory P. Smith)
Date: Sat, 5 Mar 2011 23:17:04 -0800
Subject: [Python-Dev] Devguide: "Can I make commits from machines other
 than the one I generated the keys on?"
In-Reply-To: <4D73055E.1020902@jcea.es>
References: <4D73055E.1020902@jcea.es>
Message-ID: <AANLkTikbaN4kmda8=s1ROQ+1utVTV1wcA9t7Qug9+Dv5@mail.gmail.com>

On Sat, Mar 5, 2011 at 7:54 PM, Jesus Cea <jcea at jcea.es> wrote:
>
> In
> <
> http://docs.python.org/devguide/faq.html#can-i-make-commits-from-machines-other-than-the-one-i-generated-the-keys-on
> >
> 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.
>

Using agent forwarding with ssh gives the machine you log into full access
to _all_ of your local ssh keys rather than just the python svn one
required. I'd rather not recommend that to people. Any serious user of ssh
will know the feature exists and when to prefer its use.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110305/6779baee/attachment-0001.html>

From solipsis at pitrou.net  Sun Mar  6 09:34:26 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 09:34:26 +0100
Subject: [Python-Dev] Devguide: "Can I make commits from machines other
 than the one I generated the keys on?"
References: <4D73055E.1020902@jcea.es>
Message-ID: <20110306093426.2c0346e9@pitrou.net>

On Sun, 06 Mar 2011 04:54:06 +0100
Jesus Cea <jcea at 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.



From stefan-usenet at bytereef.org  Sun Mar  6 12:56:58 2011
From: stefan-usenet at bytereef.org (Stefan Krah)
Date: Sun, 6 Mar 2011 12:56:58 +0100
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <1298933106.3692.10.camel@localhost.localdomain>
References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de>
	<1298933106.3692.10.camel@localhost.localdomain>
Message-ID: <20110306115658.GA16071@sleipnir.bytereef.org>

Antoine Pitrou <solipsis at 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



From ncoghlan at gmail.com  Sun Mar  6 12:58:24 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Mar 2011 21:58:24 +1000
Subject: [Python-Dev] [Python-checkins] devguide: More miscellaneous
	review comments.
In-Reply-To: <E1PwAPH-0006oV-BK@dinsdale.python.org>
References: <E1PwAPH-0006oV-BK@dinsdale.python.org>
Message-ID: <AANLkTi=kgJ5F8bY6monCH8UE8bHRz1LKwazhpOQduv94@mail.gmail.com>

On Sun, Mar 6, 2011 at 7:37 PM, ned.deily <python-checkins at python.org> wrote:
> http://hg.python.org/devguide/rev/ad3278cfc5f6
> changeset: ? 376:ad3278cfc5f6
> user: ? ? ? ?Ned Deily <nad at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From g.brandl at gmx.net  Sun Mar  6 13:16:17 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Mar 2011 13:16:17 +0100
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <20110306115658.GA16071@sleipnir.bytereef.org>
References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de>
	<1298933106.3692.10.camel@localhost.localdomain>
	<20110306115658.GA16071@sleipnir.bytereef.org>
Message-ID: <ikvtuj$dqe$1@dough.gmane.org>

On 06.03.2011 12:56, Stefan Krah wrote:
> Antoine Pitrou <solipsis at 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


From g.brandl at gmx.net  Sun Mar  6 13:17:26 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Mar 2011 13:17:26 +0100
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <20110306115658.GA16071@sleipnir.bytereef.org>
References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de>
	<1298933106.3692.10.camel@localhost.localdomain>
	<20110306115658.GA16071@sleipnir.bytereef.org>
Message-ID: <ikvu0n$dqe$2@dough.gmane.org>

On 06.03.2011 12:56, Stefan Krah wrote:
> Antoine Pitrou <solipsis at 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


From dirkjan at ochtman.nl  Sun Mar  6 13:27:20 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Sun, 6 Mar 2011 13:27:20 +0100
Subject: [Python-Dev] hooks: Hopefully fix the issue where notification
 of merges to buildbot
In-Reply-To: <20110306023858.5f067b8e@pitrou.net>
References: <E1Pw2tV-0006IH-Us@dinsdale.python.org>
	<20110306023858.5f067b8e@pitrou.net>
Message-ID: <AANLkTikos239p_Xzm_OUgZBS7N=sGH8ObMon4HOf0Kd5@mail.gmail.com>

On Sun, Mar 6, 2011 at 02:38, Antoine Pitrou <solipsis at 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

From ncoghlan at gmail.com  Sun Mar  6 13:51:01 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Mar 2011 22:51:01 +1000
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <ikvu0n$dqe$2@dough.gmane.org>
References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de>
	<1298933106.3692.10.camel@localhost.localdomain>
	<20110306115658.GA16071@sleipnir.bytereef.org>
	<ikvu0n$dqe$2@dough.gmane.org>
Message-ID: <AANLkTinhs=V=z5VgEv+S_NF=Win3dYUen3C6vk5Rz1MH@mail.gmail.com>

On Sun, Mar 6, 2011 at 10:17 PM, Georg Brandl <g.brandl at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From digitalxero at gmail.com  Sun Mar  6 13:51:26 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sun, 6 Mar 2011 07:51:26 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D72F267.3050204@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
Message-ID: <AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>

On Sat, Mar 5, 2011 at 9:33 PM, Mark Hammond <skippy.hammond at 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.

From stefan-usenet at bytereef.org  Sun Mar  6 13:52:57 2011
From: stefan-usenet at bytereef.org (Stefan Krah)
Date: Sun, 6 Mar 2011 13:52:57 +0100
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <ikvu0n$dqe$2@dough.gmane.org>
References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de>
	<1298933106.3692.10.camel@localhost.localdomain>
	<20110306115658.GA16071@sleipnir.bytereef.org>
	<ikvu0n$dqe$2@dough.gmane.org>
Message-ID: <20110306125257.GA16909@sleipnir.bytereef.org>

Georg Brandl <g.brandl at 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
default                    47990:6a1c8fcce229
3.2                        47988:a0752d92d207 (inactive)
3.1                        47987:9e9aa450a5f8 (inactive)
legacy-trunk               33482:cde58cd07e7d (inactive)



Stefan Krah



From solipsis at pitrou.net  Sun Mar  6 14:05:26 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 14:05:26 +0100
Subject: [Python-Dev] Please sync your feature branches
References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de>
	<1298933106.3692.10.camel@localhost.localdomain>
	<20110306115658.GA16071@sleipnir.bytereef.org>
	<ikvu0n$dqe$2@dough.gmane.org>
	<AANLkTinhs=V=z5VgEv+S_NF=Win3dYUen3C6vk5Rz1MH@mail.gmail.com>
Message-ID: <20110306140526.3d734f73@pitrou.net>


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.



From mhammond at skippinet.com.au  Sun Mar  6 14:10:39 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 07 Mar 2011 00:10:39 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>
Message-ID: <4D7387CF.6070104@skippinet.com.au>

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.

From digitalxero at gmail.com  Sun Mar  6 14:10:35 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sun, 6 Mar 2011 08:10:35 -0500
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <20110306125257.GA16909@sleipnir.bytereef.org>
References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de>
	<1298933106.3692.10.camel@localhost.localdomain>
	<20110306115658.GA16071@sleipnir.bytereef.org>
	<ikvu0n$dqe$2@dough.gmane.org>
	<20110306125257.GA16909@sleipnir.bytereef.org>
Message-ID: <AANLkTinwa-s2K6ikEPqmvnfu9fQCwnLqCH5uUU3nkTT6@mail.gmail.com>

On Sun, Mar 6, 2011 at 7:52 AM, Stefan Krah <stefan-usenet at 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/

From solipsis at pitrou.net  Sun Mar  6 14:14:03 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 14:14:03 +0100
Subject: [Python-Dev] devguide: More miscellaneous review comments.
References: <E1PwAPH-0006oV-BK@dinsdale.python.org>
	<AANLkTi=kgJ5F8bY6monCH8UE8bHRz1LKwazhpOQduv94@mail.gmail.com>
Message-ID: <20110306141403.202d12b7@pitrou.net>

On Sun, 6 Mar 2011 21:58:24 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Sun, Mar 6, 2011 at 7:37 PM, ned.deily <python-checkins at python.org> wrote:
> > http://hg.python.org/devguide/rev/ad3278cfc5f6
> > changeset: ? 376:ad3278cfc5f6
> > user: ? ? ? ?Ned Deily <nad at 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.



From digitalxero at gmail.com  Sun Mar  6 14:40:21 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sun, 6 Mar 2011 08:40:21 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D7387CF.6070104@skippinet.com.au>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>
	<4D7387CF.6070104@skippinet.com.au>
Message-ID: <AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>

On Sun, Mar 6, 2011 at 8:10 AM, Mark Hammond <mhammond at 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.

From benjamin at python.org  Sun Mar  6 15:17:35 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 6 Mar 2011 08:17:35 -0600
Subject: [Python-Dev] small commit emails nit
Message-ID: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>

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

From solipsis at pitrou.net  Sun Mar  6 15:40:09 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 15:40:09 +0100
Subject: [Python-Dev] small commit emails nit
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
Message-ID: <20110306154009.272fcbf4@pitrou.net>

On Sun, 6 Mar 2011 08:17:35 -0600
Benjamin Peterson <benjamin at 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?



From ncoghlan at gmail.com  Sun Mar  6 15:52:08 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 00:52:08 +1000
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <20110306154009.272fcbf4@pitrou.net>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
	<20110306154009.272fcbf4@pitrou.net>
Message-ID: <AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>

On Mon, Mar 7, 2011 at 12:40 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 6 Mar 2011 08:17:35 -0600
> Benjamin Peterson <benjamin at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From p.f.moore at gmail.com  Sun Mar  6 15:55:24 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 6 Mar 2011 14:55:24 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D72F267.3050204@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
Message-ID: <AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>

On 6 March 2011 02:33, Mark Hammond <skippy.hammond at 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.

From solipsis at pitrou.net  Sun Mar  6 15:56:46 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 15:56:46 +0100
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
	<20110306154009.272fcbf4@pitrou.net>
	<AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>
Message-ID: <20110306155646.69870571@pitrou.net>

On Mon, 7 Mar 2011 00:52:08 +1000
Nick Coghlan <ncoghlan at 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.

From murman at gmail.com  Sun Mar  6 16:07:57 2011
From: murman at gmail.com (Michael Urman)
Date: Sun, 6 Mar 2011 09:07:57 -0600
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>
	<4D7387CF.6070104@skippinet.com.au>
	<AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>
Message-ID: <AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>

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

From ncoghlan at gmail.com  Sun Mar  6 16:11:24 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 01:11:24 +1000
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <20110306155646.69870571@pitrou.net>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
	<20110306154009.272fcbf4@pitrou.net>
	<AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>
	<20110306155646.69870571@pitrou.net>
Message-ID: <AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>

On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 7 Mar 2011 00:52:08 +1000
> Nick Coghlan <ncoghlan at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Sun Mar  6 16:24:39 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 16:24:39 +0100
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
	<20110306154009.272fcbf4@pitrou.net>
	<AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>
	<20110306155646.69870571@pitrou.net>
	<AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
Message-ID: <20110306162439.42d80a4e@pitrou.net>

On Mon, 7 Mar 2011 01:11:24 +1000
Nick Coghlan <ncoghlan at 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.

From skip at pobox.com  Sun Mar  6 16:44:38 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 6 Mar 2011 09:44:38 -0600
Subject: [Python-Dev] hg pull failed
In-Reply-To: <ikto58$dbt$1@dough.gmane.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
Message-ID: <19827.44006.852917.924065@montanaro.dyndns.org>


    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

From skip at pobox.com  Sun Mar  6 16:50:59 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 6 Mar 2011 09:50:59 -0600
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <20110306004449.088cf2f0@pitrou.net>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
	<4D72C93C.60705@v.loewis.de> <20110306004449.088cf2f0@pitrou.net>
Message-ID: <19827.44387.694986.490254@montanaro.dyndns.org>


    Antoine> "Martin v. L?wis" <martin at 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

From solipsis at pitrou.net  Sun Mar  6 16:55:18 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 06 Mar 2011 16:55:18 +0100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <19827.44387.694986.490254@montanaro.dyndns.org>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
	<4D72C93C.60705@v.loewis.de> <20110306004449.088cf2f0@pitrou.net>
	<19827.44387.694986.490254@montanaro.dyndns.org>
Message-ID: <1299426918.3699.13.camel@localhost.localdomain>

Le dimanche 06 mars 2011 ? 09:50 -0600, skip at pobox.com a ?crit :
> Antoine> "Martin v. L?wis" <martin at 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.



From g.brandl at gmx.net  Sun Mar  6 17:07:06 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Mar 2011 17:07:06 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <19827.44006.852917.924065@montanaro.dyndns.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
Message-ID: <il0bfd$96c$1@dough.gmane.org>

On 06.03.2011 16:44, skip at 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://hg at 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


From ncoghlan at gmail.com  Sun Mar  6 17:08:58 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 02:08:58 +1000
Subject: [Python-Dev] hg pull failed
In-Reply-To: <19827.44006.852917.924065@montanaro.dyndns.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
Message-ID: <AANLkTik6XU8zpuODh0KYNh6RUpM5R9aXLdBUSyYz95Co@mail.gmail.com>

On Mon, Mar 7, 2011 at 1:44 AM,  <skip at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From rdmurray at bitdance.com  Sun Mar  6 17:10:23 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 06 Mar 2011 11:10:23 -0500
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
	<20110306154009.272fcbf4@pitrou.net>
	<AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>
	<20110306155646.69870571@pitrou.net>
	<AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
Message-ID: <20110306161023.0C98C24A228@kimball.webabinitio.net>

On Mon, 07 Mar 2011 01:11:24 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Mon, 7 Mar 2011 00:52:08 +1000
> > Nick Coghlan <ncoghlan at 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

From ncoghlan at gmail.com  Sun Mar  6 17:15:02 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 02:15:02 +1000
Subject: [Python-Dev] hg pull failed
In-Reply-To: <il0bfd$96c$1@dough.gmane.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
	<il0bfd$96c$1@dough.gmane.org>
Message-ID: <AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>

On Mon, Mar 7, 2011 at 2:07 AM, Georg Brandl <g.brandl at 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://hg at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From g.brandl at gmx.net  Sun Mar  6 17:19:48 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Mar 2011 17:19:48 +0100
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <20110306161023.0C98C24A228@kimball.webabinitio.net>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
	<20110306154009.272fcbf4@pitrou.net>
	<AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>
	<20110306155646.69870571@pitrou.net>
	<AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
	<20110306161023.0C98C24A228@kimball.webabinitio.net>
Message-ID: <il0c76$de9$1@dough.gmane.org>

On 06.03.2011 17:10, R. David Murray wrote:
> On Mon, 07 Mar 2011 01:11:24 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > On Mon, 7 Mar 2011 00:52:08 +1000
>> > Nick Coghlan <ncoghlan at 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 "rXXXXX - in python/branches/py3k" anyway, so I
don't see what's so bad about 7 helpful characters.

Georg


From solipsis at pitrou.net  Sun Mar  6 17:43:09 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 17:43:09 +0100
Subject: [Python-Dev] r88758 -
	tracker/instances/python-dev/scripts/addpatchsets
References: <20110306163240.958DBEE981@mail.python.org>
Message-ID: <20110306174309.3df82503@pitrou.net>

On Sun,  6 Mar 2011 17:32:40 +0100 (CET)
martin.v.loewis <python-checkins at 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.



From g.brandl at gmx.net  Sun Mar  6 17:49:40 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Mar 2011 17:49:40 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
	<il0bfd$96c$1@dough.gmane.org>
	<AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>
Message-ID: <il0dv6$kmb$1@dough.gmane.org>

On 06.03.2011 17:15, Nick Coghlan wrote:
> On Mon, Mar 7, 2011 at 2:07 AM, Georg Brandl <g.brandl at 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://hg at 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


From fuzzyman at voidspace.org.uk  Sun Mar  6 17:52:54 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 06 Mar 2011 16:52:54 +0000
Subject: [Python-Dev] devguide: More miscellaneous review comments.
In-Reply-To: <20110306141403.202d12b7@pitrou.net>
References: <E1PwAPH-0006oV-BK@dinsdale.python.org>	<AANLkTi=kgJ5F8bY6monCH8UE8bHRz1LKwazhpOQduv94@mail.gmail.com>
	<20110306141403.202d12b7@pitrou.net>
Message-ID: <4D73BBE6.9090805@voidspace.org.uk>

On 06/03/2011 13:14, Antoine Pitrou wrote:
> On Sun, 6 Mar 2011 21:58:24 +1000
> Nick Coghlan<ncoghlan at gmail.com>  wrote:
>
>> On Sun, Mar 6, 2011 at 7:37 PM, ned.deily<python-checkins at python.org>  wrote:
>>> http://hg.python.org/devguide/rev/ad3278cfc5f6
>>> changeset:   376:ad3278cfc5f6
>>> user:        Ned Deily<nad at 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 at 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


From fuzzyman at voidspace.org.uk  Sun Mar  6 18:01:16 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 06 Mar 2011 17:01:16 +0000
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <4D72B6BD.4050506@v.loewis.de>
References: <loom.20110225T190113-46@post.gmane.org>	<4D67F959.8080701@voidspace.org.uk>	<20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain>
	<4D68FD31.70901@voidspace.org.uk> <4D6C1ACF.3030503@v.loewis.de>
	<4D728055.1060201@voidspace.org.uk> <4D72B6BD.4050506@v.loewis.de>
Message-ID: <4D73BDDC.9020209@voidspace.org.uk>

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


From solipsis at pitrou.net  Sun Mar  6 18:05:49 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 18:05:49 +0100
Subject: [Python-Dev] devguide: More miscellaneous review comments.
In-Reply-To: <4D73BBE6.9090805@voidspace.org.uk>
References: <E1PwAPH-0006oV-BK@dinsdale.python.org>
	<AANLkTi=kgJ5F8bY6monCH8UE8bHRz1LKwazhpOQduv94@mail.gmail.com>
	<20110306141403.202d12b7@pitrou.net>
	<4D73BBE6.9090805@voidspace.org.uk>
Message-ID: <20110306180549.39003893@pitrou.net>

On Sun, 06 Mar 2011 16:52:54 +0000
Michael Foord <fuzzyman at voidspace.org.uk> wrote:

> On 06/03/2011 13:14, Antoine Pitrou wrote:
> > On Sun, 6 Mar 2011 21:58:24 +1000
> > Nick Coghlan<ncoghlan at gmail.com>  wrote:
> >
> >> On Sun, Mar 6, 2011 at 7:37 PM, ned.deily<python-checkins at python.org>  wrote:
> >>> http://hg.python.org/devguide/rev/ad3278cfc5f6
> >>> changeset:   376:ad3278cfc5f6
> >>> user:        Ned Deily<nad at 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.

From doko at ubuntu.com  Sun Mar  6 17:57:13 2011
From: doko at ubuntu.com (Matthias Klose)
Date: Sun, 06 Mar 2011 17:57:13 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTimROmiCUczRPR5KnTBnfKMbUd9KkZwYKf-3km8q@mail.gmail.com>
References: <AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>
	<20110302090155.GL30982@piotro.eu>	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>	<20110302125641.GM30982@piotro.eu>	<AANLkTikV_SiX6xmymuK=mQctYMApE19NNKyTpm5xBgae@mail.gmail.com>	<20110302140323.GN30982@piotro.eu>
	<4D6E51A7.6020302@archlinux.org>	<20110302142918.GO30982@piotro.eu>
	<4D6E5A13.5080507@archlinux.org>	<20110302152003.GP30982@piotro.eu>
	<AANLkTimROmiCUczRPR5KnTBnfKMbUd9KkZwYKf-3km8q@mail.gmail.com>
Message-ID: <4D73BCE9.1010201@ubuntu.com>

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

From fuzzyman at voidspace.org.uk  Sun Mar  6 18:08:30 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 06 Mar 2011 17:08:30 +0000
Subject: [Python-Dev] devguide: More miscellaneous review comments.
In-Reply-To: <20110306180549.39003893@pitrou.net>
References: <E1PwAPH-0006oV-BK@dinsdale.python.org>	<AANLkTi=kgJ5F8bY6monCH8UE8bHRz1LKwazhpOQduv94@mail.gmail.com>	<20110306141403.202d12b7@pitrou.net>	<4D73BBE6.9090805@voidspace.org.uk>
	<20110306180549.39003893@pitrou.net>
Message-ID: <4D73BF8E.9050507@voidspace.org.uk>

On 06/03/2011 17:05, Antoine Pitrou wrote:
> On Sun, 06 Mar 2011 16:52:54 +0000
> Michael Foord<fuzzyman at voidspace.org.uk>  wrote:
>
>> On 06/03/2011 13:14, Antoine Pitrou wrote:
>>> On Sun, 6 Mar 2011 21:58:24 +1000
>>> Nick Coghlan<ncoghlan at gmail.com>   wrote:
>>>
>>>> On Sun, Mar 6, 2011 at 7:37 PM, ned.deily<python-checkins at python.org>   wrote:
>>>>> http://hg.python.org/devguide/rev/ad3278cfc5f6
>>>>> changeset:   376:ad3278cfc5f6
>>>>> user:        Ned Deily<nad at 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 at 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


From brian.curtin at gmail.com  Sun Mar  6 18:18:40 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Sun, 6 Mar 2011 11:18:40 -0600
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>
	<4D7387CF.6070104@skippinet.com.au>
	<AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>
	<AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>
Message-ID: <AANLkTi=ybjwfsUUEZRzE6O=wv7k=ErhdxKp5MJeLH6LA@mail.gmail.com>

On Sun, Mar 6, 2011 at 09:07, Michael Urman <murman at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/e7a5b03a/attachment.html>

From martin at v.loewis.de  Sun Mar  6 18:23:58 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 18:23:58 +0100
Subject: [Python-Dev] r88758
	-	tracker/instances/python-dev/scripts/addpatchsets
In-Reply-To: <20110306174309.3df82503@pitrou.net>
References: <20110306163240.958DBEE981@mail.python.org>
	<20110306174309.3df82503@pitrou.net>
Message-ID: <4D73C32E.4050507@v.loewis.de>

>> -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

From skip at pobox.com  Sun Mar  6 18:34:06 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 6 Mar 2011 11:34:06 -0600
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <1299426918.3699.13.camel@localhost.localdomain>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
	<4D72C93C.60705@v.loewis.de> <20110306004449.088cf2f0@pitrou.net>
	<19827.44387.694986.490254@montanaro.dyndns.org>
	<1299426918.3699.13.camel@localhost.localdomain>
Message-ID: <19827.50574.771598.246570@montanaro.dyndns.org>


    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


From barry at python.org  Sun Mar  6 18:38:29 2011
From: barry at python.org (Barry Warsaw)
Date: Sun, 6 Mar 2011 12:38:29 -0500
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
Message-ID: <20110306123829.11fdaf73@limelight.wooz.org>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/1550a7f7/attachment.pgp>

From skip at pobox.com  Sun Mar  6 18:39:57 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 6 Mar 2011 11:39:57 -0600
Subject: [Python-Dev] hg pull failed
In-Reply-To: <AANLkTik6XU8zpuODh0KYNh6RUpM5R9aXLdBUSyYz95Co@mail.gmail.com>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
	<AANLkTik6XU8zpuODh0KYNh6RUpM5R9aXLdBUSyYz95Co@mail.gmail.com>
Message-ID: <19827.50925.382550.817720@montanaro.dyndns.org>


    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

From fuzzyman at voidspace.org.uk  Sun Mar  6 18:41:54 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 06 Mar 2011 17:41:54 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D72F267.3050204@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
Message-ID: <4D73C762.1050802@voidspace.org.uk>

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
>>> Hammond<mhammond at 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


From brian.curtin at gmail.com  Sun Mar  6 18:41:54 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Sun, 6 Mar 2011 11:41:54 -0600
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <iktsh9$1fl$1@dough.gmane.org>
References: <iktsh9$1fl$1@dough.gmane.org>
Message-ID: <AANLkTim3j4Ck_GiJjN+AwsFfktMNfWRw=O71d+qUa+Bq@mail.gmail.com>

On Sat, Mar 5, 2011 at 11:39, Georg Brandl <g.brandl at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/b5c2222c/attachment.html>

From skip at pobox.com  Sun Mar  6 18:43:31 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 6 Mar 2011 11:43:31 -0600
Subject: [Python-Dev] hg pull failed
In-Reply-To: <il0bfd$96c$1@dough.gmane.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
	<il0bfd$96c$1@dough.gmane.org>
Message-ID: <19827.51139.348022.619696@montanaro.dyndns.org>


    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://hg at 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

From solipsis at pitrou.net  Sun Mar  6 18:44:18 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 06 Mar 2011 18:44:18 +0100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <19827.50574.771598.246570@montanaro.dyndns.org>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
	<4D72C93C.60705@v.loewis.de> <20110306004449.088cf2f0@pitrou.net>
	<19827.44387.694986.490254@montanaro.dyndns.org>
	<1299426918.3699.13.camel@localhost.localdomain>
	<19827.50574.771598.246570@montanaro.dyndns.org>
Message-ID: <1299433458.3699.37.camel@localhost.localdomain>

Le dimanche 06 mars 2011 ? 11:34 -0600, skip at 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.



From skip at pobox.com  Sun Mar  6 18:45:48 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 6 Mar 2011 11:45:48 -0600
Subject: [Python-Dev] hg pull failed
In-Reply-To: <AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
	<il0bfd$96c$1@dough.gmane.org>
	<AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>
Message-ID: <19827.51276.575501.55448@montanaro.dyndns.org>


    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

From g.brandl at gmx.net  Sun Mar  6 18:47:31 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Mar 2011 18:47:31 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <19827.50925.382550.817720@montanaro.dyndns.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
	<AANLkTik6XU8zpuODh0KYNh6RUpM5R9aXLdBUSyYz95Co@mail.gmail.com>
	<19827.50925.382550.817720@montanaro.dyndns.org>
Message-ID: <il0hbm$5pc$1@dough.gmane.org>

On 06.03.2011 18:39, skip at 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




From brian.curtin at gmail.com  Sun Mar  6 18:53:22 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Sun, 6 Mar 2011 11:53:22 -0600
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D73C762.1050802@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<4D73C762.1050802@voidspace.org.uk>
Message-ID: <AANLkTi=u=8ikkdxuFKQ3_9QnvTavoiZTD0J1hDMcaa9A@mail.gmail.com>

On Sun, Mar 6, 2011 at 11:41, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/0812ea53/attachment.html>

From g.brandl at gmx.net  Sun Mar  6 19:01:59 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Mar 2011 19:01:59 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <19827.51276.575501.55448@montanaro.dyndns.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
	<il0bfd$96c$1@dough.gmane.org>
	<AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>
	<19827.51276.575501.55448@montanaro.dyndns.org>
Message-ID: <il0i6q$an7$1@dough.gmane.org>

On 06.03.2011 18:45, skip at 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



From doko at ubuntu.com  Sun Mar  6 19:12:48 2011
From: doko at ubuntu.com (Matthias Klose)
Date: Sun, 06 Mar 2011 19:12:48 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
Message-ID: <4D73CEA0.40006@ubuntu.com>

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

From solipsis at pitrou.net  Sun Mar  6 19:14:40 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Mar 2011 19:14:40 +0100
Subject: [Python-Dev] r88758
	-	tracker/instances/python-dev/scripts/addpatchsets
References: <20110306163240.958DBEE981@mail.python.org>
	<20110306174309.3df82503@pitrou.net> <4D73C32E.4050507@v.loewis.de>
Message-ID: <20110306191440.3b04d735@pitrou.net>

On Sun, 06 Mar 2011 18:23:58 +0100
"Martin v. L?wis" <martin at 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.



From martin at v.loewis.de  Sun Mar  6 20:09:39 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 20:09:39 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <il0i6q$an7$1@dough.gmane.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>	<ikto58$dbt$1@dough.gmane.org>	<19827.44006.852917.924065@montanaro.dyndns.org>	<il0bfd$96c$1@dough.gmane.org>	<AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>	<19827.51276.575501.55448@montanaro.dyndns.org>
	<il0i6q$an7$1@dough.gmane.org>
Message-ID: <4D73DBF3.2030904@v.loewis.de>

>> 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

From martin at v.loewis.de  Sun Mar  6 20:19:47 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 20:19:47 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D73CEA0.40006@ubuntu.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<4D73CEA0.40006@ubuntu.com>
Message-ID: <4D73DE53.7060406@v.loewis.de>

> 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

From martin at v.loewis.de  Sun Mar  6 20:25:40 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 20:25:40 +0100
Subject: [Python-Dev]
	r88758	-	tracker/instances/python-dev/scripts/addpatchsets
In-Reply-To: <20110306191440.3b04d735@pitrou.net>
References: <20110306163240.958DBEE981@mail.python.org>	<20110306174309.3df82503@pitrou.net>
	<4D73C32E.4050507@v.loewis.de> <20110306191440.3b04d735@pitrou.net>
Message-ID: <4D73DFB4.7030809@v.loewis.de>

>> 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


From adrian at cadifra.com  Sun Mar  6 20:36:04 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Sun, 06 Mar 2011 20:36:04 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <4D73DBF3.2030904@v.loewis.de>
References: <19826.24958.821162.983186@montanaro.dyndns.org>	<ikto58$dbt$1@dough.gmane.org>	<19827.44006.852917.924065@montanaro.dyndns.org>	<il0bfd$96c$1@dough.gmane.org>	<AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>	<19827.51276.575501.55448@montanaro.dyndns.org>	<il0i6q$an7$1@dough.gmane.org>
	<4D73DBF3.2030904@v.loewis.de>
Message-ID: <4D73E224.3020102@cadifra.com>

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

From martin at v.loewis.de  Sun Mar  6 21:00:19 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 21:00:19 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <4D73E224.3020102@cadifra.com>
References: <19826.24958.821162.983186@montanaro.dyndns.org>	<ikto58$dbt$1@dough.gmane.org>	<19827.44006.852917.924065@montanaro.dyndns.org>	<il0bfd$96c$1@dough.gmane.org>	<AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>	<19827.51276.575501.55448@montanaro.dyndns.org>	<il0i6q$an7$1@dough.gmane.org>	<4D73DBF3.2030904@v.loewis.de>
	<4D73E224.3020102@cadifra.com>
Message-ID: <4D73E7D3.3010808@v.loewis.de>

> 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

From mail at kerrickstaley.com  Sun Mar  6 21:12:02 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Sun, 6 Mar 2011 14:12:02 -0600
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D718816.20304@skippinet.com.au>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
Message-ID: <AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/24a8cb03/attachment.html>

From martin at v.loewis.de  Sun Mar  6 21:31:40 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 21:31:40 +0100
Subject: [Python-Dev] (Final?) release of Python 2.5 in April
Message-ID: <4D73EF2C.2070602@v.loewis.de>

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

From martin at v.loewis.de  Sun Mar  6 21:35:28 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 21:35:28 +0100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D646D.6070506@trueblade.com>	<20110301222148.49F91249CF7@kimball.webabinitio.net>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>
	<AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>
Message-ID: <4D73F010.8010101@v.loewis.de>

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

From mail at kerrickstaley.com  Sun Mar  6 21:44:59 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Sun, 6 Mar 2011 14:44:59 -0600
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>
Message-ID: <AANLkTi=VD8yck7y=Su1a+e-q0mM-49FgTr1iJ-UFPzuv@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/1c964020/attachment-0001.html>

From skip at pobox.com  Sun Mar  6 21:46:32 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 6 Mar 2011 14:46:32 -0600
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <1299433458.3699.37.camel@localhost.localdomain>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
	<4D72C93C.60705@v.loewis.de> <20110306004449.088cf2f0@pitrou.net>
	<19827.44387.694986.490254@montanaro.dyndns.org>
	<1299426918.3699.13.camel@localhost.localdomain>
	<19827.50574.771598.246570@montanaro.dyndns.org>
	<1299433458.3699.37.camel@localhost.localdomain>
Message-ID: <19827.62120.276471.798561@montanaro.dyndns.org>


    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

From martin at v.loewis.de  Sun Mar  6 21:57:39 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 21:57:39 +0100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <19827.62120.276471.798561@montanaro.dyndns.org>
References: <iktsh9$1fl$1@dough.gmane.org>	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>	<20110305230335.7505a5e4@pitrou.net>	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>	<1299364430.3692.7.camel@localhost.localdomain>	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>	<4D72C93C.60705@v.loewis.de>
	<20110306004449.088cf2f0@pitrou.net>	<19827.44387.694986.490254@montanaro.dyndns.org>	<1299426918.3699.13.camel@localhost.localdomain>	<19827.50574.771598.246570@montanaro.dyndns.org>	<1299433458.3699.37.camel@localhost.localdomain>
	<19827.62120.276471.798561@montanaro.dyndns.org>
Message-ID: <4D73F543.2040206@v.loewis.de>

Am 06.03.2011 21:46, schrieb skip at 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

From solipsis at pitrou.net  Sun Mar  6 22:09:06 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 06 Mar 2011 22:09:06 +0100
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <19827.62120.276471.798561@montanaro.dyndns.org>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
	<4D72C93C.60705@v.loewis.de> <20110306004449.088cf2f0@pitrou.net>
	<19827.44387.694986.490254@montanaro.dyndns.org>
	<1299426918.3699.13.camel@localhost.localdomain>
	<19827.50574.771598.246570@montanaro.dyndns.org>
	<1299433458.3699.37.camel@localhost.localdomain>
	<19827.62120.276471.798561@montanaro.dyndns.org>
Message-ID: <1299445746.3699.69.camel@localhost.localdomain>


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, skip at 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
> 



From skip at pobox.com  Sun Mar  6 22:10:22 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 6 Mar 2011 15:10:22 -0600
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <4D73F543.2040206@v.loewis.de>
References: <iktsh9$1fl$1@dough.gmane.org>
	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>
	<20110305230335.7505a5e4@pitrou.net>
	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>
	<1299364430.3692.7.camel@localhost.localdomain>
	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>
	<4D72C93C.60705@v.loewis.de> <20110306004449.088cf2f0@pitrou.net>
	<19827.44387.694986.490254@montanaro.dyndns.org>
	<1299426918.3699.13.camel@localhost.localdomain>
	<19827.50574.771598.246570@montanaro.dyndns.org>
	<1299433458.3699.37.camel@localhost.localdomain>
	<19827.62120.276471.798561@montanaro.dyndns.org>
	<4D73F543.2040206@v.loewis.de>
Message-ID: <19827.63550.290294.892855@montanaro.dyndns.org>


    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

From mail at kerrickstaley.com  Sun Mar  6 22:11:07 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Sun, 6 Mar 2011 15:11:07 -0600
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTi=VD8yck7y=Su1a+e-q0mM-49FgTr1iJ-UFPzuv@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>
	<AANLkTi=VD8yck7y=Su1a+e-q0mM-49FgTr1iJ-UFPzuv@mail.gmail.com>
Message-ID: <AANLkTimPEDWCsiOXfq=PpyyPfkbMR-oja54m-CnAQHQh@mail.gmail.com>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/5934db82/attachment.html>
-------------- next part --------------
--- pep-0394.txt	2011-03-05 01:06:50.000000000 -0600
+++ pep-0394-revised.txt	2011-03-06 15:07:42.373333338 -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 <mail at 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

From martin at v.loewis.de  Sun Mar  6 22:36:28 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Mar 2011 22:36:28 +0100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <AANLkTimPEDWCsiOXfq=PpyyPfkbMR-oja54m-CnAQHQh@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>	<AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>	<AANLkTi=VD8yck7y=Su1a+e-q0mM-49FgTr1iJ-UFPzuv@mail.gmail.com>
	<AANLkTimPEDWCsiOXfq=PpyyPfkbMR-oja54m-CnAQHQh@mail.gmail.com>
Message-ID: <4D73FE5C.6010508@v.loewis.de>

> 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

From nad at acm.org  Sun Mar  6 23:06:55 2011
From: nad at acm.org (Ned Deily)
Date: Sun, 06 Mar 2011 14:06:55 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>
	<AANLkTi=VD8yck7y=Su1a+e-q0mM-49FgTr1iJ-UFPzuv@mail.gmail.com>
	<AANLkTimPEDWCsiOXfq=PpyyPfkbMR-oja54m-CnAQHQh@mail.gmail.com>
Message-ID: <nad-00CA51.14065506032011@news.gmane.org>

In article 
<AANLkTimPEDWCsiOXfq=PpyyPfkbMR-oja54m-CnAQHQh at mail.gmail.com>,
 Kerrick Staley <mail at 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,
 nad at acm.org


From fuzzyman at voidspace.org.uk  Mon Mar  7 00:04:31 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 06 Mar 2011 23:04:31 +0000
Subject: [Python-Dev] [PEPs] Support the
	/usr/bin/python2	symlink	upstream
In-Reply-To: <4D73FE5C.6010508@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>	<AANLkTi=VD8yck7y=Su1a+e-q0mM-49FgTr1iJ-UFPzuv@mail.gmail.com>	<AANLkTimPEDWCsiOXfq=PpyyPfkbMR-oja54m-CnAQHQh@mail.gmail.com>
	<4D73FE5C.6010508@v.loewis.de>
Message-ID: <4D7412FF.5020408@voidspace.org.uk>

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 at 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


From tjreedy at udel.edu  Mon Mar  7 00:07:32 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 06 Mar 2011 18:07:32 -0500
Subject: [Python-Dev] CPython hg transition complete
In-Reply-To: <1299433458.3699.37.camel@localhost.localdomain>
References: <iktsh9$1fl$1@dough.gmane.org>	<AANLkTim00n3tSxQExQTDhb1KYcMCRwxubMS2jfbaXZsO@mail.gmail.com>	<20110305230335.7505a5e4@pitrou.net>	<AANLkTinBoogVnCNhi-K6RrKgnRDfC7twNkcQbS9ojg28@mail.gmail.com>	<1299364430.3692.7.camel@localhost.localdomain>	<AANLkTikAs-Y8_S4No20H=zva54o7gzrXd_aBiOrSOEC-@mail.gmail.com>	<4D72C93C.60705@v.loewis.de>
	<20110306004449.088cf2f0@pitrou.net>	<19827.44387.694986.490254@montanaro.dyndns.org>	<1299426918.3699.13.camel@localhost.localdomain>	<19827.50574.771598.246570@montanaro.dyndns.org>
	<1299433458.3699.37.camel@localhost.localdomain>
Message-ID: <il143k$rps$1@dough.gmane.org>

On 3/6/2011 12:44 PM, Antoine Pitrou wrote:
> Le dimanche 06 mars 2011 ? 11:34 -0600, skip at 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



From tjreedy at udel.edu  Mon Mar  7 00:16:20 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 06 Mar 2011 18:16:20 -0500
Subject: [Python-Dev] hg pull failed
In-Reply-To: <il0bfd$96c$1@dough.gmane.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>	<ikto58$dbt$1@dough.gmane.org>	<19827.44006.852917.924065@montanaro.dyndns.org>
	<il0bfd$96c$1@dough.gmane.org>
Message-ID: <il14k6$35k$1@dough.gmane.org>

On 3/6/2011 11:07 AM, Georg Brandl wrote:
> On 06.03.2011 16:44, skip at 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://hg at 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


From tjreedy at udel.edu  Mon Mar  7 00:23:49 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 06 Mar 2011 18:23:49 -0500
Subject: [Python-Dev] r88758 -
	tracker/instances/python-dev/scripts/addpatchsets
In-Reply-To: <20110306174309.3df82503@pitrou.net>
References: <20110306163240.958DBEE981@mail.python.org>
	<20110306174309.3df82503@pitrou.net>
Message-ID: <il1527$4v1$1@dough.gmane.org>

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


From barry at barrys-emacs.org  Mon Mar  7 00:03:53 2011
From: barry at barrys-emacs.org (Barry Scott)
Date: Sun, 6 Mar 2011 23:03:53 +0000
Subject: [Python-Dev] What does the "m" mean for the Mac OS X include folder?
Message-ID: <5AB965C9-7D5F-41B6-A5E9-2B881E92A782@barrys-emacs.org>

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


From ncoghlan at gmail.com  Mon Mar  7 00:52:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 09:52:17 +1000
Subject: [Python-Dev] devguide: More miscellaneous review comments.
In-Reply-To: <20110306180549.39003893@pitrou.net>
References: <E1PwAPH-0006oV-BK@dinsdale.python.org>
	<AANLkTi=kgJ5F8bY6monCH8UE8bHRz1LKwazhpOQduv94@mail.gmail.com>
	<20110306141403.202d12b7@pitrou.net>
	<4D73BBE6.9090805@voidspace.org.uk>
	<20110306180549.39003893@pitrou.net>
Message-ID: <AANLkTi=1dZY=gYSTn26J3c-5LmcOW=A3kqa1d=6WTQoJ@mail.gmail.com>

On Mon, Mar 7, 2011 at 3:05 AM, Antoine Pitrou <solipsis at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From barry at barrys-emacs.org  Mon Mar  7 00:09:20 2011
From: barry at barrys-emacs.org (Barry Scott)
Date: Sun, 6 Mar 2011 23:09:20 +0000
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is this
	documented?
Message-ID: <7DB3E445-223F-45A0-874F-4E6A842C357D@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.

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


From benjamin at python.org  Mon Mar  7 01:00:42 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 6 Mar 2011 18:00:42 -0600
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
Message-ID: <AANLkTimez5oQvP0pV7dt0iTbpfdLTtfJHZZpE3HXxpCz@mail.gmail.com>

2011/3/6 Barry Scott <barry at 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

From ncoghlan at gmail.com  Mon Mar  7 01:08:15 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 10:08:15 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D73CEA0.40006@ubuntu.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D646D.6070506@trueblade.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<4D73CEA0.40006@ubuntu.com>
Message-ID: <AANLkTik74eUrJ0NVVDykzR0rmiFa9hiGWCfBhdRP9z8Z@mail.gmail.com>

On Mon, Mar 7, 2011 at 4:12 AM, Matthias Klose <doko at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Mon Mar  7 01:14:30 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 10:14:30 +1000
Subject: [Python-Dev] hg pull failed
In-Reply-To: <4D73E224.3020102@cadifra.com>
References: <19826.24958.821162.983186@montanaro.dyndns.org>
	<ikto58$dbt$1@dough.gmane.org>
	<19827.44006.852917.924065@montanaro.dyndns.org>
	<il0bfd$96c$1@dough.gmane.org>
	<AANLkTinsPCF6iz_fCw2tD=ZmvErdmsCBOAwuz0Db9hRJ@mail.gmail.com>
	<19827.51276.575501.55448@montanaro.dyndns.org>
	<il0i6q$an7$1@dough.gmane.org> <4D73DBF3.2030904@v.loewis.de>
	<4D73E224.3020102@cadifra.com>
Message-ID: <AANLkTi=cZogAtjAW6GRZCvryKT8X0gByBq4eM+nQ=aMp@mail.gmail.com>

On Mon, Mar 7, 2011 at 5:36 AM, Adrian Buehlmann <adrian at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Mon Mar  7 01:22:38 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 10:22:38 +1000
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
Message-ID: <AANLkTikFw3rpx-G5-QB-0G8r8AyngmNb1aA8C7JcBvGA@mail.gmail.com>

On Mon, Mar 7, 2011 at 9:09 AM, Barry Scott <barry at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From skippy.hammond at gmail.com  Mon Mar  7 02:18:00 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Mon, 07 Mar 2011 12:18:00 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D852F.7010500@v.loewis.de>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
Message-ID: <4D743248.9060705@gmail.com>

On 7/03/2011 1:55 AM, Paul Moore wrote:
> On 6 March 2011 02:33, Mark Hammond<skippy.hammond at 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

From stephen at xemacs.org  Mon Mar  7 02:24:34 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 07 Mar 2011 10:24:34 +0900
Subject: [Python-Dev]  hg diff
In-Reply-To: <4D72CB3A.5090006@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de>
Message-ID: <87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>

"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?


From skippy.hammond at gmail.com  Mon Mar  7 02:26:36 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Mon, 07 Mar 2011 12:26:36 +1100
Subject: [Python-Dev] [PEPs] Support the
	/usr/bin/python2	symlink	upstream
In-Reply-To: <4D7412FF.5020408@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>	<AANLkTi=VD8yck7y=Su1a+e-q0mM-49FgTr1iJ-UFPzuv@mail.gmail.com>	<AANLkTimPEDWCsiOXfq=PpyyPfkbMR-oja54m-CnAQHQh@mail.gmail.com>	<4D73FE5C.6010508@v.loewis.de>
	<4D7412FF.5020408@voidspace.org.uk>
Message-ID: <4D74344C.40108@gmail.com>

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

From martin at v.loewis.de  Mon Mar  7 02:34:52 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 07 Mar 2011 02:34:52 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D74363C.1080607@v.loewis.de>

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

From nad at acm.org  Mon Mar  7 02:46:56 2011
From: nad at acm.org (Ned Deily)
Date: Sun, 06 Mar 2011 17:46:56 -0800
Subject: [Python-Dev] What does the "m" mean for the Mac OS X include
	folder?
References: <5AB965C9-7D5F-41B6-A5E9-2B881E92A782@barrys-emacs.org>
Message-ID: <nad-E4F63B.17465606032011@news.gmane.org>

In article <5AB965C9-7D5F-41B6-A5E9-2B881E92A782 at barrys-emacs.org>,
 Barry Scott <barry at 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,
 nad at acm.org


From stephen at xemacs.org  Mon Mar  7 03:43:23 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 07 Mar 2011 11:43:23 +0900
Subject: [Python-Dev] hg diff
In-Reply-To: <4D74363C.1080607@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
Message-ID: <8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>

"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.



From tjreedy at udel.edu  Mon Mar  7 03:50:20 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 06 Mar 2011 21:50:20 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D743248.9060705@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTiki
	GWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com>
Message-ID: <il1h5d$lie$1@dough.gmane.org>

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


From tjreedy at udel.edu  Mon Mar  7 03:56:57 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 06 Mar 2011 21:56:57 -0500
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
	this documented?
In-Reply-To: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
Message-ID: <il1hhr$mrr$1@dough.gmane.org>

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


From v+python at g.nevcal.com  Mon Mar  7 05:30:12 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Sun, 06 Mar 2011 20:30:12 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>
	<4D72F267.3050204@gmail.com>	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>	<4D7387CF.6070104@skippinet.com.au>	<AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>
	<AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>
Message-ID: <4D745F54.6060001@g.nevcal.com>

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", as it is purely up to the launcher/wrapper program to interpret 
it.  This complicates the wrapper script, as it would have to examine 
the registry to find the particular location of Python, and tightly 
binds it to Python usage only.


I like (B3) best, now that I've thought of it, although I implemented a 
form of (B2) in a private copy of http.server so I could have a 
cross-platform CGI script.

(B2) and (B3) also allow the wrapper to be configured to work for 
similar things for other scripting languages, which also have 
cross-platform problems similar to Python.  All the user would have to 
do is put the extra #!/#@ line in, and associate that extension with the 
wrapper.

By default, for Python, the wrapper would get associated only with .py 
files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/5ec15b80/attachment.html>

From martin at v.loewis.de  Mon Mar  7 05:32:24 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 07 Mar 2011 05:32:24 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D745FD8.9000202@v.loewis.de>

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

From mail at kerrickstaley.com  Mon Mar  7 06:02:04 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Sun, 6 Mar 2011 23:02:04 -0600
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D745F54.6060001@g.nevcal.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>
	<4D7387CF.6070104@skippinet.com.au>
	<AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>
	<AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>
	<4D745F54.6060001@g.nevcal.com>
Message-ID: <AANLkTingkJczX708xC4NM26nOyBGfB_i-xgdCAGYvFKA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110306/1588a866/attachment.html>

From skippy.hammond at gmail.com  Mon Mar  7 06:19:13 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Mon, 07 Mar 2011 16:19:13 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D745F54.6060001@g.nevcal.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>	<4D7387CF.6070104@skippinet.com.au>	<AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>	<AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>
	<4D745F54.6060001@g.nevcal.com>
Message-ID: <4D746AD1.7040801@gmail.com>

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

From ncoghlan at gmail.com  Mon Mar  7 06:32:58 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 15:32:58 +1000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTingkJczX708xC4NM26nOyBGfB_i-xgdCAGYvFKA@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>
	<4D7387CF.6070104@skippinet.com.au>
	<AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>
	<AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>
	<4D745F54.6060001@g.nevcal.com>
	<AANLkTingkJczX708xC4NM26nOyBGfB_i-xgdCAGYvFKA@mail.gmail.com>
Message-ID: <AANLkTimC1PTdRbJw6N=-9YhKOKkAuWE5D6ZDMBp6JQCV@mail.gmail.com>

On Mon, Mar 7, 2011 at 3:02 PM, Kerrick Staley <mail at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Mon Mar  7 06:34:44 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 15:34:44 +1000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D746AD1.7040801@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>
	<4D7387CF.6070104@skippinet.com.au>
	<AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>
	<AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>
	<4D745F54.6060001@g.nevcal.com> <4D746AD1.7040801@gmail.com>
Message-ID: <AANLkTikF9pHMBxHpWycL0gQ2A7xZ1ZJJnsMdoMbu5P+t@mail.gmail.com>

On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammond <skippy.hammond at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From mhammond at skippinet.com.au  Mon Mar  7 06:34:54 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 07 Mar 2011 16:34:54 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTikF9pHMBxHpWycL0gQ2A7xZ1ZJJnsMdoMbu5P+t@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>	<4D7387CF.6070104@skippinet.com.au>	<AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>	<AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>	<4D745F54.6060001@g.nevcal.com>	<4D746AD1.7040801@gmail.com>
	<AANLkTikF9pHMBxHpWycL0gQ2A7xZ1ZJJnsMdoMbu5P+t@mail.gmail.com>
Message-ID: <4D746E7E.6080006@skippinet.com.au>

On 7/03/2011 4:34 PM, Nick Coghlan wrote:
> On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammond<skippy.hammond at 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

From g.brandl at gmx.net  Mon Mar  7 08:16:17 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 07 Mar 2011 08:16:17 +0100
Subject: [Python-Dev] hg pull failed
In-Reply-To: <il14k6$35k$1@dough.gmane.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>	<ikto58$dbt$1@dough.gmane.org>	<19827.44006.852917.924065@montanaro.dyndns.org>
	<il0bfd$96c$1@dough.gmane.org> <il14k6$35k$1@dough.gmane.org>
Message-ID: <il20o9$eut$1@dough.gmane.org>

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, skip at 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://hg at 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...


From john at arbash-meinel.com  Mon Mar  7 09:36:01 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Mon, 07 Mar 2011 09:36:01 +0100
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <il1hhr$mrr$1@dough.gmane.org>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
	<il1hhr$mrr$1@dough.gmane.org>
Message-ID: <4D7498F1.3070602@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/7/2011 3:56 AM, Terry Reedy wrote:
> 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.
> 

It might be interesting to just have a stub entry with:

  PyCObject_AsVoidPtr (This was deleted in 3.2, last available in [3.1])

Might end up being too cluttered, but certainly helps the people who hit
the problem.

Especially since, AIUI, deprecations are suppressed by default now.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk10mPEACgkQJdeBCYSNAAMNCwCfUIm79vsW7KSuibBRLZUFA4P2
VooAn1Muo6yeciMBSO+ndlaq10VE5lxV
=ewPb
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Mon Mar  7 10:05:56 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 07 Mar 2011 10:05:56 +0100
Subject: [Python-Dev] Codereview on bugs.python.org ready for testing again
Message-ID: <4D749FF4.7080400@v.loewis.de>

I ported the code review support on bugs.python.org to hg,
and reactivated it. Review "issues" are created automatically
if the attached file is recognized as a patch that applies
cleanly. The roundup issue's nosy list is synchronized with the
rietveld issue's cc list, so comments get mailed to the nosy
list.

If there are any problems with that installation, please report
them to the meta tracker.

Regards,
Martin

From merwok at netwok.org  Mon Mar  7 10:05:46 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 07 Mar 2011 10:05:46 +0100
Subject: [Python-Dev] [Python-checkins] r88709 - in
 python/branches/py3k: Misc/NEWS Objects/unicodeobject.c
In-Reply-To: <20110302010314.642AEEE983@mail.python.org>
References: <20110302010314.642AEEE983@mail.python.org>
Message-ID: <4D749FEA.6080504@netwok.org>

Hi,

> Author: victor.stinner
> Date: Wed Mar  2 02:03:14 2011
> New Revision: 88709
> Log: Issue #8923: cache str.encode() result
> 
> When a string is encoded to UTF-8 in strict mode, the result is cached into the
> object. Examples: str.encode(), str.encode('utf-8'), PyUnicode_AsUTF8String()
> and PyUnicode_AsEncodedString(unicode, "utf-8", NULL).

I don?t really understand this message (especially ?cached into the
object?) :)  Maybe in the Misc/NEWS entry you could also add a line to
explain to users the reason/goal/benefit of this change?

Regards

From ncoghlan at gmail.com  Mon Mar  7 10:14:55 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2011 19:14:55 +1000
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <4D7498F1.3070602@arbash-meinel.com>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
	<il1hhr$mrr$1@dough.gmane.org> <4D7498F1.3070602@arbash-meinel.com>
Message-ID: <AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>

On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
>
> Especially since, AIUI, deprecations are suppressed by default now.

True, but developers are expected to run their tests with them enabled.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Mon Mar  7 10:33:17 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 07 Mar 2011 10:33:17 +0100
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>	<il1hhr$mrr$1@dough.gmane.org>
	<4D7498F1.3070602@arbash-meinel.com>
	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
Message-ID: <4D74A65D.40105@v.loewis.de>

Am 07.03.2011 10:14, schrieb Nick Coghlan:
> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
> <john at arbash-meinel.com>  wrote:
>>
>> Especially since, AIUI, deprecations are suppressed by default now.
>
> True, but developers are expected to run their tests with them enabled.

I think everything here is as it should be. People who really cared
about forwards compatibility could have known, but factually, most
people don't care enough. Those then learn for the first time that
some feature was deprecated after it is actually removed. They then
ask why it is removed, and somebody will tell them.

The OP is actually wrong that this isn't documented in "what's new";
there is an item about it in the "porting to 3.2" section.

Regards,
Martin

From stefan_ml at behnel.de  Mon Mar  7 10:41:43 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 07 Mar 2011 10:41:43 +0100
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
	this documented?
In-Reply-To: <4D7498F1.3070602@arbash-meinel.com>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>	<il1hhr$mrr$1@dough.gmane.org>
	<4D7498F1.3070602@arbash-meinel.com>
Message-ID: <il298n$nem$1@dough.gmane.org>

John Arbash Meinel, 07.03.2011 09:36:
> On 3/7/2011 3:56 AM, Terry Reedy wrote:
>> 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.
>>
>
> It might be interesting to just have a stub entry with:
>
>    PyCObject_AsVoidPtr (This was deleted in 3.2, last available in [3.1])
>
> Might end up being too cluttered, but certainly helps the people who hit
> the problem.

-1. When you do a search for the function on docs.python.org, you will see 
where it's being documented. Then, click on the latest version that has it 
and find the deprecation notice.

Searching will also likely let you run into the "What's new" documents that 
mention its deprecation and removal.

Stefan


From p.f.moore at gmail.com  Mon Mar  7 11:33:48 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 7 Mar 2011 10:33:48 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D743248.9060705@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com>
Message-ID: <AANLkTimf6X7X6csQ9a2gbbJUGt2GEsqAVJyz9qqNGP2G@mail.gmail.com>

On 7 March 2011 01:18, Mark Hammond <skippy.hammond at gmail.com> wrote:
> 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.

That sounds like a fairly cool idea. So if I follow what you're
suggesting, we'd have a single python.exe, probably installed in
system32, which did the necessary command line juggling and shebang
parsing, then simply redirected to the appropriate Python interpreter?
Presumably that launcher would be pretty version independent, so (a)
the one that gets installed with Python 3.3 would support older
versions even though they didn't include the launcher themselves, (b)
overwriting the launcher when a new version of Python is installed
wouldn't be too big a deal, and (c) it could be released as a
standalone package for people with only older versions of Python
installed?

I like this idea. If I had the spare time (I don't :-() I'd work on this myself.

+1 from me.

Paul.

From mhammond at skippinet.com.au  Mon Mar  7 11:49:24 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 07 Mar 2011 21:49:24 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTimf6X7X6csQ9a2gbbJUGt2GEsqAVJyz9qqNGP2G@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com>
	<AANLkTimf6X7X6csQ9a2gbbJUGt2GEsqAVJyz9qqNGP2G@mail.gmail.com>
Message-ID: <4D74B834.905@skippinet.com.au>

On 7/03/2011 9:33 PM, Paul Moore wrote:
> That sounds like a fairly cool idea. So if I follow what you're
> suggesting, we'd have a single python.exe, probably installed in
> system32, which did the necessary command line juggling and shebang
> parsing, then simply redirected to the appropriate Python interpreter?
> Presumably that launcher would be pretty version independent, so (a)
> the one that gets installed with Python 3.3 would support older
> versions even though they didn't include the launcher themselves, (b)
> overwriting the launcher when a new version of Python is installed
> wouldn't be too big a deal, and (c) it could be released as a
> standalone package for people with only older versions of Python
> installed?

Yup - although I think a pythonw.exe launcher would be needed too (for 
the same reasons we need python.exe and pythonw.exe today)

> I like this idea. If I had the spare time (I don't :-() I'd work on this myself.
>
> +1 from me.

Cool - I may have a go at this over the next few weekends... :)

Cheers,

Mark

From victor.stinner at haypocalc.com  Mon Mar  7 11:54:05 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Mon, 07 Mar 2011 11:54:05 +0100
Subject: [Python-Dev] [Python-checkins] r88709 - in
 python/branches/py3k: Misc/NEWS Objects/unicodeobject.c
In-Reply-To: <4D749FEA.6080504@netwok.org>
References: <20110302010314.642AEEE983@mail.python.org>
	<4D749FEA.6080504@netwok.org>
Message-ID: <1299495245.9793.4.camel@marge>

Le lundi 07 mars 2011 ? 10:05 +0100, ?ric Araujo a ?crit :
> Hi,
> 
> > Author: victor.stinner
> > Date: Wed Mar  2 02:03:14 2011
> > New Revision: 88709
> > Log: Issue #8923: cache str.encode() result
> > 
> > When a string is encoded to UTF-8 in strict mode, the result is cached into the
> > object. Examples: str.encode(), str.encode('utf-8'), PyUnicode_AsUTF8String()
> > and PyUnicode_AsEncodedString(unicode, "utf-8", NULL).
> 
> I don?t really understand this message (especially ?cached into the
> object?) :)  Maybe in the Misc/NEWS entry you could also add a line to
> explain to users the reason/goal/benefit of this change?

If you call str.encode() twice: the first call stores the result in a
cache, and the second call just reuse the cache. The benefit is that the
second call is much faster.

The cache is an internal attribute of the Unicode object (str type).

Do you have a suggestion to rephrase the Misc/NEWS entry?

PS: The Unicode object did already use this cache, but not always (eg.
not for str.encode() or str.encode('utf-8')).

Victor


From mail at timgolden.me.uk  Mon Mar  7 12:01:10 2011
From: mail at timgolden.me.uk (Tim Golden)
Date: Mon, 07 Mar 2011 11:01:10 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D74B834.905@skippinet.com.au>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>
	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<AANLkTimf6X7X6csQ9a2gbbJUGt2GEsqAVJyz9qqNGP2G@mail.gmail.com>
	<4D74B834.905@skippinet.com.au>
Message-ID: <4D74BAF6.3040307@timgolden.me.uk>

On 07/03/2011 10:49, Mark Hammond wrote:
> On 7/03/2011 9:33 PM, Paul Moore wrote:
>> That sounds like a fairly cool idea. So if I follow what you're
>> suggesting, we'd have a single python.exe, probably installed in
>> system32, which did the necessary command line juggling and shebang
>> parsing, then simply redirected to the appropriate Python interpreter?
>> Presumably that launcher would be pretty version independent, so (a)
>> the one that gets installed with Python 3.3 would support older
>> versions even though they didn't include the launcher themselves, (b)
>> overwriting the launcher when a new version of Python is installed
>> wouldn't be too big a deal, and (c) it could be released as a
>> standalone package for people with only older versions of Python
>> installed?
>
> Yup - although I think a pythonw.exe launcher would be needed too (for
> the same reasons we need python.exe and pythonw.exe today)
>
>> I like this idea. If I had the spare time (I don't :-() I'd work on
>> this myself.
>>
>> +1 from me.

Agreed all round. In the highly unlikely event that I find
some time I too might have a play with the idea. The devil
will undoubtedly be in the details. I've implemented
a Pure-python version of this before, but found it unacceptably
slow for anything but ad-hoc use. Still, it was useful for
that :)

TJG

From vinay_sajip at yahoo.co.uk  Mon Mar  7 12:40:04 2011
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Mon, 7 Mar 2011 11:40:04 +0000 (UTC)
Subject: [Python-Dev] Unable to build old version from hg.python.org
Message-ID: <loom.20110307T122910-430@post.gmane.org>

I want to maintain several working copies, as sometimes I have to make bugfix
changes across several revisions. Since we are supposed to use forward-porting,
I tried to set up a 2.5 clone, but building from it fails with a "Fatal Python
error: subversion keywords missing".

What I did (in ~/projects/python):

hg clone ssh://hg at hg.python.org/cpython default
hg clone default 2.5
cd 2.5
hg update 2.5
./configure
make

Failing command:
-------------------------------------
gcc -pthread  -Xlinker -export-dynamic -o python \
			Modules/python.o \
			libpython2.5.a -lpthread -ldl  -lutil   -lm  
libpython2.5.a(posixmodule.o): In function `posix_tmpnam':
/home/vinay/projects/python/2.5/./Modules/posixmodule.c:6858: warning: the use
of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.5.a(posixmodule.o): In function `posix_tempnam':
/home/vinay/projects/python/2.5/./Modules/posixmodule.c:6813: warning: the use
of `tempnam' is dangerous, better use `mkstemp'
case $MAKEFLAGS in \
	*-s*)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
	*)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv
-O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
	esac
Fatal Python error: subversion keywords missing
Aborted
-------------------------------------

BTW, this is happening on my Ubuntu Jaunty machine which I have been using for
many months with the Subversion repository.

Am I doing something wrong?

Regards,

Vinay Sajip


From ronaldoussoren at mac.com  Mon Mar  7 12:52:26 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 07 Mar 2011 12:52:26 +0100
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110304185645.7DB6424778F@kimball.webabinitio.net>
References: <78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
	<20110304185645.7DB6424778F@kimball.webabinitio.net>
Message-ID: <E46123C2-E040-4419-898E-4AA3E1021B73@mac.com>


On 4 Mar, 2011, at 19:56, R. David Murray wrote:

> On Fri, 04 Mar 2011 15:50:01 +0000, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> On 04 Mar, 2011,at 02:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 
>> For *nix, I think there is a simple way forward that is an improvement
>> over where things stand now. For Windows, I don't think we can do much
>> better than the status quo and for Mac OS X... I think Apple will do
>> whatever Apple feel like doing :)
>> 
>> Apple will generally follow what we decide to do for the base install.
>> 
>> Anyway, I'd say that OSX should do the same as Unix platforms here and support
>> '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.
> 
> FYI, Ronald, the text version of your emails looses all quoting
> information.  It would be nice if you could use standard email
> quoting (leading '>' characters).

Sorry about this, I keep forgetting how crummy the webmail interface of mobileme is in that regard.

> 
>> P.S. I'm a bit confused about this discussion though, wouldn't adding python2 to
>> the installation be a feature change and as such not something that can be done
>> in a maintenance branch?
> 
> The purpose of the "no new features" rule is to prevent the situation
> where a piece of code written for X.X.2 fails to run on X.X.1 because
> it relies on a feature introduced in X.X.2.  In this situation, we
> *already* have failures because scripts using /usr/bin/python2 that
> run on one distro won't run on a different distro where that symlink
> isn't defined.  In this case I don't think the "no new features" rule
> can be applied blindly, because the feature has *already been introduced*
> by third parties.  What we are attempting to do is make it *more* likely
> that things will work in the future.

This is a new feature for the cannonical distribution, no release on python.org will install a binary named 'python2'. Adding one now will result in a clear change in behaviour: "#!/usr/bin/env python2" will work in 2.7.2 while it won't work with 2.7.1. That it happens to work right now with some python distributions doesn't mean this isn't a new feature, it's just another instance where the linux distribution maintainers think they know better than the developers.


> 
> You can argue that having /usr/bin/python2 installed by 2.7.2 means
> that code written for 2.7.2 that relies on it won't run on a vanilla
> user-install of 2.7.1 or 2.7.  But how likely is that scenario compared
> to the scenario where a script written for another distro fails to run
> because /usr/bin/python2 doesn't exist?  I think the balance of the
> argument comes down in favor of making the change, personally.

That depends on the distributions that have /usr/bin/python2 and change /usr/bin/python to be python3. IIRC the discussion only mentioned Arch Linux and Gentoo, which are AFAIK not major distributions. I'm personally unlikely to run into a distribution that has a broken /usr/bin/python anytime soon, most linux code I write runs on enterprise distributions and those aren't known for being frontrunners with changes like this ;-)

BTW. I'm +0 on the change, having python2 can be useful and while this is a new feature it doesn't require major changes when backporting scripts to previous patchlevels.

Ronald


From vinay_sajip at yahoo.co.uk  Mon Mar  7 12:57:49 2011
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Mon, 7 Mar 2011 11:57:49 +0000 (UTC)
Subject: [Python-Dev] Unable to build old version from hg.python.org
References: <loom.20110307T122910-430@post.gmane.org>
Message-ID: <loom.20110307T125720-141@post.gmane.org>

OK, I see issue 11421 on the tracker.


From merwok at netwok.org  Mon Mar  7 15:36:38 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 07 Mar 2011 15:36:38 +0100
Subject: [Python-Dev] [Python-checkins] devguide: More miscellaneous
 review comments.
In-Reply-To: <AANLkTi=kgJ5F8bY6monCH8UE8bHRz1LKwazhpOQduv94@mail.gmail.com>
References: <E1PwAPH-0006oV-BK@dinsdale.python.org>
	<AANLkTi=kgJ5F8bY6monCH8UE8bHRz1LKwazhpOQduv94@mail.gmail.com>
Message-ID: <4D74ED76.2040005@netwok.org>

> For non-Windows, get people to run "make patchcheck".
The non-non-Windows equivalent should be something like ?./python.exe
Tools/scripts/patchcheck.py? (I don?t remember if the leading ./ is
required).

FTR, what the make target is a bit more complicated:
?$(RUNSHARED) ./$(BUILDPYTHON) $(srcdir)/Tools/scripts/patchcheck.py?

Cheers

From solipsis at pitrou.net  Mon Mar  7 15:47:18 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Mar 2011 15:47:18 +0100
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
	<il1hhr$mrr$1@dough.gmane.org> <4D7498F1.3070602@arbash-meinel.com>
	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
Message-ID: <20110307154718.27a22edb@pitrou.net>

On Mon, 7 Mar 2011 19:14:55 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
> <john at arbash-meinel.com> wrote:
> >
> > Especially since, AIUI, deprecations are suppressed by default now.
> 
> True, but developers are expected to run their tests with them enabled.

Where do we actually document this?



From merwok at netwok.org  Mon Mar  7 15:54:20 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 07 Mar 2011 15:54:20 +0100
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into
 Python 3.3)
In-Reply-To: <AANLkTim-0eT8Ph+99Hhfoy8XkxxTLxCs+ACmKkabLhpE@mail.gmail.com>
References: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>	<AANLkTimkQHFEPXa9gkLb8b+ubTzQfhuw+kt9B+uE8HAC@mail.gmail.com>
	<AANLkTim-0eT8Ph+99Hhfoy8XkxxTLxCs+ACmKkabLhpE@mail.gmail.com>
Message-ID: <4D74F19C.4030608@netwok.org>

Hi,

> Roadmap is not a strict plan for release. It helps people
> *self-organize into teams* around specific feature or bugs.
I think the tracker is used to this effect with success.

> Yes, there can (or even should) be a way for everybody with Python
> account to vote on items in the Roadmap
Doing something is a good way to vote.  For example, on #2504, a number
of people added ?+1? comments, but when I tried to move the patch
forward and asked for tests and reviews, nobody replied.  Votes without
commitment take time away from developers and don?t help with the work.

On the other hand, it is useful to get the feel of the community to know
what bugs or features are really desired by our users.  If someone tried
to create and maintain a roadmap, I?d be interested in the results.

Regards

From solipsis at pitrou.net  Mon Mar  7 15:49:52 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Mar 2011 15:49:52 +0100
Subject: [Python-Dev] Unable to build old version from hg.python.org
References: <loom.20110307T122910-430@post.gmane.org>
Message-ID: <20110307154952.23a89d03@pitrou.net>

On Mon, 7 Mar 2011 11:40:04 +0000 (UTC)
Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> I want to maintain several working copies, as sometimes I have to make bugfix
> changes across several revisions. Since we are supposed to use forward-porting,
> I tried to set up a 2.5 clone,

Vinay, 2.5 has been long closed for bug fixes. You should target 2.7.

Thanks

Antoine.



From arfrever.fta at gmail.com  Mon Mar  7 16:01:52 2011
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 7 Mar 2011 16:01:52 +0100
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
	this documented?
In-Reply-To: <4D74A65D.40105@v.loewis.de>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
	<4D74A65D.40105@v.loewis.de>
Message-ID: <201103071602.21772.Arfrever.FTA@gmail.com>

2011-03-07 10:33:17 Martin v. L?wis napisa?(a):
> Am 07.03.2011 10:14, schrieb Nick Coghlan:
> > On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
> > <john at arbash-meinel.com>  wrote:
> >>
> >> Especially since, AIUI, deprecations are suppressed by default now.
> >
> > True, but developers are expected to run their tests with them enabled.
> 
> I think everything here is as it should be.

IMHO cobject.h should have been declaring deprecated functions with Py_DEPRECATED,
which would cause build-time deprecation warnings.

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/b11f8846/attachment.pgp>

From anikom15 at gmail.com  Mon Mar  7 15:59:39 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Mon, 07 Mar 2011 06:59:39 -0800
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into
 Python 3.3)
In-Reply-To: <4D74F19C.4030608@netwok.org>
References: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
	<AANLkTimkQHFEPXa9gkLb8b+ubTzQfhuw+kt9B+uE8HAC@mail.gmail.com>
	<AANLkTim-0eT8Ph+99Hhfoy8XkxxTLxCs+ACmKkabLhpE@mail.gmail.com>
	<4D74F19C.4030608@netwok.org>
Message-ID: <1299509979.8549.0.camel@localhost.localdomain>

On Mon, 2011-03-07 at 15:54 +0100, ?ric Araujo wrote:
> Hi,
> 
> > Roadmap is not a strict plan for release. It helps people
> > *self-organize into teams* around specific feature or bugs.
> I think the tracker is used to this effect with success.
> 
> > Yes, there can (or even should) be a way for everybody with Python
> > account to vote on items in the Roadmap
> Doing something is a good way to vote.  For example, on #2504, a number
> of people added ?+1? comments, but when I tried to move the patch
> forward and asked for tests and reviews, nobody replied.  Votes without
> commitment take time away from developers and don?t help with the work.
> 
> On the other hand, it is useful to get the feel of the community to know
> what bugs or features are really desired by our users.  If someone tried
> to create and maintain a roadmap, I?d be interested in the results.
> 
> Regards
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/anikom15%40gmail.com

+1 for voting


From skip at pobox.com  Mon Mar  7 16:15:33 2011
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 7 Mar 2011 09:15:33 -0600
Subject: [Python-Dev] Codereview on bugs.python.org ready for testing
 again
In-Reply-To: <4D749FF4.7080400@v.loewis.de>
References: <4D749FF4.7080400@v.loewis.de>
Message-ID: <19828.63125.659829.248745@montanaro.dyndns.org>


    Martin> I ported the code review support on bugs.python.org to hg, and
    Martin> reactivated it. Review "issues" are created automatically if the
    Martin> attached file is recognized as a patch that applies cleanly. The
    Martin> roundup issue's nosy list is synchronized with the rietveld
    Martin> issue's cc list, so comments get mailed to the nosy list.

What should I be looking for?  For example, this issue:

    http://bugs.python.org/issue11205

contains a patch but I don't see anything which looks like "create a
review".

Thx,

Skip


From skip at pobox.com  Mon Mar  7 16:18:57 2011
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 7 Mar 2011 09:18:57 -0600
Subject: [Python-Dev] Unable to build old version from hg.python.org
In-Reply-To: <loom.20110307T122910-430@post.gmane.org>
References: <loom.20110307T122910-430@post.gmane.org>
Message-ID: <19828.63329.962092.805354@montanaro.dyndns.org>


    Vinay> I want to maintain several working copies, as sometimes I have to
    Vinay> make bugfix changes across several revisions. Since we are
    Vinay> supposed to use forward-porting, I tried to set up a 2.5 clone,
    Vinay> but building from it fails with a "Fatal Python error: subversion
    Vinay> keywords missing".

I encountered the same problem.  My "solution" was to manually expand the
$HeadURL$ string at the top of posixmodule.c as it would have been expanded
by Subversion.  I then committed that locally.

Skip

From brian.curtin at gmail.com  Mon Mar  7 16:19:40 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Mon, 7 Mar 2011 09:19:40 -0600
Subject: [Python-Dev] Codereview on bugs.python.org ready for testing
	again
In-Reply-To: <19828.63125.659829.248745@montanaro.dyndns.org>
References: <4D749FF4.7080400@v.loewis.de>
	<19828.63125.659829.248745@montanaro.dyndns.org>
Message-ID: <AANLkTinxjUeUO=7VmZoS0B4TapLZ08QFO+DKpKBJrq-A@mail.gmail.com>

On Mon, Mar 7, 2011 at 09:15, <skip at pobox.com> wrote:

>
>    Martin> I ported the code review support on bugs.python.org to hg, and
>    Martin> reactivated it. Review "issues" are created automatically if the
>    Martin> attached file is recognized as a patch that applies cleanly. The
>    Martin> roundup issue's nosy list is synchronized with the rietveld
>    Martin> issue's cc list, so comments get mailed to the nosy list.
>
> What should I be looking for?  For example, this issue:
>
>    http://bugs.python.org/issue11205
>
> contains a patch but I don't see anything which looks like "create a
> review".


The review was already created. Look to the left of the Remove button.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/533f942b/attachment-0001.html>

From barry at python.org  Mon Mar  7 16:30:19 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 7 Mar 2011 10:30:19 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110304200043.GG3275@unaka.lan>
References: <4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
	<20110303170804.GD3275@unaka.lan>
	<20110303214623.64e880ba@neurotica.wooz.org>
	<20110304043707.GF3275@unaka.lan>
	<20110304135639.2bef9975@neurotica.wooz.org>
	<20110304200043.GG3275@unaka.lan>
Message-ID: <20110307103019.32fb7a9c@neurotica.wooz.org>

On Mar 04, 2011, at 12:00 PM, Toshio Kuratomi wrote:

>Actually, my post was saying that these two can be decoupled.  ie: It's
>possible to not have /usr/bin/python while still allowing users to type
>python at a shell prompt and get the interpreter.
>
>This is done by either redefining the PATH to include the directory that the
>interpreter named "python" is in or by creating an alias for python to the
>proper interpreter.

I personally would prefer aliasing rather than $PATH manipulation.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/7ff36887/attachment.pgp>

From vinay_sajip at yahoo.co.uk  Mon Mar  7 17:00:41 2011
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Mon, 7 Mar 2011 16:00:41 +0000 (UTC)
Subject: [Python-Dev] Unable to build old version from hg.python.org
References: <loom.20110307T122910-430@post.gmane.org>
	<20110307154952.23a89d03@pitrou.net>
Message-ID: <loom.20110307T165653-496@post.gmane.org>

Antoine Pitrou <solipsis <at> pitrou.net> writes:

> 
> Vinay, 2.5 has been long closed for bug fixes. You should target 2.7.
> 

I understand that - I was only doing it as a forward-porting exercise as per
your suggestion on another thread about merge flow:

- on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain 2.5)
- on the other hand: 3.1 -> 3.2 -> default

As it happens, the fix I'm doing won't apply to 2.5 anyway, so it doesn't matter.

Regards,

Vinay Sajip




From skip at pobox.com  Mon Mar  7 17:23:02 2011
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 7 Mar 2011 10:23:02 -0600
Subject: [Python-Dev] Unable to build old version from hg.python.org
In-Reply-To: <loom.20110307T165653-496@post.gmane.org>
References: <loom.20110307T122910-430@post.gmane.org>
	<20110307154952.23a89d03@pitrou.net>
	<loom.20110307T165653-496@post.gmane.org>
Message-ID: <19829.1638.799325.945481@montanaro.dyndns.org>


    >> Vinay, 2.5 has been long closed for bug fixes. You should target 2.7.

But it wasn't a bug in 2.5 per se, it was a bug introduced by the migration
from Subversion to Mercurial.  Perhaps Mercurial could be trained to expand
the $HeadURL$ string appropriately.  Failing that, I don't see any great
harm in expanding that string and checking it in, simply to avoid this
problem in the future.  I'm sure there are plenty of developers maintaining
external code which is still supposed to be 2.5-compatible.

Skip

From guido at python.org  Mon Mar  7 17:43:01 2011
From: guido at python.org (Guido van Rossum)
Date: Mon, 7 Mar 2011 08:43:01 -0800
Subject: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into
	Python 3.3)
In-Reply-To: <1299509979.8549.0.camel@localhost.localdomain>
References: <AANLkTim5PCjMY2bPLi9Wn8rn-ydEVtMD29H7WUATgp=Z@mail.gmail.com>
	<AANLkTimkQHFEPXa9gkLb8b+ubTzQfhuw+kt9B+uE8HAC@mail.gmail.com>
	<AANLkTim-0eT8Ph+99Hhfoy8XkxxTLxCs+ACmKkabLhpE@mail.gmail.com>
	<4D74F19C.4030608@netwok.org>
	<1299509979.8549.0.camel@localhost.localdomain>
Message-ID: <AANLkTikECM7bfcx24wc5nEhfpE9yBPZvQkCnxLCru+3m@mail.gmail.com>

On Mon, Mar 7, 2011 at 6:59 AM, Westley Mart?nez <anikom15 at gmail.com> wrote:
> +1 for voting

Can we call it something else though? "Voting" reminds me too much of
situations where people who don't do anything get to say what they
want others to do. That doesn't sit well in a volunteer-run open
source project.

But it makes total sense to have e.g. the users of the language
express their needs or desires in a way that can guide volunteers
looking for a project in their selection of the most important goals.
For this some kind of "poll" makes sense -- the outcome is not binding
and the assumption is that only a small representation of users
express an opinion, but polls (when used properly) can still be very
useful.

As long as other forms of feedback aren't suppressed of frowned upon
-- not every need can conveniently be expressed in a binary choice.

-- 
--Guido van Rossum (python.org/~guido)

From tseaver at palladion.com  Mon Mar  7 17:44:55 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 07 Mar 2011 11:44:55 -0500
Subject: [Python-Dev] hg diff
In-Reply-To: <4D745FD8.9000202@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de>
Message-ID: <il3228$56i$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/2011 11:32 PM, "Martin v. L?wis" wrote:
> 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.

If we can get to a mode where non-committers can push to a "fork" on
hg.python.org, we can dodge the patch format issue by having folks post
"pull requests" for that fork instaed.

For the repoze and pylons projects, we have found the quality and
quantity of patches went up *significantly* when we made it easy for
somebody who doesn't work on the code all the time to use this workflow
(fork to a public repo, clone, hack, commit, push, request a pull).


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk11C4cACgkQ+gerLs4ltQ78JwCfSwyPfJHu1C7q25o54EIoOS7L
UrQAoIgNlPmes31eHEIQo1hEkoXxCbL2
=/+0X
-----END PGP SIGNATURE-----


From barry at python.org  Mon Mar  7 18:04:18 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 7 Mar 2011 12:04:18 -0500
Subject: [Python-Dev] hg diff
In-Reply-To: <il3228$56i$1@dough.gmane.org>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
Message-ID: <20110307120418.16dc0cd1@neurotica.wooz.org>

On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:

>If we can get to a mode where non-committers can push to a "fork" on
>hg.python.org, we can dodge the patch format issue by having folks post
>"pull requests" for that fork instaed.
>
>For the repoze and pylons projects, we have found the quality and
>quantity of patches went up *significantly* when we made it easy for
>somebody who doesn't work on the code all the time to use this workflow
>(fork to a public repo, clone, hack, commit, push, request a pull).

+1.  'Branches' are better than patches.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/dd9794d8/attachment.pgp>

From sridhar.ratna at gmail.com  Mon Mar  7 18:21:14 2011
From: sridhar.ratna at gmail.com (Sridhar Ratnakumar)
Date: Mon, 7 Mar 2011 09:21:14 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
 upstream
In-Reply-To: <AANLkTi=u=8ikkdxuFKQ3_9QnvTavoiZTD0J1hDMcaa9A@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<20110301222148.49F91249CF7@kimball.webabinitio.net>
	<4D6D852F.7010500@v.loewis.de>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<4D73C762.1050802@voidspace.org.uk>
	<AANLkTi=u=8ikkdxuFKQ3_9QnvTavoiZTD0J1hDMcaa9A@mail.gmail.com>
Message-ID: <28BE15FAC0454F529E197111F0511355@gmail.com>


On Sunday, March 6, 2011 at 9:53 AM, Brian Curtin wrote: 
> On Sun, Mar 6, 2011 at 11:41, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> - Hide quoted message -
> > 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?
> 
 ActivePython for Windows includes the following binaries on Windows: 

* python.exe
* python3.2.exe
* python3.xe 
(plus the `pythonw` versions)

python3.2.exe is better than python32.exe because that matches the invocation (eg: "python3.2 -m foo") on Unix.

Similarly for 2.x (python2.exe / python2.7.exe).

All of this is particularly useful if the installer adds Python directory to %PATH% (which is the case for ActivePython, but not the one from python.org).

-srid 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/901dc25f/attachment.html>

From solipsis at pitrou.net  Mon Mar  7 18:31:12 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Mar 2011 18:31:12 +0100
Subject: [Python-Dev] hg diff
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
Message-ID: <20110307183112.3ff1e7c9@pitrou.net>

On Mon, 7 Mar 2011 12:04:18 -0500
Barry Warsaw <barry at python.org> wrote:
> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
> 
> >If we can get to a mode where non-committers can push to a "fork" on
> >hg.python.org, we can dodge the patch format issue by having folks post
> >"pull requests" for that fork instaed.
> >
> >For the repoze and pylons projects, we have found the quality and
> >quantity of patches went up *significantly* when we made it easy for
> >somebody who doesn't work on the code all the time to use this workflow
> >(fork to a public repo, clone, hack, commit, push, request a pull).
> 
> +1.  'Branches' are better than patches.

How do you review a branch?



From barry at python.org  Mon Mar  7 19:04:11 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 7 Mar 2011 13:04:11 -0500
Subject: [Python-Dev] hg diff
In-Reply-To: <20110307183112.3ff1e7c9@pitrou.net>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
Message-ID: <20110307130411.6db7f1a9@neurotica.wooz.org>

On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:

>On Mon, 7 Mar 2011 12:04:18 -0500
>Barry Warsaw <barry at python.org> wrote:
>> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
>> 
>> >If we can get to a mode where non-committers can push to a "fork" on
>> >hg.python.org, we can dodge the patch format issue by having folks post
>> >"pull requests" for that fork instaed.
>> >
>> >For the repoze and pylons projects, we have found the quality and
>> >quantity of patches went up *significantly* when we made it easy for
>> >somebody who doesn't work on the code all the time to use this workflow
>> >(fork to a public repo, clone, hack, commit, push, request a pull).
>> 
>> +1.  'Branches' are better than patches.
>
>How do you review a branch?

You can merge it locally and look at the diff.  Or use Rietveld if that's
supported.  But the reason a branch is better is because it's easier to track
the submitter's changes in response to your review comments, and it's easier
to make changes to their branch and push an update for *them* to see.

It's easier to have a ongoing conversation about a branch than a patch.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/5385cf65/attachment.pgp>

From merwok at netwok.org  Mon Mar  7 19:29:51 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 07 Mar 2011 19:29:51 +0100
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
 determining child loggers.
In-Reply-To: <E1Pwf58-0007Si-3W@dinsdale.python.org>
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
Message-ID: <4D75241F.7090403@netwok.org>

Hello,

> changeset:   68315:b9d76846bb1c
> branch:      2.6
> parent:      68264:50166a4bcfc6
> user:        Vinay Sajip <vinay_sajip at yahoo.co.uk>
> date:        Mon Mar 07 15:02:11 2011 +0000
> summary:
>   Issue #11424: Fix bug in determining child loggers.

This does not look like a security bug, and is therefore not suitable
for 2.6.

Hook authors: including the local revision number in the -checkins
messages is misleading and possibly harmful.

Regards

From thomas at python.org  Mon Mar  7 19:32:30 2011
From: thomas at python.org (Thomas Wouters)
Date: Mon, 7 Mar 2011 10:32:30 -0800
Subject: [Python-Dev] hg diff
In-Reply-To: <20110307130411.6db7f1a9@neurotica.wooz.org>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
Message-ID: <AANLkTins88yLJTpMgyp5ohR5f5sey5hAncC9gZDUdFky@mail.gmail.com>

On Mon, Mar 7, 2011 at 10:04, Barry Warsaw <barry at python.org> wrote:

> On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
>
> >On Mon, 7 Mar 2011 12:04:18 -0500
> >Barry Warsaw <barry at python.org> wrote:
> >> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
> >>
> >> >If we can get to a mode where non-committers can push to a "fork" on
> >> >hg.python.org, we can dodge the patch format issue by having folks
> post
> >> >"pull requests" for that fork instaed.
> >> >
> >> >For the repoze and pylons projects, we have found the quality and
> >> >quantity of patches went up *significantly* when we made it easy for
> >> >somebody who doesn't work on the code all the time to use this workflow
> >> >(fork to a public repo, clone, hack, commit, push, request a pull).
> >>
> >> +1.  'Branches' are better than patches.
> >
> >How do you review a branch?
>
> You can merge it locally and look at the diff.  Or use Rietveld if that's
> supported.  But the reason a branch is better is because it's easier to
> track
> the submitter's changes in response to your review comments, and it's
> easier
> to make changes to their branch and push an update for *them* to see.
>
> It's easier to have a ongoing conversation about a branch than a patch.


While I agree that *maintaining* the patch is easier in a branch, I don't
agree that it's necessarily easier to review it: in Rietveld (by design!)
subsequent uploads look very much like changes in a branch. The only
difference with peeking directly in the branch is that it requires an
explicit upload by the patch-owner, which actually has its upsides as well
(no need for Rietveld to 'poll' changes, an explicit 'ok, updated according
to feedback' report, no irrelevant intermediate changes to get confused at.)
There's one thing Rietveld always has a bit of trouble representing, that
being merges with another branch, but it's hard to imagine a clearer way to
represent it without conflating the whole thing, and frankly it does a
better job of it than 'hg diff' in the branch itself :-)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/07b9f441/attachment-0001.html>

From fuzzyman at voidspace.org.uk  Mon Mar  7 19:35:31 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Mar 2011 18:35:31 +0000
Subject: [Python-Dev] hg diff
In-Reply-To: <AANLkTins88yLJTpMgyp5ohR5f5sey5hAncC9gZDUdFky@mail.gmail.com>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>
	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<AANLkTins88yLJTpMgyp5ohR5f5sey5hAncC9gZDUdFky@mail.gmail.com>
Message-ID: <4D752573.8050107@voidspace.org.uk>

On 07/03/2011 18:32, Thomas Wouters wrote:
>
>
> On Mon, Mar 7, 2011 at 10:04, Barry Warsaw <barry at python.org 
> <mailto:barry at python.org>> wrote:
>
>     On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
>
>     >On Mon, 7 Mar 2011 12:04:18 -0500
>     >Barry Warsaw <barry at python.org <mailto:barry at python.org>> wrote:
>     >> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
>     >>
>     >> >If we can get to a mode where non-committers can push to a
>     "fork" on
>     >> >hg.python.org <http://hg.python.org>, we can dodge the patch
>     format issue by having folks post
>     >> >"pull requests" for that fork instaed.
>     >> >
>     >> >For the repoze and pylons projects, we have found the quality and
>     >> >quantity of patches went up *significantly* when we made it
>     easy for
>     >> >somebody who doesn't work on the code all the time to use this
>     workflow
>     >> >(fork to a public repo, clone, hack, commit, push, request a
>     pull).
>     >>
>     >> +1.  'Branches' are better than patches.
>     >
>     >How do you review a branch?
>
>     You can merge it locally and look at the diff.  Or use Rietveld if
>     that's
>     supported.  But the reason a branch is better is because it's
>     easier to track
>     the submitter's changes in response to your review comments, and
>     it's easier
>     to make changes to their branch and push an update for *them* to see.
>
>     It's easier to have a ongoing conversation about a branch than a
>     patch.
>
>
> While I agree that *maintaining* the patch is easier in a branch, I 
> don't agree that it's necessarily easier to review it: in Rietveld (by 
> design!) subsequent uploads look very much like changes in a branch.

With the right tools reviewing branches

> The only difference with peeking directly in the branch is that it 
> requires an explicit upload by the patch-owner, which actually has its 
> upsides as well (no need for Rietveld to 'poll' changes, an explicit 
> 'ok, updated according to feedback' report, no irrelevant intermediate 
> changes to get confused at.) There's one thing Rietveld always has a 
> bit of trouble representing, that being merges with another branch, 
> but it's hard to imagine a clearer way to represent it without 
> conflating the whole thing, and frankly it does a better job of it 
> than 'hg diff' in the branch itself :-)
>
> -- 
> Thomas Wouters <thomas at python.org <mailto:thomas at python.org>>
>
> Hi! I'm a .signature virus! copy me into your .signature file to help 
> me spread!
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/4689f66e/attachment.html>

From solipsis at pitrou.net  Mon Mar  7 19:36:32 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Mar 2011 19:36:32 +0100
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
 determining child loggers.
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
	<4D75241F.7090403@netwok.org>
Message-ID: <20110307193632.33d15435@pitrou.net>

On Mon, 07 Mar 2011 19:29:51 +0100
?ric Araujo <merwok at netwok.org> wrote:
> Hello,
> 
> > changeset:   68315:b9d76846bb1c
> > branch:      2.6
> > parent:      68264:50166a4bcfc6
> > user:        Vinay Sajip <vinay_sajip at yahoo.co.uk>
> > date:        Mon Mar 07 15:02:11 2011 +0000
> > summary:
> >   Issue #11424: Fix bug in determining child loggers.
> 
> This does not look like a security bug, and is therefore not suitable
> for 2.6.
> 
> Hook authors: including the local revision number in the -checkins
> messages is misleading and possibly harmful.

We're using the stock template output from Mercurial (the one you get
when typing "hg log -v -r <somechangeset>").  Another issue is
that the "files" section in merges doesn't show all affected
files.  Patches welcome (the hooks are in hg.python.org/hooks).

Regards

Antoine.



From solipsis at pitrou.net  Mon Mar  7 19:44:16 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Mar 2011 19:44:16 +0100
Subject: [Python-Dev] hg diff
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
Message-ID: <20110307194416.1a82800b@pitrou.net>

On Mon, 7 Mar 2011 13:04:11 -0500
Barry Warsaw <barry at python.org> wrote:

> On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
> 
> >On Mon, 7 Mar 2011 12:04:18 -0500
> >Barry Warsaw <barry at python.org> wrote:
> >> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
> >> 
> >> >If we can get to a mode where non-committers can push to a "fork" on
> >> >hg.python.org, we can dodge the patch format issue by having folks post
> >> >"pull requests" for that fork instaed.
> >> >
> >> >For the repoze and pylons projects, we have found the quality and
> >> >quantity of patches went up *significantly* when we made it easy for
> >> >somebody who doesn't work on the code all the time to use this workflow
> >> >(fork to a public repo, clone, hack, commit, push, request a pull).
> >> 
> >> +1.  'Branches' are better than patches.
> >
> >How do you review a branch?
> 
> You can merge it locally and look at the diff.  Or use Rietveld if that's
> supported.  But the reason a branch is better is because it's easier to track
> the submitter's changes in response to your review comments, and it's easier
> to make changes to their branch and push an update for *them* to see.

I agree with Thomas' answer here: while a branch makes it easier to
maintain a patch (but you can also use e.g. Mercurial Queues), it
doesn't make it easier to *review*.  You are assuming that I, as a
reviewer, want to know about the history of changesets that led to the
patch, but I don't: I want to read the patch as a cohesive whole, and I
couldn't care less about the various typo fixes, style changes,
performance tweaks that were checked in all along.

So, I'd rather have the submitter post a patch, than generate it
myself. Meaning that if I have to generate it myself, I might be too
lazy (or overworked) and not do a review at all.

Regards

Antoine.



From fuzzyman at voidspace.org.uk  Mon Mar  7 19:46:49 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Mar 2011 18:46:49 +0000
Subject: [Python-Dev] hg diff
In-Reply-To: <4D752573.8050107@voidspace.org.uk>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>	<AANLkTins88yLJTpMgyp5ohR5f5sey5hAncC9gZDUdFky@mail.gmail.com>
	<4D752573.8050107@voidspace.org.uk>
Message-ID: <4D752819.3050500@voidspace.org.uk>

On 07/03/2011 18:35, Michael Foord wrote:
> On 07/03/2011 18:32, Thomas Wouters wrote:
>>
>>
>> On Mon, Mar 7, 2011 at 10:04, Barry Warsaw <barry at python.org 
>> <mailto:barry at python.org>> wrote:
>>
>>     On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
>>
>>     >On Mon, 7 Mar 2011 12:04:18 -0500
>>     >Barry Warsaw <barry at python.org <mailto:barry at python.org>> wrote:
>>     >> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
>>     >>
>>     >> >If we can get to a mode where non-committers can push to a
>>     "fork" on
>>     >> >hg.python.org <http://hg.python.org>, we can dodge the patch
>>     format issue by having folks post
>>     >> >"pull requests" for that fork instaed.
>>     >> >
>>     >> >For the repoze and pylons projects, we have found the quality and
>>     >> >quantity of patches went up *significantly* when we made it
>>     easy for
>>     >> >somebody who doesn't work on the code all the time to use
>>     this workflow
>>     >> >(fork to a public repo, clone, hack, commit, push, request a
>>     pull).
>>     >>
>>     >> +1.  'Branches' are better than patches.
>>     >
>>     >How do you review a branch?
>>
>>     You can merge it locally and look at the diff.  Or use Rietveld
>>     if that's
>>     supported.  But the reason a branch is better is because it's
>>     easier to track
>>     the submitter's changes in response to your review comments, and
>>     it's easier
>>     to make changes to their branch and push an update for *them* to see.
>>
>>     It's easier to have a ongoing conversation about a branch than a
>>     patch.
>>
>>
>> While I agree that *maintaining* the patch is easier in a branch, I 
>> don't agree that it's necessarily easier to review it: in Rietveld 
>> (by design!) subsequent uploads look very much like changes in a branch.
>
> With the right tools reviewing branches
>

Dammit, meant to cancel that email not send. Anyway, with the right 
tools reviewing a branch is trivially easy as it will *show* you a diff. 
This is what launchpad does for bzr merge proposals and how we do code 
reviews. It's great. :-)

Michael

>> The only difference with peeking directly in the branch is that it 
>> requires an explicit upload by the patch-owner, which actually has 
>> its upsides as well (no need for Rietveld to 'poll' changes, an 
>> explicit 'ok, updated according to feedback' report, no irrelevant 
>> intermediate changes to get confused at.) There's one thing Rietveld 
>> always has a bit of trouble representing, that being merges with 
>> another branch, but it's hard to imagine a clearer way to represent 
>> it without conflating the whole thing, and frankly it does a better 
>> job of it than 'hg diff' in the branch itself :-)
>>
>> -- 
>> Thomas Wouters <thomas at python.org <mailto:thomas at python.org>>
>>
>> Hi! I'm a .signature virus! copy me into your .signature file to help 
>> me spread!
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at 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 blessinghttp://www.sqlite.org/different.html
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/df32e454/attachment.html>

From barry at python.org  Mon Mar  7 20:02:43 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 7 Mar 2011 14:02:43 -0500
Subject: [Python-Dev] hg diff
In-Reply-To: <20110307194416.1a82800b@pitrou.net>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
Message-ID: <20110307140243.6ada217b@neurotica.wooz.org>

On Mar 07, 2011, at 07:44 PM, Antoine Pitrou wrote:

>I agree with Thomas' answer here: while a branch makes it easier to
>maintain a patch (but you can also use e.g. Mercurial Queues), it
>doesn't make it easier to *review*.  You are assuming that I, as a
>reviewer, want to know about the history of changesets that led to the
>patch, but I don't: I want to read the patch as a cohesive whole, and I
>couldn't care less about the various typo fixes, style changes,
>performance tweaks that were checked in all along.

I hear this complaint a lot from hg and git users, so maybe it's just the
nature of the tools.  In which case, I'm fine with whatever works better for
Python.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/6bdb8fb1/attachment.pgp>

From ethan at stoneleaf.us  Mon Mar  7 20:11:35 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 07 Mar 2011 11:11:35 -0800
Subject: [Python-Dev] [PEPs] Support the
	/usr/bin/python2	symlink	upstream
In-Reply-To: <4D74BAF6.3040307@timgolden.me.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<AANLkTimf6X7X6csQ9a2gbbJUGt2GEsqAVJyz9qqNGP2G@mail.gmail.com>	<4D74B834.905@skippinet.com.au>
	<4D74BAF6.3040307@timgolden.me.uk>
Message-ID: <4D752DE7.3070000@stoneleaf.us>

Tim Golden wrote:
> On 07/03/2011 10:49, Mark Hammond wrote:
>> On 7/03/2011 9:33 PM, Paul Moore wrote:
>>> That sounds like a fairly cool idea. So if I follow what you're
>>> suggesting, we'd have a single python.exe, probably installed in
>>> system32, which did the necessary command line juggling and shebang
>>> parsing, then simply redirected to the appropriate Python interpreter?
>>> Presumably that launcher would be pretty version independent, so (a)
>>> the one that gets installed with Python 3.3 would support older
>>> versions even though they didn't include the launcher themselves, (b)
>>> overwriting the launcher when a new version of Python is installed
>>> wouldn't be too big a deal, and (c) it could be released as a
>>> standalone package for people with only older versions of Python
>>> installed?
>>
>> Yup - although I think a pythonw.exe launcher would be needed too (for
>> the same reasons we need python.exe and pythonw.exe today)
>>
>>> I like this idea. If I had the spare time (I don't :-() I'd work on
>>> this myself.
>>>
>>> +1 from me.
> 
> Agreed all round. 

+1 here also.  This seems a sensible solution to the 'Windows Problem'.  ;)

~Ethan~

From tjreedy at udel.edu  Mon Mar  7 20:45:57 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 07 Mar 2011 14:45:57 -0500
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
	this documented?
In-Reply-To: <20110307154718.27a22edb@pitrou.net>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>	<il1hhr$mrr$1@dough.gmane.org>
	<4D7498F1.3070602@arbash-meinel.com>	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
	<20110307154718.27a22edb@pitrou.net>
Message-ID: <il3cll$6cl$1@dough.gmane.org>

On 3/7/2011 9:47 AM, Antoine Pitrou wrote:
> On Mon, 7 Mar 2011 19:14:55 +1000
> Nick Coghlan<ncoghlan at gmail.com>  wrote:
>> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
>> <john at arbash-meinel.com>  wrote:
>>>
>>> Especially since, AIUI, deprecations are suppressed by default now.
>>
>> True, but developers are expected to run their tests with them enabled.
>
> Where do we actually document this?

Should be, and maybe is, in the nice new dev guide.

Also, the doc for unittest.TextTestRunner says "By default this runner 
shows DeprecationWarning, PendingDeprecationWarning, and ImportWarning 
even if they are ignored by default." The idea (discussed here) is that 
developers of a module should see warnings when testing, even if users 
of the module do not. I am not sure whether above applies when running 
through unittest.main, but it should.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Mon Mar  7 20:49:19 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 07 Mar 2011 14:49:19 -0500
Subject: [Python-Dev] [Python-checkins] r88709 - in
 python/branches/py3k: Misc/NEWS Objects/unicodeobject.c
In-Reply-To: <1299495245.9793.4.camel@marge>
References: <20110302010314.642AEEE983@mail.python.org>	<4D749FEA.6080504@netwok.org>
	<1299495245.9793.4.camel@marge>
Message-ID: <il3cru$6cl$2@dough.gmane.org>

On 3/7/2011 5:54 AM, Victor Stinner wrote:

>> I don?t really understand this message (especially ?cached into the
>> object?) :)  Maybe in the Misc/NEWS entry you could also add a line to
>> explain to users the reason/goal/benefit of this change?
>
> If you call str.encode() twice: the first call stores the result in a
> cache, and the second call just reuse the cache. The benefit is that the
> second call is much faster.
>
> The cache is an internal attribute of the Unicode object (str type).
>
> Do you have a suggestion to rephrase the Misc/NEWS entry?

(Without reading the entire entry,) something like:
'More consistently cached as an internal attribute of the str object for 
possible later reuse.'


-- 
Terry Jan Reedy



From fuzzyman at voidspace.org.uk  Mon Mar  7 20:57:09 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Mar 2011 19:57:09 +0000
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <il3cll$6cl$1@dough.gmane.org>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>	<il1hhr$mrr$1@dough.gmane.org>	<4D7498F1.3070602@arbash-meinel.com>	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>	<20110307154718.27a22edb@pitrou.net>
	<il3cll$6cl$1@dough.gmane.org>
Message-ID: <4D753895.1050002@voidspace.org.uk>

On 07/03/2011 19:45, Terry Reedy wrote:
> On 3/7/2011 9:47 AM, Antoine Pitrou wrote:
>> On Mon, 7 Mar 2011 19:14:55 +1000
>> Nick Coghlan<ncoghlan at gmail.com>  wrote:
>>> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
>>> <john at arbash-meinel.com>  wrote:
>>>>
>>>> Especially since, AIUI, deprecations are suppressed by default now.
>>>
>>> True, but developers are expected to run their tests with them enabled.
>>
>> Where do we actually document this?
>
> Should be, and maybe is, in the nice new dev guide.
>
> Also, the doc for unittest.TextTestRunner says "By default this runner 
> shows DeprecationWarning, PendingDeprecationWarning, and ImportWarning 
> even if they are ignored by default." The idea (discussed here) is 
> that developers of a module should see warnings when testing, even if 
> users of the module do not. I am not sure whether above applies when 
> running through unittest.main, but it should.
>
I believe it does apply through unittest.main() - Ezio would know best 
as he implemented this feature though.

All the best,

Michael

-- 
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


From tjreedy at udel.edu  Mon Mar  7 20:59:32 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 07 Mar 2011 14:59:32 -0500
Subject: [Python-Dev] hg pull failed
In-Reply-To: <il20o9$eut$1@dough.gmane.org>
References: <19826.24958.821162.983186@montanaro.dyndns.org>	<ikto58$dbt$1@dough.gmane.org>	<19827.44006.852917.924065@montanaro.dyndns.org>	<il0bfd$96c$1@dough.gmane.org>
	<il14k6$35k$1@dough.gmane.org> <il20o9$eut$1@dough.gmane.org>
Message-ID: <il3df5$akb$1@dough.gmane.org>

On 3/7/2011 2:16 AM, Georg Brandl wrote:
> On 07.03.2011 00:16, Terry Reedy wrote:

>> 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.

On my current older WinXP machine, the startup time to do anything with 
the svn repository was about 10 secs. Long enough to be a drag, not long 
enough to do much else ;-). Maybe it will be faster with *nix or newer 
Windows, hg, and newer machine (all of which I plan to get).

-- 
Terry Jan Reedy


From g.brandl at gmx.net  Mon Mar  7 21:02:46 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 07 Mar 2011 21:02:46 +0100
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
 determining child loggers.
In-Reply-To: <4D75241F.7090403@netwok.org>
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
	<4D75241F.7090403@netwok.org>
Message-ID: <il3dmr$a77$1@dough.gmane.org>

On 07.03.2011 19:29, ?ric Araujo wrote:
> Hello,
> 
>> changeset:   68315:b9d76846bb1c
>> branch:      2.6
>> parent:      68264:50166a4bcfc6
>> user:        Vinay Sajip <vinay_sajip at yahoo.co.uk>
>> date:        Mon Mar 07 15:02:11 2011 +0000
>> summary:
>>   Issue #11424: Fix bug in determining child loggers.
> 
> This does not look like a security bug, and is therefore not suitable
> for 2.6.
> 
> Hook authors: including the local revision number in the -checkins
> messages is misleading and possibly harmful.

In this case, it's not really a local revision number, but the revision
number in the authoritative upstream repository.

Georg


From solipsis at pitrou.net  Mon Mar  7 21:06:51 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Mar 2011 21:06:51 +0100
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
	<il1hhr$mrr$1@dough.gmane.org> <4D7498F1.3070602@arbash-meinel.com>
	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
	<20110307154718.27a22edb@pitrou.net> <il3cll$6cl$1@dough.gmane.org>
Message-ID: <20110307210651.5266ae40@pitrou.net>

On Mon, 07 Mar 2011 14:45:57 -0500
Terry Reedy <tjreedy at udel.edu> wrote:
> On 3/7/2011 9:47 AM, Antoine Pitrou wrote:
> > On Mon, 7 Mar 2011 19:14:55 +1000
> > Nick Coghlan<ncoghlan at gmail.com>  wrote:
> >> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
> >> <john at arbash-meinel.com>  wrote:
> >>>
> >>> Especially since, AIUI, deprecations are suppressed by default now.
> >>
> >> True, but developers are expected to run their tests with them enabled.
> >
> > Where do we actually document this?
> 
> Should be, and maybe is, in the nice new dev guide.

The dev guide is for development *of* Python, not *with* Python ;)



From fuzzyman at voidspace.org.uk  Mon Mar  7 21:09:21 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Mar 2011 20:09:21 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D746AD1.7040801@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinqanSeLXDf0cQxEzSk+-B2QXJatwjDxzbR8jak@mail.gmail.com>	<4D7387CF.6070104@skippinet.com.au>	<AANLkTikhyHtdNC3LD_-SrNLP9xFYXJ91W4jY0PMA8yaJ@mail.gmail.com>	<AANLkTinuaBkTbHfGG1Pkyp5mAUUvxqWrDUsa6CPJagDk@mail.gmail.com>	<4D745F54.6060001@g.nevcal.com>
	<4D746AD1.7040801@gmail.com>
Message-ID: <4D753B71.4040301@voidspace.org.uk>

On 07/03/2011 05:19, Mark Hammond wrote:
> [snip...]
>> (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.
>

"/usr/bin/env python" is popular too, and it would be nice to support 
the new aliases (or binaries) being created by the pep (python2 / python3).

Michael

>> 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 at 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


From fuzzyman at voidspace.org.uk  Mon Mar  7 21:16:00 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Mar 2011 20:16:00 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <28BE15FAC0454F529E197111F0511355@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<4D73C762.1050802@voidspace.org.uk>
	<AANLkTi=u=8ikkdxuFKQ3_9QnvTavoiZTD0J1hDMcaa9A@mail.gmail.com>
	<28BE15FAC0454F529E197111F0511355@gmail.com>
Message-ID: <4D753D00.7010005@voidspace.org.uk>

On 07/03/2011 17:21, Sridhar Ratnakumar wrote:
>
> On Sunday, March 6, 2011 at 9:53 AM, Brian Curtin wrote:
>
>> On Sun, Mar 6, 2011 at 11:41, Michael Foord<fuzzyman at voidspace.org.uk 
>> <mailto:fuzzyman at voidspace.org.uk>>wrote:
>> - Hide quoted message -
>>> 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?
> ActivePython for Windows includes the following binaries on Windows:
>
> * python.exe
> * python3.2.exe
> * python3.xe
> (plus the `pythonw` versions)
>
> python3.2.exe is better than python32.exe because that matches the 
> invocation (eg: "python3.2 -m foo") on Unix.
>
> Similarly for 2.x (python2.exe / python2.7.exe).
>
> All of this is particularly useful if the installer adds Python 
> directory to %PATH% (which is the case for ActivePython, but not the 
> one from python.org).

Sounds ideal. :-)

Michael

>
> -srid


-- 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/a72810a3/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Mar  7 21:33:39 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Mar 2011 20:33:39 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D743248.9060705@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com>
Message-ID: <4D754123.7070703@voidspace.org.uk>

On 07/03/2011 01:18, Mark Hammond wrote:
> [snip...]
> 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.
>

A python launcher as you describe is a *great* idea.

A few concerns:

* we're missing an opportunity to do something easy (Martin is happy to 
modify the installer and says it is easy) for something that may or may 
not happen

* will you call it python.exe? will it be installed by the python 
installer?

     - I doubt calling it python.exe will fly, but I'm not sure. If so 
what will you call what is currently 'python.exe'? - if not then "python 
foo.py" on the command line will *still* not work...

     - it will still have to be installed on the PATH, but I guess 
System32 will do for that - users without admin rights will still have 
to modify their PATH manually and place it somewhere else

* we're (yet again) making instructions for running stuff on Windows 
*different* to other platforms (and making tutorials written for other 
pythons "not work" in certain ways)

* as I work with multiple platforms it would be really nice if the same 
invocations worked across all of them - whilst I say again that I really 
like the idea of the launcher it doesn't conflict with the other 
suggestions (creating multiple binaries) and as you (Mark) say it 
wouldn't hurt...

So why not do both? We could create the extra binaries to bring Python 
on Windows inline with the unix conventions for command line 
invocations, and the new launcher can follow on as a nice addition.

Note that the discussions about the Python installer adding to the PATH 
won't be *ended* by the creation of the installer. A typical install on 
a Unix-like system adds various other utilities to the path that merely 
adding the top-level of your Python install on Windows still doesn't 
add. In particular distutils installed scripts go into a subdirectory of 
your Python install.

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


From p.f.moore at gmail.com  Mon Mar  7 21:49:59 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 7 Mar 2011 20:49:59 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D754123.7070703@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
Message-ID: <AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>

On 7 March 2011 20:33, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> So why not do both? We could create the extra binaries to bring Python on
> Windows inline with the unix conventions for command line invocations, and
> the new launcher can follow on as a nice addition.

I was assuming that the exes in the installation directories would
include version-specific ones (bringing Windows in line with Unix
behaviour) and the python.exe launcher would be in system32 (making
python foo.py work on the command line) and would redirect to the
"default" python for the box (or a specific one, if -2, -3, -2.7 or
whatever flags were specified).

The launcher could also (as per Mark's suggestion) interpret a shebang
line in the script, so that scripts could specify their required
version without needing a different command,or multiple
version-specific extensions.

So yes, let's do both. That's certainly what I expected.
Paul.

From martin at v.loewis.de  Mon Mar  7 22:03:54 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 07 Mar 2011 22:03:54 +0100
Subject: [Python-Dev] combined hg incoming patch
Message-ID: <4D75483A.50600@v.loewis.de>

I'd like to experiment with adding Rietveld support for reviewing
remote repositories. For that, I'd need to create a single patch
(programmatically) that covers all incoming changes. 'hg incoming -p'
mostly works, but it may provide multiple patches for a single file,
which I think would harm the review (since some changes may be 
superseded in a separate patch).

So I would need to compute the most recent revision in both 
repositories, and then create a diff between the default head
of the remote repository and that base revision.

Regards,
Martin

From nad at acm.org  Mon Mar  7 22:14:32 2011
From: nad at acm.org (Ned Deily)
Date: Mon, 07 Mar 2011 13:14:32 -0800
Subject: [Python-Dev] Obsolete content at http://www.python.org/dev/* ?
Message-ID: <nad-152F7D.13143207032011@dough.gmane.org>

With the transition to the new devguide, references to the main page of 
the old dev section of the website, http://www.python.org/dev/, redirect 
to http://docs.python.org/devguide/, the main page of the new guide.  
However, many links to some obsoleted sections of the old dev section 
are out in the wild (and showing up prominently in Google searches) and 
the webserver still seems to be serving up those obsolete links even 
though they appear to have been deleted from the www repo, for instance, 
the old links previously under Core Development on the left margin bar:

http://www.python.org/dev/faq/
http://www.python.org/dev/setup/
http://www.python.org/dev/tools/
etc

I was going to suggest that the webserver be changed to redirect all 
/dev/* references to /devguide/ but then I noticed that's it not that 
simple as there are other valid links still under /dev:

http://www.python.org/dev/buildbot/
http://www.python.org/dev/peps/
http://www.python.org/dev/pydotorg/
http://www.python.org/dev/searchplugin/

So I think there are two issues here:
1. deleted webpages cached by the webserver
2. adding redirects from /dev/{faq|setup|tools| et al } to 
docs.python.org/devguide

-- 
 Ned Deily,
 nad at acm.org


From skip at pobox.com  Mon Mar  7 22:45:58 2011
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 7 Mar 2011 15:45:58 -0600
Subject: [Python-Dev] PyCon blogging?
Message-ID: <19829.21014.528494.314883@montanaro.dyndns.org>

Anybody here (or elsewhere) with plans to blog at PyCon for those of us not
going?

Thx,

Skip


From brian.curtin at gmail.com  Mon Mar  7 23:00:18 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Mon, 7 Mar 2011 16:00:18 -0600
Subject: [Python-Dev] PyCon blogging?
In-Reply-To: <19829.21014.528494.314883@montanaro.dyndns.org>
References: <19829.21014.528494.314883@montanaro.dyndns.org>
Message-ID: <AANLkTimDvqT0a6WQDG4102rCT1siAAE0AGRAFx8u4i1V@mail.gmail.com>

On Mon, Mar 7, 2011 at 15:45, <skip at pobox.com> wrote:

> Anybody here (or elsewhere) with plans to blog at PyCon for those of us not
> going?
>
> Thx,
>
> Skip


I've been writing a lot lately for the PyCon blog so I might as well keep
that up. I'll try to write something up for the language summit, and I
imagine I could do some sort of daily summary as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/89d8aec2/attachment-0001.html>

From brendan at kublai.com  Mon Mar  7 23:09:24 2011
From: brendan at kublai.com (Brendan Cully)
Date: Mon, 7 Mar 2011 14:09:24 -0800
Subject: [Python-Dev] combined hg incoming patch
In-Reply-To: <4D75483A.50600@v.loewis.de>
References: <4D75483A.50600@v.loewis.de>
Message-ID: <03D49162-8E97-464F-A1EA-F156C94FAC7D@kublai.com>

On 2011-03-07, at 1:03 PM, Martin v. L?wis wrote:

> I'd like to experiment with adding Rietveld support for reviewing
> remote repositories. For that, I'd need to create a single patch
> (programmatically) that covers all incoming changes. 'hg incoming -p'
> mostly works, but it may provide multiple patches for a single file,
> which I think would harm the review (since some changes may be superseded in a separate patch).
> 
> So I would need to compute the most recent revision in both repositories, and then create a diff between the default head
> of the remote repository and that base revision.

You might like the rdiff extension, which does essentially this.

http://mercurial.selenic.com/wiki/RdiffExtension


From foom at fuhm.net  Mon Mar  7 23:18:00 2011
From: foom at fuhm.net (James Y Knight)
Date: Mon, 7 Mar 2011 17:18:00 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>
Message-ID: <30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>

On Mar 7, 2011, at 3:49 PM, Paul Moore wrote:
> The launcher could also (as per Mark's suggestion) interpret a shebang
> line in the script, so that scripts could specify their required
> version without needing a different command,or multiple
> version-specific extensions.

Note that, on Unix, "python file.py" doesn't choose the correct version of python to run by looking at a shebang, it just runs the version of python installed as "python". Only "./file.py" looks at the shebang (assuming that file is marked executable). 

Is the proposal to make python.exe do that on windows? That is a rather significant difference from the unix behavior.

From martin at v.loewis.de  Mon Mar  7 23:18:27 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 07 Mar 2011 23:18:27 +0100
Subject: [Python-Dev] combined hg incoming patch
In-Reply-To: <03D49162-8E97-464F-A1EA-F156C94FAC7D@kublai.com>
References: <4D75483A.50600@v.loewis.de>
	<03D49162-8E97-464F-A1EA-F156C94FAC7D@kublai.com>
Message-ID: <4D7559B3.8060605@v.loewis.de>

Am 07.03.2011 23:09, schrieb Brendan Cully:
> On 2011-03-07, at 1:03 PM, Martin v. L?wis wrote:
>
>> I'd like to experiment with adding Rietveld support for reviewing
>> remote repositories. For that, I'd need to create a single patch
>> (programmatically) that covers all incoming changes. 'hg incoming -p'
>> mostly works, but it may provide multiple patches for a single file,
>> which I think would harm the review (since some changes may be superseded in a separate patch).
>>
>> So I would need to compute the most recent revision in both repositories, and then create a diff between the default head
>> of the remote repository and that base revision.
>
> You might like the rdiff extension, which does essentially this.
>
> http://mercurial.selenic.com/wiki/RdiffExtension

I've looked at it, and it does something different. It computes the diff 
between the local tip and the remote tip. What I want is a diff between 
the common ancestor between the two, and the remote tip.

Regards,
Martin

From ncoghlan at gmail.com  Mon Mar  7 23:25:50 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 8 Mar 2011 08:25:50 +1000
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <20110307103019.32fb7a9c@neurotica.wooz.org>
References: <4D6D8BE8.7020808@v.loewis.de> <20110302090155.GL30982@piotro.eu>
	<AANLkTinSRUhLALc-BsWVSJMOhgVCxN3jJUSwWzwfjafP@mail.gmail.com>
	<20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
	<20110303170804.GD3275@unaka.lan>
	<20110303214623.64e880ba@neurotica.wooz.org>
	<20110304043707.GF3275@unaka.lan>
	<20110304135639.2bef9975@neurotica.wooz.org>
	<20110304200043.GG3275@unaka.lan>
	<20110307103019.32fb7a9c@neurotica.wooz.org>
Message-ID: <AANLkTi=-jeCJrtqhA6J4ng8p6gf9SZuLxj+3ZuFSRVka@mail.gmail.com>

On Tue, Mar 8, 2011 at 1:30 AM, Barry Warsaw <barry at python.org> wrote:
> On Mar 04, 2011, at 12:00 PM, Toshio Kuratomi wrote:
>
>>Actually, my post was saying that these two can be decoupled. ?ie: It's
>>possible to not have /usr/bin/python while still allowing users to type
>>python at a shell prompt and get the interpreter.
>>
>>This is done by either redefining the PATH to include the directory that the
>>interpreter named "python" is in or by creating an alias for python to the
>>proper interpreter.
>
> I personally would prefer aliasing rather than $PATH manipulation.

Toshio's suggestion wouldn't work anyway - the "/usr/bin/env python"
idiom will pick up a "python" alias no matter where it lives on $PATH.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From fuzzyman at voidspace.org.uk  Mon Mar  7 23:29:19 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Mar 2011 22:29:19 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>
	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>
	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>
	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
Message-ID: <4D755C3F.1000703@voidspace.org.uk>

On 07/03/2011 22:18, James Y Knight wrote:
> On Mar 7, 2011, at 3:49 PM, Paul Moore wrote:
>> The launcher could also (as per Mark's suggestion) interpret a shebang
>> line in the script, so that scripts could specify their required
>> version without needing a different command,or multiple
>> version-specific extensions.
> Note that, on Unix, "python file.py" doesn't choose the correct version of python to run by looking at a shebang, it just runs the version of python installed as "python". Only "./file.py" looks at the shebang (assuming that file is marked executable).
>
> Is the proposal to make python.exe do that on windows? That is a rather significant difference from the unix behavior.

By default "python.exe" is not on the path in windows, so unless the 
current directory is the python install (or you have manually changed 
your path) "python foo.py" does *nothing*. That is a *very* big 
difference from unix behaviour.

The proposal is (apparently) to create another executable called 
"python.exe" that is put on the path by the installer (if the user has 
the right permissions to do this).

I believe the intention is that "python foo.py" *will* then lookup the 
shebang to run the "right" version of python, defaulting to the last 
installed version of python (I assume).

All the best,

Michael Foord

> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From brendan at kublai.com  Mon Mar  7 23:30:03 2011
From: brendan at kublai.com (Brendan Cully)
Date: Mon, 7 Mar 2011 14:30:03 -0800
Subject: [Python-Dev] combined hg incoming patch
In-Reply-To: <4D7559B3.8060605@v.loewis.de>
References: <4D75483A.50600@v.loewis.de>
	<03D49162-8E97-464F-A1EA-F156C94FAC7D@kublai.com>
	<4D7559B3.8060605@v.loewis.de>
Message-ID: <0113DA3C-0FD9-4527-B819-8B2C5928A8C7@kublai.com>

On 2011-03-07, at 2:18 PM, Martin v. L?wis wrote:

> Am 07.03.2011 23:09, schrieb Brendan Cully:
>> On 2011-03-07, at 1:03 PM, Martin v. L?wis wrote:
>> 
>>> I'd like to experiment with adding Rietveld support for reviewing
>>> remote repositories. For that, I'd need to create a single patch
>>> (programmatically) that covers all incoming changes. 'hg incoming -p'
>>> mostly works, but it may provide multiple patches for a single file,
>>> which I think would harm the review (since some changes may be superseded in a separate patch).
>>> 
>>> So I would need to compute the most recent revision in both repositories, and then create a diff between the default head
>>> of the remote repository and that base revision.
>> 
>> You might like the rdiff extension, which does essentially this.
>> 
>> http://mercurial.selenic.com/wiki/RdiffExtension
> 
> I've looked at it, and it does something different. It computes the diff between the local tip and the remote tip. What I want is a diff between the common ancestor between the two, and the remote tip.

Ah right. Well, I think this shell should work (with hg new enough to have revsets):

hg in --bundle tmp.bundle
hg diff -r 'outgoing(.)' -R tmp.bundle


From ncoghlan at gmail.com  Mon Mar  7 23:30:45 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 8 Mar 2011 08:30:45 +1000
Subject: [Python-Dev] PyCon blogging?
In-Reply-To: <19829.21014.528494.314883@montanaro.dyndns.org>
References: <19829.21014.528494.314883@montanaro.dyndns.org>
Message-ID: <AANLkTikOHYqGHYB8Fx-k0_VUsEwKnpXLdNqmXUms4F1t@mail.gmail.com>

On Tue, Mar 8, 2011 at 7:45 AM,  <skip at pobox.com> wrote:
> Anybody here (or elsewhere) with plans to blog at PyCon for those of us not
> going?

Since I'll likely forget it myself otherwise, I'll probably be posting
stuff about the language summit and the sprints:
http://www.boredomandlaziness.org

How much I post will depend on how much downtime I end up with, though.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From barry at barrys-emacs.org  Mon Mar  7 22:58:44 2011
From: barry at barrys-emacs.org (Barry Scott)
Date: Mon, 7 Mar 2011 21:58:44 +0000
Subject: [Python-Dev] What does the "m" mean for the Mac OS X include
	folder?
In-Reply-To: <nad-E4F63B.17465606032011@news.gmane.org>
References: <5AB965C9-7D5F-41B6-A5E9-2B881E92A782@barrys-emacs.org>
	<nad-E4F63B.17465606032011@news.gmane.org>
Message-ID: <5A4310DB-57F9-4A24-AAF2-0FB8842EFFC8@barrys-emacs.org>


On 7 Mar 2011, at 01:46, Ned Deily wrote:

> In article <5AB965C9-7D5F-41B6-A5E9-2B881E92A782 at barrys-emacs.org>,
> Barry Scott <barry at 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).

Thanks for this full explanation.

I can use the Headers link and that will make it possible to do the same thing
for compiling against all versions from 2.4 to 3.2.

Barry



From skippy.hammond at gmail.com  Mon Mar  7 23:48:06 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Tue, 08 Mar 2011 09:48:06 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D754123.7070703@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
Message-ID: <4D7560A6.4030802@gmail.com>

On 8/03/2011 7:33 AM, Michael Foord wrote:
> A python launcher as you describe is a *great* idea.
>
> A few concerns:
>
> * we're missing an opportunity to do something easy (Martin is happy to
> modify the installer and says it is easy) for something that may or may
> not happen

Don't let my -0 stop anyone :)

> * will you call it python.exe? will it be installed by the python
> installer?
>
> - I doubt calling it python.exe will fly, but I'm not sure. If so what
> will you call what is currently 'python.exe'? - if not then "python
> foo.py" on the command line will *still* not work...

Calling it python.exe would make the most sense for people who don't 
look behind the curtain, but I agree it could potentially be confusing 
for people.  Further, we would need to ensure we didn't create an 
infinite loop where the launcher python.exe found a python.exe it 
thought was an appropriate sub-process, but where it turns out it is 
actually another launcher.

Having it installed by the Python installer also makes sense to me but 
I'd be very interested in Martin's take on this (and also on everything 
else we are discussing here).

> * we're (yet again) making instructions for running stuff on Windows
> *different* to other platforms (and making tutorials written for other
> pythons "not work" in certain ways)

Actually, I'd argue we are making them more similar as we would be 
honoring a shebang line and allowing the exact same mechanism be used to 
denote the major version of Python needed.

> * as I work with multiple platforms it would be really nice if the same
> invocations worked across all of them - whilst I say again that I really
> like the idea of the launcher it doesn't conflict with the other
> suggestions (creating multiple binaries) and as you (Mark) say it
> wouldn't hurt...
>
> So why not do both? We could create the extra binaries to bring Python
> on Windows inline with the unix conventions for command line
> invocations, and the new launcher can follow on as a nice addition.
>
> Note that the discussions about the Python installer adding to the PATH
> won't be *ended* by the creation of the installer. A typical install on
> a Unix-like system adds various other utilities to the path that merely
> adding the top-level of your Python install on Windows still doesn't
> add. In particular distutils installed scripts go into a subdirectory of
> your Python install.

The distutils scripts are a good point.  To be honest, apart from the 
"file association" issue, I can't see much advantage in doing both - if 
all Python directories end up on your path such that "python3 foo.py" 
magically works, then the launcher script is adding complexity without 
bringing much to the table.  Further, I'm somewhat skeptical that the 
file associations are used by that many people in the real world - 
currently when you double-click on a script you get a temp console 
created, and should a traceback be raised, you get to see it for about 
2ms before the console is destroyed.  Some people may be .pyw to avoid 
that, but then their script has to go to extraordinary lengths to 
display such errors in a UI of some kind.  I suspect most people just 
find it more convenient to launch such scripts from a console.  Maybe a 
quick poll on python-list would be reasonable...

Cheers,

Mark

From fuzzyman at voidspace.org.uk  Mon Mar  7 23:58:38 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Mar 2011 22:58:38 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D7560A6.4030802@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
	<4D7560A6.4030802@gmail.com>
Message-ID: <4D75631E.90401@voidspace.org.uk>

On 07/03/2011 22:48, Mark Hammond wrote:
> On 8/03/2011 7:33 AM, Michael Foord wrote:
>> A python launcher as you describe is a *great* idea.
>>
>> A few concerns:
>>
>> * we're missing an opportunity to do something easy (Martin is happy to
>> modify the installer and says it is easy) for something that may or may
>> not happen
>
> Don't let my -0 stop anyone :)

Will you be at PyCon this year?

>
>> * will you call it python.exe? will it be installed by the python
>> installer?
>>
>> - I doubt calling it python.exe will fly, but I'm not sure. If so what
>> will you call what is currently 'python.exe'? - if not then "python
>> foo.py" on the command line will *still* not work...
>
> Calling it python.exe would make the most sense for people who don't 
> look behind the curtain, but I agree it could potentially be confusing 
> for people.  Further, we would need to ensure we didn't create an 
> infinite loop where the launcher python.exe found a python.exe it 
> thought was an appropriate sub-process, but where it turns out it is 
> actually another launcher.
>

Sounds like fun. :-)

> Having it installed by the Python installer also makes sense to me but 
> I'd be very interested in Martin's take on this (and also on 
> everything else we are discussing here).
>
Ditto.

>> * we're (yet again) making instructions for running stuff on Windows
>> *different* to other platforms (and making tutorials written for other
>> pythons "not work" in certain ways)
>
> Actually, I'd argue we are making them more similar as we would be 
> honoring a shebang line and allowing the exact same mechanism be used 
> to denote the major version of Python needed.
>
Well, except (as pointed out a few minutes ago) that *isn't* what unix 
does ("python foo.py" does not honour the shebang). It gets us to 
something that works reliably though so I still like the idea.

>> * as I work with multiple platforms it would be really nice if the same
>> invocations worked across all of them - whilst I say again that I really
>> like the idea of the launcher it doesn't conflict with the other
>> suggestions (creating multiple binaries) and as you (Mark) say it
>> wouldn't hurt...
>>
>> So why not do both? We could create the extra binaries to bring Python
>> on Windows inline with the unix conventions for command line
>> invocations, and the new launcher can follow on as a nice addition.
>>
>> Note that the discussions about the Python installer adding to the PATH
>> won't be *ended* by the creation of the installer. A typical install on
>> a Unix-like system adds various other utilities to the path that merely
>> adding the top-level of your Python install on Windows still doesn't
>> add. In particular distutils installed scripts go into a subdirectory of
>> your Python install.
>
> The distutils scripts are a good point.  To be honest, apart from the 
> "file association" issue, I can't see much advantage in doing both - 
> if all Python directories end up on your path such that "python3 
> foo.py" magically works, then the launcher script is adding complexity 
> without bringing much to the table.  Further, I'm somewhat skeptical 
> that the file associations are used by that many people in the real 
> world - currently when you double-click on a script you get a temp 
> console created, and should a traceback be raised, you get to see it 
> for about 2ms before the console is destroyed.  Some people may be 
> .pyw to avoid that, but then their script has to go to extraordinary 
> lengths to display such errors in a UI of some kind.  I suspect most 
> people just find it more convenient to launch such scripts from a 
> console.  Maybe a quick poll on python-list would be reasonable...

The launcher program could thrive without *having* to be part of a 
standard Python install. Offering it separately makes sense even if it 
*is* included. If we do both then users can vote with their feet.

Personally I suspect that many people, particularly new programmers, 
will appreciate the launcher but more advanced developers will want more 
precise control (and similarity to unix for command line invocations).

I agree with you about file associations. They are useful for .pyw 
programs (like IDLE), but not for scripts.

All the best,

Michael

>
> 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


From greg.ewing at canterbury.ac.nz  Tue Mar  8 00:05:22 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 08 Mar 2011 12:05:22 +1300
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <4D7498F1.3070602@arbash-meinel.com>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
	<il1hhr$mrr$1@dough.gmane.org> <4D7498F1.3070602@arbash-meinel.com>
Message-ID: <4D7564B2.1060703@canterbury.ac.nz>

I'm wondering whether one major release is enough of a
deprecation period in the current situation. Many people
haven't started using 3.x in earnest yet, and by the
time they do, several major releases will have already
gone by.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Tue Mar  8 00:15:20 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 08 Mar 2011 12:15:20 +1300
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D74B834.905@skippinet.com.au>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com>
	<AANLkTimf6X7X6csQ9a2gbbJUGt2GEsqAVJyz9qqNGP2G@mail.gmail.com>
	<4D74B834.905@skippinet.com.au>
Message-ID: <4D756708.8080003@canterbury.ac.nz>

Mark Hammond wrote:

> Yup - although I think a pythonw.exe launcher would be needed too

Couldn't the launcher look at the extension of the file being
launched to decide about this?

-- 
Greg

From jsbueno at python.org.br  Tue Mar  8 00:16:03 2011
From: jsbueno at python.org.br (Joao S. O. Bueno)
Date: Mon, 7 Mar 2011 20:16:03 -0300
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <4D7564B2.1060703@canterbury.ac.nz>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
	<il1hhr$mrr$1@dough.gmane.org> <4D7498F1.3070602@arbash-meinel.com>
	<4D7564B2.1060703@canterbury.ac.nz>
Message-ID: <AANLkTin465maHAOWKC2q4J-p_3urVjrCs3edW5jnHQ2V@mail.gmail.com>

On Mon, Mar 7, 2011 at 8:05 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> I'm wondering whether one major release is enough of a
> deprecation period in the current situation. Many people
> haven't started using 3.x in earnest yet, and by the
> time they do, several major releases will have already
> gone by.

That, IMHO, makes it less severe to drop things being marked as
deprecated after just one
major release . This way, most changes can take place before people
migrate to 3.x, and
get all the news at once when they do.

  js
 -><-

>
> --
> Greg
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>

From brendan at kublai.com  Tue Mar  8 00:19:17 2011
From: brendan at kublai.com (Brendan Cully)
Date: Mon, 7 Mar 2011 15:19:17 -0800
Subject: [Python-Dev] combined hg incoming patch
In-Reply-To: <0113DA3C-0FD9-4527-B819-8B2C5928A8C7@kublai.com>
References: <4D75483A.50600@v.loewis.de>
	<03D49162-8E97-464F-A1EA-F156C94FAC7D@kublai.com>
	<4D7559B3.8060605@v.loewis.de>
	<0113DA3C-0FD9-4527-B819-8B2C5928A8C7@kublai.com>
Message-ID: <C0BE2765-BE3D-4A4A-8B00-3132A2940D51@kublai.com>

On 2011-03-07, at 2:30 PM, Brendan Cully wrote:

> On 2011-03-07, at 2:18 PM, Martin v. L?wis wrote:
> 
>> Am 07.03.2011 23:09, schrieb Brendan Cully:
>>> On 2011-03-07, at 1:03 PM, Martin v. L?wis wrote:
>>> 
>>>> I'd like to experiment with adding Rietveld support for reviewing
>>>> remote repositories. For that, I'd need to create a single patch
>>>> (programmatically) that covers all incoming changes. 'hg incoming -p'
>>>> mostly works, but it may provide multiple patches for a single file,
>>>> which I think would harm the review (since some changes may be superseded in a separate patch).
>>>> 
>>>> So I would need to compute the most recent revision in both repositories, and then create a diff between the default head
>>>> of the remote repository and that base revision.
>>> 
>>> You might like the rdiff extension, which does essentially this.
>>> 
>>> http://mercurial.selenic.com/wiki/RdiffExtension
>> 
>> I've looked at it, and it does something different. It computes the diff between the local tip and the remote tip. What I want is a diff between the common ancestor between the two, and the remote tip.
> 
> Ah right. Well, I think this shell should work (with hg new enough to have revsets):
> 
> hg in --bundle tmp.bundle
> hg diff -r 'outgoing(.)' -R tmp.bundle

Sorry, I didn't think that through. Revsets still have the power though:

hg -R tmp.bundle diff -r'ancestor(.,default)' -r default

(assuming your local repo is at the tip of default)


From brian.curtin at gmail.com  Tue Mar  8 00:32:43 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Mon, 7 Mar 2011 17:32:43 -0600
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <4D7564B2.1060703@canterbury.ac.nz>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>
	<il1hhr$mrr$1@dough.gmane.org> <4D7498F1.3070602@arbash-meinel.com>
	<4D7564B2.1060703@canterbury.ac.nz>
Message-ID: <AANLkTi=JcLCM4EpZQ7SoPiou7Nhr2_=kBZYSQ5B0Tj2O@mail.gmail.com>

On Mon, Mar 7, 2011 at 17:05, Greg Ewing <greg.ewing at canterbury.ac.nz>wrote:

> Many people haven't started using 3.x in earnest yet, and by the
> time they do, several major releases will have already gone by.


Sounds like motivation to me :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/e7ef532d/attachment.html>

From greg.ewing at canterbury.ac.nz  Tue Mar  8 00:52:42 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 08 Mar 2011 12:52:42 +1300
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D754123.7070703@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
Message-ID: <4D756FCA.4070509@canterbury.ac.nz>

Michael Foord wrote:

>     - I doubt calling it python.exe will fly, but I'm not sure. If so 
> what will you call what is currently 'python.exe'? - if not then "python 
> foo.py" on the command line will *still* not work...

However, if it's installed as the exe associated with the .py
and .pyw extensions, then simply 'foo.py' on the command line
*will* work, and will work better than it does now.

-- 
Greg

From fuzzyman at voidspace.org.uk  Tue Mar  8 01:00:11 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 08 Mar 2011 00:00:11 +0000
Subject: [Python-Dev] [PEPs] Support the
	/usr/bin/python2	symlink	upstream
In-Reply-To: <4D756FCA.4070509@canterbury.ac.nz>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>
	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>
	<4D754123.7070703@voidspace.org.uk>
	<4D756FCA.4070509@canterbury.ac.nz>
Message-ID: <4D75718B.7050908@voidspace.org.uk>

On 07/03/2011 23:52, Greg Ewing wrote:
> Michael Foord wrote:
>
>>     - I doubt calling it python.exe will fly, but I'm not sure. If so 
>> what will you call what is currently 'python.exe'? - if not then 
>> "python foo.py" on the command line will *still* not work...
>
> However, if it's installed as the exe associated with the .py
> and .pyw extensions, then simply 'foo.py' on the command line
> *will* work, and will work better than it does now.
>
So long as '.py' and '.pyw' are set in the PATHEXT environment variable. 
(Which again the Python installer doesn't do by default.)

Michael

-- 
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


From skippy.hammond at gmail.com  Tue Mar  8 01:10:05 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Tue, 08 Mar 2011 11:10:05 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D756708.8080003@canterbury.ac.nz>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>
	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<AANLkTimf6X7X6csQ9a2gbbJUGt2GEsqAVJyz9qqNGP2G@mail.gmail.com>	<4D74B834.905@skippinet.com.au>
	<4D756708.8080003@canterbury.ac.nz>
Message-ID: <4D7573DD.3030906@gmail.com>

On 8/03/2011 10:15 AM, Greg Ewing wrote:
> Mark Hammond wrote:
>
>> Yup - although I think a pythonw.exe launcher would be needed too
>
> Couldn't the launcher look at the extension of the file being
> launched to decide about this?

Nope - the launcher itself must be marked as "console" or "windows", and 
hence would suffer the exact same problem which needs us to have 
python.exe and pythonw.exe in the first place (ie, in some cases you get 
a "temp" console where you don't want one, and in other cases you get a 
new console where you wanted an existing one to be used)

Mark



From a.badger at gmail.com  Tue Mar  8 01:13:18 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 7 Mar 2011 16:13:18 -0800
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <AANLkTi=-jeCJrtqhA6J4ng8p6gf9SZuLxj+3ZuFSRVka@mail.gmail.com>
References: <20110302125641.GM30982@piotro.eu>
	<AANLkTikK7OrnHOFMZ+a0JZUsEwCCMA7naLMY8NJ-9HT4@mail.gmail.com>
	<20110303085525.GQ30982@piotro.eu>
	<20110303170804.GD3275@unaka.lan>
	<20110303214623.64e880ba@neurotica.wooz.org>
	<20110304043707.GF3275@unaka.lan>
	<20110304135639.2bef9975@neurotica.wooz.org>
	<20110304200043.GG3275@unaka.lan>
	<20110307103019.32fb7a9c@neurotica.wooz.org>
	<AANLkTi=-jeCJrtqhA6J4ng8p6gf9SZuLxj+3ZuFSRVka@mail.gmail.com>
Message-ID: <20110308001318.GL3275@unaka.lan>

On Tue, Mar 08, 2011 at 08:25:50AM +1000, Nick Coghlan wrote:
> On Tue, Mar 8, 2011 at 1:30 AM, Barry Warsaw <barry at python.org> wrote:
> > On Mar 04, 2011, at 12:00 PM, Toshio Kuratomi wrote:
> >
> >>Actually, my post was saying that these two can be decoupled. ?ie: It's
> >>possible to not have /usr/bin/python while still allowing users to type
> >>python at a shell prompt and get the interpreter.
> >>
> >>This is done by either redefining the PATH to include the directory that the
> >>interpreter named "python" is in or by creating an alias for python to the
> >>proper interpreter.
> >
> > I personally would prefer aliasing rather than $PATH manipulation.
> 
> Toshio's suggestion wouldn't work anyway - the "/usr/bin/env python"
> idiom will pick up a "python" alias no matter where it lives on $PATH.
> 
I thought I pointed out that env wouldn't work with PATH but I guess I just
thought that silently in my head.  Pointing that out was going to live in
the same paragraph as saying that it does work with an alias::

$ sudo mv /usr/bin/python /usr/bin/python.bak
$ alias python='/usr/bin/python2.7'
$ python --version
Python 2.7
$ cat test.py
#! /bin/env python
print 'hi'
$ ./test.py
/bin/env: python: No such file or directory
$ mv /usr/bin/python.bak /usr/bin/python
$ ./test.py
hi


-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/5815a1a1/attachment.pgp>

From stutzbach at google.com  Tue Mar  8 02:28:16 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Mon, 7 Mar 2011 17:28:16 -0800
Subject: [Python-Dev] hg diff
In-Reply-To: <20110307194416.1a82800b@pitrou.net>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
Message-ID: <AANLkTikGzMdm1BESbV3i-GyW4brgFmcRz7rUXrmmwUo2@mail.gmail.com>

On Antoine Pitrou <solipsis at pitrou.net> wrote:

> How do you review a branch?


Below is an example from github (because that's where my experience with
reviewing DCVS branches comes from), but I think it communicates the idea
well.

The user hsoft forked my blist project, made some changes, and sent me a
request to pull from his branch.  This is what I see:
https://github.com/DanielStutzbach/blist/pull/30/files

On Antoine Pitrou <solipsis at pitrou.net> wrote:

> You are assuming that I, as a
> reviewer, want to know about the history of changesets that led to the
> patch, but I don't: I want to read the patch as a cohesive whole, and I
> couldn't care less about the various typo fixes, style changes,
> performance tweaks that were checked in all along.
>

With a branch you can easily view the full patch, making a branch strictly
more general.

The advantage of having a branch comes when you want to review the second or
third iteration of a proposed change.  With a branch, you can view the diff
between the latest iteration and the branch point to view the change as a
cohesive whole.  Or you can view the diff between the latest iteration and
the last iteration you reviewed, to see if they have addressed your earlier
comments or not.

You can also just tweak a few things and push the changes back to them.
 They can easily merge your changes with any changes they've made in the
meantime (which is hard to do if you're pushing patch files around).

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/d1df6566/attachment.html>

From thomas at python.org  Tue Mar  8 03:18:00 2011
From: thomas at python.org (Thomas Wouters)
Date: Mon, 7 Mar 2011 18:18:00 -0800
Subject: [Python-Dev] hg diff
In-Reply-To: <AANLkTikGzMdm1BESbV3i-GyW4brgFmcRz7rUXrmmwUo2@mail.gmail.com>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
	<AANLkTikGzMdm1BESbV3i-GyW4brgFmcRz7rUXrmmwUo2@mail.gmail.com>
Message-ID: <AANLkTinh-hjcaAXcCBu07ZRnyA8HWU-wemhTw1SRewCo@mail.gmail.com>

On Mon, Mar 7, 2011 at 17:28, Daniel Stutzbach <stutzbach at google.com> wrote:

> With a branch you can easily view the full patch, making a branch strictly
> more general.
>
> The advantage of having a branch comes when you want to review the second
> or third iteration of a proposed change.  With a branch, you can view the
> diff between the latest iteration and the branch point to view the change as
> a cohesive whole.  Or you can view the diff between the latest iteration and
> the last iteration you reviewed, to see if they have addressed your earlier
> comments or not.
>
> You can also just tweak a few things and push the changes back to them.
>  They can easily merge your changes with any changes they've made in the
> meantime (which is hard to do if you're pushing patch files around).
>

Actually, it isn't. As I said, Rietveld handles this the same way. The fact
that it got there by analyzing subsequent patches is really immaterial --
except in so far as it marks the intended changes more clearly.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/2eb5b2d2/attachment-0001.html>

From v+python at g.nevcal.com  Tue Mar  8 03:33:12 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Mon, 07 Mar 2011 18:33:12 -0800
Subject: [Python-Dev] [PEPs] Support the
	/usr/bin/python2	symlink	upstream
In-Reply-To: <4D75718B.7050908@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<4D756FCA.4070509@canterbury.ac.nz>
	<4D75718B.7050908@voidspace.org.uk>
Message-ID: <4D759568.9000508@g.nevcal.com>

On 3/7/2011 4:00 PM, Michael Foord wrote:
> On 07/03/2011 23:52, Greg Ewing wrote:
>> Michael Foord wrote:
>>
>>>     - I doubt calling it python.exe will fly, but I'm not sure. If 
>>> so what will you call what is currently 'python.exe'? - if not then 
>>> "python foo.py" on the command line will *still* not work...
>>
>> However, if it's installed as the exe associated with the .py
>> and .pyw extensions, then simply 'foo.py' on the command line
>> *will* work, and will work better than it does now.
>>
> So long as '.py' and '.pyw' are set in the PATHEXT environment 
> variable. (Which again the Python installer doesn't do by default.)


No, PATHEXT only means you can invoke

foo.py

and

foo

and get the same results (sometimes, depending on what all in on PATH 
and PATHEXT)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/86bdc477/attachment.html>

From v+python at g.nevcal.com  Tue Mar  8 03:42:01 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Mon, 07 Mar 2011 18:42:01 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>
	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>
	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>
	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
Message-ID: <4D759779.9050505@g.nevcal.com>

On 3/7/2011 2:18 PM, James Y Knight wrote:
> On Mar 7, 2011, at 3:49 PM, Paul Moore wrote:
>> >  The launcher could also (as per Mark's suggestion) interpret a shebang
>> >  line in the script, so that scripts could specify their required
>> >  version without needing a different command,or multiple
>> >  version-specific extensions.
> Note that, on Unix, "python file.py" doesn't choose the correct version of python to run by looking at a shebang, it just runs the version of python installed as "python". Only "./file.py" looks at the shebang (assuming that file is marked executable).
>
> Is the proposal to make python.exe do that on windows? That is a rather significant difference from the unix behavior.


The launcher need not be called "python.exe", and maybe it would be 
better called  #@launcher.exe  (or similar, depending on its exact 
function details).

For launching from the command line, if various versions python binaries 
or batch files are on the PATH, then appropriate explicit python invocation

python foo.py   # Just like Unix
python2 foo.py
python3 foo.py

should launch the specified version (where python may be somewhat 
ambiguous) but

foo.py  # with the help of a launcher this could be just like Unix too

would implicitly use the launcher, as would launching it from the GUI.

There are two problems here, explicit command-line invocation, and 
GUI/assoc invocation.  A launcher need not, and probably should not, do 
anything for explicit python invocation, but would only solve the 
implicit and GUI type of invocations.

From stephen at xemacs.org  Tue Mar  8 04:01:16 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 08 Mar 2011 12:01:16 +0900
Subject: [Python-Dev] hg diff
In-Reply-To: <20110307140243.6ada217b@neurotica.wooz.org>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
	<20110307140243.6ada217b@neurotica.wooz.org>
Message-ID: <87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > I hear this complaint [about branches being no help in reviewing] a
 > lot from hg and git users, so maybe it's just the nature of the
 > tools.  In which case, I'm fine with whatever works better for
 > Python.

First, let me remind you that PEP 374 was quite clear about one thing.
"Read my lips: No new workflows!"  But this was practicality over
purity, not vice versa.  That is, the idea was to minimize change to
the workflow until the contributors are used to the new VCS.  Clearly,
not everybody is, yet.  So everything below is referring to the medium
to long term.

>From experience in XEmacs, which uses hg as the VCS for 3 years now
but still has a diff | sendmail review process, I would have to agree
that for *most* contributions by *most* users having the patch in the
change proposal is more convenient than using a separate branch.

However, as Michael points out, you can have your tools generate the
patch.  For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU burden).  So I don't see why branch-based submissions should be
*harder* to use than patch-based submissions (in the long run).

OTOH, for larger features, which tend to be composites of smaller
features, it's often useful to me to have a series of changesets
representing each subfeature.  Email6, I'm looking at you!<wink>  Also
for patches that go through several iterations, I *do* sometimes check
the logs and individual diffs if available.  In a patch-based
workflow, it's not unheard of for a contributor to revert desired
changes along with undesired ones, and omit restoring them.  This is
less likely if the code is being developed *in* a branch, and it's
easier to detect if you have the branch available when reviewing.

Finally, a patch that goes through several iterations tends to
gradually acquire cruft in the form of merge conflict resolution as
the contributor's clone is updated to trunk tip.  These occasionally
are suboptimal because the conflicts themselves are evolving.  It's
sometimes better to resolve all the conflicts at merge to trunk time,
and I've never seen it be worse.

I think it's up to the advocates of branch-based review to improve the
tools, and I think it's worth it.  Now, if only I can find some
time...

From thomas at python.org  Tue Mar  8 07:57:20 2011
From: thomas at python.org (Thomas Wouters)
Date: Mon, 7 Mar 2011 22:57:20 -0800
Subject: [Python-Dev] [Python-checkins] (3.1): transform izip_longest
	#11424
In-Reply-To: <E1Pwoyu-0004nG-Av@dinsdale.python.org>
References: <E1Pwoyu-0004nG-Av@dinsdale.python.org>
Message-ID: <AANLkTi=cBe29vVCXrAGHKJzKsUySwjE=73VgNKh38RHA@mail.gmail.com>

On Mon, Mar 7, 2011 at 20:57, benjamin.peterson
<python-checkins at python.org>wrote:

> http://hg.python.org/cpython/rev/a7e0cff05597
> changeset:   68323:a7e0cff05597
> branch:      3.1
> parent:      68317:d9125bf3bac5
> user:        Benjamin Peterson <benjamin at python.org>
> date:        Mon Mar 07 22:50:37 2011 -0600
> summary:
>  transform izip_longest #11424
>

Could we get a little less cryptic checkin messages? I have no idea what
this is supposed to mean (and it doesn't look related to
http://bugs.python.org/issue11424 either.) When looking through the changes
(for example when figuring out when a change was introduced and whether it
was intentional) it's really helpful if the checkin message explains the
intent without having to visit the bugtracker for each one.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110307/66b1c106/attachment.html>

From martin at v.loewis.de  Tue Mar  8 09:34:32 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 08 Mar 2011 09:34:32 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <AANLkTikGzMdm1BESbV3i-GyW4brgFmcRz7rUXrmmwUo2@mail.gmail.com>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>
	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>	<20110307194416.1a82800b@pitrou.net>
	<AANLkTikGzMdm1BESbV3i-GyW4brgFmcRz7rUXrmmwUo2@mail.gmail.com>
Message-ID: <4D75EA18.1070208@v.loewis.de>

> With a branch you can easily view the full patch, making a branch
> strictly more general.

I just asked this before: how *exactly* do you do that?

Regards,
Martin

From martin at v.loewis.de  Tue Mar  8 09:38:27 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 08 Mar 2011 09:38:27 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>
	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>	<20110307194416.1a82800b@pitrou.net>	<20110307140243.6ada217b@neurotica.wooz.org>
	<87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D75EB03.8040208@v.loewis.de>

> However, as Michael points out, you can have your tools generate the
> patch.  For example, it shouldn't be too hard to add a dynamic patch
> generator to Roundup (although I haven't thought about the UI or the
> CPU burden).

For Mercurial, that's more difficult than you might expect. There is "hg 
incoming -p", but it has the nasty problem that it may produce
multiple patches for a single file.

Regards,
Martin

From martin at v.loewis.de  Tue Mar  8 10:03:45 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 08 Mar 2011 10:03:45 +0100
Subject: [Python-Dev] combined hg incoming patch
In-Reply-To: <C0BE2765-BE3D-4A4A-8B00-3132A2940D51@kublai.com>
References: <4D75483A.50600@v.loewis.de>
	<03D49162-8E97-464F-A1EA-F156C94FAC7D@kublai.com>
	<4D7559B3.8060605@v.loewis.de>
	<0113DA3C-0FD9-4527-B819-8B2C5928A8C7@kublai.com>
	<C0BE2765-BE3D-4A4A-8B00-3132A2940D51@kublai.com>
Message-ID: <4D75F0F1.4000905@v.loewis.de>

> Sorry, I didn't think that through. Revsets still have the power though:
>
> hg -R tmp.bundle diff -r'ancestor(.,default)' -r default
>
> (assuming your local repo is at the tip of default)

I can't make this work. I'm using hg 1.6.4, which does have revsets and
(including ancestor). Still, with this command, I get

martin at mira:~/work/3k$ LANG=C hg -R tmp.bundle diff 
-r'ancestor(.,default)' -r default
abort: unknown revision 'ancestor(.,default)'!

Regards,
Martin

From martin at v.loewis.de  Tue Mar  8 10:33:56 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 08 Mar 2011 10:33:56 +0100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2
	symlink	upstream
In-Reply-To: <4D7560A6.4030802@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<4D6D8BE8.7020808@v.loewis.de>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>
	<4D754123.7070703@voidspace.org.uk> <4D7560A6.4030802@gmail.com>
Message-ID: <4D75F804.6030405@v.loewis.de>

> Calling it python.exe would make the most sense for people who don't
> look behind the curtain, but I agree it could potentially be confusing
> for people. Further, we would need to ensure we didn't create an
> infinite loop where the launcher python.exe found a python.exe it
> thought was an appropriate sub-process, but where it turns out it is
> actually another launcher.
>
> Having it installed by the Python installer also makes sense to me but
> I'd be very interested in Martin's take on this (and also on everything
> else we are discussing here).

I think I would be opposed to adding a launcher to 2.7. It also
wouldn't be necessary - if it was released with 3.3, then it could
still do version switching for 2.7.

If it's called "python.exe", I wonder what it should do when given a
file that doesn't carry version information.

> I suspect most people just
> find it more convenient to launch such scripts from a console. Maybe a
> quick poll on python-list would be reasonable...

I certainly have script files that I double-click. However, those happen
to be batch files, not Python. If I would do scripting in Python (which
I don't do much these days), I would like to be able to double-click
them. I always write my scripts so that they don't give exceptions :-)

Actually, the one Python script I run regularly is msi.py, and I
currently launch it in a terminal window, because I need to run it with
c:\python25\python.exe, which double-clicking won't do for me. If I
could double-click it, I would like that more (there is also the issue
that the script needs the VS envvars set, so I'd need to find a solution
to that, also).

Regards,
Martin

From martin at v.loewis.de  Tue Mar  8 10:36:24 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 08 Mar 2011 10:36:24 +0100
Subject: [Python-Dev] [PEPs] Support
	the	/usr/bin/python2	symlink	upstream
In-Reply-To: <4D75718B.7050908@voidspace.org.uk>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<1299179864.15972.5.camel@radiator.bos.redhat.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<4D756FCA.4070509@canterbury.ac.nz>
	<4D75718B.7050908@voidspace.org.uk>
Message-ID: <4D75F898.3050402@v.loewis.de>

Am 08.03.2011 01:00, schrieb Michael Foord:
> On 07/03/2011 23:52, Greg Ewing wrote:
>> Michael Foord wrote:
>>
>>> - I doubt calling it python.exe will fly, but I'm not sure. If so
>>> what will you call what is currently 'python.exe'? - if not then
>>> "python foo.py" on the command line will *still* not work...
>>
>> However, if it's installed as the exe associated with the .py
>> and .pyw extensions, then simply 'foo.py' on the command line
>> *will* work, and will work better than it does now.
>>
> So long as '.py' and '.pyw' are set in the PATHEXT environment variable.
> (Which again the Python installer doesn't do by default.)

Running foo.py works fine with the current installers (just try to see
for yourself). You don't need PATHEXT for that.

Regards,
Martin

From gklein at xs4all.nl  Tue Mar  8 10:40:44 2011
From: gklein at xs4all.nl (Gertjan Klein)
Date: Tue, 08 Mar 2011 10:40:44 +0100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
References: <AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72
	F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
	<4D7560A6.4030802@gmail.com> <4D75631E.90401@voidspace.org.uk>
Message-ID: <pjsbn69ao0isflfaju4b3191ckic1sgurl@4ax.com>

Michael Foord wrote:

>The launcher program could thrive without *having* to be part of a 
>standard Python install. Offering it separately makes sense even if it 
>*is* included. If we do both then users can vote with their feet.

A launcher might be difficult to integrate into the Python installer, as
there can, by definition, only be one. What if I install a new version
of Python and then uninstall it? Will the launcher be uninstalled as
well? Will it be reverted to a previous version, and if so, which?

I am actually working on such a launcher for myself right now. The main
problem I am trying to solve is doubleclicking a .py or .pyw file and
having it run in the Python version it is intended for. From the command
line, I want "something.py arg1 ... argn" to do the right thing as well.
I don't care much for fixing "python something.py arg1 ... argn", as I
personally rarely need to pass options to Python. I may look into that
later, though.

My launcher parses the first line of the script for something that
starts with "#!" and contains "python<something>". It tries to match
that with a list of installed Python versions obtained from the
registry, falling back to a configurable default if no such line is
found.

As to performance of such a solution: I'm writing this in Python (2.5,
as its MSVCRT is easier to include in an exe) and converting it to an
executable with py2exe. The extra startup time is manageble on my
system. Using Python to write this in makes it much easier to experiment
with adding features. Once the dust has settled I may attempt to rewrite
it in C.

Anyway, I believe that such a launcher should not be part of Python
itself at first; an external program makes it easier to figure out what
works well.

As to adding Python to the Windows path: I'd be mildly annoyed if the
installer offered that option, and seriously annoyed if it defaulted
that option to "yes".

Gertjan.



From g.brandl at gmx.net  Tue Mar  8 10:41:05 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 08 Mar 2011 10:41:05 +0100
Subject: [Python-Dev] combined hg incoming patch
In-Reply-To: <4D75F0F1.4000905@v.loewis.de>
References: <4D75483A.50600@v.loewis.de>
	<03D49162-8E97-464F-A1EA-F156C94FAC7D@kublai.com>
	<4D7559B3.8060605@v.loewis.de>
	<0113DA3C-0FD9-4527-B819-8B2C5928A8C7@kublai.com>
	<C0BE2765-BE3D-4A4A-8B00-3132A2940D51@kublai.com>
	<4D75F0F1.4000905@v.loewis.de>
Message-ID: <il4tlc$hkp$1@dough.gmane.org>

On 08.03.2011 10:03, "Martin v. L?wis" wrote:
>> Sorry, I didn't think that through. Revsets still have the power though:
>>
>> hg -R tmp.bundle diff -r'ancestor(.,default)' -r default
>>
>> (assuming your local repo is at the tip of default)
> 
> I can't make this work. I'm using hg 1.6.4, which does have revsets and
> (including ancestor). Still, with this command, I get
> 
> martin at mira:~/work/3k$ LANG=C hg -R tmp.bundle diff 
> -r'ancestor(.,default)' -r default
> abort: unknown revision 'ancestor(.,default)'!

ISTM that "hg diff" doesn't accept revsets in 1.6.

Georg



From stefan-usenet at bytereef.org  Tue Mar  8 10:45:41 2011
From: stefan-usenet at bytereef.org (Stefan Krah)
Date: Tue, 8 Mar 2011 10:45:41 +0100
Subject: [Python-Dev] v2.7 tag
Message-ID: <20110308094541.GA13505@sleipnir.bytereef.org>

Hi,

I can't update to v2.7 in the new cpython repository:

$ hg up v2.7
abort: unknown revision 'v2.7'!


Am I missing something here? My goal is to get the same directory state
as from this command:

svn co http://svn.python.org/projects/python/tags/r27


Stefan Krah



From dirkjan at ochtman.nl  Tue Mar  8 10:49:53 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Tue, 8 Mar 2011 10:49:53 +0100
Subject: [Python-Dev] v2.7 tag
In-Reply-To: <20110308094541.GA13505@sleipnir.bytereef.org>
References: <20110308094541.GA13505@sleipnir.bytereef.org>
Message-ID: <AANLkTik_r4DavOy5xCHu-oFFH1S9-4wTVE2rV4KLp2xw@mail.gmail.com>

On Tue, Mar 8, 2011 at 10:45, Stefan Krah <stefan-usenet at bytereef.org> wrote:
> Hi,
>
> I can't update to v2.7 in the new cpython repository:
>
> $ hg up v2.7
> abort: unknown revision 'v2.7'!
>
> Am I missing something here? My goal is to get the same directory state
> as from this command:
>
> svn co http://svn.python.org/projects/python/tags/r27

Did you by any chance use hg clone -rv2.7? That's a common gotcha:
that will only clone the repository up to but not including the
tagging changeset (the tip in the clone will be the tagged changeset),
meaning a subsequent update to the tag will fail.

Cheers,

Dirkjan

From adrian at cadifra.com  Tue Mar  8 10:53:13 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Tue, 08 Mar 2011 10:53:13 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <4D75EB03.8040208@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>	<20110307194416.1a82800b@pitrou.net>	<20110307140243.6ada217b@neurotica.wooz.org>	<87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D75EB03.8040208@v.loewis.de>
Message-ID: <4D75FC89.9040903@cadifra.com>

On 2011-03-08 09:38, "Martin v. L?wis" wrote:
>> However, as Michael points out, you can have your tools generate the
>> patch.  For example, it shouldn't be too hard to add a dynamic patch
>> generator to Roundup (although I haven't thought about the UI or the
>> CPU burden).
> 
> For Mercurial, that's more difficult than you might expect. There is "hg 
> incoming -p", but it has the nasty problem that it may produce
> multiple patches for a single file.

I didn't follow/understand closely/completely what your problems is, but
I wouldn't be surprised if mercurial's 'incoming' command has its
limitations (it's most likely intentional, since remote inspection is
limited on purpose and frowned upon by design).

In general, you have to have all the changesets in a local repo to enjoy
the full power of mercurial's history inspection tools.

Maybe the following trick could be interesting for you:

If you don't want to do an outright pull from a (possibly dubious)
remote repo into your precious local repo yet, you can instead
"superimpose" a separate overlay bundle file on your local repo.

Example (initial step):

  $ cd cpython
  $ hg -q incoming --bundle in.hg
  68322:8947c47a9fef
  68323:a7e0cff05597
  68324:88bbc574cfb0
  68325:c43d685e1533
  68326:a69ef22b60e3
  68327:770d45d22a40

Now, you have a mercurial bundle file named "in.hg" which contains all
these incoming changes, but -- of course -- the changes haven't yet been
added to the repo.

The interesting thing is, you can now superimpose this bundle on your
repo, which has the effect that the aggregate is treated as if the
changes had already been pulled.

Continuing my example, let's now specify the bundle "in.hg" as an
*overlay* by using the option -R/--repository [1]:

  $ hg -R in.hg log -r tip
  changeset:   68327:770d45d22a40
  branch:      2.7
  tag:         tip
  parent:      68321:d9cc58f93d72
  user:        Benjamin Peterson <...>
  date:        Mon Mar 07 22:50:37 2011 -0600
  summary:     transform izip_longest #11424

The fun thing with overlay bundles is: you have the full power of all
mercurial history inspection commands as if the changesets had already
been added to your repo.

As an added extra bonus, you can later unbundle the bundle into your
repo without another network round trip -- assuming you are pleased with
what you've seen coming in:

  $ hg unbundle in.hg
  adding changesets
  adding manifests
  adding file changes
  added 6 changesets with 6 changes to 3 files
  (run 'hg update' to get a working copy)

BTW, we regularly use overlay bundles under the hood of TortoiseHg.

[1]
'hg help -v' says:
global options:
 -R --repository REPO    repository root directory or name of overlay
                         bundle file

From martin at v.loewis.de  Tue Mar  8 10:57:53 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 08 Mar 2011 10:57:53 +0100
Subject: [Python-Dev] v2.7 tag
In-Reply-To: <AANLkTik_r4DavOy5xCHu-oFFH1S9-4wTVE2rV4KLp2xw@mail.gmail.com>
References: <20110308094541.GA13505@sleipnir.bytereef.org>
	<AANLkTik_r4DavOy5xCHu-oFFH1S9-4wTVE2rV4KLp2xw@mail.gmail.com>
Message-ID: <4D75FDA1.2060801@v.loewis.de>

Am 08.03.2011 10:49, schrieb Dirkjan Ochtman:
> On Tue, Mar 8, 2011 at 10:45, Stefan Krah<stefan-usenet at bytereef.org>  wrote:
>> Hi,
>>
>> I can't update to v2.7 in the new cpython repository:
>>
>> $ hg up v2.7
>> abort: unknown revision 'v2.7'!
>>
>> Am I missing something here? My goal is to get the same directory state
>> as from this command:
>>
>> svn co http://svn.python.org/projects/python/tags/r27
>
> Did you by any chance use hg clone -rv2.7?

No: the cpython repository simply does not contain a tag called 'v2.7'. 
Not sure why not; v2.7rc1 and v2.7.1 are present.

Regards,
Martin

From schmir at gmail.com  Tue Mar  8 11:04:00 2011
From: schmir at gmail.com (Ralf Schmitt)
Date: Tue, 08 Mar 2011 11:04:00 +0100
Subject: [Python-Dev] git mirror [Re:  CPython hg transition complete]
In-Reply-To: <iktsh9$1fl$1@dough.gmane.org> (Georg Brandl's message of "Sat,
	05 Mar 2011 18:39:52 +0100")
References: <iktsh9$1fl$1@dough.gmane.org>
Message-ID: <877hca2ajz.fsf@muni.brainbot.com>

Georg Brandl <g.brandl at gmx.net> writes:

> I'm very happy to announce that the core Python repository switch
> to Mercurial is complete and the new repository at
> http://hg.python.org/cpython/ is now officially open for cloning,
> and for commits by those who had commit access to SVN.

I've setup a git mirror of that repository on github:
https://github.com/schmir/python

Cheers,
- Ralf

From g.brandl at gmx.net  Tue Mar  8 11:08:40 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 08 Mar 2011 11:08:40 +0100
Subject: [Python-Dev] v2.7 tag
In-Reply-To: <4D75FDA1.2060801@v.loewis.de>
References: <20110308094541.GA13505@sleipnir.bytereef.org>
	<AANLkTik_r4DavOy5xCHu-oFFH1S9-4wTVE2rV4KLp2xw@mail.gmail.com>
	<4D75FDA1.2060801@v.loewis.de>
Message-ID: <il4v8v$pa5$1@dough.gmane.org>

On 08.03.2011 10:57, "Martin v. L?wis" wrote:
> Am 08.03.2011 10:49, schrieb Dirkjan Ochtman:
>> On Tue, Mar 8, 2011 at 10:45, Stefan Krah<stefan-usenet at bytereef.org>  wrote:
>>> Hi,
>>>
>>> I can't update to v2.7 in the new cpython repository:
>>>
>>> $ hg up v2.7
>>> abort: unknown revision 'v2.7'!
>>>
>>> Am I missing something here? My goal is to get the same directory state
>>> as from this command:
>>>
>>> svn co http://svn.python.org/projects/python/tags/r27
>>
>> Did you by any chance use hg clone -rv2.7?
> 
> No: the cpython repository simply does not contain a tag called 'v2.7'. 
> Not sure why not; v2.7rc1 and v2.7.1 are present.

I just fixed this.  The revision that added the "v2.7" tag was the last
commit on legacy-trunk, and as such an extra head that didn't get pulled
into the "working" repo when we pruned the full-history repo.

The 2.7.1rc1 tag was also wrongly called "2.7rc1"; that was a copy-paste
error in the tagmap used while converting.

Georg


From adrian at cadifra.com  Tue Mar  8 11:07:55 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Tue, 08 Mar 2011 11:07:55 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <4D75FC89.9040903@cadifra.com>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>	<20110307194416.1a82800b@pitrou.net>	<20110307140243.6ada217b@neurotica.wooz.org>	<87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D75EB03.8040208@v.loewis.de>
	<4D75FC89.9040903@cadifra.com>
Message-ID: <4D75FFFB.1030204@cadifra.com>

On 2011-03-08 10:53, Adrian Buehlmann wrote:
> On 2011-03-08 09:38, "Martin v. L?wis" wrote:
>>> However, as Michael points out, you can have your tools generate the
>>> patch.  For example, it shouldn't be too hard to add a dynamic patch
>>> generator to Roundup (although I haven't thought about the UI or the
>>> CPU burden).
>>
>> For Mercurial, that's more difficult than you might expect. There is "hg 
>> incoming -p", but it has the nasty problem that it may produce
>> multiple patches for a single file.
> 
> I didn't follow/understand closely/completely what your problems is, but
> I wouldn't be surprised if mercurial's 'incoming' command has its
> limitations (it's most likely intentional, since remote inspection is
> limited on purpose and frowned upon by design).
> 
> In general, you have to have all the changesets in a local repo to enjoy
> the full power of mercurial's history inspection tools.
> 
> Maybe the following trick could be interesting for you:
> 
> If you don't want to do an outright pull from a (possibly dubious)
> remote repo into your precious local repo yet, you can instead
> "superimpose" a separate overlay bundle file on your local repo.

OOPS. I failed to notice that this has already been proposed in the
thread "combined hg incoming patch".

Sorry for the noise.

From solipsis at pitrou.net  Tue Mar  8 11:19:31 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 8 Mar 2011 11:19:31 +0100
Subject: [Python-Dev] hg diff
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
	<20110307140243.6ada217b@neurotica.wooz.org>
	<87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D75EB03.8040208@v.loewis.de>
Message-ID: <20110308111931.38f18a7c@pitrou.net>

On Tue, 08 Mar 2011 09:38:27 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> > However, as Michael points out, you can have your tools generate the
> > patch.  For example, it shouldn't be too hard to add a dynamic patch
> > generator to Roundup (although I haven't thought about the UI or the
> > CPU burden).
> 
> For Mercurial, that's more difficult than you might expect. There is "hg 
> incoming -p", but it has the nasty problem that it may produce
> multiple patches for a single file.

If you use named branches it's trivial, and it's suggested in the
devguide in
http://docs.python.org/devguide/committing.html#long-term-development-of-features

Regards

Antoine.



From stephen at xemacs.org  Tue Mar  8 11:30:42 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 08 Mar 2011 19:30:42 +0900
Subject: [Python-Dev] hg diff
In-Reply-To: <4D75EB03.8040208@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
	<20110307140243.6ada217b@neurotica.wooz.org>
	<87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D75EB03.8040208@v.loewis.de>
Message-ID: <87oc5lkip9.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. L?wis" writes:

 > > However, as Michael points out, you can have your tools generate the
 > > patch.  For example, it shouldn't be too hard to add a dynamic patch
 > > generator to Roundup (although I haven't thought about the UI or the
 > > CPU burden).

 > For Mercurial, that's more difficult than you might expect. There is "hg 
 > incoming -p", but it has the nasty problem that it may produce
 > multiple patches for a single file.

Doesn't "hg diff -r 'ancestor(branch,default)::branch'", where "branch"
is the unmerged branch you would like to inspect, do the right thing?

The revision function ancestor() gives the most recent common ancestor
of two revisions.

hg --version 
Mercurial Distributed SCM (version 1.8)

From nad at acm.org  Tue Mar  8 11:34:19 2011
From: nad at acm.org (Ned Deily)
Date: Tue, 08 Mar 2011 02:34:19 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<AANLkTimg2DdRomKY3S4Ze_w8BfBoJNE_sUfKkzuk9Wbr@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTim_CxGZT-kTbp6Y2L=5eY2Qi9wNdCB7S4FNTKLS@mail.gmail.com>
	<AANLkTi=VD8yck7y=Su1a+e-q0mM-49FgTr1iJ-UFPzuv@mail.gmail.com>
	<AANLkTimPEDWCsiOXfq=PpyyPfkbMR-oja54m-CnAQHQh@mail.gmail.com>
	<nad-00CA51.14065506032011@news.gmane.org>
Message-ID: <nad-5C733C.02341908032011@news.gmane.org>

After a little investigation, I think what is currently proposed in the 
PEP is fine for OS X and other systems which use the Unix makefile 
altinstall and install targets, as far as it goes.  However, for 
completeness, I think the PEP should also cover (most of) the other 
files that are installed in the "bin" directory besides python; those 
are idle, pydoc, and python-config, and 2to3.  To allow a clean eventual 
transition to Python 3 as the default, 2.7.2 should be changed to 
install the new hard links: python2, idle2, pydoc2, and python2-config.  

Currently, there are no overlapping filenames in the bin directory 
between Py2 and Py3 installs except for 2to3.  2to3 is a bit of a 
special case since it is common between Py2 and Py3; however the version 
of 2to3 itself differs between releases.  As of now, if the standard 
Makefiles are used, the user will get 2to3 from the Python release for 
which a "make install" (or for Python 2.x, a "make altinstall" as well) 
has most recently been executed.  That might not be the most recent 
version of 2to3, say, if an older Py2 release is installed after a newer 
Py3 one.  That's not good practice.  But that is also outside the scope 
of the PEP.

What is currently added to the installation bin directory for 2.7 and 
3.2 is summarized in the table below followed by the proposed changes.  
Note, the bin directory is typically /usr/bin on Unix-y systems; for Mac 
OS X framework builds, each Python minor version has its own bin 
directory within the same base Python framework.

  2.7        3.2
--- ---    --- ---
alt ins    alt ins
--- ---    --- ---
 Y   Y          Y   2to3
            Y   Y   2to3-3.2
                Y   2to3 (symlink to 2to3-3.2)
 Y   Y              idle
            Y   Y   idle3.2
                Y   idle3 (symlink to idle3.2)
 Y   Y              pydoc
            Y   Y   pydoc3.2
                Y   pydoc3 (symlink to pydoc3.2)
     Y              python (hardlink to python2.7)
     Y              python-config (symlink to python2.7-config)
 Y   Y              python2.7
 Y   Y              python2.7-config
                Y   python3 (hardlink to python3.2m)
                Y   python3-config (symlink to python3.2-config)
            Y   Y   python3.2 (hardlink to python3.2m)
                Y   python3.2-config (symlink to python3.2m-config)
            Y   Y   python3.2m
            Y   Y   python3.2m-config
 Y   Y              smtpd.py

     +              python2 (hardlink to python2.7)
     ?              idle2 (hardlink to idle)
     ?              pydoc2 (hardlink to pydoc)
     ?              python2-config (hardlink to python-config)
     X              2to3-2 (no need for 2 versions)

----
alt =  installed by "make altinstall"
ins =  installed by "make install"
Y = installed
m = optional combination of "d", "m", "u"
+ = currently in PEP 394
? = should be added to PEP 394
X = should not be added

-- 
 Ned Deily,
 nad at acm.org


From solipsis at pitrou.net  Tue Mar  8 14:19:28 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 8 Mar 2011 14:19:28 +0100
Subject: [Python-Dev] hooks: Add roundup integration hook.
References: <E1Pwv18-0002f2-4m@dinsdale.python.org>
Message-ID: <20110308141928.42bf8526@pitrou.net>

On Tue, 08 Mar 2011 12:23:54 +0100
local <python-checkins at python.org> wrote:
> +
> +VERBS = r'(?:\b(?P<verb>close[sd]?|closing|fixe[sd]|fixing|fix)\s+)?'
> +ISSUE_PATTERN = re.compile(r'%s(?:#|\bissue|\bbug)\s*(?P<issue_id>[0-9]+)'
> +                           % VERBS, re.I)

This should only match numbers with 4 and 5 figures IMO.
Otherwise things like "this is priority #1" in commit messages will
spam issue number 1 (assuming it exists).

Also, I'm not sure trying to match too many verbs is useful. Things are
clearer and more predictible if we mandate a single form, perhaps only
at the last line of the commit message. We don't want false positives
(such as messages about closed files, etc.).

Regards

Antoine.



From murman at gmail.com  Tue Mar  8 15:29:47 2011
From: murman at gmail.com (Michael Urman)
Date: Tue, 8 Mar 2011 08:29:47 -0600
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D75F804.6030405@v.loewis.de>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<4D6D8BE8.7020808@v.loewis.de>
	<1299179864.15972.5.camel@radiator.bos.redhat.com>
	<20110303211140.1e2280fd@neurotica.wooz.org>
	<20110304040954.GE3275@unaka.lan>
	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
	<4D7560A6.4030802@gmail.com> <4D75F804.6030405@v.loewis.de>
Message-ID: <AANLkTikiyjpkSdcOjZcc3+DD3tkNYFTnyfDD6VAHXOxs@mail.gmail.com>

On Tue, Mar 8, 2011 at 03:33, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> If it's called "python.exe", I wonder what it should do when given a
> file that doesn't carry version information.

I would expect it to follow the guidance of the Unix PEP as much as
possible. IIRC this means it would launch the highest 2.x version of
Python on the system. If there is no 2.x version, it would launch the
highest known version (presumably 3.x) for now. I would expect this
behavior for any unversioned name of the launcher (e.g. python.exe or
pystart.exe).

> Actually, the one Python script I run regularly is msi.py, and I
> currently launch it in a terminal window, because I need to run it with
> c:\python25\python.exe, which double-clicking won't do for me. If I
> could double-click it, I would like that more (there is also the issue
> that the script needs the VS envvars set, so I'd need to find a solution
> to that, also).

It's implicit scope creep, but perhaps the launcher could be
configured to provide certain environment tweaks, either for all
versions of Python, or specific for each version. A more extreme scope
creep could allow this information to be stored in the .py file, but
that seems backwards to me.

To think a bit further on how the launcher should resolve the version,
We should probably first see if the #! line works as an executable
with optional single argument. This would allow someone to specify
overrides like:

   #! D:\Checkout\...\python

If the file doesn't exist, fall back to scanning for python[.exe] with
or without a version (in order to support scripts with
/usr/bin/python* or /usr/bin/env python*). If it has a version follow
the version as closely as possible (map 2 to latest 2.x, 3 to latest
3.x, etc.). If it doesn't have a version, find the latest 2.x or
latest any version as above, per the most recent relevant PEP. Open
question is what to do if the script clearly requests version 2.6 but
only 2.5, 2.7 and 3.2 are installed, or requests 2.x but only 3.x is
installed; I could see erroring out as "refus[ing] the temptation to
guess".

-- 
Michael Urman

From murman at gmail.com  Tue Mar  8 15:31:53 2011
From: murman at gmail.com (Michael Urman)
Date: Tue, 8 Mar 2011 08:31:53 -0600
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <pjsbn69ao0isflfaju4b3191ckic1sgurl@4ax.com>
References: <AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
	<4D7560A6.4030802@gmail.com> <4D75631E.90401@voidspace.org.uk>
	<pjsbn69ao0isflfaju4b3191ckic1sgurl@4ax.com>
Message-ID: <AANLkTikcXAnyLgAgacRBXhP7yXokHe=TZs+zs2V8Kgmo@mail.gmail.com>

On Tue, Mar 8, 2011 at 03:40, Gertjan Klein <gklein at xs4all.nl> wrote:
> A launcher might be difficult to integrate into the Python installer, as
> there can, by definition, only be one. What if I install a new version
> of Python and then uninstall it? Will the launcher be uninstalled as
> well? Will it be reverted to a previous version, and if so, which?

As long as component rules are maintained (the same components with
same GUIDs install the same files in the same locations) and they are
marked shared, Windows Installer will handle everything for us. If the
files have versions the way Windows Installer can process them, it
will even keep the highest version of the file in place.

-- 
Michael Urman

From g.brandl at gmx.net  Tue Mar  8 17:40:13 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 08 Mar 2011 17:40:13 +0100
Subject: [Python-Dev] hooks: Add roundup integration hook.
In-Reply-To: <20110308141928.42bf8526@pitrou.net>
References: <E1Pwv18-0002f2-4m@dinsdale.python.org>
	<20110308141928.42bf8526@pitrou.net>
Message-ID: <il5m77$ttq$1@dough.gmane.org>

On 08.03.2011 14:19, Antoine Pitrou wrote:
> On Tue, 08 Mar 2011 12:23:54 +0100
> local <python-checkins at python.org> wrote:
>> +
>> +VERBS = r'(?:\b(?P<verb>close[sd]?|closing|fixe[sd]|fixing|fix)\s+)?'
>> +ISSUE_PATTERN = re.compile(r'%s(?:#|\bissue|\bbug)\s*(?P<issue_id>[0-9]+)'
>> +                           % VERBS, re.I)
> 
> This should only match numbers with 4 and 5 figures IMO.
> Otherwise things like "this is priority #1" in commit messages will
> spam issue number 1 (assuming it exists).
> 
> Also, I'm not sure trying to match too many verbs is useful. Things are
> clearer and more predictible if we mandate a single form, perhaps only
> at the last line of the commit message. We don't want false positives
> (such as messages about closed files, etc.).

Please go ahead: I'm not attached to any of the details.

Georg


From barry at python.org  Tue Mar  8 17:44:40 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 8 Mar 2011 11:44:40 -0500
Subject: [Python-Dev] hg diff
In-Reply-To: <87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
	<20110307140243.6ada217b@neurotica.wooz.org>
	<87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20110308114440.05518d7b@neurotica.wooz.org>

On Mar 08, 2011, at 12:01 PM, Stephen J. Turnbull wrote:

>Barry Warsaw writes:
>
> > I hear this complaint [about branches being no help in reviewing] a
> > lot from hg and git users, so maybe it's just the nature of the
> > tools.  In which case, I'm fine with whatever works better for
> > Python.

Actually, the complaint I've commonly heard from hg and git users is that they
want local, intermediate history to be collapsed into one revision/changeset
when merging into the target branch.

Daniel's example shows that the benefits of branches for review is not limited
to Bazaar+Launchpad users <wink>.  I do agree that it's a new workflow for
Python.

>I think it's up to the advocates of branch-based review to improve the
>tools, and I think it's worth it.  Now, if only I can find some
>time...

Continuing to use patch-based reviews for Python is fine, and I think as we
all adjust to the Mercurial conversion, new and more efficient ways of working
will evolve over time.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110308/91827dcf/attachment.pgp>

From stutzbach at google.com  Tue Mar  8 19:04:34 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Tue, 8 Mar 2011 10:04:34 -0800
Subject: [Python-Dev] hg diff
In-Reply-To: <4D75EA18.1070208@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
	<AANLkTikGzMdm1BESbV3i-GyW4brgFmcRz7rUXrmmwUo2@mail.gmail.com>
	<4D75EA18.1070208@v.loewis.de>
Message-ID: <AANLkTimSc+gqdGA6UiRyLfa+MamczfARfK2DNB=DLV2L@mail.gmail.com>

On Tue, Mar 8, 2011 at 12:34 AM, "Martin v. L?wis" <martin at v.loewis.de>wrote:

> With a branch you can easily view the full patch, making a branch
>> strictly more general.
>>
>
> I just asked this before: how *exactly* do you do that?
>

I confess: I'm not sure exactly how to do it in hg.  I know it's easy in
git; I assume it's easy in hg.  I did some searching but was unable to come
up with the right incantation.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110308/8542220b/attachment.html>

From brendan at kublai.com  Tue Mar  8 19:59:21 2011
From: brendan at kublai.com (Brendan Cully)
Date: Tue, 8 Mar 2011 10:59:21 -0800
Subject: [Python-Dev] combined hg incoming patch
In-Reply-To: <4D75F0F1.4000905@v.loewis.de>
References: <4D75483A.50600@v.loewis.de>
	<03D49162-8E97-464F-A1EA-F156C94FAC7D@kublai.com>
	<4D7559B3.8060605@v.loewis.de>
	<0113DA3C-0FD9-4527-B819-8B2C5928A8C7@kublai.com>
	<C0BE2765-BE3D-4A4A-8B00-3132A2940D51@kublai.com>
	<4D75F0F1.4000905@v.loewis.de>
Message-ID: <F584FB22-A223-4789-B1DC-C7040DB9F7EB@kublai.com>

On 2011-03-08, at 1:03 AM, Martin v. L?wis wrote:

>> Sorry, I didn't think that through. Revsets still have the power though:
>> 
>> hg -R tmp.bundle diff -r'ancestor(.,default)' -r default
>> 
>> (assuming your local repo is at the tip of default)
> 
> I can't make this work. I'm using hg 1.6.4, which does have revsets and
> (including ancestor). Still, with this command, I get
> 
> martin at mira:~/work/3k$ LANG=C hg -R tmp.bundle diff -r'ancestor(.,default)' -r default
> abort: unknown revision 'ancestor(.,default)'!

It looks like that was fixed a week after 1.6.4 was released, here:

http://hg.intevation.org/mercurial/crew/rev/2063d36b406e

It should work in 1.7.

From reliable.domains at gmail.com  Tue Mar  8 03:31:19 2011
From: reliable.domains at gmail.com (Reliable Domains)
Date: Mon, 07 Mar 2011 18:31:19 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>
	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>
	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>
	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>
	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
Message-ID: <4D7594F7.2050105@gmail.com>

On 3/7/2011 2:18 PM, James Y Knight wrote:
> On Mar 7, 2011, at 3:49 PM, Paul Moore wrote:
>> >  The launcher could also (as per Mark's suggestion) interpret a shebang
>> >  line in the script, so that scripts could specify their required
>> >  version without needing a different command,or multiple
>> >  version-specific extensions.
> Note that, on Unix, "python file.py" doesn't choose the correct version of python to run by looking at a shebang, it just runs the version of python installed as "python". Only "./file.py" looks at the shebang (assuming that file is marked executable).
>
> Is the proposal to make python.exe do that on windows? That is a rather significant difference from the unix behavior.


The launcher need not be called "python.exe", and maybe it would be 
better called  #@launcher.exe  (or similar, depending on its exact 
function details).

For launching from the command line, if various versions python binaries 
or batch files are on the PATH, then appropriate explicit python invocation

python foo.py   # Just like Unix
python2 foo.py
python3 foo.py

should launch the specified version (where python may be somewhat 
ambiguous) but

foo.py  # with the help of a launcher this could be just like Unix too

would implicitly use the launcher, as would launching it from the GUI.

There are two problems here, explicit command-line invocation, and 
GUI/assoc invocation.  A launcher need not, and probably should not, do 
anything for explicit python invocation, but would only solve the 
implicit and GUI type of invocations.

From roundup-admin at psf.upfronthosting.co.za  Tue Mar  8 20:32:20 2011
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Tue, 08 Mar 2011 19:32:20 +0000
Subject: [Python-Dev] Failed issue tracker submission
Message-ID: <20110308193220.81EF21CC0A@psf.upfronthosting.co.za>



You are not a registered user.

Unknown address: python-dev at python.org
-------------- next part --------------
Return-Path: <python-dev at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id 3751A1C882
	for <report at bugs.python.org>; Tue,  8 Mar 2011 20:32:20 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id E997CEE982
	for <report at bugs.python.org>; Tue,  8 Mar 2011 20:32:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1299612739; bh=Bm/2p8PHDn+4WE7m0+s+IN5vXbdlXyuJIaBOBx3pZx0=;
	h=Date:Message-Id:Content-Type:MIME-Version:
	 Content-Transfer-Encoding:From:To:Subject;
	b=LoV7iLjY9Iw+vYf3SFnuqChBT6nSZ671M1ZJEJunosSATE+6JlkWjt/GZh7qXXRnO
	 58wWGG6wv/ydMfpGFKuFgW8fjq4jrLZp76xB59v6jRh4qwWs3ejJLZvkg3r8PAkbJy
	 OuwQoxgPaDqUpO+U1jEsdDH49hutOtfMTEyUX2aw=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 08 Mar 2011 20:32:19 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.python.org (Postfix) with ESMTPS
	for <report at bugs.python.org>; Tue,  8 Mar 2011 20:32:19 +0100 (CET)
Received: from localhost
	([127.0.0.1] helo=dinsdale.python.org ident=hg)
	by dinsdale.python.org with esmtp (Exim 4.72)
	(envelope-from <python-dev at python.org>)
	id 1Px2dn-0002Pv-SP
	for report at bugs.python.org; Tue, 08 Mar 2011 20:32:19 +0100
Date: Tue, 08 Mar 2011 20:32:19 +0100
Message-Id: <E1Px2dn-0002Pv-SP at dinsdale.python.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Mercurial robot <python-dev at python.org>
To: report at bugs.python.org
Subject: [issue2771]

Changeset b92334d06445 by Antoine Pitrou <solipsis at pitrou.net>:
Issue #2771: fixing frobnicator\nI hope this works

From roundup-admin at psf.upfronthosting.co.za  Tue Mar  8 20:37:52 2011
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Tue, 08 Mar 2011 19:37:52 +0000
Subject: [Python-Dev] Failed issue tracker submission
Message-ID: <20110308193752.52C791D4D5@psf.upfronthosting.co.za>


An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
-------------- next part --------------
Return-Path: <python-dev at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id 401941CCBB
	for <report at bugs.python.org>; Tue,  8 Mar 2011 20:37:51 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id 07431F50E
	for <report at bugs.python.org>; Tue,  8 Mar 2011 20:37:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1299613071; bh=Bm/2p8PHDn+4WE7m0+s+IN5vXbdlXyuJIaBOBx3pZx0=;
	h=Date:Message-Id:Content-Type:MIME-Version:
	 Content-Transfer-Encoding:From:To:Subject;
	b=c2EwRcbLb6xyNVyGuEYgXsFXucMs8eDjr+gNZxI8n4qptSKtw1oDYcSQ/crFbP/3/
	 rXpiXCZpBqzTqCpSm3OCFU1LMOKMp2NSb1TGVHPtnPNba6DsIljrSB0ChpQjNFzmDi
	 hrahhvjF+xdlyFaRi9zH8hUtbgqUSJ5JFtrZ5PtU=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 08 Mar 2011 20:37:51 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.python.org (Postfix) with ESMTPS
	for <report at bugs.python.org>; Tue,  8 Mar 2011 20:37:50 +0100 (CET)
Received: from localhost
	([127.0.0.1] helo=dinsdale.python.org ident=hg)
	by dinsdale.python.org with esmtp (Exim 4.72)
	(envelope-from <python-dev at python.org>)
	id 1Px2j8-0002xv-RP
	for report at bugs.python.org; Tue, 08 Mar 2011 20:37:50 +0100
Date: Tue, 08 Mar 2011 20:37:50 +0100
Message-Id: <E1Px2j8-0002xv-RP at dinsdale.python.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Mercurial robot <python-dev at python.org>
To: report at bugs.python.org
Subject: [issue2771]

Changeset b92334d06445 by Antoine Pitrou <solipsis at pitrou.net>:
Issue #2771: fixing frobnicator\nI hope this works

From roundup-admin at psf.upfronthosting.co.za  Tue Mar  8 20:38:22 2011
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Tue, 08 Mar 2011 19:38:22 +0000
Subject: [Python-Dev] Failed issue tracker submission
Message-ID: <20110308193822.708BF1D41B@psf.upfronthosting.co.za>


An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
-------------- next part --------------
Return-Path: <python-dev at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id 2BCB01CF45
	for <report at bugs.python.org>; Tue,  8 Mar 2011 20:38:20 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id E3164F50E
	for <report at bugs.python.org>; Tue,  8 Mar 2011 20:38:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1299613099; bh=Bm/2p8PHDn+4WE7m0+s+IN5vXbdlXyuJIaBOBx3pZx0=;
	h=Date:Message-Id:Content-Type:MIME-Version:
	 Content-Transfer-Encoding:From:To:Subject;
	b=cZuu5TUJ+2EKtvuJRRg8z6d0Kg91LmwDAkiJDfLyZgnVmR9qIt6WH3yT51E9BVJYS
	 iGsyAfzvyldNq4ckKUN/xZk4I1DpWiQIpWGEvKZ0EqXfuCSU/4jVbfQh6IfbMFj2Ll
	 /CybOdJt6JqDvqDOH5bK+A37djNgw6uKFUvQ+yvg=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 08 Mar 2011 20:38:19 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.python.org (Postfix) with ESMTPS
	for <report at bugs.python.org>; Tue,  8 Mar 2011 20:38:19 +0100 (CET)
Received: from localhost
	([127.0.0.1] helo=dinsdale.python.org ident=hg)
	by dinsdale.python.org with esmtp (Exim 4.72)
	(envelope-from <python-dev at python.org>)
	id 1Px2jb-0002yL-Qw
	for report at bugs.python.org; Tue, 08 Mar 2011 20:38:19 +0100
Date: Tue, 08 Mar 2011 20:38:19 +0100
Message-Id: <E1Px2jb-0002yL-Qw at dinsdale.python.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: python-dev at python.org
To: report at bugs.python.org
Subject: [issue2771]

Changeset b92334d06445 by Antoine Pitrou <solipsis at pitrou.net>:
Issue #2771: fixing frobnicator\nI hope this works

From rndblnch at gmail.com  Tue Mar  8 20:44:16 2011
From: rndblnch at gmail.com (rndblnch)
Date: Tue, 8 Mar 2011 19:44:16 +0000 (UTC)
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
	<4D6AB409.40001@canterbury.ac.nz>
Message-ID: <loom.20110308T202041-921@post.gmane.org>

Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:

> 
> Guido van Rossum wrote:
> > Ok. Will you hvae time to port your patches to 3.3?
> 
> I'm not sure -- I'll see what I can do.
> 

If this can help, I've "ported" the patch YieldFrom-Python3.1.2-rev5.patch
against current cpython tip.
What I've done:
- cloned current http://hg.python.org/cpython/ tip
- replaced tabs by 4 spaces in YieldFrom-Python3.1.2-rev5.patch and applied
result to tip
- manually applied failed hunks
- built and tested resulting python (configure/make/make test smoothly pass)
- successfully ran "yield from" samples with resulting binary
Resulting patch obtained by running "hg diff" is available here:
<http://tinypaste.com/4cc47d>

This patch includes graminit.[ch] modification since those files are versioned,
but I guess they are not necessary since they seem to be generated.

Hope this helps.

renaud


From solipsis at pitrou.net  Tue Mar  8 21:00:54 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 8 Mar 2011 21:00:54 +0100
Subject: [Python-Dev] Failed issue tracker submission
References: <20110308193220.81EF21CC0A@psf.upfronthosting.co.za>
Message-ID: <20110308210054.43ac1cbf@pitrou.net>


Ouch. I fear this message may be repeated several times :/
Sorry for the spam, if that happens...

Regards

Antoine.


On Tue, 08 Mar 2011 19:32:20 +0000
Python tracker <roundup-admin at psf.upfronthosting.co.za> wrote:
> 
> 
> You are not a registered user.
> 
> Unknown address: python-dev at python.org
> 



From skip at pobox.com  Tue Mar  8 21:02:25 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 8 Mar 2011 14:02:25 -0600
Subject: [Python-Dev] Failed issue tracker submission
In-Reply-To: <20110308193220.81EF21CC0A@psf.upfronthosting.co.za>
References: <20110308193220.81EF21CC0A@psf.upfronthosting.co.za>
Message-ID: <19830.35665.527598.210889@montanaro.dyndns.org>


    >> You are not a registered user.

    >> Unknown address: python-dev at python.org

I should point out that I approved this message, mostly so whoever has
thinks set up to send messages to the meta tracker as python-dev can fix the
problem.

Skip

From tjreedy at udel.edu  Tue Mar  8 21:02:56 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 08 Mar 2011 15:02:56 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D7594F7.2050105@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
	<4D7594F7.2050105@gmail.com>
Message-ID: <il621e$320$1@dough.gmane.org>

On 3/7/2011 9:31 PM, Reliable Domains wrote:

> The launcher need not be called "python.exe", and maybe it would be
> better called #@launcher.exe (or similar, depending on its exact
> function details).

I do not know that the '#@' part is about, but pygo would be short and 
expressive.

-- 
Terry Jan Reedy


From solipsis at pitrou.net  Tue Mar  8 21:29:05 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 8 Mar 2011 21:29:05 +0100
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
	<20110306154009.272fcbf4@pitrou.net>
	<AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>
	<20110306155646.69870571@pitrou.net>
	<AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
Message-ID: <20110308212905.4db44208@pitrou.net>


Well, after a couple of days with the "cpython" prefix stripped, I have
to say that I find it much less practical than it was before. Any other
opinions?

Regards

Antoine.



On Mon, 7 Mar 2011 01:11:24 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Mon, 7 Mar 2011 00:52:08 +1000
> > Nick Coghlan <ncoghlan at 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?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From skip at pobox.com  Tue Mar  8 21:51:37 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 8 Mar 2011 14:51:37 -0600
Subject: [Python-Dev] Failed issue tracker submission
In-Reply-To: <20110308210054.43ac1cbf@pitrou.net>
References: <20110308193220.81EF21CC0A@psf.upfronthosting.co.za>
	<20110308210054.43ac1cbf@pitrou.net>
Message-ID: <19830.38617.740752.161799@montanaro.dyndns.org>


    Antoine> Ouch. I fear this message may be repeated several times :/
    Antoine> Sorry for the spam, if that happens...

Do you want me to reject or discard future messages to python-dev from
roundup-admin?

Skip

From solipsis at pitrou.net  Tue Mar  8 21:58:19 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 08 Mar 2011 21:58:19 +0100
Subject: [Python-Dev] Failed issue tracker submission
In-Reply-To: <19830.38617.740752.161799@montanaro.dyndns.org>
References: <20110308193220.81EF21CC0A@psf.upfronthosting.co.za>
	<20110308210054.43ac1cbf@pitrou.net>
	<19830.38617.740752.161799@montanaro.dyndns.org>
Message-ID: <1299617899.3763.28.camel@localhost.localdomain>

Le mardi 08 mars 2011 ? 14:51 -0600, skip at pobox.com a ?crit :
> Antoine> Ouch. I fear this message may be repeated several times :/
>     Antoine> Sorry for the spam, if that happens...
> 
> Do you want me to reject or discard future messages to python-dev from
> roundup-admin?

Hopefully there won't be any more (I've fixed the issue by creating an
appropriate Roundup user).

I think it's better not to discard them, in case it starts failing
again.

Regards

Antoine.



From ethan at stoneleaf.us  Tue Mar  8 22:12:09 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 08 Mar 2011 13:12:09 -0800
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <20110308212905.4db44208@pitrou.net>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>	<20110306154009.272fcbf4@pitrou.net>	<AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>	<20110306155646.69870571@pitrou.net>	<AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
	<20110308212905.4db44208@pitrou.net>
Message-ID: <4D769BA9.3070202@stoneleaf.us>

Antoine Pitrou wrote:
> Well, after a couple of days with the "cpython" prefix stripped, I have
> to say that I find it much less practical than it was before. Any other
> opinions?

I would rather have it back.

~Ethan~

From g.brandl at gmx.net  Tue Mar  8 22:07:54 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 08 Mar 2011 22:07:54 +0100
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <20110308212905.4db44208@pitrou.net>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
	<20110306154009.272fcbf4@pitrou.net>
	<AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>
	<20110306155646.69870571@pitrou.net>
	<AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
	<20110308212905.4db44208@pitrou.net>
Message-ID: <il65t5$tnc$1@dough.gmane.org>

On 08.03.2011 21:29, Antoine Pitrou wrote:
> 
> Well, after a couple of days with the "cpython" prefix stripped, I have
> to say that I find it much less practical than it was before. Any other
> opinions?

>From me, only the same opinion :)

Georg



From solipsis at pitrou.net  Tue Mar  8 22:16:13 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 8 Mar 2011 22:16:13 +0100
Subject: [Python-Dev] hooks: Add roundup integration hook.
References: <E1Pwv18-0002f2-4m@dinsdale.python.org> <4D768C81.5080609@udel.edu>
Message-ID: <20110308221613.3c17b8f0@pitrou.net>

On Tue, 08 Mar 2011 15:07:29 -0500
Terry Reedy <tjreedy at udel.edu> wrote:
> 
> > +If "closes" or "fixes" (with alternative verb forms like "fixing"
> > +allowed too) is prepended, the issue is automatically closed as
> > +"fixed".
> 
> Fix may be too broad. "This patch fixes the first part of the issue."

Ok, it has been removed. Only "closes" and derivatives trigger closing
now.

Regards

Antoine.





From g.brandl at gmx.net  Tue Mar  8 22:16:33 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 08 Mar 2011 22:16:33 +0100
Subject: [Python-Dev] hooks: Add roundup integration hook.
In-Reply-To: <4D768C81.5080609@udel.edu>
References: <E1Pwv18-0002f2-4m@dinsdale.python.org> <4D768C81.5080609@udel.edu>
Message-ID: <il66dc$vut$1@dough.gmane.org>

On 08.03.2011 21:07, Terry Reedy wrote:
> 
>> +If "closes" or "fixes" (with alternative verb forms like "fixing"
>> +allowed too) is prepended, the issue is automatically closed as
>> +"fixed".
> 
> Fix may be too broad. "This patch fixes the first part of the issue."

Well, you'd have to write "This patch fixes #12345 (the first part)".

But in any case, by popular demand "fix" is now removed, and only
"close" and its variants actually closes the issue -- since there
is not much chance that you can write "close #12345" without
actually meaning to close the issue :)

Georg


From martin at v.loewis.de  Tue Mar  8 22:45:07 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 08 Mar 2011 22:45:07 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <87oc5lkip9.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>	<20110307194416.1a82800b@pitrou.net>	<20110307140243.6ada217b@neurotica.wooz.org>	<87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D75EB03.8040208@v.loewis.de>
	<87oc5lkip9.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D76A363.3020309@v.loewis.de>

Am 08.03.2011 11:30, schrieb Stephen J. Turnbull:
> "Martin v. L?wis" writes:
>
>   >  >  However, as Michael points out, you can have your tools generate the
>   >  >  patch.  For example, it shouldn't be too hard to add a dynamic patch
>   >  >  generator to Roundup (although I haven't thought about the UI or the
>   >  >  CPU burden).
>
>   >  For Mercurial, that's more difficult than you might expect. There is "hg
>   >  incoming -p", but it has the nasty problem that it may produce
>   >  multiple patches for a single file.
>
> Doesn't "hg diff -r 'ancestor(branch,default)::branch'", where "branch"
> is the unmerged branch you would like to inspect, do the right thing?

What would I specify as "branch" if all I have is 
"http://bitbucket.com/turnbull/foo", and know that it must be the 
default branch?

Regards,
Martin

From benjamin at python.org  Tue Mar  8 23:08:04 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 8 Mar 2011 16:08:04 -0600
Subject: [Python-Dev] small commit emails nit
In-Reply-To: <20110308212905.4db44208@pitrou.net>
References: <AANLkTi=c34hd5opNEugSL-ffU_7s8U-H-i32TX+FNH=q@mail.gmail.com>
	<20110306154009.272fcbf4@pitrou.net>
	<AANLkTimjt5m4pbAa1vrQB___on4eGuCgRea9_CUVdM-k@mail.gmail.com>
	<20110306155646.69870571@pitrou.net>
	<AANLkTimp4dJO_RGP-TG=2OWnXs6zd2YH9LShJDYU_b=M@mail.gmail.com>
	<20110308212905.4db44208@pitrou.net>
Message-ID: <AANLkTimooa0meCD0PKU5X6Gi54=cM=s1HDEKaobLgMXV@mail.gmail.com>

2011/3/8 Antoine Pitrou <solipsis at pitrou.net>:
>
> Well, after a couple of days with the "cpython" prefix stripped, I have
> to say that I find it much less practical than it was before. Any other
> opinions?

"cpy" maybe?



-- 
Regards,
Benjamin

From martin at v.loewis.de  Tue Mar  8 23:35:11 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 08 Mar 2011 23:35:11 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <20110308111931.38f18a7c@pitrou.net>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>
	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>	<20110307194416.1a82800b@pitrou.net>	<20110307140243.6ada217b@neurotica.wooz.org>	<87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D75EB03.8040208@v.loewis.de>
	<20110308111931.38f18a7c@pitrou.net>
Message-ID: <4D76AF1F.4020708@v.loewis.de>

Am 08.03.2011 11:19, schrieb Antoine Pitrou:
> On Tue, 08 Mar 2011 09:38:27 +0100
> "Martin v. L?wis"<martin at v.loewis.de>  wrote:
>>> However, as Michael points out, you can have your tools generate the
>>> patch.  For example, it shouldn't be too hard to add a dynamic patch
>>> generator to Roundup (although I haven't thought about the UI or the
>>> CPU burden).
>>
>> For Mercurial, that's more difficult than you might expect. There is "hg
>> incoming -p", but it has the nasty problem that it may produce
>> multiple patches for a single file.
>
> If you use named branches it's trivial, and it's suggested in the
> devguide in
> http://docs.python.org/devguide/committing.html#long-term-development-of-features

That requires a local repository, right? Plus it requires knowing the 
branch name, which makes it difficult for automated patch generation.

Regards,
Martin

From martin at v.loewis.de  Tue Mar  8 23:47:29 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 08 Mar 2011 23:47:29 +0100
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
 this documented?
In-Reply-To: <6DE2A542-E3F8-4A76-A5BB-7C3B7629C384@barrys-emacs.org>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>	<il1hhr$mrr$1@dough.gmane.org>
	<4D7498F1.3070602@arbash-meinel.com>
	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
	<4D74A65D.40105@v.loewis.de>
	<6DE2A542-E3F8-4A76-A5BB-7C3B7629C384@barrys-emacs.org>
Message-ID: <4D76B201.2040809@v.loewis.de>

>> I think everything here is as it should be. People who really cared
>> about forwards compatibility could have known, but factually, most
>> people don't care enough. Those then learn for the first time that
>> some feature was deprecated after it is actually removed. They then
>> ask why it is removed, and somebody will tell them.
>
> I was not aware I could turn on deprecation warning for use of the C API.
> How can I do that?

Not sure that you can. When I said "could have known", I meant "by 
reading the documentation".

Regards,
Martin

From martin at v.loewis.de  Tue Mar  8 23:48:26 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 08 Mar 2011 23:48:26 +0100
Subject: [Python-Dev] combined hg incoming patch
In-Reply-To: <F584FB22-A223-4789-B1DC-C7040DB9F7EB@kublai.com>
References: <4D75483A.50600@v.loewis.de>
	<03D49162-8E97-464F-A1EA-F156C94FAC7D@kublai.com>
	<4D7559B3.8060605@v.loewis.de>
	<0113DA3C-0FD9-4527-B819-8B2C5928A8C7@kublai.com>
	<C0BE2765-BE3D-4A4A-8B00-3132A2940D51@kublai.com>
	<4D75F0F1.4000905@v.loewis.de>
	<F584FB22-A223-4789-B1DC-C7040DB9F7EB@kublai.com>
Message-ID: <4D76B23A.20500@v.loewis.de>

>> martin at mira:~/work/3k$ LANG=C hg -R tmp.bundle diff -r'ancestor(.,default)' -r default
>> abort: unknown revision 'ancestor(.,default)'!
>
> It looks like that was fixed a week after 1.6.4 was released, here:
>
> http://hg.intevation.org/mercurial/crew/rev/2063d36b406e
>
> It should work in 1.7.

Ah ok, it does indeed.

Thanks,
Martin

From barry at barrys-emacs.org  Tue Mar  8 23:32:53 2011
From: barry at barrys-emacs.org (Barry Scott)
Date: Tue, 8 Mar 2011 22:32:53 +0000
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
	this documented?
In-Reply-To: <4D74A65D.40105@v.loewis.de>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>	<il1hhr$mrr$1@dough.gmane.org>
	<4D7498F1.3070602@arbash-meinel.com>
	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
	<4D74A65D.40105@v.loewis.de>
Message-ID: <6DE2A542-E3F8-4A76-A5BB-7C3B7629C384@barrys-emacs.org>


On 7 Mar 2011, at 09:33, Martin v. L?wis wrote:

> Am 07.03.2011 10:14, schrieb Nick Coghlan:
>> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
>> <john at arbash-meinel.com>  wrote:
>>> 
>>> Especially since, AIUI, deprecations are suppressed by default now.
>> 
>> True, but developers are expected to run their tests with them enabled.
> 
> I think everything here is as it should be. People who really cared
> about forwards compatibility could have known, but factually, most
> people don't care enough. Those then learn for the first time that
> some feature was deprecated after it is actually removed. They then
> ask why it is removed, and somebody will tell them.

I was not aware I could turn on deprecation warning for use of the C API.
How can I do that?

> The OP is actually wrong that this isn't documented in "what's new";
> there is an item about it in the "porting to 3.2" section.

O.k. I see that now. I searched for the API call that vanished and came up
empty. I did not think to search for cobject or read the porting section.

BTW the link on http://www.python.org/download/releases/3.2/
to what's new points to the 3.3a0 whats new page.

Barry


From martin at v.loewis.de  Wed Mar  9 00:37:20 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 09 Mar 2011 00:37:20 +0100
Subject: [Python-Dev] GSoC mentors: projects list is up
Message-ID: <4D76BDB0.3010802@v.loewis.de>

If you want to see a project done in this year's GSoC,
please add it to

http://wiki.python.org/moin/SummerOfCode/2011

Python 3 related projects are preferred.

Students will look at this page for ideas what kinds of projects to 
propose; the earlier you add an idea, the more likely is it that you
get good proposals from good students.

Regards,
Martin

From merwok at netwok.org  Wed Mar  9 03:30:41 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 09 Mar 2011 03:30:41 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <AANLkTimSc+gqdGA6UiRyLfa+MamczfARfK2DNB=DLV2L@mail.gmail.com>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>
	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>	<20110307194416.1a82800b@pitrou.net>	<AANLkTikGzMdm1BESbV3i-GyW4brgFmcRz7rUXrmmwUo2@mail.gmail.com>	<4D75EA18.1070208@v.loewis.de>
	<AANLkTimSc+gqdGA6UiRyLfa+MamczfARfK2DNB=DLV2L@mail.gmail.com>
Message-ID: <4D76E651.4090204@netwok.org>

Hi,

Le 08/03/2011 19:04, Daniel Stutzbach a ?crit :
>>> With a branch you can easily view the full patch, making a branch
>>> strictly more general.
>> I just asked this before: how *exactly* do you do that?
> I confess: I'm not sure exactly how to do it in hg.  I know it's easy in
> git; I assume it's easy in hg.
The tools do not share the same design choices, so assuming there?s a
Merrcurial equivalent to something that?s possibly advanced git usage is
risked.

> I did some searching but was unable to come up with the right incantation.
What?s the command you use with git?  Maybe someone will find the
Mercurial one.

Regards

From merwok at netwok.org  Wed Mar  9 03:32:48 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 09 Mar 2011 03:32:48 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <4D72CB3A.5090006@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de>
Message-ID: <4D76E6D0.6020707@netwok.org>

Hi,

First, thank you for stepping up again to work on the code review
integration.

> It seems that the dev guide recommends to use the --git option in hg
> diff.

>From ?hg help diffs?:

    While this standard format [unified diff] is often enough, it does
    not encode the following information:

    - executable status and other permission bits
    - copy or rename information
    - changes in binary files
    - creation or deletion of empty files

I?m of the opinion that hg diffs should always use the extended git
format, given their usefulness.  A tool working with hg diffs that does
not support this format is broken IMO.

Regards

From guido at python.org  Wed Mar  9 03:41:57 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Mar 2011 21:41:57 -0500
Subject: [Python-Dev] hg diff
In-Reply-To: <4D76E6D0.6020707@netwok.org>
References: <4D72CB3A.5090006@v.loewis.de> <4D76E6D0.6020707@netwok.org>
Message-ID: <AANLkTinXMDrwtErXqMWxY1YLD9vVTB4GbRHEeEMWzotr@mail.gmail.com>

On Tue, Mar 8, 2011 at 9:32 PM, ?ric Araujo <merwok at netwok.org> wrote:
> I?m of the opinion that hg diffs should always use the extended git
> format, given their usefulness. ?A tool working with hg diffs that does
> not support this format is broken IMO.

Can you please contribute changes to Rietveld to support that format then?

-- 
--Guido van Rossum (python.org/~guido)

From v+python at g.nevcal.com  Wed Mar  9 03:43:19 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Tue, 08 Mar 2011 18:43:19 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <il621e$320$1@dough.gmane.org>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>	<4D7594F7.2050105@gmail.com>
	<il621e$320$1@dough.gmane.org>
Message-ID: <4D76E947.5030208@g.nevcal.com>

On 3/8/2011 12:02 PM, Terry Reedy wrote:
> On 3/7/2011 9:31 PM, Reliable Domains wrote:
>
>> The launcher need not be called "python.exe", and maybe it would be
>> better called #@launcher.exe (or similar, depending on its exact
>> function details).
>
> I do not know that the '#@' part is about, but pygo would be short and 
> expressive.
>

If my proposal to make a line starting with #@ to be used instead of the 
Unix #! (#@ could be on the first or second line, to allow 
cross-platform scripts to use both, and Windows only scripts to not have 
#!), then #@launcher.exe (and #@launcherw.exe I suppose) would reflect 
the functionality of the launcher, which need not be tightly tied to 
Python, if it uses a separate line.  But the launcher should probably 
not be the thing invoked from the command line, only implicitly when 
running scripts by naming them as the first thing on the command line.

I'm of the opinion that attempting to parse a Unix #! line, and intuit 
what would be the equivalent on Windows is unnecessarily complex and 
error prone, and assumes that the variant systems are configured using 
the same guidelines (which the Python community may espouse, but may not 
be followed by all distributions, sysadmins, or users).  That's why I 
propose a different line for Windows... it is as simple as the 
long-proven Unix #! line, but imposes no restrictions on or requirements 
that there be a #! line; it has more flexibility in that it could invoke 
different versions or provide different options on Unix and Windows if 
necessary for some environments.

#!/usr/bin/env python2.6 -B
#@c:\python26\python2.6.exe

or

#!/usr/bin/python2.5
#@"C:\Program Files (x86)\IronPython 2.6 for .NET 4.0\ipy.exe"

Now that I've had this idea, one might want to create other "2nd 
character" codes after the Unix #! line... one could have

#! Unix command processor
#@ Windows command processor
#$ OS/2 command processor
#% Alternate Windows command processor.

One could even port it to Unix:

#!/usr/bin/#@launcher
#@c:\python2.6\python.exe
#^/usr/bin/python2.5
#&/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe
#  I made up the line above, having no knowledge of Mono, but I think 
you get the idea

Choice of command line would be an environment variable, I suppose, that 
the launcher would look at, or if none, then a system-specific default.  
It would have to search forward in the file until it finds the 
appropriate prefix or a line not starting with #, or starting with "# " 
or "##", at which point it would give up.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110308/02d7fcb7/attachment.html>

From a.badger at gmail.com  Wed Mar  9 05:02:55 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 8 Mar 2011 20:02:55 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D76E947.5030208@g.nevcal.com>
References: <4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>
	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
	<4D7594F7.2050105@gmail.com> <il621e$320$1@dough.gmane.org>
	<4D76E947.5030208@g.nevcal.com>
Message-ID: <20110309040255.GM3275@unaka.lan>

On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote:
> On 3/8/2011 12:02 PM, Terry Reedy wrote:
> 
>     On 3/7/2011 9:31 PM, Reliable Domains wrote:
> 
> 
>         The launcher need not be called "python.exe", and maybe it would be
>         better called #@launcher.exe (or similar, depending on its exact
>         function details).
> 
> 
>     I do not know that the '#@' part is about, but pygo would be short and
>     expressive.
> 
> 
> 
> If my proposal to make a line starting with #@ to be used instead of the Unix
> #! (#@ could be on the first or second line, to allow cross-platform scripts to
> use both, and Windows only scripts to not have #!
>
You'd need to allow for it to be on the third line as well.  pep-0263
has already taken the second line if it's in a script that has a Unix
shebang.


> ), then #@launcher.exe (and #
> @launcherw.exe I suppose) would reflect the functionality of the launcher,
> which need not be tightly tied to Python, if it uses a separate line.  But the
> launcher should probably not be the thing invoked from the command line, only
> implicitly when running scripts by naming them as the first thing on the
> command line.
> 
> I'm of the opinion that attempting to parse a Unix #! line, and intuit what
> would be the equivalent on Windows is unnecessarily complex and error prone,
> and assumes that the variant systems are configured using the same guidelines
> (which the Python community may espouse, but may not be followed by all
> distributions, sysadmins, or users).
>
I do not have a Windows system so I don't have a horse in this race but if
the argument is to avoid complexity, be careful that your proposed solution
isn't more complex than what you're avoiding.  ie::

> Now that I've had this idea, one might want to create other "2nd character"
> codes after the Unix #! line... one could have
> 
> #! Unix command processor
> #@ Windows command processor
> #$ OS/2 command processor
> #% Alternate Windows command processor.
> 
> One could even port it to Unix:
> 
> #!/usr/bin/#@launcher
> #@c:\python2.6\python.exe
> #^/usr/bin/python2.5
> #&/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe
> #  I made up the line above, having no knowledge of Mono, but I think you get
> the idea
> 
> Choice of command line would be an environment variable, I suppose, that the
> launcher would look at, or if none, then a system-specific default.  It would
> have to search forward in the file until it finds the appropriate prefix or a
> line not starting with #, or starting with "# " or "##", at which point it
> would give up.
> 
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110308/a81479cc/attachment.pgp>

From v+python at g.nevcal.com  Wed Mar  9 05:22:50 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Tue, 08 Mar 2011 20:22:50 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <20110309040255.GM3275@unaka.lan>
References: <4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>
	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
	<4D7594F7.2050105@gmail.com> <il621e$320$1@dough.gmane.org>
	<4D76E947.5030208@g.nevcal.com> <20110309040255.GM3275@unaka.lan>
Message-ID: <4D77009A.7000004@g.nevcal.com>

On 3/8/2011 8:02 PM, Toshio Kuratomi wrote:
> On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote:
>> On 3/8/2011 12:02 PM, Terry Reedy wrote:
>>
>>      On 3/7/2011 9:31 PM, Reliable Domains wrote:
>>
>>
>>          The launcher need not be called "python.exe", and maybe it would be
>>          better called #@launcher.exe (or similar, depending on its exact
>>          function details).
>>
>>
>>      I do not know that the '#@' part is about, but pygo would be short and
>>      expressive.
>>
>>
>>
>> If my proposal to make a line starting with #@ to be used instead of the Unix
>> #! (#@ could be on the first or second line, to allow cross-platform scripts to
>> use both, and Windows only scripts to not have #!
>>
> You'd need to allow for it to be on the third line as well.  pep-0263
> has already taken the second line if it's in a script that has a Unix
> shebang.

Thanks for your feedback Toshio...

Indeed!  I've been using Python 3 and UTF-8 encoding only long enough, I 
forgot about pep-0263, although I'd been aware of it before...  Now I 
only port back to Python 2 for stuff I have to run on my web host, which 
runs Python 2.6, and those are all ASCII files by design.


>> ), then #@launcher.exe (and #
>> @launcherw.exe I suppose) would reflect the functionality of the launcher,
>> which need not be tightly tied to Python, if it uses a separate line.  But the
>> launcher should probably not be the thing invoked from the command line, only
>> implicitly when running scripts by naming them as the first thing on the
>> command line.
>>
>> I'm of the opinion that attempting to parse a Unix #! line, and intuit what
>> would be the equivalent on Windows is unnecessarily complex and error prone,
>> and assumes that the variant systems are configured using the same guidelines
>> (which the Python community may espouse, but may not be followed by all
>> distributions, sysadmins, or users).
>>
> I do not have a Windows system so I don't have a horse in this race but if
> the argument is to avoid complexity, be careful that your proposed solution
> isn't more complex than what you're avoiding.  ie::

Yep, even after I wrote the below, I thought about not sending that 
part, for exactly that reason.

But after slightly investigating the other Python implementations, I 
realized even more strongly that interpreting the Unix #! line is very 
limiting:

1) it requires the same version to exist on both Unix and Windows, which 
may often, but not always, be true.

2) it either hard-codes an alternative path name in the launcher, or 
hard-codes an algorithm to do lookups in the registry to find the 
alternative path names.  Neither of these are very friendly to 
alternative Python implementations.

3) people concerned with keeping scripts and modules compatible with 
alternative implementations might have more than one implementation on 
their system.

So the complexity I'm avoiding is the "hard-coding" sort of complexity.  
The complexity I propose adds flexibility that the hard-coding would be 
hard-pressed to achieve.

>> Now that I've had this idea, one might want to create other "2nd character"
>> codes after the Unix #! line... one could have
>>
>> #! Unix command processor
>> #@ Windows command processor
>> #$ OS/2 command processor
>> #% Alternate Windows command processor.
>>
>> One could even port it to Unix:
>>
>> #!/usr/bin/#@launcher
>> #@c:\python2.6\python.exe
>> #^/usr/bin/python2.5
>> #&/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe
>> #  I made up the line above, having no knowledge of Mono, but I think you get
>> the idea
>>
>> Choice of command line would be an environment variable, I suppose, that the
>> launcher would look at, or if none, then a system-specific default.  It would
>> have to search forward in the file until it finds the appropriate prefix or a
>> line not starting with #, or starting with "# " or "##", at which point it
>> would give up.
For PEP-0263 compliance, modify the terminator to be a line not starting 
with #, or a line starting with "##".  This may cause reduced 
performance for scripts starting with large block comments without 
having the searched-for execution code... but only in the case where the 
searched-for execution code is not present.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110308/be330644/attachment.html>

From skippy.hammond at gmail.com  Wed Mar  9 06:06:05 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Wed, 09 Mar 2011 16:06:05 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D76E947.5030208@g.nevcal.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>	<4D7594F7.2050105@gmail.com>	<il621e$320$1@dough.gmane.org>
	<4D76E947.5030208@g.nevcal.com>
Message-ID: <4D770ABD.8060009@gmail.com>

On 9/03/2011 1:43 PM, Glenn Linderman wrote:
> I'm of the opinion that attempting to parse a Unix #! line, and intuit
> what would be the equivalent on Windows is unnecessarily complex and
> error prone, and assumes that the variant systems are configured using
> the same guidelines (which the Python community may espouse, but may not
> be followed by all distributions, sysadmins, or users). That's why I
> propose a different line for Windows... it is as simple as the
> long-proven Unix #! line, but imposes no restrictions on or requirements
> that there be a #! line; it has more flexibility in that it could invoke
> different versions or provide different options on Unix and Windows if
> necessary for some environments.
>
> #!/usr/bin/env python2.6 -B
> #@c:\python26\python2.6.exe
>
> or
>
> #!/usr/bin/python2.5
> #@"C:\Program Files (x86)\IronPython 2.6 for .NET 4.0\ipy.exe"

I don't think that buys us much.  A script with "#!/usr/bin/env python" 
could be distributed with an expectation it will work across various 
different machines (and possibly even different operating systems).  A 
script with "c:\..." could not be distributed and expected to work 
reliably anywhere.  ie, any script with a #! line (or even a #@ line) 
with a fully qualified Windows path can only be expected to work on a 
single machine - so there is no need to support both #! and #@ as the 
script is not even cross-machine portable, let alone cross-platform 
portable.

The only way to expect a #! line to work across machines would be to 
have a "virtual" path - eg just "python2.6" without any path specifier 
at all.  In that case, I see no problem with reusing the #! from *nix 
systems and treating "/usr/bin" etc as a "virtual" specifier on Windows. 
  If people find a need on Windows to add a fully-qualified path to this 
line (whatever the spelling), they are implicitly saying this script 
works only on the current machine.

IOW, as soon as someone has:

#!/usr/bin/env python2.6 -B
#@c:\python26\python2.6.exe

in their script, the script is targeted at exactly 1 specific machine, 
so why not just reuse the #! syntax?  OTOH, if an existing script has:

#!/usr/bin/env python2.6 -B

They are attempting to declare in a portable way that Python 2.6 is 
necessary - so why force them to add a #@ line to make it work on 
Windows when the #! line is the only clue Windows needs to make it work 
automagically?

Cheers,

Mark

From martin at v.loewis.de  Wed Mar  9 06:44:34 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 09 Mar 2011 06:44:34 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <4D76E6D0.6020707@netwok.org>
References: <4D72CB3A.5090006@v.loewis.de> <4D76E6D0.6020707@netwok.org>
Message-ID: <4D7713C2.2090604@v.loewis.de>

> I?m of the opinion that hg diffs should always use the extended git
> format, given their usefulness.  A tool working with hg diffs that does
> not support this format is broken IMO.

IMO, it's "hg diff --git" that's broken, as it doesn't include the base 
revision (other formats, such as "hg export", do).

Regards,
Martin

From v+python at g.nevcal.com  Wed Mar  9 07:05:01 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Tue, 08 Mar 2011 22:05:01 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D770ABD.8060009@gmail.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>	<4D7594F7.2050105@gmail.com>	<il621e$320$1@dough.gmane.org>
	<4D76E947.5030208@g.nevcal.com> <4D770ABD.8060009@gmail.com>
Message-ID: <4D77188D.3080308@g.nevcal.com>

On 3/8/2011 9:06 PM, Mark Hammond wrote:
> On 9/03/2011 1:43 PM, Glenn Linderman wrote:
>> I'm of the opinion that attempting to parse a Unix #! line, and intuit
>> what would be the equivalent on Windows is unnecessarily complex and
>> error prone, and assumes that the variant systems are configured using
>> the same guidelines (which the Python community may espouse, but may not
>> be followed by all distributions, sysadmins, or users). That's why I
>> propose a different line for Windows... it is as simple as the
>> long-proven Unix #! line, but imposes no restrictions on or requirements
>> that there be a #! line; it has more flexibility in that it could invoke
>> different versions or provide different options on Unix and Windows if
>> necessary for some environments.
>>
>> #!/usr/bin/env python2.6 -B
>> #@c:\python26\python2.6.exe
>>
>> or
>>
>> #!/usr/bin/python2.5
>> #@"C:\Program Files (x86)\IronPython 2.6 for .NET 4.0\ipy.exe"
>
> I don't think that buys us much.  A script with "#!/usr/bin/env 
> python" could be distributed with an expectation it will work across 
> various different machines (and possibly even different operating 
> systems).  A script with "c:\..." could not be distributed and 
> expected to work reliably anywhere.  ie, any script with a #! line (or 
> even a #@ line) with a fully qualified Windows path can only be 
> expected to work on a single machine - so there is no need to support 
> both #! and #@ as the script is not even cross-machine portable, let 
> alone cross-platform portable.

Standard installation paths are accepted by about 99% of the users, so 
embedding standard installation paths can work well for that batch of 
users.  Of course, Windows changes the standard path periodically, so 
that it different from versions prior to and including WinXP versus 
versions after WinXP.  And they had no standard before WinNT (or if they 
did, few followed it).  Your comment does point out a possible need for 
multiple standard installation paths just for different versions of 
Windows, though :(

Also, corporate environments are generally quite standardized, so 
scripts developed within and for a corporation (or modified for use 
within a corporation) could quite successfully use such.

You do make a good point, though, that Unix-based environments have more 
standardization in their diversity than Windows does.  Back when I wrote 
Unix code, though, there were plenty of system utility programs that had 
different default paths on different Unix platforms.  /usr/bin/env can 
cover some of that, but is also somewhat of a security hole.

>
> The only way to expect a #! line to work across machines would be to 
> have a "virtual" path - eg just "python2.6" without any path specifier 
> at all.  In that case, I see no problem with reusing the #! from *nix 
> systems and treating "/usr/bin" etc as a "virtual" specifier on 
> Windows.  If people find a need on Windows to add a fully-qualified 
> path to this line (whatever the spelling), they are implicitly saying 
> this script works only on the current machine.
>
> IOW, as soon as someone has:
>
> #!/usr/bin/env python2.6 -B
> #@c:\python26\python2.6.exe
>
> in their script, the script is targeted at exactly 1 specific machine, 
> so why not just reuse the #! syntax?  OTOH, if an existing script has:
>
> #!/usr/bin/env python2.6 -B
>
> They are attempting to declare in a portable way that Python 2.6 is 
> necessary - so why force them to add a #@ line to make it work on 
> Windows when the #! line is the only clue Windows needs to make it 
> work automagically?

Your premise that using a standard installation path in #@ restricts the 
script to be targeted to one machine is fallacious, so the conclusions 
are also.  You also missed the fact that the -B parameter was deemed 
necessary in the above for the Unix machine(s) of interest, but not 
needed for Windows, which a single line cannot impart (although that is 
an admittedly contrived example of potentially different option 
syntax).  And the use of  cpython on Unix and IronPython on Windows may 
be appropriate for some corporate environments.  A lot of the Unix 
discussion mentioned things like "curable by the sysadmin" like in 
regards to the links... a sysadmin implies a corporate environment, and 
a locked-down path structure.

Of course, /usr/bin/env  is already a "launcher" type facility, specific 
to Unix, to mask variations between systems, and to overcome the fact 
that Unix itself will not walk the PATH to find a non-fully-qualified name.

The #! line is clearly is NOT "the only clue Windows needs to make it 
work automagically" or we wouldn't be having this discussion at all.  
And it is not at all clear if a Windows machine contains Jython, 
IronPython, and Cython which one should be launched by a launcher.  You 
could, of course, argue that python-dev is only concerned with CPython, 
and the launcher can be specific to CPython, and that argument might 
carry the day, but the CPython registry lookup necessary to make that 
happen doesn't help the users of alternate implementations a bit, 
forcing each of them to implement their own launcher as well... or have 
they already solved this problem some other way that has not been 
brought to this discussion?  I downloaded/installed IronPython today to 
get the above path to it, but I didn't find any decent documentation for 
it to learn this sort of thing... a book reference seemed to claim the 
most comprehensive documentation, but I'm not going to buy a book just 
to learn that they haven't solved this issue, even if Michael Foord is 
one of the authors!

Of course if appropriate versioned python executables were placed on the 
Windows path, then an exact corollary to /usr/bin/env could be used on 
Windows, also... but there would still be the question of whether to 
use  python2.6.exe or ipy2.6.exe, perhaps.  And then there is the "w" 
issue, too.

#!/usr/bin/env python2.6
#@"C:\Program Files\Env.exe" ipy2.6.3.exe

in .py files and

#!/usr/bin/env python2.6
#@"C:\Program Files\Env.exe" ipy2.6.3w.exe

in .pyw files.

I have scripts that I run on my web server using

#!/usr/bin/python2.6

because they only have that and /usr/bin/python which is 2.4.2.  But I 
want to run them locally for testing with (infrequently) Windows cpython 
2.6 and (mostly) Windows cpython 3.2, to prove that they will (yes, 
certain common functions check sys.version to determine how to do 
things).  So using the Unix #! line certainly doesn't work for that 
case.  If I can have only one default, I would want it to be 3.2 
locally, and 2.6 on the server, and to manually override something to 
run 2.6 locally.  Yet all my Pythons are installed in the standard 
installation directory, and still your Unix hack won't let me do what I 
need.

So no matter what is done, it won't solve world hunger.  Probably that's 
why Windows users have been left high and dry for years in this 
regard... there is no "system" Python on it, out of the box, so the only 
users are those that are smart enough to download and install and 
configure things, and those who use a Python embedded into an 
application, at the cost of a Python installation per application, 
because there has been no "system" Python, and because Windows users are 
not perceived to be capable of, or willing to bother with, downloading 
and installing various requisite dependencies.

The resulting vacuum has been filled by people with different points of 
view, because there has been no technique implemented, none declared to 
be "best", and anarchy and variant workarounds have abounded.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110308/8d8c0223/attachment.html>

From stefan_ml at behnel.de  Wed Mar  9 07:15:07 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 09 Mar 2011 07:15:07 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before it's
 too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
Message-ID: <il75tb$c8s$1@dough.gmane.org>

"Martin v. L?wis", 08.03.2011 23:47:
>>> I think everything here is as it should be. People who really cared
>>> about forwards compatibility could have known, but factually, most
>>> people don't care enough. Those then learn for the first time that
>>> some feature was deprecated after it is actually removed. They then
>>> ask why it is removed, and somebody will tell them.
>>
>> I was not aware I could turn on deprecation warning for use of the C
>> API. How can I do that?
>
> Not sure that you can. When I said "could have known", I meant "by
> reading the documentation".

I can confirm that the Cython project was as surprised of the PyCapsule 
change in Python 3.2 as (I guess) most other users, and I would claim that 
we are a project with one of the highest probabilities of being impacted by 
C-API changes.

Maybe the "what's new" document could at least include a link to the 
relevant python-dev discussion/decision, so that fewer people have to ask back?

Actually, why not put up a web page of "upcoming changes" somewhere, that 
lists major decisions with user impact that were taken on python-dev? 
Including a link to the relevant discussion and decision. Often enough, 
decisions are taken inside of huge mailing list threads that get off-topic 
before someone has "the right idea" and everyone who's still there to 
listen agrees. Even for people lurking around on python-dev, it's easy 
enough to miss these moments.

A publicly visible list of those decisions would

a) make it easier for non-core developers to follow important changes on 
python-dev

b) allow potentially impacted people to bring up their POV more quickly, 
e.g. during the alpha cycle of a deprecation release rather than the 
following release, as in this case

c) document the decision taking process by listing the relevant mailing 
list threads

d) help in writing the "what's new" documents

Stefan


From stephen at xemacs.org  Wed Mar  9 07:27:49 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 09 Mar 2011 15:27:49 +0900
Subject: [Python-Dev] hg diff
In-Reply-To: <4D76A363.3020309@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
	<20110307140243.6ada217b@neurotica.wooz.org>
	<87tyfejoxv.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D75EB03.8040208@v.loewis.de>
	<87oc5lkip9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D76A363.3020309@v.loewis.de>
Message-ID: <87ei6gkdui.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. L?wis" writes:

 > > Doesn't "hg diff -r 'ancestor(branch,default)::branch'", where "branch"
 > > is the unmerged branch you would like to inspect, do the right thing?
 > 
 > What would I specify as "branch" if all I have is 
 > "http://bitbucket.com/turnbull/foo", and know that it must be the 
 > default branch?

Dunno offhand; I'm a git person.  Here I was specifically addressing
the "multiple patches per file" issue.

What I do in practice is git-like:

hg branch turnbull-foo
hg pull http://bitbucket.com/turnbull/foo
hg commit -m "Temporary turnbull-foo."
hg diff -r 'ancestor(<head>,default)::<head>'
hg branch default

Then if the code is good I merge it and close the branch, if the code
sucks I close the branch, if it needs improvement I keep the branch
until a decision is made.  I haven't thought about automating the
clean up operations, probably you can just close the branch.  Also,
for cases with multiple accesses to the same remote, I'm not sure
whether use of "hg branch --force" would be appropriate or not.

There's probably a way to get around the accumulation of branches and
revision data, but I don't need it (the few people who submit branches
generally submit good code that can be integrated) so I haven't looked
for it.  One obvious approach would be to do this in a separate repo
used only for this purpose and throw it away occasionally, and create
a new one as a clone of the public repo.



From mhammond at skippinet.com.au  Wed Mar  9 07:27:28 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 09 Mar 2011 17:27:28 +1100
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D77188D.3080308@g.nevcal.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>	<4D7594F7.2050105@gmail.com>	<il621e$320$1@dough.gmane.org>
	<4D76E947.5030208@g.nevcal.com> <4D770ABD.8060009@gmail.com>
	<4D77188D.3080308@g.nevcal.com>
Message-ID: <4D771DD0.2010402@skippinet.com.au>

On 9/03/2011 5:05 PM, Glenn Linderman wrote:
>
> Standard installation paths are accepted by about 99% of the users, so
> embedding standard installation paths can work well for that batch of
> users. Of course, Windows changes the standard path periodically, so
> that it different from versions prior to and including WinXP versus
> versions after WinXP. And they had no standard before WinNT (or if they
> did, few followed it). Your comment does point out a possible need for
> multiple standard installation paths just for different versions of
> Windows, though :(

The python installer ignores "Program Files" - as much as anything I'm 
concerned about the drive letter - IIUC, Python will default to 
installing on the system drive, which may not be C:

...

> Your premise that using a standard installation path in #@ restricts the
> script to be targeted to one machine is fallacious, so the conclusions
> are also.

Sorry - I should have said "some machines with Python installed by the 
installer".  Contrast this to the option of looking up the registry and 
you have "all machines with Python installed by the installer".  I'm not 
going to quibble about the percentages in the first category as I have 
no data to guide me, but I'm reasonably confident about the "all" in the 
second.

...

> The #! line is clearly is NOT "the only clue Windows needs to make it
> work automagically" or we wouldn't be having this discussion at all.

Sorry - I should have been clear - I meant "the only clue a windows 
specific Python launcher needs".

 > And
> it is not at all clear if a Windows machine contains Jython, IronPython,
> and Cython which one should be launched by a launcher.

I think it is reasonably clear: it would be the same version which would 
be launched on most *nix systems.  Are there any systems where 
"/usr/bin/python" would use Jython, for example?

> You could, of
> course, argue that python-dev is only concerned with CPython, and the
> launcher can be specific to CPython, and that argument might carry the
> day, but the CPython registry lookup necessary to make that happen
> doesn't help the users of alternate implementations a bit, forcing each
> of them to implement their own launcher as well...

I'd have no problem with the Windows launcher supporting other 
implementations - I expect something like "/usr/bin/jython" would be 
reasonable.  How we locate the installed jython is indeed an interesting 
problem, but I'd guess it is surmountable - especially if we can get the 
buy-in of these alternate implementations for their future releases.

> #!/usr/bin/env python2.6
> #@"C:\Program Files\Env.exe" ipy2.6.3.exe

As above, the C: assumes Windows is installed on C: - that may be 
common, but not universal.  Further, a 64bit machine would probably want 
"\Program Files (x86)" (which is becoming more and more common)

>
> in .py files and
>
> #!/usr/bin/env python2.6
> #@"C:\Program Files\Env.exe" ipy2.6.3w.exe
>
> in .pyw files.

I'm slightly skeptical about that - .pyw files are surely rare on *nix 
systems and as we've discussed, pyw files are generally not meant to be 
cmd-line scripts.  IOW, I'm skeptical scripts exist which are meant to 
work with '/usr/bin/env python2.6' on *nix and pythonw.exe on windows.

...

> So no matter what is done, it won't solve world hunger. Probably that's
> why Windows users have been left high and dry for years in this
> regard... there is no "system" Python on it, out of the box, so the only
> users are those that are smart enough to download and install and
> configure things, and those who use a Python embedded into an
> application, at the cost of a Python installation per application,
> because there has been no "system" Python, and because Windows users are
> not perceived to be capable of, or willing to bother with, downloading
> and installing various requisite dependencies.
>
> The resulting vacuum has been filled by people with different points of
> view, because there has been no technique implemented, none declared to
> be "best", and anarchy and variant workarounds have abounded.

I'm glad solving world hunger is out of scope for this :)  I understand 
your position but my personal opinion is that simple support for #! is 
more desirable.  I'd be happy to go with the consensus though...

Cheers,

Mark

From g.brandl at gmx.net  Wed Mar  9 07:50:02 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 09 Mar 2011 07:50:02 +0100
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
	this documented?
In-Reply-To: <4D76B201.2040809@v.loewis.de>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>	<il1hhr$mrr$1@dough.gmane.org>
	<4D7498F1.3070602@arbash-meinel.com>
	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
	<4D74A65D.40105@v.loewis.de>
	<6DE2A542-E3F8-4A76-A5BB-7C3B7629C384@barrys-emacs.org>
	<4D76B201.2040809@v.loewis.de>
Message-ID: <il780l$k6a$1@dough.gmane.org>

On 08.03.2011 23:47, "Martin v. L?wis" wrote:
>>> I think everything here is as it should be. People who really cared
>>> about forwards compatibility could have known, but factually, most
>>> people don't care enough. Those then learn for the first time that
>>> some feature was deprecated after it is actually removed. They then
>>> ask why it is removed, and somebody will tell them.
>>
>> I was not aware I could turn on deprecation warning for use of the C API.
>> How can I do that?
> 
> Not sure that you can. When I said "could have known", I meant "by 
> reading the documentation".

Well, it looks like the CObject functions actually emitted
PendingDeprecationWarnings when used:

http://hg.python.org/cpython/file/16f8f359db9c/Objects/cobject.c#l12

Georg


From g.brandl at gmx.net  Wed Mar  9 07:51:35 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 09 Mar 2011 07:51:35 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <4D7713C2.2090604@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de> <4D76E6D0.6020707@netwok.org>
	<4D7713C2.2090604@v.loewis.de>
Message-ID: <il783i$k6a$2@dough.gmane.org>

On 09.03.2011 06:44, "Martin v. L?wis" wrote:
>> I?m of the opinion that hg diffs should always use the extended git
>> format, given their usefulness.  A tool working with hg diffs that does
>> not support this format is broken IMO.
> 
> IMO, it's "hg diff --git" that's broken, as it doesn't include the base 
> revision (other formats, such as "hg export", do).

You might want to bring that up on mercurial-devel then.

Georg



From v+python at g.nevcal.com  Wed Mar  9 08:20:53 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Tue, 08 Mar 2011 23:20:53 -0800
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D771DD0.2010402@skippinet.com.au>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>	<4D7594F7.2050105@gmail.com>	<il621e$320$1@dough.gmane.org>
	<4D76E947.5030208@g.nevcal.com> <4D770ABD.8060009@gmail.com>
	<4D77188D.3080308@g.nevcal.com> <4D771DD0.2010402@skippinet.com.au>
Message-ID: <4D772A55.2000202@g.nevcal.com>

On 3/8/2011 10:27 PM, Mark Hammond wrote:
> On 9/03/2011 5:05 PM, Glenn Linderman wrote:
>>
>> Standard installation paths are accepted by about 99% of the users, so
>> embedding standard installation paths can work well for that batch of
>> users. Of course, Windows changes the standard path periodically, so
>> that it different from versions prior to and including WinXP versus
>> versions after WinXP. And they had no standard before WinNT (or if they
>> did, few followed it). Your comment does point out a possible need for
>> multiple standard installation paths just for different versions of
>> Windows, though :(
>
> The python installer ignores "Program Files" - as much as anything I'm 
> concerned about the drive letter - IIUC, Python will default to 
> installing on the system drive, which may not be C:

The system drive usually is C:, there is a fair bit of software that 
won't work when it is not C:, and in any particular corporate 
environment it is usually standardized by the IT folks.  And you are 
referring specifically to the CPython installer as the IronPython (for 
example) does install in Program Files.

>
> ...
>
>> Your premise that using a standard installation path in #@ restricts the
>> script to be targeted to one machine is fallacious, so the conclusions
>> are also.
>
> Sorry - I should have said "some machines with Python installed by the 
> installer".  Contrast this to the option of looking up the registry 
> and you have "all machines with Python installed by the installer".  
> I'm not going to quibble about the percentages in the first category 
> as I have no data to guide me, but I'm reasonably confident about the 
> "all" in the second.
>
> ...
>
>> The #! line is clearly is NOT "the only clue Windows needs to make it
>> work automagically" or we wouldn't be having this discussion at all.
>
> Sorry - I should have been clear - I meant "the only clue a windows 
> specific Python launcher needs".

Sorrier yet :)  I think you really meant "the only clue a Windows 
specific CPython specific Python launcher needs.

>
> > And
>> it is not at all clear if a Windows machine contains Jython, IronPython,
>> and Cython which one should be launched by a launcher.
>
> I think it is reasonably clear: it would be the same version which 
> would be launched on most *nix systems.  Are there any systems where 
> "/usr/bin/python" would use Jython, for example?

I have no idea the answer to your question... I don't think you do 
either.  There may be some.  The sysadmin can change what 
/usr/bin/python points to.  I have seen plenty of Unix systems where 
/bin/sh is really bash, for example, so if the replacement is 
"compatible enough" the sysadmin may choose to make such a change.


>> You could, of
>> course, argue that python-dev is only concerned with CPython, and the
>> launcher can be specific to CPython, and that argument might carry the
>> day, but the CPython registry lookup necessary to make that happen
>> doesn't help the users of alternate implementations a bit, forcing each
>> of them to implement their own launcher as well...
>
> I'd have no problem with the Windows launcher supporting other 
> implementations - I expect something like "/usr/bin/jython" would be 
> reasonable.  How we locate the installed jython is indeed an 
> interesting problem, but I'd guess it is surmountable - especially if 
> we can get the buy-in of these alternate implementations for their 
> future releases.

Indeed.  But now you have a script that require jython on all machines 
that it runs on, rather than being flexible in being configurable to use 
the preferred implementations of a particular environment (perhaps 
CPython 2.6 on Unix boxes, and Jython 2.5 on Windows boxes, or vice versa).


>
>> #!/usr/bin/env python2.6
>> #@"C:\Program Files\Env.exe" ipy2.6.3.exe
>
> As above, the C: assumes Windows is installed on C: - that may be 
> common, but not universal.  Further, a 64bit machine would probably 
> want "\Program Files (x86)" (which is becoming more and more common)

Yes, same C: issue as above, see response above.  And if the launcher 
comes in a 64-bit version for 64-bit machines, then it would be 
installed as C:\Program Files\Env.exe on the 64-bit machines.  That 
should be straightforward to achieve.


>
>>
>> in .py files and
>>
>> #!/usr/bin/env python2.6
>> #@"C:\Program Files\Env.exe" ipy2.6.3w.exe
>>
>> in .pyw files.
>
> I'm slightly skeptical about that - .pyw files are surely rare on *nix 
> systems and as we've discussed, pyw files are generally not meant to 
> be cmd-line scripts.  IOW, I'm skeptical scripts exist which are meant 
> to work with '/usr/bin/env python2.6' on *nix and pythonw.exe on windows.

Indeed, .pyw files are even rare on my Windows box :)

A GUI sort of Python script would generally want to be .pyw on a Windows 
box.  There are a variety of cross-platform GUIs such as Qt and 
wxWindows, so those same scripts could be written to work on Unix boxes 
also.  Unix, happily, doesn't care about the name of the script as long 
as the #! line points the right place, and neither does CPython on Unix, 
at least for non-module scripts (which are the ones that have #! lines 
anyway).  So it is quite conceivable, even if you have never done it 
personally.


>
> ...
>
>> So no matter what is done, it won't solve world hunger. Probably that's
>> why Windows users have been left high and dry for years in this
>> regard... there is no "system" Python on it, out of the box, so the only
>> users are those that are smart enough to download and install and
>> configure things, and those who use a Python embedded into an
>> application, at the cost of a Python installation per application,
>> because there has been no "system" Python, and because Windows users are
>> not perceived to be capable of, or willing to bother with, downloading
>> and installing various requisite dependencies.
>>
>> The resulting vacuum has been filled by people with different points of
>> view, because there has been no technique implemented, none declared to
>> be "best", and anarchy and variant workarounds have abounded.
>
> I'm glad solving world hunger is out of scope for this :)  I 
> understand your position but my personal opinion is that simple 
> support for #! is more desirable.  I'd be happy to go with the 
> consensus though...

The solution should be as simple as possible, but no simpler. -- Albert

I agree that parsing #! for a version and looking that up in the CPython 
registry entries would help in the limited circumstances where only the 
CPython implementation is of interest, and the same versions are 
available with the same names on all the machines of interest to the script.

Of course, my web host has /usr/bin/python (CPython 2.4.2),  
/usr/bin/python2.4 (Cpython 2.4.2) and /usr/bin/python (Cpython 2.6 -- 
apparently 2.6.0).  So when I choose the first, I get whatever the 
sysadmin chooses for that (they are slow to make changes for 
compatibility reasons, which is good).  When I choose the second for my 
#! line I get 2.4.2 there.  Now if I have  all of 2.4, 2.4.1, 2.4.3, and 
2.4.4 versions installed on my Windows box, which one should be run in 
the case of /usr/bin/python2.4?  The registry doesn't seem to tell which 
was installed first, second, or last.  Should it pick the newest, or the 
exact match of 2.4?  It can hardly intuit which version is most 
compatible with the other machines I run it on.  Whatever is picked 
would seem to be some heuristic.  And what if there is only 2.5 on the 
Windows boxes?  Or what if there is no CPython on the Windows box, but 
only Jython or IronPython, etc. the heuristics would have to understand 
all those mappings between versions... or simply not work at all, with 
no fallback technique to help it work.

With the #@ idea, application installers could ask which version of 
Python the application should be configured to use, from among the 
installed versions that the application has been tested with, and update 
the #@ lines, and that would stay constant for the life the application 
(and if the application has an installer that is that smart, it also 
wouldn't need a #! line, likely, when installed for Windows).  If there 
is no installer, then the user (or his sysadmin) must be smart enough to 
know how to use a text editor, and configure the version he wants by 
putting its path in the #@ line... and if the user (or his sysadmin) 
wants to use it cross-platform, then they put in the appropriate #! line 
for their Unix machines too.

Some configuration for the launcher would be required to handle the case 
where there is no #! line, or else in those cases, the launcher could 
report "no #@ line" like Unix's shell reports "syntax error" for python 
scripts handed to /bin/sh because the #! line was omitted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110308/7f4e9bdd/attachment-0001.html>

From stephen at xemacs.org  Wed Mar  9 08:48:10 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 09 Mar 2011 16:48:10 +0900
Subject: [Python-Dev] hg diff
In-Reply-To: <4D7713C2.2090604@v.loewis.de>
References: <4D72CB3A.5090006@v.loewis.de> <4D76E6D0.6020707@netwok.org>
	<4D7713C2.2090604@v.loewis.de>
Message-ID: <878vwoka4l.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. Loewis" writes:
 > > I?m of the opinion that hg diffs should always use the extended git
 > > format, given their usefulness.  A tool working with hg diffs that does
 > > not support this format is broken IMO.
 > 
 > IMO, it's "hg diff --git" that's broken, as it doesn't include the base 
 > revision (other formats, such as "hg export", do).

I agree that it's poor form to omit the revisions, and we should
supplicate Mercury at his temple.  But I don't see the problem for
Reitveld integration; they're easily available, no?  At least, so far
in the discussion the "two -r" form has been used, so this should do
the trick:

improved-hg-diff--git () {
    # usage: improved-hg-diff--git BASE TIP
    hg identify -i -r $1
    hg identify -i -r $2
    hg diff --git -r $1 -r $2
}

What am I missing?

From tjreedy at udel.edu  Wed Mar  9 08:57:58 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 09 Mar 2011 02:57:58 -0500
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D771DD0.2010402@skippinet.com.au>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>	<30A63A17
	-2320-49DB-9E5F-86C10290A817@fuhm.net>	<4D7594F7.2050105@gmail.com>	<il621e$320$1@dough.gmane.org>	<4D76E947.5030208@g.nevcal.com>
	<4D770ABD.8060009@gmail.com>	<4D77188D.3080308@g.nevcal.com>
	<4D771DD0.2010402@skippinet.com.au>
Message-ID: <il7bu4$41g$1@dough.gmane.org>

On 3/9/2011 1:27 AM, Mark Hammond wrote:

> your position but my personal opinion is that simple support for #! is
> more desirable.

I agree. One weird line in a file is enough!

-- 
Terry Jan Reedy


From scott+python-dev at scottdial.com  Wed Mar  9 09:15:33 2011
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Wed, 09 Mar 2011 03:15:33 -0500
Subject: [Python-Dev] hg mq workflow is broken (issue11450)
Message-ID: <4D773725.8020707@scottdial.com>

I wanted to draw attention to issue11450 [1]. In trying to using mq to
work on patches for CPython, I found that I could no longer get regrtest
to run. This issue comes down to the size of the output of
"hg id -t ." being much longer than expected.

$ hg qnew dummy-patch
$ echo "/* dummy change */" >> Modules/getbuildinfo.c
$ ./python -c 'import sys; print(sys.version)'
3.3a0 (dummy-patch qbase qtip tip:191f047a07b4+, Mar  9 )
[GCC 4.4.5]

This is a showstopper for using mq and CPython, since you can no longer
run regrtest because the platform module cannot parse that truncated string.

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From p.f.moore at gmail.com  Wed Mar  9 11:41:46 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 9 Mar 2011 10:41:46 +0000
Subject: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink
	upstream
In-Reply-To: <4D771DD0.2010402@skippinet.com.au>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>
	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>
	<20110304135723.F3307249609@kimball.webabinitio.net>
	<20110304101057.6b16622e@neurotica.wooz.org>
	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>
	<20110304133127.554716a0@neurotica.wooz.org>
	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>
	<4D7157EC.5090709@v.loewis.de> <4D718816.20304@skippinet.com.au>
	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>
	<4D723C90.6090307@voidspace.org.uk> <4D72F267.3050204@gmail.com>
	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>
	<4D743248.9060705@gmail.com> <4D754123.7070703@voidspace.org.uk>
	<AANLkTinneK71qC3Cy26=jypEZanVo82jmzLG20c-4PXC@mail.gmail.com>
	<30A63A17-2320-49DB-9E5F-86C10290A817@fuhm.net>
	<4D7594F7.2050105@gmail.com> <il621e$320$1@dough.gmane.org>
	<4D76E947.5030208@g.nevcal.com> <4D770ABD.8060009@gmail.com>
	<4D77188D.3080308@g.nevcal.com> <4D771DD0.2010402@skippinet.com.au>
Message-ID: <AANLkTi=_wKHLb_xZqkXxkpEgdZFBzhVkctNS0RqpEFL+@mail.gmail.com>

On 9 March 2011 06:27, Mark Hammond <mhammond at skippinet.com.au> wrote:
> I'm glad solving world hunger is out of scope for this :) ?I understand your
> position but my personal opinion is that simple support for #! is more
> desirable. ?I'd be happy to go with the consensus though...

Just in case you need some reassurance about the level of consensus, I
agree that simple support for #! is sufficient. Any more is YAGNI.

(But if you manage to solve world hunger, do let us know :-))

Paul.

From ncoghlan at gmail.com  Wed Mar  9 12:05:20 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 9 Mar 2011 06:05:20 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <il75tb$c8s$1@dough.gmane.org>
References: <il75tb$c8s$1@dough.gmane.org>
Message-ID: <AANLkTi=Fdbet55qe2xpi6-uQZZZUnDqi4zKMhmG7v7KS@mail.gmail.com>

On Wed, Mar 9, 2011 at 1:15 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> A publicly visible list of those decisions would
>
> a) make it easier for non-core developers to follow important changes on
> python-dev
>
> b) allow potentially impacted people to bring up their POV more quickly,
> e.g. during the alpha cycle of a deprecation release rather than the
> following release, as in this case
>
> c) document the decision taking process by listing the relevant mailing list
> threads
>
> d) help in writing the "what's new" documents

I've wondered myself if we should simply be more inclined to create
PEPs for changes with a wide impact, even if they're technically a
CPython-specific implementation decision (cf. zipfile/directory
execution, migration from PyCObject to PyCapsule API). Both of those
were backed by extensive tracker and mailing list discussions, but
there's no easy reference point for anyone coming across them later.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From scott+python-dev at scottdial.com  Wed Mar  9 13:04:12 2011
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Wed, 09 Mar 2011 07:04:12 -0500
Subject: [Python-Dev] hg mq workflow is broken (issue11450)
In-Reply-To: <4D773725.8020707@scottdial.com>
References: <4D773725.8020707@scottdial.com>
Message-ID: <4D776CBC.9080308@scottdial.com>

On 3/9/2011 3:15 AM, Scott Dial wrote:
> I wanted to draw attention to issue11450 [1]. In trying to using mq to
> work on patches for CPython, I found that I could no longer get regrtest
> to run.

Just to update this thread, thanks to the swift work of Nadeem Vawda and
Antoine for pushing it in, it's fixed!

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From marks at dcs.gla.ac.uk  Wed Mar  9 13:55:19 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Wed, 09 Mar 2011 12:55:19 +0000
Subject: [Python-Dev] Implementation of variable sized objects.
In-Reply-To: <AANLkTin261KPx6WTv7OThjm1ivEO-7eF6X6ACst_MGkA@mail.gmail.com>
References: <4D70A45A.5090609@v.loewis.de>
	<AANLkTin261KPx6WTv7OThjm1ivEO-7eF6X6ACst_MGkA@mail.gmail.com>
Message-ID: <4D7778B7.4010805@dcs.gla.ac.uk>

Hi,

I hope this is the right place to ask this.

Do anyone know why the str (unicode) object is implemented
with an external buffer like list, rather than internal one like
tuple and bytes?
Would anything bad happen if it were changed?

I'm not suggesting any changes, just doing some research.

Cheers,
Mark.


From eric at trueblade.com  Wed Mar  9 14:37:41 2011
From: eric at trueblade.com (Eric Smith)
Date: Wed, 09 Mar 2011 08:37:41 -0500
Subject: [Python-Dev] Implementation of variable sized objects.
In-Reply-To: <4D7778B7.4010805@dcs.gla.ac.uk>
References: <4D70A45A.5090609@v.loewis.de>	<AANLkTin261KPx6WTv7OThjm1ivEO-7eF6X6ACst_MGkA@mail.gmail.com>
	<4D7778B7.4010805@dcs.gla.ac.uk>
Message-ID: <4D7782A5.7050506@trueblade.com>

On 3/9/2011 7:55 AM, Mark Shannon wrote:
> Hi,
>
> I hope this is the right place to ask this.
>
> Do anyone know why the str (unicode) object is implemented
> with an external buffer like list, rather than internal one like
> tuple and bytes?
> Would anything bad happen if it were changed?
>
> I'm not suggesting any changes, just doing some research.

See http://bugs.python.org/issue1943

Eric.

From tlesher at gmail.com  Wed Mar  9 15:50:50 2011
From: tlesher at gmail.com (Tim Lesher)
Date: Wed, 9 Mar 2011 09:50:50 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <il75tb$c8s$1@dough.gmane.org>
References: <il75tb$c8s$1@dough.gmane.org>
Message-ID: <AANLkTikFXeUw477+vhEs1xfFeTJpy_Eeo54LqYbLfG90@mail.gmail.com>

On Wed, Mar 9, 2011 at 01:15, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Actually, why not put up a web page of "upcoming changes" somewhere, that
> lists major decisions with user impact that were taken on python-dev?
> Including a link to the relevant discussion and decision. Often enough,
> decisions are taken inside of huge mailing list threads that get off-topic
> before someone has "the right idea" and everyone who's still there to listen
> agrees. Even for people lurking around on python-dev, it's easy enough to
> miss these moments.

We used to do biweekly-ish Python-Dev summaries for this reason.

The original links at python.org appear to be down, but I found an
example mirrored at
ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html

Would resuming these and putting them back on python.org address the issue?

It's been on my back burner for about two years now, but I want to
make sure I can keep up before diving in again.

-- 
Tim Lesher <tlesher at gmail.com>

From jnoller at gmail.com  Wed Mar  9 17:24:02 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 9 Mar 2011 11:24:02 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <il75tb$c8s$1@dough.gmane.org>
References: <il75tb$c8s$1@dough.gmane.org>
Message-ID: <AANLkTikYrtC1UB+2AvaV5p=LmZwE7LTeD-mw3qpCTqOw@mail.gmail.com>

On Wed, Mar 9, 2011 at 1:15 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> "Martin v. L?wis", 08.03.2011 23:47:
>>>>
>>>> I think everything here is as it should be. People who really cared
>>>> about forwards compatibility could have known, but factually, most
>>>> people don't care enough. Those then learn for the first time that
>>>> some feature was deprecated after it is actually removed. They then
>>>> ask why it is removed, and somebody will tell them.
>>>
>>> I was not aware I could turn on deprecation warning for use of the C
>>> API. How can I do that?
>>
>> Not sure that you can. When I said "could have known", I meant "by
>> reading the documentation".
>
> I can confirm that the Cython project was as surprised of the PyCapsule
> change in Python 3.2 as (I guess) most other users, and I would claim that
> we are a project with one of the highest probabilities of being impacted by
> C-API changes.
>
> Maybe the "what's new" document could at least include a link to the
> relevant python-dev discussion/decision, so that fewer people have to ask
> back?
>
> Actually, why not put up a web page of "upcoming changes" somewhere, that
> lists major decisions with user impact that were taken on python-dev?
> Including a link to the relevant discussion and decision. Often enough,
> decisions are taken inside of huge mailing list threads that get off-topic
> before someone has "the right idea" and everyone who's still there to listen
> agrees. Even for people lurking around on python-dev, it's easy enough to
> miss these moments.
>
> A publicly visible list of those decisions would
>
> a) make it easier for non-core developers to follow important changes on
> python-dev
>
> b) allow potentially impacted people to bring up their POV more quickly,
> e.g. during the alpha cycle of a deprecation release rather than the
> following release, as in this case
>
> c) document the decision taking process by listing the relevant mailing list
> threads
>
> d) help in writing the "what's new" documents
>
> Stefan
>

A "python dev" blog/news site is on the list of topics for the
language summit tomorrow at PyCon. Doug hellmann is going to be
managing that discussion - but there is a general agreement we have to
spread word outside of core and into the general world a little bit
more - and this also applies to other python VMs as well.

jesse

From g.rodola at gmail.com  Wed Mar  9 19:42:36 2011
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Wed, 9 Mar 2011 19:42:36 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <il75tb$c8s$1@dough.gmane.org>
References: <il75tb$c8s$1@dough.gmane.org>
Message-ID: <AANLkTimjaO+mQ2RBC0VqQqNN7cXNzPiwq77j_nS2CUO5@mail.gmail.com>

> Actually, why not put up a web page of "upcoming changes" somewhere, that
> lists major decisions with user impact that were taken on python-dev?

I think "what's new" serves this purpose properly.
Usually, every time I commit a new feature, I update the what's new
file as well.
In fact we already have a partial "roadmap" for Python 3.3:
http://docs.python.org/dev/whatsnew/3.3.html

I'm not sure who else is doing the same though.
If we agree that every time a new feature is added we also update the
what's new file we can have such a roadmap with relatively no effort.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/



2011/3/9 Stefan Behnel <stefan_ml at behnel.de>:
> "Martin v. L?wis", 08.03.2011 23:47:
>>>>
>>>> I think everything here is as it should be. People who really cared
>>>> about forwards compatibility could have known, but factually, most
>>>> people don't care enough. Those then learn for the first time that
>>>> some feature was deprecated after it is actually removed. They then
>>>> ask why it is removed, and somebody will tell them.
>>>
>>> I was not aware I could turn on deprecation warning for use of the C
>>> API. How can I do that?
>>
>> Not sure that you can. When I said "could have known", I meant "by
>> reading the documentation".
>
> I can confirm that the Cython project was as surprised of the PyCapsule
> change in Python 3.2 as (I guess) most other users, and I would claim that
> we are a project with one of the highest probabilities of being impacted by
> C-API changes.
>
> Maybe the "what's new" document could at least include a link to the
> relevant python-dev discussion/decision, so that fewer people have to ask
> back?
>
> Actually, why not put up a web page of "upcoming changes" somewhere, that
> lists major decisions with user impact that were taken on python-dev?
> Including a link to the relevant discussion and decision. Often enough,
> decisions are taken inside of huge mailing list threads that get off-topic
> before someone has "the right idea" and everyone who's still there to listen
> agrees. Even for people lurking around on python-dev, it's easy enough to
> miss these moments.
>
> A publicly visible list of those decisions would
>
> a) make it easier for non-core developers to follow important changes on
> python-dev
>
> b) allow potentially impacted people to bring up their POV more quickly,
> e.g. during the alpha cycle of a deprecation release rather than the
> following release, as in this case
>
> c) document the decision taking process by listing the relevant mailing list
> threads
>
> d) help in writing the "what's new" documents
>
> Stefan
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
>

From doug.hellmann at gmail.com  Wed Mar  9 21:40:56 2011
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Wed, 9 Mar 2011 15:40:56 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
	it's too late" (was: PyCObject_AsVoidPtr removed from python
	3.2 - is this documented?)
In-Reply-To: <AANLkTikFXeUw477+vhEs1xfFeTJpy_Eeo54LqYbLfG90@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTikFXeUw477+vhEs1xfFeTJpy_Eeo54LqYbLfG90@mail.gmail.com>
Message-ID: <A8557CC0-68C0-46A6-B2AF-DF9200FFF4B7@gmail.com>


On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote:

> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Actually, why not put up a web page of "upcoming changes" somewhere, that
>> lists major decisions with user impact that were taken on python-dev?
>> Including a link to the relevant discussion and decision. Often enough,
>> decisions are taken inside of huge mailing list threads that get off-topic
>> before someone has "the right idea" and everyone who's still there to listen
>> agrees. Even for people lurking around on python-dev, it's easy enough to
>> miss these moments.
> 
> We used to do biweekly-ish Python-Dev summaries for this reason.
> 
> The original links at python.org appear to be down, but I found an
> example mirrored at
> ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html
> 
> Would resuming these and putting them back on python.org address the issue?
> 
> It's been on my back burner for about two years now, but I want to
> make sure I can keep up before diving in again.

As Jesse mentioned, this topic came up on the board mailing list recently for a reason completely unrelated to this thread. As a result of that discussion, the board has asked me in my capacity as PSF Communications Director to help the python-dev crew set up a blog (or other forum) through which you can communicate news about major projects undertaken during development. This would be in addition to, rather than a replacement for, individual developer blogs, and would provide an official channel for the team to talk about projects publicly after they are complete. 

Topics proposed as part of the discussion on the board list included the hg migration, the new developer's guide, changes to the Mac installer, and the updated release process for 3.2. Those are just examples, though. This deprecation would make another good topic, and I'm sure everyone can think of others. Consider the blog as an analog to the PEP process. Where PEPs come at the beginning of a project, a blog post would come at a major milestones or the completion of a project.

The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. I will provide editorial guidance to anyone that wants me to read their posts before they are published, and I will administer the tool if needed (granting access and moderating comments that look like spam).

I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea. I was going to hold discussion for the mailing list until after that meeting, but since the topic came up on its own please go ahead and respond here with questions or comments, especially if you won't be in Atlanta tomorrow. Let's table discussion of tools for now, though, because I want to make sure there is enough support for the project before we spend too much energy on implementation details.

Doug


From solipsis at pitrou.net  Wed Mar  9 22:14:14 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 9 Mar 2011 22:14:14 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjaO+mQ2RBC0VqQqNN7cXNzPiwq77j_nS2CUO5@mail.gmail.com>
Message-ID: <20110309221414.690e9aca@pitrou.net>

On Wed, 9 Mar 2011 19:42:36 +0100
Giampaolo Rodol? <g.rodola at gmail.com> wrote:
> > Actually, why not put up a web page of "upcoming changes" somewhere, that
> > lists major decisions with user impact that were taken on python-dev?
> 
> I think "what's new" serves this purpose properly.
> Usually, every time I commit a new feature, I update the what's new
> file as well.
> In fact we already have a partial "roadmap" for Python 3.3:
> http://docs.python.org/dev/whatsnew/3.3.html

Perhaps the part of the "what's new" document which deals with porting
issues and compatibility breakage would need more highlighting?

Regards

Antoine.



From pje at telecommunity.com  Wed Mar  9 22:30:56 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 09 Mar 2011 16:30:56 -0500
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <4D7122D1.30505@voidspace.org.uk>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
	<20110304120743.22042ded@neurotica.wooz.org>
	<4D7122D1.30505@voidspace.org.uk>
Message-ID: <20110309213119.9F22D3A4116@sparrow.telecommunity.com>

At 05:35 PM 3/4/2011 +0000, Michael Foord wrote:
>That (below) is not distutils it is setuptools. distutils just uses 
>`scripts=[...]`, which annoyingly *doesn't* work with setuptools.

Er, what?  That's news to me.  Could you file a bug report about what 
doesn't work, specifically?


From tjreedy at udel.edu  Wed Mar  9 23:18:34 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 09 Mar 2011 17:18:34 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <20110309221414.690e9aca@pitrou.net>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTimjaO+mQ2RBC0VqQqNN7cXNzPiwq77j_nS2CUO5@mail.gmail.com>
	<20110309221414.690e9aca@pitrou.net>
Message-ID: <il8ubp$c1e$1@dough.gmane.org>

On 3/9/2011 4:14 PM, Antoine Pitrou wrote:
> On Wed, 9 Mar 2011 19:42:36 +0100

> Perhaps the part of the "what's new" document which deals with porting
> issues and compatibility breakage would need more highlighting?

That could go at the tops.

Deletions in 3.3
...
Planned deletions in future versions
...
Porting issues
...


then the usual
...

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Wed Mar  9 23:22:58 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 09 Mar 2011 17:22:58 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <AANLkTikFXeUw477+vhEs1xfFeTJpy_Eeo54LqYbLfG90@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTikFXeUw477+vhEs1xfFeTJpy_Eeo54LqYbLfG90@mail.gmail.com>
Message-ID: <il8uk1$eqd$1@dough.gmane.org>

On 3/9/2011 9:50 AM, Tim Lesher wrote:

> We used to do biweekly-ish Python-Dev summaries for this reason.

They were, is a sense, too detailed, complete, and voluminous.
In whatever format, terser announcement of just things others really 
need to know - like decisions that affect them, would probably be more 
useful.

There is also python-announce, but I do not follow it.

-- 
Terry Jan Reedy


From foom at fuhm.net  Thu Mar 10 00:20:01 2011
From: foom at fuhm.net (James Y Knight)
Date: Wed, 9 Mar 2011 18:20:01 -0500
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
Message-ID: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>

It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to "import ssl".

Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem...

Thanks to Ulrik Sverdrup  (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing this out...

James

[1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html

From barry at barrys-emacs.org  Wed Mar  9 23:44:43 2011
From: barry at barrys-emacs.org (Barry Scott)
Date: Wed, 9 Mar 2011 22:44:43 +0000
Subject: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is
	this documented?
In-Reply-To: <il780l$k6a$1@dough.gmane.org>
References: <7DB3E445-223F-45A0-874F-4E6A842C357D@barrys-emacs.org>	<il1hhr$mrr$1@dough.gmane.org>
	<4D7498F1.3070602@arbash-meinel.com>
	<AANLkTin7v4XT_KO=YphuoYfPPT63o4gVapzJxdSDw=E8@mail.gmail.com>
	<4D74A65D.40105@v.loewis.de>
	<6DE2A542-E3F8-4A76-A5BB-7C3B7629C384@barrys-emacs.org>
	<4D76B201.2040809@v.loewis.de> <il780l$k6a$1@dough.gmane.org>
Message-ID: <AA3B8067-39A9-4E82-AFDF-496934A0A47E@barrys-emacs.org>

On 9 Mar 2011, at 06:50, Georg Brandl wrote:

> On 08.03.2011 23:47, "Martin v. L?wis" wrote:
>>>> I think everything here is as it should be. People who really cared
>>>> about forwards compatibility could have known, but factually, most
>>>> people don't care enough. Those then learn for the first time that
>>>> some feature was deprecated after it is actually removed. They then
>>>> ask why it is removed, and somebody will tell them.
>>> 
>>> I was not aware I could turn on deprecation warning for use of the C API.
>>> How can I do that?
>> 
>> Not sure that you can. When I said "could have known", I meant "by 
>> reading the documentation".
> 
> Well, it looks like the CObject functions actually emitted
> PendingDeprecationWarnings when used:
> 
> http://hg.python.org/cpython/file/16f8f359db9c/Objects/cobject.c#l12

I changed my testing code for PyCXX to run python -W default and did
indeed get a nice message:

Demo/Python3/test_simple.py:1: PendingDeprecationWarning: The CObject API is deprecated as of Python 3.1.  Please convert to using the Capsule API.

Thanks for the info. I'm going to run PyCXX like this for all future release testing.

Barry


From solipsis at pitrou.net  Thu Mar 10 00:32:20 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 10 Mar 2011 00:32:20 +0100
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
	OpenSSL
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
Message-ID: <20110310003220.7f1fc86e@pitrou.net>

On Wed, 9 Mar 2011 18:20:01 -0500
James Y Knight <foom at fuhm.net> wrote:
> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to "import ssl".
> 
> Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem...

A Python program is not a derivative of the Python interpreter any more
than a C program is a derivative of gcc (or any other compiler).

That said, with a non-shared build of Python 3.x:

$ ldd ./python
	linux-vdso.so.1 =>  (0x00007fffa574d000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd9a56d2000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fd9a54ce000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007fd9a52cb000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fd9a5049000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fd9a4cdd000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd9a58ee000)

$ objdump -p ./python | grep NEEDED
  NEEDED               libpthread.so.0
  NEEDED               libdl.so.2
  NEEDED               libutil.so.1
  NEEDED               libm.so.6
  NEEDED               libc.so.6

Also, with the system Python 2.6 shipped on a Mandriva distribution:

$ ldd /usr/bin/python
	linux-vdso.so.1 =>  (0x00007fff8456d000)
	libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0
(0x00007f1a0b1e2000) libc.so.6 => /lib64/libc.so.6 (0x00007f1a0ae76000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f1a0ac72000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1a0aa56000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f1a0a853000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f1a0a5d1000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1a0b583000)

$ objdump -p /usr/bin/python | grep NEEDED
  NEEDED               libpython2.6.so.1.0
  NEEDED               libc.so.6


So I'm not sure which build options led to that result.

Regards

Antoine.



From morph at debian.org  Thu Mar 10 00:45:01 2011
From: morph at debian.org (Sandro Tosi)
Date: Thu, 10 Mar 2011 00:45:01 +0100
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
	OpenSSL
In-Reply-To: <20110310003220.7f1fc86e@pitrou.net>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
	<20110310003220.7f1fc86e@pitrou.net>
Message-ID: <AANLkTi=Ppn_pQFWF8WJOOhpyfGROCKGTxBbthugOAPJS@mail.gmail.com>

On Thu, Mar 10, 2011 at 00:32, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Also, with the system Python 2.6 shipped on a Mandriva distribution:
>
> $ ldd /usr/bin/python
> ? ? ? ?linux-vdso.so.1 => ?(0x00007fff8456d000)
> ? ? ? ?libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0
> (0x00007f1a0b1e2000) libc.so.6 => /lib64/libc.so.6 (0x00007f1a0ae76000)
> ? ? ? ?libdl.so.2 => /lib64/libdl.so.2 (0x00007f1a0ac72000)
> ? ? ? ?libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1a0aa56000)
> ? ? ? ?libutil.so.1 => /lib64/libutil.so.1 (0x00007f1a0a853000)
> ? ? ? ?libm.so.6 => /lib64/libm.so.6 (0x00007f1a0a5d1000)
> ? ? ? ?/lib64/ld-linux-x86-64.so.2 (0x00007f1a0b583000)
>
> $ objdump -p /usr/bin/python | grep NEEDED
> ?NEEDED ? ? ? ? ? ? ? libpython2.6.so.1.0
> ?NEEDED ? ? ? ? ? ? ? libc.so.6

(just nitpicking) but it's there on a debian system:

$ ldd /usr/bin/python
	linux-vdso.so.1 =>  (0x00007ffff7bff000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f9abcb82000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f9abc97e000)
	libutil.so.1 => /lib/libutil.so.1 (0x00007f9abc77a000)
	libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f9abc525000)
	libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f9abc184000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f9abbf6c000)
	libm.so.6 => /lib/libm.so.6 (0x00007f9abbcea000)
	libc.so.6 => /lib/libc.so.6 (0x00007f9abb989000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9abcdc4000)

$ objdump -p /usr/bin/python | grep NEEDED
  NEEDED               libpthread.so.0
  NEEDED               libdl.so.2
  NEEDED               libutil.so.1
  NEEDED               libssl.so.0.9.8
  NEEDED               libcrypto.so.0.9.8
  NEEDED               libz.so.1
  NEEDED               libm.so.6
  NEEDED               libc.so.6

It seems introduced by the patch debian/patches/setup-modules-ssl.diff
with description "# DP: Modules/Setup.dist: patch to build _hashlib
and _ssl extensions statically"

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From eltoder at gmail.com  Thu Mar 10 01:31:45 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Wed, 9 Mar 2011 19:31:45 -0500
Subject: [Python-Dev] constant folding of -0
Message-ID: <AANLkTinpS+NPmHQtGEbLNO8iwgRpnJSB84EcoTX7i3tm@mail.gmail.com>

Hello,

I've noticed since version 3.2 python doesn't fold -0:

Python 3.1.3 (r313:86834, Nov 28 2010, 10:01:07)
>>> def foo(): return -0
>>> dis(foo)
  1           0 LOAD_CONST               1 (0)
              3 RETURN_VALUE

Python 3.2 (r32:88445, Feb 20 2011, 21:30:00)
>>> def foo(): return -0
>>> dis(foo)
  1           0 LOAD_CONST               1 (0)
              3 UNARY_NEGATIVE
              4 RETURN_VALUE

(version built from head behaves the same way).

It looks like folding -0 is disabled in peephole since this commit
http://hg.python.org/cpython/diff/660419bdb4ae/Python/compile.c
which was a long time ago. Before 3.2 -0 was likely folded in the
parser -- in a more complex case no folding happens in either version:

>>> def foo(): return -(1-1)
>>> dis(foo)
  1           0 LOAD_CONST               2 (0)
              3 UNARY_NEGATIVE
              4 RETURN_VALUE

In 3.2 parser no longer folds -0.

So I wanted to ask why folding of -0 was disabled in peephole? Commit
message makes me think this was a work-around for a problem in marshal
-- perhaps it couldn't save -0.0 properly and so not creating -0.0 in
the code objects was a simple fix. (This would mean the change
predates folding in the parser.) Was marshal fixed? If I revert the
change everything seems to work and all tests pass. Since tests are
run with .pyc-s I assume they test marshal?
Maybe this check is no longer needed and can be reverted? Or is it
there for some different reason which still holds?

Regards,
Eugene

From solipsis at pitrou.net  Thu Mar 10 01:40:30 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 10 Mar 2011 01:40:30 +0100
Subject: [Python-Dev] constant folding of -0
References: <AANLkTinpS+NPmHQtGEbLNO8iwgRpnJSB84EcoTX7i3tm@mail.gmail.com>
Message-ID: <20110310014030.21bd6c56@pitrou.net>


Hello,

> I've noticed since version 3.2 python doesn't fold -0:

Indeed, see http://bugs.python.org/issue11244

Regards

Antoine.



From sturla at molden.no  Thu Mar 10 02:25:08 2011
From: sturla at molden.no (Sturla Molden)
Date: Thu, 10 Mar 2011 02:25:08 +0100
Subject: [Python-Dev] Bugs in thread_nt.h
Message-ID: <4D782874.7070803@molden.no>


Atomic operations (InterlockedCompareExchange, et al.) are used on the 
field 'owned' in NRMUTEX. These methods require the memory to be aligned 
on 32-byte boundaries. They also require the volatile qualifer. Three 
small changes are therefore needed (see below).


Regards,
Sturla Molden





typedef struct NRMUTEX {
     volatile LONG   owned ;  /* Bugfix: remember volatile */
     DWORD  thread_id ;
     HANDLE hevent ;
} NRMUTEX, *PNRMUTEX;


NRMUTEX
AllocNonRecursiveMutex(void)
{
     PNRMUTEX mutex = (PNRMUTEX)_aligned_malloc(sizeof(NRMUTEX),32) ; /* 
Bugfix: align to 32-bytes */
     if (mutex && !InitializeNonRecursiveMutex(mutex))
     {
         free(mutex) ;
         mutex = NULL ;
     }
     return mutex ;
}

void
FreeNonRecursiveMutex(PNRMUTEX mutex)
{
     if (mutex)
     {
         DeleteNonRecursiveMutex(mutex) ;
         _aligned_free(mutex) ; /* Bugfix: align to 32-bytes */
     }
}








From jsbueno at python.org.br  Thu Mar 10 02:27:08 2011
From: jsbueno at python.org.br (Joao S. O. Bueno)
Date: Wed, 9 Mar 2011 22:27:08 -0300
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
	OpenSSL
In-Reply-To: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
Message-ID: <AANLkTi=pOQdVb8N025PLhm++_x252aFNBjNVPqtd=_bL@mail.gmail.com>

On Wed, Mar 9, 2011 at 8:20 PM, James Y Knight <foom at fuhm.net> wrote:
> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to "import ssl".
>
> Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem...

Hi -


Any libraries commonly avaliable with a CPython instalation can be
considered as "system libraries" for GPL purposes - and so
this would fall in the "system library exception" as described by the FAQ:

http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

In GPLv2 we have
"""
However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable.
"""

And in v3:
"""
The ?System Libraries? of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
?Major Component?, in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
"""


regards,

   js
  -><-

>
> Thanks to Ulrik Sverdrup ?(http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing this out...
>
> James
>
> [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>

From mhammond at skippinet.com.au  Thu Mar 10 03:02:49 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Thu, 10 Mar 2011 13:02:49 +1100
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <4D782874.7070803@molden.no>
References: <4D782874.7070803@molden.no>
Message-ID: <4D783149.5020404@skippinet.com.au>

These issues are best put in the tracker so they don't get lost - 
especially at the moment with lots of regulars at pycon.

It would also be good to know if there is an actual behaviour bug caused 
by this (ie, what problems can be observed which are caused by the 
current code?)

Cheers,

Mark

On 10/03/2011 12:25 PM, Sturla Molden wrote:
>
> Atomic operations (InterlockedCompareExchange, et al.) are used on the
> field 'owned' in NRMUTEX. These methods require the memory to be aligned
> on 32-byte boundaries. They also require the volatile qualifer. Three
> small changes are therefore needed (see below).
>
>
> Regards,
> Sturla Molden
>
>
>
>
>
> typedef struct NRMUTEX {
> volatile LONG owned ; /* Bugfix: remember volatile */
> DWORD thread_id ;
> HANDLE hevent ;
> } NRMUTEX, *PNRMUTEX;
>
>
> NRMUTEX
> AllocNonRecursiveMutex(void)
> {
> PNRMUTEX mutex = (PNRMUTEX)_aligned_malloc(sizeof(NRMUTEX),32) ; /*
> Bugfix: align to 32-bytes */
> if (mutex && !InitializeNonRecursiveMutex(mutex))
> {
> free(mutex) ;
> mutex = NULL ;
> }
> return mutex ;
> }
>
> void
> FreeNonRecursiveMutex(PNRMUTEX mutex)
> {
> if (mutex)
> {
> DeleteNonRecursiveMutex(mutex) ;
> _aligned_free(mutex) ; /* Bugfix: align to 32-bytes */
> }
> }
>
>
>
>
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/skippy.hammond%40gmail.com
>


From eltoder at gmail.com  Thu Mar 10 03:17:34 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Thu, 10 Mar 2011 02:17:34 +0000 (UTC)
Subject: [Python-Dev] constant folding of -0
References: <AANLkTinpS+NPmHQtGEbLNO8iwgRpnJSB84EcoTX7i3tm@mail.gmail.com>
	<20110310014030.21bd6c56@pitrou.net>
Message-ID: <loom.20110310T030107-127@post.gmane.org>

> Indeed, see http://bugs.python.org/issue11244

Yes, I've noticed that too. However, if I'm not missing something, your patches
do not address folding of -0.

Btw, there's an alternative approach to allow "recursive" constant folding.
Instead of keeping a stack of last constants, you can keep a pointer to the
start of the last (LOAD_CONSTs + NOPs) run and the number of LOAD_CONSTs in
that run (called lastlc in the current version). When you want Nth constant
from the end, you start from that pointer and skip lastlc-N constants. You
also make a function to get next constant from that point. This approach has
worse time complexity for searching in a long run of LOAD_CONSTs, however,
there are upsides:
- very long runs of constants are rare in real code
- it uses less memory and doesn't have arbitrary limits on the size of the run
- it's book-keeping overhead is smaller, so when you don't have long runs of
constants (common case, I believe), it should be faster
- I think it's simpler to implement
(There's also an optimization -- if
(current_position - start_of_run) / 3 == lastlc
there are no NOPs in the run and you can get constants by simple indexing).

Eugene



From ronaldoussoren at mac.com  Thu Mar 10 03:11:04 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 09 Mar 2011 21:11:04 -0500
Subject: [Python-Dev] Support the /usr/bin/python2 symlink upstream
In-Reply-To: <4D715B2F.7070501@v.loewis.de>
References: <AANLkTikapt=rxP7Top3f1eKimj-gGcm48iCDnmyt+a2x@mail.gmail.com>
	<78304f09-c144-e8c6-e2ef-d243c2dd97fd@me.com>
	<AANLkTim8f701W3qmyhYvUoWK9ECWtzTU8KsjiYTPT3vy@mail.gmail.com>
	<4D712B05.2020607@voidspace.org.uk> <4D715B2F.7070501@v.loewis.de>
Message-ID: <3BCEBDFF-6C93-4A01-8F7E-F212FA0DB312@mac.com>


On 4 Mar, 2011, at 16:35, Martin v. L?wis wrote:
> 
> 
> I'd still like the PEP to tell me whether it's python3w.exe or
> pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
> me). It would also be good if the PEP took a position on providing
> pythonXY.exe binaries on Windows (with the related question of
> whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe)

It is pythonw3 and pythonw3.2 on OSX.

Ronald

From sturla at molden.no  Thu Mar 10 04:15:35 2011
From: sturla at molden.no (Sturla Molden)
Date: Thu, 10 Mar 2011 04:15:35 +0100
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <4D783149.5020404@skippinet.com.au>
References: <4D782874.7070803@molden.no> <4D783149.5020404@skippinet.com.au>
Message-ID: <4D784257.4020505@molden.no>

Den 10.03.2011 03:02, skrev Mark Hammond:
> These issues are best put in the tracker so they don't get lost - 
> especially at the moment with lots of regulars at pycon.
>
  Ok, sorry :-)


> It would also be good to know if there is an actual behaviour bug 
> caused by this (ie, what problems can be observed which are caused by 
> the current code?)

None that I have observed, but this is required according to MSDN.

Theoretically, an optimizing compiler could cache the 'owned' field if 
it's not declared volatile. It currently works because a wait on the 
lock is implemented with a WaitForSingleObject on a kernel event object 
when the waitfalg is set. If the wait mechanism is changed to a much 
less expensive user-space spinlock, just releasing the time-slice by 
Sleep(0) for each iteration, it will certainly fail without a volatile 
qualifier.

As for InterlockedCompareExchange et al., MSDN says this: "The 
parameters for this function must be aligned on a 32-bit boundary; 
otherwise, the function will behave unpredictably on multiprocessor x86 
systems and any non-x86 systems. See _aligned_malloc."

Well, it does not hurt to obey :-)

Regards,
Sturla




From anikom15 at gmail.com  Thu Mar 10 04:49:55 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Wed, 09 Mar 2011 19:49:55 -0800
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
 OpenSSL
In-Reply-To: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
Message-ID: <1299728995.20151.1.camel@localhost.localdomain>

On Wed, 2011-03-09 at 18:20 -0500, James Y Knight wrote:
> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to "import ssl".
> 
> Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem...
> 
> Thanks to Ulrik Sverdrup  (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing this out...
> 
> James
> 
> [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html

Is it legal to distribute GPL programs that use the Win32 API?


From martin at v.loewis.de  Thu Mar 10 04:54:18 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 09 Mar 2011 22:54:18 -0500
Subject: [Python-Dev] hg diff
In-Reply-To: <878vwoka4l.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D72CB3A.5090006@v.loewis.de>	<4D76E6D0.6020707@netwok.org>	<4D7713C2.2090604@v.loewis.de>
	<878vwoka4l.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D784B6A.9070602@v.loewis.de>

>   >  IMO, it's "hg diff --git" that's broken, as it doesn't include the base
>   >  revision (other formats, such as "hg export", do).
>
> I agree that it's poor form to omit the revisions, and we should
> supplicate Mercury at his temple.  But I don't see the problem for
> Reitveld integration; they're easily available, no?  At least, so far
> in the discussion the "two -r" form has been used, so this should do
> the trick:
>
> improved-hg-diff--git () {
>      # usage: improved-hg-diff--git BASE TIP
>      hg identify -i -r $1
>      hg identify -i -r $2
>      hg diff --git -r $1 -r $2
> }
>
> What am I missing?

Not sure what problem you are trying to solve. To make such a script
useful, users would actually have to use it, instead of using what they
use now, right? If so, how does that help me with patches that don't
have this form?

If I can get users to use something different, any of "diff without 
--git", "export with or without --git", "outgoing with or without --git"
would do (although outgoing uses a localized header, which would make
it more difficult to parse).

Regards,
Martin

From martin at v.loewis.de  Thu Mar 10 05:08:00 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 09 Mar 2011 23:08:00 -0500
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
	OpenSSL
In-Reply-To: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
Message-ID: <4D784EA0.8060207@v.loewis.de>

Am 09.03.11 18:20, schrieb James Y Knight:
> [1] Python (from 2.6) is *always* linked against openssl

Others have already pointed that out, but let me stress it again:
this statement is false. It is as possible and easy to build Python
without OpenSSL as it always was.

 > instead of waiting for you to "import ssl".

In addition, that is also false. Even if OpenSSL is used, it is easy
to build Python so that OpenSSL is only loaded when needed.

Regards,
Martin

From jsbueno at python.org.br  Thu Mar 10 05:10:38 2011
From: jsbueno at python.org.br (Joao S. O. Bueno)
Date: Thu, 10 Mar 2011 01:10:38 -0300
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
	OpenSSL
In-Reply-To: <1299728995.20151.1.camel@localhost.localdomain>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
	<1299728995.20151.1.camel@localhost.localdomain>
Message-ID: <AANLkTi=b8XBJnW2_5d_HBEXNWFTaM=DezjdPW0SfR0um@mail.gmail.com>

On Thu, Mar 10, 2011 at 12:49 AM, Westley Mart?nez <anikom15 at gmail.com> wrote:
> On Wed, 2011-03-09 at 18:20 -0500, James Y Knight wrote:
>> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to "import ssl".
>>
>> Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem...
>>
>> Thanks to Ulrik Sverdrup ?(http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing this out...
>>
>> James
>>
>> [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html
>
> Is it legal to distribute GPL programs that use the Win32 API?

Of course it is -- otherwise no program running on windows could ever
be under the GPL.
You probably are  thinking of Python programs that would specifically
use the win32 extensions --
but implicitly any program, including binary programs, using Windows
will have to use some API from
the OS in order to communicate with the rest of the system and the world.

This "system library" exception could not apply automatically to
Python win32 if its terms where too restrictive or if
it was a component hard to set up, or with a high commercial cost
(neither is the case). But even then, since the licensing
of a Software is ultimately upon its authors, they are always OK to
add special  exceptions to the License file
distributed with the program, stating that this or that library is
exempted from the GPL terms.

What one can't do is to take a work under the GPL, build upon it, and
in this process make use of a library or module
with a license incompatible with the GPL, and redistribute that work
(though, note that even then one is free
to use such a work on his own systems). Because then he'd have to add
that exception to the original
license.

   js
 -><-
That is clear from the examples on the FAQ.


>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>

From stutzbach at google.com  Thu Mar 10 05:11:16 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Wed, 9 Mar 2011 20:11:16 -0800
Subject: [Python-Dev] hg diff
In-Reply-To: <4D76E651.4090204@netwok.org>
References: <4D72CB3A.5090006@v.loewis.de>
	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D74363C.1080607@v.loewis.de>
	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D745FD8.9000202@v.loewis.de> <il3228$56i$1@dough.gmane.org>
	<20110307120418.16dc0cd1@neurotica.wooz.org>
	<20110307183112.3ff1e7c9@pitrou.net>
	<20110307130411.6db7f1a9@neurotica.wooz.org>
	<20110307194416.1a82800b@pitrou.net>
	<AANLkTikGzMdm1BESbV3i-GyW4brgFmcRz7rUXrmmwUo2@mail.gmail.com>
	<4D75EA18.1070208@v.loewis.de>
	<AANLkTimSc+gqdGA6UiRyLfa+MamczfARfK2DNB=DLV2L@mail.gmail.com>
	<4D76E651.4090204@netwok.org>
Message-ID: <AANLkTikhBfVVdoM8QS5csZRgwQ9Jkr=5DFKxYEv_fcmV@mail.gmail.com>

On Tue, Mar 8, 2011 at 6:30 PM, ?ric Araujo <merwok at netwok.org> wrote:

> What?s the command you use with git?  Maybe someone will find the

Mercurial one.
>

Something like the following, assuming we're both working on branch "master"
to begin with.

git fetch their-repository master:experimental-branch
git diff master...experimental-branch

The idea is to pull their remote branch but not merge it, which will create
multiple heads locally.  Then find the common ancestor of my regular local
head and the new head, and diff the ancestor with the new head.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110309/604ba687/attachment.html>

From martin at v.loewis.de  Thu Mar 10 05:42:24 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 09 Mar 2011 23:42:24 -0500
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <4D782874.7070803@molden.no>
References: <4D782874.7070803@molden.no>
Message-ID: <4D7856B0.1020909@v.loewis.de>

Am 09.03.11 20:25, schrieb Sturla Molden:
> These methods require the memory to be aligned
> on 32-byte boundaries.

You misread the documentation - it's a 32-*bit*
boundary that the LONG variable must be on. The malloc()
call that is currently used trivially meets this requirement.

As for the volatile marker - I believe the code is also
correct without it, since the owned field is only accessed
through initialization and Interlocked operations.

Regards,
Martin

From stephen at xemacs.org  Thu Mar 10 06:41:17 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 10 Mar 2011 14:41:17 +0900
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked
	against	OpenSSL
In-Reply-To: <AANLkTi=pOQdVb8N025PLhm++_x252aFNBjNVPqtd=_bL@mail.gmail.com>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
	<AANLkTi=pOQdVb8N025PLhm++_x252aFNBjNVPqtd=_bL@mail.gmail.com>
Message-ID: <87sjuvo7lu.fsf@uwakimon.sk.tsukuba.ac.jp>

Joao S. O. Bueno writes:

 > Any libraries commonly avaliable with a CPython instalation can be
 > considered as "system libraries" for GPL purposes - and so
 > this would fall in the "system library exception" as described by the FAQ:

Note that your interpretation would allow Python to distribute
arbitrarily licensed libraries and GPL programs to link with them.
That is surely not the intent of the authors of the GPL, and in the
past, the FSF has explicitly restricted the interpretation of "system
library".  Specifically, in

 > "Major Component", in this context, means a major essential component
 > (kernel, window system, and so on) of the specific operating system
 > (if any) on which the executable work runs, or a compiler used to
 > produce the work, or an object code interpreter used to run it.

the word "essential" would refer to running the compiler or the
operating system or interpreter, not to a component essential to
running the program but in general optional for using the system.

Perhaps this has changed with the advent of GPL v3, but the FSF used
this interpretation to block the consideration of (old-Qt-licensed) Qt
as a system library on GNU/Linux systems, even where distributed by
vendors such as Red Hat.  OTOH, for some reason Motif on Sun and HP
systems, and Windows and Mac GUIs were considered essential.

From foom at fuhm.net  Thu Mar 10 06:52:52 2011
From: foom at fuhm.net (James Y Knight)
Date: Thu, 10 Mar 2011 00:52:52 -0500
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
	OpenSSL
In-Reply-To: <AANLkTi=Ppn_pQFWF8WJOOhpyfGROCKGTxBbthugOAPJS@mail.gmail.com>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
	<20110310003220.7f1fc86e@pitrou.net>
	<AANLkTi=Ppn_pQFWF8WJOOhpyfGROCKGTxBbthugOAPJS@mail.gmail.com>
Message-ID: <A452056F-0CE8-41EF-99F4-020B2EC575DE@fuhm.net>

On Mar 9, 2011, at 6:45 PM, Sandro Tosi wrote:
> It seems introduced by the patch debian/patches/setup-modules-ssl.diff
> with description "# DP: Modules/Setup.dist: patch to build _hashlib
> and _ssl extensions statically"

Indeed you're right -- out of the box, python still builds _ssl.so as a separate module. Sorry for the misinformation -- indeed *nothing* has changed here upstream, it was just a build patch added to debian's python packaging.

[[
BTW, the actual thing causing that special behavior is not that diff, but rather is in debian/rules:
        egrep \
          "^#($$(awk '$$2 ~ /^extension$$/ {print $$1}' debian/PVER-minimal.README.Debian.in | tr '\012' '|')XX)" \
            Modules/Setup.dist \
          | sed -e 's/^#//' -e 's/-Wl,-Bdynamic//;s/-Wl,-Bstatic//' \
            >> $(buildd_shared)/Modules/Setup.local
which causes all the modules listed as "extension" in PVER-minimal.README.Debian.in to be compiled in to the python interpreter instead of built as separate ".so" files.
]]

Despite that not having changed recently, it still seems like there's a problem in upstream python, which perhaps nobody has thought much about: even if you don't use SSL, many modules indirectly import either _hashlib or _ssl, and thus your program is linked against openssl.

You can of course prevent that from happening:
  sys.modules['_ssl'] = None; sys.modules['_hashlib'] = None

Luckily, basically everything is already written to keep working if 'import ssl' fails, so that's fine. (assuming you don't want SSL support, of course).

But you're also left with not being able to 'import hashlib'. While python has fallback code, those modules (_md5, _sha, _sha256, _sha512) aren't built if openssl was found at build time. So you can't just select at runtime that you didn't want to use openssl.
Not being able to import hashlib unfortunately makes urllib2 (and a lot of 3rd party packages) fail to import.

Possibly distributors like Debian should just cause _hashopenssl to never be used, and always use the fallback code, for maximal license compatibility?

On Mar 9, 2011, at 8:27 PM, Joao S. O. Bueno wrote:
> Any libraries commonly avaliable with a CPython instalation can be
> considered as "system libraries" for GPL purposes - and so
> this would fall in the "system library exception" as described by the FAQ:


The "system library" exception is often held not to apply when you are distributing your program as part of the same system as said system library. The "system library" exception would also not be applicable if it is the license of a system library itself that you're violating, e.g. if I have a BSD-licensed program which starts with "import hashlib, readline".

See also:
http://curl.haxx.se/legal/distro-dilemma.html

James

From stephen at xemacs.org  Thu Mar 10 07:05:10 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 10 Mar 2011 15:05:10 +0900
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
 OpenSSL
In-Reply-To: <1299728995.20151.1.camel@localhost.localdomain>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
	<1299728995.20151.1.camel@localhost.localdomain>
Message-ID: <87r5afo6i1.fsf@uwakimon.sk.tsukuba.ac.jp>

Westley Mart?nez writes:

 > Is it legal to distribute GPL programs that use the Win32 API?

Yes.  Their use of the Win32 API falls under the "essential system
library" clause.  The criterion for "essential" is that normal, basic
use of the system would fail without the library.  Windows won't boot
without Win32 API support, so it satisfies that clause.

OpenSSL is needed only by a minority of programs, and Python itself
will run without it, so OpenSSL will not qualify for that exception.
As Martin points out, that's not relevant to Python, since it can be
built without and Python is not a GPL program.  And as Antoine points
out, it's not relevant to Python programs unless they actually call
OpenSSL functions.  In that case only, the program becomes a
derivative of OpenSSL, and only with agreement of all owners of GPLed
code in the program may the program be distributed.  (Ie, if they all
agree to the special exception for specific non-GPL libraries that
Joao Bueno describes.)



From stefan_ml at behnel.de  Thu Mar 10 08:01:04 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 10 Mar 2011 08:01:04 +0100
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
	OpenSSL
In-Reply-To: <A452056F-0CE8-41EF-99F4-020B2EC575DE@fuhm.net>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>	<20110310003220.7f1fc86e@pitrou.net>	<AANLkTi=Ppn_pQFWF8WJOOhpyfGROCKGTxBbthugOAPJS@mail.gmail.com>
	<A452056F-0CE8-41EF-99F4-020B2EC575DE@fuhm.net>
Message-ID: <il9svg$g5o$1@dough.gmane.org>

James Y Knight, 10.03.2011 06:52:
> But you're also left with not being able to 'import hashlib'. While python has fallback code, those modules (_md5, _sha, _sha256, _sha512) aren't built if openssl was found at build time. So you can't just select at runtime that you didn't want to use openssl.
> Not being able to import hashlib unfortunately makes urllib2 (and a lot of 3rd party packages) fail to import.

Agreed. Could you file a bug report, in case there isn't one yet?

Stefan


From ulrich.eckhardt at dominolaser.com  Thu Mar 10 08:56:40 2011
From: ulrich.eckhardt at dominolaser.com (Ulrich Eckhardt)
Date: Thu, 10 Mar 2011 08:56:40 +0100
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <4D784257.4020505@molden.no>
References: <4D782874.7070803@molden.no> <4D783149.5020404@skippinet.com.au> 
	<4D784257.4020505@molden.no>
Message-ID: <201103100856.41058.ulrich.eckhardt@dominolaser.com>

On Thursday 10 March 2011, Sturla Molden wrote:
> As for InterlockedCompareExchange et al., MSDN says this: "The
> parameters for this function must be aligned on a 32-bit boundary;

bit != byte

Uli



**************************************************************************************
Domino Laser GmbH, Fangdieckstra?e 75a, 22547 Hamburg, Deutschland
Gesch?ftsf?hrer: Thorsten F?cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.dominolaser.com/>
**************************************************************************************
Diese E-Mail einschlie?lich s?mtlicher Anh?nge ist nur f?r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf?nger sein sollten. Die E-Mail ist in diesem Fall zu l?schen und darf weder gelesen, weitergeleitet, ver?ffentlicht oder anderweitig benutzt werden.
E-Mails k?nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte ?nderungen enthalten. Domino Laser GmbH ist f?r diese Folgen nicht verantwortlich.
**************************************************************************************



From paul.dubois at gmail.com  Thu Mar 10 09:07:03 2011
From: paul.dubois at gmail.com (Paul Du Bois)
Date: Thu, 10 Mar 2011 00:07:03 -0800
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <4D7856B0.1020909@v.loewis.de>
References: <4D782874.7070803@molden.no> <4D7856B0.1020909@v.loewis.de>
Message-ID: <AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>

On Wed, Mar 9, 2011 at 8:42 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> As for the volatile marker - I believe the code is also
> correct without it, since the owned field is only accessed
> through initialization and Interlocked operations.

Furthermore, if the code weren't correct, "volatile" would only be
half the solution since
it only restricts compiler-induced reorders. Some sort of CPU fence instruction
would almost certainly be needed as well.

Sturla wrote:
> releasing the time-slice by Sleep(0) for each iteration, it will certainly fail without a volatile qualifier.

In general, your compiler will reload globally-accessible memory after
a function call (or
after a memory store). In fact, it can be quite a job to give them
enough hints that they stop doing so!
This behavior (which "volatile" aggravates) unfortunately makes it
even tougher to find race
conditions. In my experience, volatile should be avoided. I'd even bet
money that some grumpy
person has written a "volatile considered harmful" essay.

I Am Not A memory-model expert so consult your local guru,
p

From scott+python-dev at scottdial.com  Thu Mar 10 11:06:43 2011
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Thu, 10 Mar 2011 05:06:43 -0500
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>
References: <4D782874.7070803@molden.no> <4D7856B0.1020909@v.loewis.de>
	<AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>
Message-ID: <4D78A2B3.2010303@scottdial.com>

On 3/10/2011 3:07 AM, Paul Du Bois wrote:
> volatile considered harmful

http://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From martin at v.loewis.de  Thu Mar 10 11:24:11 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 10 Mar 2011 05:24:11 -0500
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>
References: <4D782874.7070803@molden.no> <4D7856B0.1020909@v.loewis.de>
	<AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>
Message-ID: <4D78A6CB.2040707@v.loewis.de>

> This behavior (which "volatile" aggravates) unfortunately makes it
> even tougher to find race conditions. In my experience,
 > volatile should be avoided. I'd even bet money that some grumpy
> person has written a "volatile considered harmful" essay.

I guess all this advice doesn't really apply to this case, though.
The Microsoft API declares the parameter as a volatile*, indicating
that they consider it "proper" usage of the API to declare the storage
volatile. So ISTM that we should comply regardless of whether volatile
is considered "morally wrong" in the general case.

Regards,
Martin

From martin at v.loewis.de  Thu Mar 10 11:36:36 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 10 Mar 2011 05:36:36 -0500
Subject: [Python-Dev] GPL'd python code vs Python2.6
	linked	against	OpenSSL
In-Reply-To: <87sjuvo7lu.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>	<AANLkTi=pOQdVb8N025PLhm++_x252aFNBjNVPqtd=_bL@mail.gmail.com>
	<87sjuvo7lu.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D78A9B4.4030606@v.loewis.de>

> Note that your interpretation would allow Python to distribute
> arbitrarily licensed libraries and GPL programs to link with them.
> That is surely not the intent of the authors of the GPL, and in the
> past, the FSF has explicitly restricted the interpretation of "system
> library".

Note that it is ultimately up to a court to interpret these words of the
GPL, not to the FSF lawyer.

> Specifically, in
>
>   >  "Major Component", in this context, means a major essential component
>   >  (kernel, window system, and so on) of the specific operating system
>   >  (if any) on which the executable work runs, or a compiler used to
>   >  produce the work, or an object code interpreter used to run it.
>
> the word "essential" would refer to running the compiler or the
> operating system or interpreter, not to a component essential to
> running the program but in general optional for using the system.

Maybe my English is not good enough - I read that to mean that the 
compiler itself is a major component of the system (and thus doesn't
need to be distributed along with the source of the GPL'ed program).
Note that it explicitly also says that a "object code interpreter"
used to run "it" (the executable) is a major component, which would
explicitly declare Python a major component (as long as it's actually
distributed with the system).

If your interpetation was right and Python is *not* a major component,
then any GPL'ed Python application would need to distribute the source 
code of Python along with its own source code, and with that the source
of all libraries that are not major components themselves.

Also, if your interpretation was right, it wouldn't be possible to
license Java programs under the GPL, since the JVM wouldn't be a major
component, and hence you would need to distribute JVM's source code
under the terms of the GPL (which you may or may not be able to today,
but surely couldn't over many years during which many GPL'ed Java
programs were written).

Regards,
Martin

From sturla at molden.no  Thu Mar 10 12:18:22 2011
From: sturla at molden.no (Sturla Molden)
Date: Thu, 10 Mar 2011 12:18:22 +0100
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <4D78A2B3.2010303@scottdial.com>
References: <4D782874.7070803@molden.no>
	<4D7856B0.1020909@v.loewis.de>	<AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>
	<4D78A2B3.2010303@scottdial.com>
Message-ID: <4D78B37E.1060104@molden.no>

Den 10.03.2011 11:06, skrev Scott Dial:
> http://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt
>



The important part here (forgive me for being a pedant) is that register 
allocation of the (1) 'owned' field is actually unwanted, and (2) 
Microsoft specify 'volatile' in calls to the Interlocked* API-functions.

I am sorry for misreading 32 bits (4 bytes) as 32 bytes. That is 
obviously very different. If Microsoft's malloc is sufficient, why does 
MSDN tell us to use _aligned_malloc instead of malloc?


The rest is a comment to the link and a bit OT:

Their argument is that (1) volatile supresses optimization; (2) within a 
critical section, access to shared data is synchronized; and thus (3) 
volatile is critical there.

That is true, to some extent.

Volatile is not a memory barrier, nor a mutex. Volatile's main purpose 
is to prevent the compiler from storing  a variable in a register. 
Volatile might be used incorrectly if we don't understand this.

Obvious usecases for volatile are:

- Implementation of a spinlock, where register allocation is detrimental.
- A buffer that is filled from the "outside" with some DMA mechanism.
- Real-time programs and games where order of execution and and timing 
is critical, so optimization must be supressed.

Even though volatile is not needed for processing within a critical 
section, we still need the shared data to be re-loaded upon entering and 
er-written upon leaving. We can use a typecast to non-volatile within a 
critical section, and achieve both data consisitency and compiler 
optimization. OpenMP has a better mechanism for this, where a 
flush-operand (#pragma omp flush) will force a synchronization of shared 
data among threads (write and reload), and volatile is never needed for 
consistency of shared data.

Sturla







From jsbueno at python.org.br  Thu Mar 10 13:13:31 2011
From: jsbueno at python.org.br (Joao S. O. Bueno)
Date: Thu, 10 Mar 2011 09:13:31 -0300
Subject: [Python-Dev] GPL'd python code vs Python2.6 linked against
	OpenSSL
In-Reply-To: <87sjuvo7lu.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
	<AANLkTi=pOQdVb8N025PLhm++_x252aFNBjNVPqtd=_bL@mail.gmail.com>
	<87sjuvo7lu.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTikuDdVAuzzKURg9jgDwbjBBncKyHjg8+4rHuiYH@mail.gmail.com>

On Thu, Mar 10, 2011 at 2:41 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Joao S. O. Bueno writes:
>
> ?> Any libraries commonly avaliable with a CPython instalation can be
> ?> considered as "system libraries" for GPL purposes - and so
> ?> this would fall in the "system library exception" as described by the FAQ:
>
> Note that your interpretation would allow Python to distribute
> arbitrarily licensed libraries and GPL programs to link with them.
> That is surely not the intent of the authors of the GPL, and in the
> past, the FSF has explicitly restricted the interpretation of "system
> library". ?Specifically, in
>
> ?> "Major Component", in this context, means a major essential component
> ?> (kernel, window system, and so on) of the specific operating system
> ?> (if any) on which the executable work runs, or a compiler used to
> ?> produce the work, or an object code interpreter used to run it.
>
> the word "essential" would refer to running the compiler or the
> operating system or interpreter, not to a component essential to
> running the program but in general optional for using the system.


So tellme how the Python interpreter and the libraries linked to it are not
"essential" to a program made in Python?

I did not refer to distributing Python itself with GPL librareis
linked into it -
you had put it this way.

The original question is whether a Python program can be GPLed, and
the answer is:
it can.

You can see Antonie Pitrou's first answer to question:
" A Python program is not a derivative of the Python interpreter any more
than a C program is a derivative of gcc (or any other compiler)."

The fact is that Python programs need more of environment t run than a
C program,
since besides the system libraries they run oer the Python interpreter and any
libraries it links too: all these are intrinsic in order to the proram to run.
Otherwise no one could ever have a GPLed program written in notoriously
privative language or environments such as Visualbasic, Microsfot's .net,
or even Java using Oracle's Java environment.


> Perhaps this has changed with the advent of GPL v3, but the FSF used
> this interpretation to block the consideration of (old-Qt-licensed) Qt
> as a system library on GNU/Linux systems, even where distributed by
> vendors such as Red Hat. ?OTOH, for some reason Motif on Sun and HP
> systems, and Windows and Mac GUIs were considered essential.
>

They where then contradicting their own current FAQs on the GPL.
Anyway, the original author has
always the right to exempt some library his program links to of complying with
the GPL.

  js
 -><-

From nyamatongwe at gmail.com  Thu Mar 10 13:55:59 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Thu, 10 Mar 2011 23:55:59 +1100
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <4D78A6CB.2040707@v.loewis.de>
References: <4D782874.7070803@molden.no> <4D7856B0.1020909@v.loewis.de>
	<AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>
	<4D78A6CB.2040707@v.loewis.de>
Message-ID: <AANLkTi=bSaj-uDhRg2pp3Anj8B+r3ykAfptyP3GR0fbX@mail.gmail.com>

Martin v. L?wis:

> I guess all this advice doesn't really apply to this case, though.
> The Microsoft API declares the parameter as a volatile*, indicating
> that they consider it "proper" usage of the API to declare the storage
> volatile.

   The 'volatile' here is a modifier on the parameter and does not
require a corresponding agreement in the variable declaration. It
indicates that all access through the pointer inside the function will
be with volatile semantics. As long as all functions that operate on
the variable do so treating access as volatile then everything is
fine. You should only need to declare the variable as volatile if
there is other code that accesses it directly.

   If agreement was required then the compiler would print a warning.

   It is similar to declaring a function to take a const parameter:
there is no need for the variable to also be const.

   Neil

From solipsis at pitrou.net  Thu Mar 10 15:32:01 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 10 Mar 2011 15:32:01 +0100
Subject: [Python-Dev] Bugs in thread_nt.h
References: <4D782874.7070803@molden.no> <4D7856B0.1020909@v.loewis.de>
	<AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>
	<4D78A2B3.2010303@scottdial.com> <4D78B37E.1060104@molden.no>
Message-ID: <20110310153201.7317d559@pitrou.net>

On Thu, 10 Mar 2011 12:18:22 +0100
Sturla Molden <sturla at molden.no> wrote:
> 
> Obvious usecases for volatile are:
> 
> - Implementation of a spinlock, where register allocation is detrimental.
> - A buffer that is filled from the "outside" with some DMA mechanism.
> - Real-time programs and games where order of execution and and timing 
> is critical, so optimization must be supressed.

- variables mutated from signal handlers

Regards

Antoine.



From martin at v.loewis.de  Thu Mar 10 16:02:02 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 10 Mar 2011 10:02:02 -0500
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <4D78B37E.1060104@molden.no>
References: <4D782874.7070803@molden.no>	<4D7856B0.1020909@v.loewis.de>	<AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>	<4D78A2B3.2010303@scottdial.com>
	<4D78B37E.1060104@molden.no>
Message-ID: <4D78E7EA.2060309@v.loewis.de>

> I am sorry for misreading 32 bits (4 bytes) as 32 bytes. That is
> obviously very different. If Microsoft's malloc is sufficient, why does
> MSDN tell us to use _aligned_malloc instead of malloc?

I don't know. Perhaps they assume that people may be using alternative
malloc implementations, or (more likely) people in the platform group
are unaware of the guarantees the compiler group makes (because of
compliance with the C standard).

> Obvious usecases for volatile are:
>
> - Implementation of a spinlock, where register allocation is detrimental.

Unfortunately, that's not true. It's not really possible to implement
a spinlock in C if the processor can make changes to the write ordering.

> - A buffer that is filled from the "outside" with some DMA mechanism.
> - Real-time programs and games where order of execution and and timing
> is critical, so optimization must be supressed.

Likewise. On many current processors, you have to use fencing 
instructions to make this kind of stuff work, something that the 
compiler will not normally generate (except through inline assembly).

> Even though volatile is not needed for processing within a critical
> section, we still need the shared data to be re-loaded upon entering and
> er-written upon leaving.

Please see the code. Where exactly does such reloading/rewriting need to 
happen?

Regards,
Martin

From martin at v.loewis.de  Thu Mar 10 16:39:57 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 10 Mar 2011 10:39:57 -0500
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <AANLkTi=bSaj-uDhRg2pp3Anj8B+r3ykAfptyP3GR0fbX@mail.gmail.com>
References: <4D782874.7070803@molden.no>
	<4D7856B0.1020909@v.loewis.de>	<AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>	<4D78A6CB.2040707@v.loewis.de>
	<AANLkTi=bSaj-uDhRg2pp3Anj8B+r3ykAfptyP3GR0fbX@mail.gmail.com>
Message-ID: <4D78F0CD.7050500@v.loewis.de>

Am 10.03.11 07:55, schrieb Neil Hodgson:
> Martin v. L?wis:
>
>> I guess all this advice doesn't really apply to this case, though.
>> The Microsoft API declares the parameter as a volatile*, indicating
>> that they consider it "proper" usage of the API to declare the storage
>> volatile.
>
>     The 'volatile' here is a modifier on the parameter and does not
> require a corresponding agreement in the variable declaration.

I see. So then we don't need to make any changes.

Regards,
Martin

From eltoder at gmail.com  Thu Mar 10 18:27:48 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Thu, 10 Mar 2011 12:27:48 -0500
Subject: [Python-Dev] Bugs in thread_nt.h
In-Reply-To: <4D78A6CB.2040707@v.loewis.de>
References: <4D782874.7070803@molden.no> <4D7856B0.1020909@v.loewis.de>
	<AANLkTimuL1b_FS=GRedVOJNMkb0QDB3=_+HAsLOEO2a4@mail.gmail.com>
	<4D78A6CB.2040707@v.loewis.de>
Message-ID: <AANLkTin=kYphtsmRNjJDFy8438kNyJBiV4A8b9pdGJ5n@mail.gmail.com>

> I guess all this advice doesn't really apply to this case, though.
> The Microsoft API declares the parameter as a volatile*, indicating
> that they consider it "proper" usage of the API to declare the storage
> volatile. So ISTM that we should comply regardless of whether volatile
> is considered "morally wrong" in the general case.

Microsoft compiler implements Microsoft-specific behaviour for
volatile variables, making them close to volatiles in Java:
http://msdn.microsoft.com/en-us/library/12a04hfd(v=VS.100).aspx
That may be the reason they use it in Interlocked* functions.

As already been said, the thread_nt doesn't need any changes.

Eugene

From janssen at parc.com  Thu Mar 10 21:18:24 2011
From: janssen at parc.com (Bill Janssen)
Date: Thu, 10 Mar 2011 12:18:24 PST
Subject: [Python-Dev] funky buildbot
Message-ID: <81942.1299788304@parc.com>

I'm trying to get a new buildbot in the swim of things, and it keeps
getting into this state where the buildslave process seems caught in an
endless loop.  Perhaps someone here knows why?

It's a new Mac Mini running the latest Snow Leopard, with Python 2.6.1
(the /usr/bin/python) and buildslave 0.8.3, using Twisted 8.2.0.

Bill

From dickinsm at gmail.com  Thu Mar 10 21:30:07 2011
From: dickinsm at gmail.com (Mark Dickinson)
Date: Thu, 10 Mar 2011 20:30:07 +0000
Subject: [Python-Dev] constant folding of -0
In-Reply-To: <loom.20110310T030107-127@post.gmane.org>
References: <AANLkTinpS+NPmHQtGEbLNO8iwgRpnJSB84EcoTX7i3tm@mail.gmail.com>
	<20110310014030.21bd6c56@pitrou.net>
	<loom.20110310T030107-127@post.gmane.org>
Message-ID: <AANLkTi=6T9oDaF9pDzk0o=CjQ-S3hze24xskvZAntN=H@mail.gmail.com>

On Thu, Mar 10, 2011 at 2:17 AM, Eugene Toder <eltoder at gmail.com> wrote:
>> Indeed, see http://bugs.python.org/issue11244
>
> Yes, I've noticed that too. However, if I'm not missing something, your patches
> do not address folding of -0.

Hmm, it seems that way.  Could you post a comment on the tracker issue
about that, please?

I'm not sure why the original changeset went in, but I agree it looks
as though it's no longer necessary.  Certainly there should be enough
-0.0 versus 0.0 tests around to detect any issues, so if all the tests
pass with the extra PyObject_IsTrue check disabled then there probably
isn't a problem.

Mark

From merwok at netwok.org  Thu Mar 10 21:29:59 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 10 Mar 2011 21:29:59 +0100
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
 determining child loggers.
In-Reply-To: <4D75241F.7090403@netwok.org>
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
	<4D75241F.7090403@netwok.org>
Message-ID: <4D7934C7.5060800@netwok.org>

Hi,

>> changeset:   68315:b9d76846bb1c
>> branch:      2.6
>> parent:      68264:50166a4bcfc6
>> user:        Vinay Sajip <vinay_sajip at yahoo.co.uk>
>> date:        Mon Mar 07 15:02:11 2011 +0000
>> summary:
>>   Issue #11424: Fix bug in determining child loggers.
> 
> This does not look like a security bug, and is therefore not suitable
> for 2.6.

I?d like to know what we should do about this: just ignore it and not
import it into Subversion, or revert it in Mercurial too?

Regards

From merwok at netwok.org  Thu Mar 10 21:43:49 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 10 Mar 2011 21:43:49 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <AANLkTikhBfVVdoM8QS5csZRgwQ9Jkr=5DFKxYEv_fcmV@mail.gmail.com>
References: <4D72CB3A.5090006@v.loewis.de>	<87aah7lo31.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D74363C.1080607@v.loewis.de>	<8762rvlkfo.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D745FD8.9000202@v.loewis.de>	<il3228$56i$1@dough.gmane.org>	<20110307120418.16dc0cd1@neurotica.wooz.org>	<20110307183112.3ff1e7c9@pitrou.net>	<20110307130411.6db7f1a9@neurotica.wooz.org>	<20110307194416.1a82800b@pitrou.net>	<AANLkTikGzMdm1BESbV3i-GyW4brgFmcRz7rUXrmmwUo2@mail.gmail.com>	<4D75EA18.1070208@v.loewis.de>	<AANLkTimSc+gqdGA6UiRyLfa+MamczfARfK2DNB=DLV2L@mail.gmail.com>	<4D76E651.4090204@netwok.org>
	<AANLkTikhBfVVdoM8QS5csZRgwQ9Jkr=5DFKxYEv_fcmV@mail.gmail.com>
Message-ID: <4D793805.80701@netwok.org>

> The idea is to pull their remote branch but not merge it, which will create
> multiple heads locally.
?hg pull some-repo-uri? does that.

> Then find the common ancestor of my regular local head and the new head,
> and diff the ancestor with the new head.
I think Mercurial revsets can do that, but I don?t feel confident enough
to try and convert your example to use them.  From ?hg help revsets? /
http://www.selenic.com/mercurial/hg.1#revsets :

not x
    Changesets not in x. Short form is ! x.

x::y

    A DAG range, meaning all changesets that are descendants of x and
ancestors of y, including x and y themselves. If the first endpoint is
left out, this is equivalent to ancestors(y), if the second is left out
it is equivalent to descendants(x).

    An alternative syntax is x..y.

x:y
    All changesets with revision numbers between x and y, both
inclusive. Either endpoint can be left out, they default to 0 and tip.

x and y
    The intersection of changesets in x and y. Short form is x & y.

x or y
    The union of changesets in x and y. There are two alternative short
forms: x | y and x + y.

x - y
    Changesets in x but not in y.

From solipsis at pitrou.net  Thu Mar 10 21:48:12 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 10 Mar 2011 21:48:12 +0100
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
 determining child loggers.
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
	<4D75241F.7090403@netwok.org> <4D7934C7.5060800@netwok.org>
Message-ID: <20110310214812.4029de53@pitrou.net>

On Thu, 10 Mar 2011 21:29:59 +0100
?ric Araujo <merwok at netwok.org> wrote:
> Hi,
> 
> >> changeset:   68315:b9d76846bb1c
> >> branch:      2.6
> >> parent:      68264:50166a4bcfc6
> >> user:        Vinay Sajip <vinay_sajip at yahoo.co.uk>
> >> date:        Mon Mar 07 15:02:11 2011 +0000
> >> summary:
> >>   Issue #11424: Fix bug in determining child loggers.
> > 
> > This does not look like a security bug, and is therefore not suitable
> > for 2.6.
> 
> I?d like to know what we should do about this: just ignore it and not
> import it into Subversion, or revert it in Mercurial too?

If you revert (backout) it in Mercurial, you should be careful to
dummy-merge the backout in 2.7 (so that the backout doesn't get
accidentally propagated by someone else doing a merge from 2.6 to 2.7).

Regards

Antoine.



From db3l.net at gmail.com  Thu Mar 10 22:19:23 2011
From: db3l.net at gmail.com (David Bolen)
Date: Thu, 10 Mar 2011 16:19:23 -0500
Subject: [Python-Dev] funky buildbot
References: <81942.1299788304@parc.com>
Message-ID: <m2ei6eptb8.fsf@valheru.db3l.homeip.net>

Bill Janssen <janssen at parc.com> writes:

> I'm trying to get a new buildbot in the swim of things, and it keeps
> getting into this state where the buildslave process seems caught in an
> endless loop.  Perhaps someone here knows why?

Do you have any information as to what it is doing while in the loop?

I think the only obvious "looping" I've seen with any of my buildbots
is a loop while trying to attach to the master, either because the
master was down/unreachable, rejecting connections (bad
user/password), not yet configured for my buildbot, or occasionally
because it thought the buildbot was still attached.  In that latter
case I just had to wait long enough for the status page to switch from
idle to disconnected and then try again.

-- David


From eltoder at gmail.com  Thu Mar 10 22:23:36 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Thu, 10 Mar 2011 16:23:36 -0500
Subject: [Python-Dev] constant folding of -0
In-Reply-To: <AANLkTi=6T9oDaF9pDzk0o=CjQ-S3hze24xskvZAntN=H@mail.gmail.com>
References: <AANLkTinpS+NPmHQtGEbLNO8iwgRpnJSB84EcoTX7i3tm@mail.gmail.com>
	<20110310014030.21bd6c56@pitrou.net>
	<loom.20110310T030107-127@post.gmane.org>
	<AANLkTi=6T9oDaF9pDzk0o=CjQ-S3hze24xskvZAntN=H@mail.gmail.com>
Message-ID: <AANLkTinS1vDYa+Um4TmWsyB+pVvyfSyE7_z-kc7O8CDh@mail.gmail.com>

I've posted a patch.

Eugene

On Thu, Mar 10, 2011 at 3:30 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
> On Thu, Mar 10, 2011 at 2:17 AM, Eugene Toder <eltoder at gmail.com> wrote:
>>> Indeed, see http://bugs.python.org/issue11244
>>
>> Yes, I've noticed that too. However, if I'm not missing something, your patches
>> do not address folding of -0.
>
> Hmm, it seems that way. ?Could you post a comment on the tracker issue
> about that, please?
>
> I'm not sure why the original changeset went in, but I agree it looks
> as though it's no longer necessary. ?Certainly there should be enough
> -0.0 versus 0.0 tests around to detect any issues, so if all the tests
> pass with the extra PyObject_IsTrue check disabled then there probably
> isn't a problem.
>
> Mark
>

From vinay_sajip at yahoo.co.uk  Thu Mar 10 22:21:55 2011
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Thu, 10 Mar 2011 21:21:55 +0000 (GMT)
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
	determining child loggers.
In-Reply-To: <4D7934C7.5060800@netwok.org>
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
	<4D75241F.7090403@netwok.org> <4D7934C7.5060800@netwok.org>
Message-ID: <338044.5218.qm@web25805.mail.ukl.yahoo.com>

>From what I understand, we're supposed to forward-port in Mercurial, which is 
why I started with 2.6 (the bugfix wasn't applicable to 2.5). So we don't need 
to import into Subversion, but I see no point in reverting it in Mercurial.

Regards,

Vinay Sajip




----- Original Message ----
> From: ?ric Araujo <merwok at netwok.org>
> To: python-dev at python.org; Friendly Uncle <barry at python.org>; Vinay Sajip 
><vinay_sajip at yahoo.co.uk>
> Sent: Thu, 10 March, 2011 20:29:59
> Subject: Re: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in 
>determining child loggers.
> 
> Hi,
> 
> >> changeset:   68315:b9d76846bb1c
> >>  branch:      2.6
> >> parent:       68264:50166a4bcfc6
> >> user:        Vinay Sajip  <vinay_sajip at yahoo.co.uk>
> >>  date:        Mon Mar 07 15:02:11 2011 +0000
> >>  summary:
> >>   Issue #11424: Fix bug in determining child  loggers.
> > 
> > This does not look like a security bug, and is  therefore not suitable
> > for 2.6.
> 
> I?d like to know what we should  do about this: just ignore it and not
> import it into Subversion, or revert it  in Mercurial too?
> 
> Regards
> 


      

From merwok at netwok.org  Thu Mar 10 23:15:55 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 10 Mar 2011 23:15:55 +0100
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
 determining child loggers.
In-Reply-To: <338044.5218.qm@web25805.mail.ukl.yahoo.com>
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
	<4D75241F.7090403@netwok.org> <4D7934C7.5060800@netwok.org>
	<338044.5218.qm@web25805.mail.ukl.yahoo.com>
Message-ID: <4D794D9B.7030502@netwok.org>

Hi,

> From what I understand, we're supposed to forward-port in Mercurial,
Correct, but only in maintained branches, not security-mode branches.

> which is why I started with 2.6 (the bugfix wasn't applicable to 2.5).
As I said in my first message:
>>> This does not look like a security bug, and is  therefore not suitable
>>> for 2.6.

I don?t know if Barry will make the next 2.6 releases from Subversion or
Mercurial; anyway, bug fixes should not go into 2.6.

Regards

From vinay_sajip at yahoo.co.uk  Thu Mar 10 23:41:20 2011
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Thu, 10 Mar 2011 22:41:20 +0000 (GMT)
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
	determining child loggers.
In-Reply-To: <4D794D9B.7030502@netwok.org>
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
	<4D75241F.7090403@netwok.org> <4D7934C7.5060800@netwok.org>
	<338044.5218.qm@web25805.mail.ukl.yahoo.com>
	<4D794D9B.7030502@netwok.org>
Message-ID: <4691.44041.qm@web25801.mail.ukl.yahoo.com>

----- Original Message ----

> From: ?ric Araujo <merwok at netwok.org>
> > From what I understand, we're supposed to forward-port in  Mercurial,
> Correct, but only in maintained branches, not security-mode  branches.
> 

Well, I saw this recent mail from Antoine:

http://mail.python.org/pipermail/python-dev/2011-March/108766.html

where he mentioned


- on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain 2.5)
- on the other hand: 3.1 -> 3.2 -> default

and perhaps misunderstood. I was assuming that there wouldn't be any 2.6  
releases from Mercurial, perhaps that assumption was unwarranted.

Also, the section on forward-porting in the Dev Guide says "it should be applied 
to the oldest branch applicable" and this could be interpreted to mean 
applicable based on the content of the branch, rather than according to release 
policy.

Regards,

Vinay Sajip



      

From solipsis at pitrou.net  Fri Mar 11 00:30:47 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 11 Mar 2011 00:30:47 +0100
Subject: [Python-Dev] constant folding of -0
References: <AANLkTinpS+NPmHQtGEbLNO8iwgRpnJSB84EcoTX7i3tm@mail.gmail.com>
	<20110310014030.21bd6c56@pitrou.net>
	<loom.20110310T030107-127@post.gmane.org>
Message-ID: <20110311003047.59fed706@pitrou.net>

On Thu, 10 Mar 2011 02:17:34 +0000 (UTC)
Eugene Toder <eltoder at gmail.com> wrote:
> > Indeed, see http://bugs.python.org/issue11244
> 
> Yes, I've noticed that too. However, if I'm not missing something, your patches
> do not address folding of -0.
> 
> Btw, there's an alternative approach to allow "recursive" constant folding.
> Instead of keeping a stack of last constants, you can keep a pointer to the
> start of the last (LOAD_CONSTs + NOPs) run and the number of LOAD_CONSTs in
> that run (called lastlc in the current version). When you want Nth constant
> from the end, you start from that pointer and skip lastlc-N constants. You
> also make a function to get next constant from that point. This approach has
> worse time complexity for searching in a long run of LOAD_CONSTs,

Yes, the stack basically acts as a cache to avoid computing all this
again and again.

> however,
> there are upsides:
> - very long runs of constants are rare in real code

True, but they might appear in generated code.

> - it uses less memory and doesn't have arbitrary limits on the size of the run

Neither does the latest patch.

> - it's book-keeping overhead is smaller, so when you don't have long runs of
> constants (common case, I believe), it should be faster

The book-keeping overhead should be quite small really, it's a simple
autogrowing array with O(1) access and amortized append time. What's
left is the overhead of the initial malloc() (and final free()).

> - I think it's simpler to implement

Feel free to propose an alternate patch, but I'm not sure that it would
be significantly simpler (and a stack is a well-known data structure).
Also, please present some benchmarks if you do.

Regards

Antoine.



From janssen at parc.com  Fri Mar 11 00:46:11 2011
From: janssen at parc.com (Bill Janssen)
Date: Thu, 10 Mar 2011 15:46:11 PST
Subject: [Python-Dev] funky buildbot
In-Reply-To: <m2ei6eptb8.fsf@valheru.db3l.homeip.net>
References: <81942.1299788304@parc.com>
	<m2ei6eptb8.fsf@valheru.db3l.homeip.net>
Message-ID: <190.1299800771@parc.com>

David Bolen <db3l.net at gmail.com> wrote:

> Bill Janssen <janssen at parc.com> writes:
> 
> > I'm trying to get a new buildbot in the swim of things, and it keeps
> > getting into this state where the buildslave process seems caught in an
> > endless loop.  Perhaps someone here knows why?
> 
> Do you have any information as to what it is doing while in the loop?

Not much.  The twistd log shows that it is, in fact, trying to reconnect
to the build master.  It's just chewing up 100% CPU.  Could just be
updates to the master that are doing this, but my other (PPC) buildbots
seem OK with it.

Bill

> I think the only obvious "looping" I've seen with any of my buildbots
> is a loop while trying to attach to the master, either because the
> master was down/unreachable, rejecting connections (bad
> user/password), not yet configured for my buildbot, or occasionally
> because it thought the buildbot was still attached.  In that latter
> case I just had to wait long enough for the status page to switch from
> idle to disconnected and then try again.
> 
> -- David
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/bill%40janssen.org

From db3l.net at gmail.com  Fri Mar 11 00:57:13 2011
From: db3l.net at gmail.com (David Bolen)
Date: Thu, 10 Mar 2011 18:57:13 -0500
Subject: [Python-Dev] funky buildbot
References: <81942.1299788304@parc.com>
	<m2ei6eptb8.fsf@valheru.db3l.homeip.net> <190.1299800771@parc.com>
Message-ID: <m27hc6wmue.fsf@valheru.db3l.homeip.net>

Bill Janssen <janssen at parc.com> writes:

> David Bolen <db3l.net at gmail.com> wrote:
>
>> Bill Janssen <janssen at parc.com> writes:
>> 
>> > I'm trying to get a new buildbot in the swim of things, and it keeps
>> > getting into this state where the buildslave process seems caught in an
>> > endless loop.  Perhaps someone here knows why?
>> 
>> Do you have any information as to what it is doing while in the loop?
>
> Not much.  The twistd log shows that it is, in fact, trying to reconnect
> to the build master.  It's just chewing up 100% CPU.  Could just be
> updates to the master that are doing this, but my other (PPC) buildbots
> seem OK with it.

When I look at the slave status page[*], it seems to show all of your
slaves as idle, so if one of them is looping trying to connect, I
suspect you may have run into that last case I've seen (mismatch
between slave and master).

Try shutting down the build slave for a while and watching the status
page until it shows disconnected.  Then you should be able to restart
things and have it attach successfully.  Leaving the slave continually
trying to reattach, I believe, prevents the master from ever declaring
it disconnected.

I'm guessing the master is rejecting the new connection since it
thinks the slave is still attached (though the request seems to defeat
the status from correcting).  I'm not sure how it gets into that state
but it's happened a handful of times to me (typically after some
network interruptions, so maybe it just needs enough time for
buildbot's own keepalives to notice what is otherwise a quiet TCP
channel).

There used to be a way to request a "ping" from the master side (I
think on the same page you could manually run a build from) that I
would used to force it to recognize a slave was really down, but after
the web interface got rearranged a while back, I can't seem to find
the option any more.

-- David

[*] http://www.python.org/dev/buildbot/buildslaves


From solipsis at pitrou.net  Fri Mar 11 01:01:32 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 11 Mar 2011 01:01:32 +0100
Subject: [Python-Dev] funky buildbot
References: <81942.1299788304@parc.com>
	<m2ei6eptb8.fsf@valheru.db3l.homeip.net> <190.1299800771@parc.com>
Message-ID: <20110311010132.6d607575@pitrou.net>

On Thu, 10 Mar 2011 15:46:11 PST
Bill Janssen <janssen at parc.com> wrote:
> David Bolen <db3l.net at gmail.com> wrote:
> 
> > Bill Janssen <janssen at parc.com> writes:
> > 
> > > I'm trying to get a new buildbot in the swim of things, and it keeps
> > > getting into this state where the buildslave process seems caught in an
> > > endless loop.  Perhaps someone here knows why?
> > 
> > Do you have any information as to what it is doing while in the loop?
> 
> Not much.  The twistd log shows that it is, in fact, trying to reconnect
> to the build master.  It's just chewing up 100% CPU.  Could just be
> updates to the master that are doing this, but my other (PPC) buildbots
> seem OK with it.

What login are you using?



From eltoder at gmail.com  Fri Mar 11 01:41:12 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Thu, 10 Mar 2011 19:41:12 -0500
Subject: [Python-Dev] constant folding of -0
In-Reply-To: <20110311003047.59fed706@pitrou.net>
References: <AANLkTinpS+NPmHQtGEbLNO8iwgRpnJSB84EcoTX7i3tm@mail.gmail.com>
	<20110310014030.21bd6c56@pitrou.net>
	<loom.20110310T030107-127@post.gmane.org>
	<20110311003047.59fed706@pitrou.net>
Message-ID: <AANLkTinLKfPakG28jnKfyEcY3K9zU_edOFAqhHv=RDp9@mail.gmail.com>

Well, that was just a though. You're right that long runs of constants
can appear, and it's better to avoid pathological behaviour in such
cases.
Your second path looks good.

Eugene

On Thu, Mar 10, 2011 at 6:30 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 10 Mar 2011 02:17:34 +0000 (UTC)
> Eugene Toder <eltoder at gmail.com> wrote:
>> > Indeed, see http://bugs.python.org/issue11244
>>
>> Yes, I've noticed that too. However, if I'm not missing something, your patches
>> do not address folding of -0.
>>
>> Btw, there's an alternative approach to allow "recursive" constant folding.
>> Instead of keeping a stack of last constants, you can keep a pointer to the
>> start of the last (LOAD_CONSTs + NOPs) run and the number of LOAD_CONSTs in
>> that run (called lastlc in the current version). When you want Nth constant
>> from the end, you start from that pointer and skip lastlc-N constants. You
>> also make a function to get next constant from that point. This approach has
>> worse time complexity for searching in a long run of LOAD_CONSTs,
>
> Yes, the stack basically acts as a cache to avoid computing all this
> again and again.
>
>> however,
>> there are upsides:
>> - very long runs of constants are rare in real code
>
> True, but they might appear in generated code.
>
>> - it uses less memory and doesn't have arbitrary limits on the size of the run
>
> Neither does the latest patch.
>
>> - it's book-keeping overhead is smaller, so when you don't have long runs of
>> constants (common case, I believe), it should be faster
>
> The book-keeping overhead should be quite small really, it's a simple
> autogrowing array with O(1) access and amortized append time. What's
> left is the overhead of the initial malloc() (and final free()).
>
>> - I think it's simpler to implement
>
> Feel free to propose an alternate patch, but I'm not sure that it would
> be significantly simpler (and a stack is a well-known data structure).
> Also, please present some benchmarks if you do.
>
> Regards
>
> Antoine.

From janssen at parc.com  Fri Mar 11 02:32:33 2011
From: janssen at parc.com (Bill Janssen)
Date: Thu, 10 Mar 2011 17:32:33 PST
Subject: [Python-Dev] funky buildbot
In-Reply-To: <m27hc6wmue.fsf@valheru.db3l.homeip.net>
References: <81942.1299788304@parc.com>
	<m2ei6eptb8.fsf@valheru.db3l.homeip.net> <190.1299800771@parc.com>
	<m27hc6wmue.fsf@valheru.db3l.homeip.net>
Message-ID: <1892.1299807153@parc.com>

David Bolen <db3l.net at gmail.com> wrote:

> There used to be a way to request a "ping" from the master side (I
> think on the same page you could manually run a build from) that I
> would used to force it to recognize a slave was really down, but after
> the web interface got rearranged a while back, I can't seem to find
> the option any more.

Looks like the ping option is back now :-).

I restarted the buildslave, and it built 3.2 OK.  Still don't know
what's up, but this runaway buildslave condition has happened three
times in the last week or so.

Bill

From db3l.net at gmail.com  Fri Mar 11 02:42:19 2011
From: db3l.net at gmail.com (David Bolen)
Date: Thu, 10 Mar 2011 20:42:19 -0500
Subject: [Python-Dev] funky buildbot
References: <81942.1299788304@parc.com>
	<m2ei6eptb8.fsf@valheru.db3l.homeip.net> <190.1299800771@parc.com>
	<m27hc6wmue.fsf@valheru.db3l.homeip.net> <1892.1299807153@parc.com>
Message-ID: <m239muwhz8.fsf@valheru.db3l.homeip.net>

Bill Janssen <janssen at parc.com> writes:

> David Bolen <db3l.net at gmail.com> wrote:
>
>> There used to be a way to request a "ping" from the master side (I
>> think on the same page you could manually run a build from) that I
>> would used to force it to recognize a slave was really down, but after
>> the web interface got rearranged a while back, I can't seem to find
>> the option any more.
>
> Looks like the ping option is back now :-).

Hey, how about that.  (I had taken a quick peek before writing the
response to verify it was still unavailable so it's definitely recent)

Thanks to whomever restored that.

-- David


From ncoghlan at gmail.com  Fri Mar 11 03:45:50 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 10 Mar 2011 21:45:50 -0500
Subject: [Python-Dev] [Python-checkins] (2.7): Use simpler assert in
	basic example.
In-Reply-To: <E1PxnWh-0005Jj-1I@dinsdale.python.org>
References: <E1PxnWh-0005Jj-1I@dinsdale.python.org>
Message-ID: <AANLkTinUVARaa_NFBcvu9S1Ur_MkZQ9w7WfEDg-9pnAJ@mail.gmail.com>

On Thu, Mar 10, 2011 at 4:36 PM, ezio.melotti
<python-checkins at python.org> wrote:
> http://hg.python.org/cpython/rev/9adc4792db9a
> changeset: ? 68356:9adc4792db9a
> branch: ? ? ?2.7
> user: ? ? ? ?Ezio Melotti <ezio.melotti at gmail.com>
> date: ? ? ? ?Thu Mar 10 23:35:39 2011 +0200
> summary:
> ?Use simpler assert in basic example.

Please don't. Now the new methods are available, using assertTrue() on
supported expressions is actively throwing away data, and the docs
shouldn't recommend it *anywhere*.

If using assertIn() at this point in the docs is a genuine problem,
find an alternative test example that isn't better written using one
of the more specific methods.

Cheers,
Nick.

>
> files:
> ?Doc/library/unittest.rst
>
> diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst
> --- a/Doc/library/unittest.rst
> +++ b/Doc/library/unittest.rst
> @@ -130,13 +130,13 @@
>
> ? ? ? ?def test_choice(self):
> ? ? ? ? ? ?element = random.choice(self.seq)
> - ? ? ? ? ? self.assertIn(element, self.seq)
> + ? ? ? ? ? self.assertTrue(element in self.seq)
>
> ? ? ? ?def test_sample(self):
> ? ? ? ? ? ?with self.assertRaises(ValueError):
> ? ? ? ? ? ? ? ?random.sample(self.seq, 20)
> ? ? ? ? ? ?for element in random.sample(self.seq, 5):
> - ? ? ? ? ? ? ? self.assertIn(element, self.seq)
> + ? ? ? ? ? ? ? self.assertTrue(element in self.seq)
>
> ? ?if __name__ == '__main__':
> ? ? ? ?unittest.main()
>
> --
> Repository URL: http://hg.python.org/cpython
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
>



-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar 11 03:47:57 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 10 Mar 2011 21:47:57 -0500
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
 determining child loggers.
In-Reply-To: <4691.44041.qm@web25801.mail.ukl.yahoo.com>
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
	<4D75241F.7090403@netwok.org> <4D7934C7.5060800@netwok.org>
	<338044.5218.qm@web25805.mail.ukl.yahoo.com>
	<4D794D9B.7030502@netwok.org>
	<4691.44041.qm@web25801.mail.ukl.yahoo.com>
Message-ID: <AANLkTinDN_QmAL-J8HYjE4dWtad1uxaCEDQQGkFaVpL9@mail.gmail.com>

On Thu, Mar 10, 2011 at 5:41 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> ----- Original Message ----
>
>> From: ?ric Araujo <merwok at netwok.org>
>> > From what I understand, we're supposed to forward-port in ?Mercurial,
>> Correct, but only in maintained branches, not security-mode ?branches.
>>
>
> Well, I saw this recent mail from Antoine:
>
> http://mail.python.org/pipermail/python-dev/2011-March/108766.html
>
> where he mentioned
>
>
> - on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain 2.5)
> - on the other hand: 3.1 -> 3.2 -> default
>
> and perhaps misunderstood. I was assuming that there wouldn't be any 2.6
> releases from Mercurial, perhaps that assumption was unwarranted.
>
> Also, the section on forward-porting in the Dev Guide says "it should be applied
> to the oldest branch applicable" and this could be interpreted to mean
> applicable based on the content of the branch, rather than according to release
> policy.

It's the intersection: if the change applies to the content of that
branch and that branch is still maintained, then start there.

So security fixes start further back than ordinary bug fixes.

This should be reverted in 2.6, with the dummy merge to prevent
inadvertent reversion in 2.7.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From glyph at twistedmatrix.com  Fri Mar 11 06:18:25 2011
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Fri, 11 Mar 2011 00:18:25 -0500
Subject: [Python-Dev] funky buildbot
In-Reply-To: <81942.1299788304@parc.com>
References: <81942.1299788304@parc.com>
Message-ID: <FE1D2959-192C-40E0-A869-A78038A3B7EE@twistedmatrix.com>

On Mar 10, 2011, at 3:18 PM, Bill Janssen wrote:

> It's a new Mac Mini running the latest Snow Leopard, with Python 2.6.1
> (the /usr/bin/python) and buildslave 0.8.3, using Twisted 8.2.0.

I realize that Python 2.6 is pretty old too, but a _lot_ of bugfixes have gone into Twisted since 8.2.  I'm not 100% sure this is a Twisted issue but you may want to try upgrading to 10.2.0 and see if that fixes things.  (I have a dim memory of similar issues which were eventually fixed by something in our subprocess support...)

-glyph


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110311/fc2a370f/attachment.html>

From stephen at xemacs.org  Fri Mar 11 06:49:19 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 11 Mar 2011 14:49:19 +0900
Subject: [Python-Dev] GPL'd python code vs
	Python2.6	linked	against	OpenSSL
In-Reply-To: <4D78A9B4.4030606@v.loewis.de>
References: <EE439C8E-1D2A-41C8-8AE8-C80D87A65351@fuhm.net>
	<AANLkTi=pOQdVb8N025PLhm++_x252aFNBjNVPqtd=_bL@mail.gmail.com>
	<87sjuvo7lu.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D78A9B4.4030606@v.loewis.de>
Message-ID: <87mxl2qk9s.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. L?wis" writes:

 > Note that it is ultimately up to a court to interpret these words of the
 > GPL, not to the FSF lawyer.

True, and in the case of a non-FSF product, any ambiguities would be
resolved first by determining the intent of the copyright owner,
second (perhaps even overriding the intent of the owner) by the
understanding of the user, and only third by asking the author of the
license.

Nevertheless, in the U.S. at least the court would likely be
influenced in its judgments about "intent" and "understanding" by
public statements of the author, because those would tend to condition
the general public's understanding, including that of the parties to
the license.

 > > Specifically, in
 > >
 > >   >  "Major Component", in this context, means a major essential component
 > >   >  (kernel, window system, and so on) of the specific operating system
 > >   >  (if any) on which the executable work runs, or a compiler used to
 > >   >  produce the work, or an object code interpreter used to run it.
 > >
 > > the word "essential" would refer to running the compiler or the
 > > operating system or interpreter, not to a component essential to
 > > running the program but in general optional for using the system.
 > 
 > Maybe my English is not good enough

Mine is definitely not! :-)

 > - I read that to mean that the compiler itself is a major component
 > of the system (and thus doesn't need to be distributed along with
 > the source of the GPL'ed program).  Note that it explicitly also
 > says that a "object code interpreter" used to run "it" (the
 > executable) is a major component, which would explicitly declare
 > Python a major component (as long as it's actually distributed with
 > the system).

Well, English being what it is, your guess is as good as mine.<0.2 wink>

My understanding is that the compiler or interpreter is not being
defined as a major component.  It is being defined as something which,
like a major component, is exempt from the source distribution and
licensing requirements of the GPL.  As is typical of the GPL :-(, the
English is ambiguous as to whether "major essential components" of
compilers or interpreters are exempt, too.  I would think so, though.
This simplifies licensing of things like the runtime code distributed
with GCC, Java Swing (or whatever the preferred GUI is nowadays), or
the implementation of print() in Python 3 dramatically, at little cost
in additional leniency that I can see.

That is, the reason that Java and Python programs can usefully be GPL
is unrelated to the "major component" part of that clause.  Rather, my
understanding of the above GPLv3 clause is that it promotes VMs and
interpreters to the level of *platform*, just like the kernel.  In
general using a language *translator* is *not* considered to create a
derivative, because a derivative is a (possibly partial or modified)
copy of the original.  I've asked Richard Stallman about this
specifically for GPLv2, and that's what he told me about Emacs Lisp:
it is possible to write and distribute non-GPL programs in Emacs Lisp
(but difficult, because you have to avoid using Emacs-specific data
structures and functions).

This makes a fair amount of sense anyway, since the translator works
on the program as data, but the translator is not (usually) copied
into the program.  In other words, the GPL doesn't apply to the output
of GCC, not because of the generosity of Richard Stallman, but because
in U.S. copyright law, at least, it *can't*.[1]  In the case of an
interpreter, this is a lot more fuzzy (the interpreter is linked to
the implementations of the statements).  The English/legalese of GPLv2
doesn't make this clear.  I think that's why GPLv3 explicitly
specifies "interpreters of object code" in that clause.

 > If your interpetation was right and Python is *not* a major
 > component, then any GPL'ed Python application would need to
 > distribute the source code of Python along with its own source
 > code, and with that the source of all libraries that are not major
 > components themselves.

Yes, for the libraries.  That's what James is worried about.

 > Also, if your interpretation was right, it wouldn't be possible to
 > license Java programs under the GPL, since the JVM wouldn't be a major
 > component,

No, of course it's possible for the copyright holders to license Java
programs under the GPL, and even for you (not the owner) to create
derivatives, as long as you are confident that the copyright holders
won't sue you.

As for what the law and the GPL actually say about these matters,
surely it is not news to you that the GPL sucks unless you want all
software GPLed, and even then there are "regrettable" side effects.


Footnotes: 
[1]  OTOH, the bison license contains a special clause because the "hairy
parser" is a fairly extensive piece of C code that is copied into a
program using bison to compile yacc specifications.  This clause says
basically "the hairy parser is part of bison but as a special
exception its presence in your program is OK even if you distribute
the program under a license other than the GPL."




From ezio.melotti at gmail.com  Fri Mar 11 13:53:42 2011
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Fri, 11 Mar 2011 14:53:42 +0200
Subject: [Python-Dev] [Python-checkins] (2.7): Use simpler assert in
	basic example.
In-Reply-To: <AANLkTinUVARaa_NFBcvu9S1Ur_MkZQ9w7WfEDg-9pnAJ@mail.gmail.com>
References: <E1PxnWh-0005Jj-1I@dinsdale.python.org>
	<AANLkTinUVARaa_NFBcvu9S1Ur_MkZQ9w7WfEDg-9pnAJ@mail.gmail.com>
Message-ID: <4D7A1B56.7010302@gmail.com>

On 11/03/2011 4.45, Nick Coghlan wrote:
> On Thu, Mar 10, 2011 at 4:36 PM, ezio.melotti
> <python-checkins at python.org>  wrote:
>> http://hg.python.org/cpython/rev/9adc4792db9a
>> changeset:   68356:9adc4792db9a
>> branch:      2.7
>> user:        Ezio Melotti<ezio.melotti at gmail.com>
>> date:        Thu Mar 10 23:35:39 2011 +0200
>> summary:
>>   Use simpler assert in basic example.
> Please don't. Now the new methods are available, using assertTrue() on
> supported expressions is actively throwing away data, and the docs
> shouldn't recommend it *anywhere*.

I agree with you, but Raymond wants to keep the example as simple as 
possible and asked me to change it back.

> If using assertIn() at this point in the docs is a genuine problem,
> find an alternative test example that isn't better written using one
> of the more specific methods.

That would be best.  Can you come up with a different example that only 
uses assertEqual/assertTrue/assertRaises?

Best Regards,
Ezio Melotti

> Cheers,
> Nick.
>
>> files:
>>   Doc/library/unittest.rst
>>
>> diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst
>> --- a/Doc/library/unittest.rst
>> +++ b/Doc/library/unittest.rst
>> @@ -130,13 +130,13 @@
>>
>>         def test_choice(self):
>>             element = random.choice(self.seq)
>> -           self.assertIn(element, self.seq)
>> +           self.assertTrue(element in self.seq)
>>
>>         def test_sample(self):
>>             with self.assertRaises(ValueError):
>>                 random.sample(self.seq, 20)
>>             for element in random.sample(self.seq, 5):
>> -               self.assertIn(element, self.seq)
>> +               self.assertTrue(element in self.seq)
>>
>>     if __name__ == '__main__':
>>         unittest.main()
>>
>> --
>> Repository URL: http://hg.python.org/cpython
>>
>> _______________________________________________
>> Python-checkins mailing list
>> Python-checkins at python.org
>> http://mail.python.org/mailman/listinfo/python-checkins
>>
>>
>
>


From thomas at python.org  Fri Mar 11 15:23:06 2011
From: thomas at python.org (Thomas Wouters)
Date: Fri, 11 Mar 2011 06:23:06 -0800
Subject: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in
 determining child loggers.
In-Reply-To: <AANLkTinDN_QmAL-J8HYjE4dWtad1uxaCEDQQGkFaVpL9@mail.gmail.com>
References: <E1Pwf58-0007Si-3W@dinsdale.python.org>
	<4D75241F.7090403@netwok.org> <4D7934C7.5060800@netwok.org>
	<338044.5218.qm@web25805.mail.ukl.yahoo.com>
	<4D794D9B.7030502@netwok.org>
	<4691.44041.qm@web25801.mail.ukl.yahoo.com>
	<AANLkTinDN_QmAL-J8HYjE4dWtad1uxaCEDQQGkFaVpL9@mail.gmail.com>
Message-ID: <AANLkTi=f9+qiu-+hsPApDMoVBM8QE6QETufEU-35kbnd@mail.gmail.com>

On Thu, Mar 10, 2011 at 18:47, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Thu, Mar 10, 2011 at 5:41 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk>
> wrote:
> > ----- Original Message ----
> >
> >> From: ?ric Araujo <merwok at netwok.org>
> >> > From what I understand, we're supposed to forward-port in  Mercurial,
> >> Correct, but only in maintained branches, not security-mode  branches.
> >>
> >
> > Well, I saw this recent mail from Antoine:
> >
> > http://mail.python.org/pipermail/python-dev/2011-March/108766.html
> >
> > where he mentioned
> >
> >
> > - on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain 2.5)
> > - on the other hand: 3.1 -> 3.2 -> default
> >
> > and perhaps misunderstood. I was assuming that there wouldn't be any 2.6
> > releases from Mercurial, perhaps that assumption was unwarranted.
> >
> > Also, the section on forward-porting in the Dev Guide says "it should be
> applied
> > to the oldest branch applicable" and this could be interpreted to mean
> > applicable based on the content of the branch, rather than according to
> release
> > policy.
>
> It's the intersection: if the change applies to the content of that
> branch and that branch is still maintained, then start there.
>
> So security fixes start further back than ordinary bug fixes.
>
> This should be reverted in 2.6, with the dummy merge to prevent
> inadvertent reversion in 2.7.
>

Just to be clear on this, so people don't think this is more complicated
than it needs to be: you can still *develop* a patch based on 2.5, even
commit it to your local repository, and then only push it to 2.6 or 2.7 and
later. You don't have to consider where the patch should go beforehand.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110311/60dac250/attachment.html>

From status at bugs.python.org  Fri Mar 11 18:07:03 2011
From: status at bugs.python.org (Python tracker)
Date: Fri, 11 Mar 2011 18:07:03 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20110311170703.2BFC11CCA7@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2011-03-04 - 2011-03-11)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    2709 (+18)
  closed 20540 (+53)
  total  23249 (+71)

Open issues with patches: 1151 


Issues opened (46)
==================

#1271: Raw string parsing fails with backslash as last character
http://bugs.python.org/issue1271  reopened by ezio.melotti

#11397: os.path.realpath() may produce incorrect results
http://bugs.python.org/issue11397  opened by mkovtun

#11401: email.header error during .flatten()
http://bugs.python.org/issue11401  opened by sdaoden

#11402: _PyUnicode_Init leaks a little memory once
http://bugs.python.org/issue11402  opened by stutzbach

#11403: Add some generated files in PC/ to .hgignore.
http://bugs.python.org/issue11403  opened by santa4nt

#11406: There is no os.listdir() equivalent returning generator instea
http://bugs.python.org/issue11406  opened by mmarkk

#11407: unittest.TestCase.run should return result
http://bugs.python.org/issue11407  opened by michael.foord

#11409: pysetup --search should return non-zero when a dist is not ins
http://bugs.python.org/issue11409  opened by kelseyhightower

#11410: Use GCC visibility attrs in PyAPI_*
http://bugs.python.org/issue11410  opened by twouters

#11412: Section numbers in the Library Reference have a trailing perio
http://bugs.python.org/issue11412  opened by rhettinger

#11414: Add import fix for email.Message
http://bugs.python.org/issue11414  opened by kitterma

#11415: ZipFile don't overwrite compresed files at create
http://bugs.python.org/issue11415  opened by piranna

#11416: netrc module does not handle multiple entries for a single hos
http://bugs.python.org/issue11416  opened by saffroy

#11418: Method's global scope is module containing function definition
http://bugs.python.org/issue11418  opened by naoki

#11419: Python-ast.[ch] out-of-date w.r.t. sources in fresh 2.5 checko
http://bugs.python.org/issue11419  opened by skip.montanaro

#11420: Make testsuite pass with -B/DONTWRITEBYTECODE set.
http://bugs.python.org/issue11420  opened by twouters

#11421: Subversion keywords missing on 2.5 checkout
http://bugs.python.org/issue11421  opened by skip.montanaro

#11426: CSV examples can't close their files
http://bugs.python.org/issue11426  opened by gwideman

#11427: ctypes from_buffer no longer accepts bytes
http://bugs.python.org/issue11427  opened by benrg

#11429: ctypes is highly eclectic in its raw-memory support
http://bugs.python.org/issue11429  opened by benrg

#11430: can't change the sizeof a Structure that doesn't own its buffe
http://bugs.python.org/issue11430  opened by benrg

#11432: webbrowser.open on unix fails.
http://bugs.python.org/issue11432  opened by ideasman42

#11436: Clarify struct doc for format 's'.
http://bugs.python.org/issue11436  opened by terry.reedy

#11437: IDLE crash on startup with typo in config-keys.cfg
http://bugs.python.org/issue11437  opened by George.Dhoore

#11439: subversion keyword breakage
http://bugs.python.org/issue11439  opened by skrah

#11440: fix_callable should be dropped from lib2to3 / changed
http://bugs.python.org/issue11440  opened by SilentGhost

#11441: compile() raises SystemError if called from except clause
http://bugs.python.org/issue11441  opened by july

#11442: list_directory() in SimpleHTTPServer.py should add charset=...
http://bugs.python.org/issue11442  opened by gvanrossum

#11445: python.exe on OS X shared-llbrary build erroneously linked to 
http://bugs.python.org/issue11445  opened by skip.montanaro

#11446: Incorrect PEP link in Language Reference section 7.7
http://bugs.python.org/issue11446  opened by terrence

#11447: test_pydoc refleak
http://bugs.python.org/issue11447  opened by pitrou

#11448: docs for HTTPConnection.set_tunnel are ambiguous
http://bugs.python.org/issue11448  opened by rfk

#11449: tarfile tries to file_.tell() even when creating a new archive
http://bugs.python.org/issue11449  opened by strombrg

#11453: asyncore.file_wrapper should implement __del__ and call close 
http://bugs.python.org/issue11453  opened by amajorek

#11454: email.message import time
http://bugs.python.org/issue11454  opened by rosslagerwall

#11455: issue a warning when populating a CPython type dict with non-s
http://bugs.python.org/issue11455  opened by michael.foord

#11456: Documentation csv RFC4180
http://bugs.python.org/issue11456  opened by tonywallace

#11457: Expose nanosecond precision from system calls
http://bugs.python.org/issue11457  opened by khenriksson

#11459: Python select.select does not correctly report read readyness
http://bugs.python.org/issue11459  opened by amicitas

#11461: Reading UTF-16 with codecs.readline() breaks on surrogate pair
http://bugs.python.org/issue11461  opened by ply

#11462: Peephole creates duplicate and unused constants
http://bugs.python.org/issue11462  opened by eltoder

#11463: IncompleteRead: IncompleteRead(168 bytes read)
http://bugs.python.org/issue11463  opened by caitifbrito

#11464: Call Mac API Crash via ctypes
http://bugs.python.org/issue11464  opened by heyt1981

#11465: Set documentation: Link to wikipedia
http://bugs.python.org/issue11465  opened by guettli

#11466: getpass.getpass doesn't close tty file
http://bugs.python.org/issue11466  opened by sdaoden

#11467: urlparse.urlsplit() regression for paths consisting of digits
http://bugs.python.org/issue11467  opened by calvin



Most recent 15 issues with no replies (15)
==========================================

#11453: asyncore.file_wrapper should implement __del__ and call close 
http://bugs.python.org/issue11453

#11446: Incorrect PEP link in Language Reference section 7.7
http://bugs.python.org/issue11446

#11430: can't change the sizeof a Structure that doesn't own its buffe
http://bugs.python.org/issue11430

#11429: ctypes is highly eclectic in its raw-memory support
http://bugs.python.org/issue11429

#11427: ctypes from_buffer no longer accepts bytes
http://bugs.python.org/issue11427

#11418: Method's global scope is module containing function definition
http://bugs.python.org/issue11418

#11416: netrc module does not handle multiple entries for a single hos
http://bugs.python.org/issue11416

#11407: unittest.TestCase.run should return result
http://bugs.python.org/issue11407

#11403: Add some generated files in PC/ to .hgignore.
http://bugs.python.org/issue11403

#11402: _PyUnicode_Init leaks a little memory once
http://bugs.python.org/issue11402

#11390: doctest: add cmdline parameters
http://bugs.python.org/issue11390

#11376: Solaris/GCC/shared lib problem
http://bugs.python.org/issue11376

#11375: urllib2 over SOCKS doesn't use proxy for DNS
http://bugs.python.org/issue11375

#11367: xml.etree.ElementTree.find(all): docs are wrong
http://bugs.python.org/issue11367

#11361: suggestion for os.kill(pid,CTRL_C_EVENT) in tests
http://bugs.python.org/issue11361



Most recent 15 issues waiting for review (15)
=============================================

#11466: getpass.getpass doesn't close tty file
http://bugs.python.org/issue11466

#11462: Peephole creates duplicate and unused constants
http://bugs.python.org/issue11462

#11461: Reading UTF-16 with codecs.readline() breaks on surrogate pair
http://bugs.python.org/issue11461

#11459: Python select.select does not correctly report read readyness
http://bugs.python.org/issue11459

#11456: Documentation csv RFC4180
http://bugs.python.org/issue11456

#11455: issue a warning when populating a CPython type dict with non-s
http://bugs.python.org/issue11455

#11448: docs for HTTPConnection.set_tunnel are ambiguous
http://bugs.python.org/issue11448

#11441: compile() raises SystemError if called from except clause
http://bugs.python.org/issue11441

#11436: Clarify struct doc for format 's'.
http://bugs.python.org/issue11436

#11432: webbrowser.open on unix fails.
http://bugs.python.org/issue11432

#11426: CSV examples can't close their files
http://bugs.python.org/issue11426

#11420: Make testsuite pass with -B/DONTWRITEBYTECODE set.
http://bugs.python.org/issue11420

#11410: Use GCC visibility attrs in PyAPI_*
http://bugs.python.org/issue11410

#11409: pysetup --search should return non-zero when a dist is not ins
http://bugs.python.org/issue11409

#11403: Add some generated files in PC/ to .hgignore.
http://bugs.python.org/issue11403



Top 10 most discussed issues (10)
=================================

#11406: There is no os.listdir() equivalent returning generator instea
http://bugs.python.org/issue11406  20 msgs

#11395: print(s) fails on Windows with long strings
http://bugs.python.org/issue11395  15 msgs

#11441: compile() raises SystemError if called from except clause
http://bugs.python.org/issue11441  14 msgs

#11462: Peephole creates duplicate and unused constants
http://bugs.python.org/issue11462  12 msgs

#11072: Add MLSD command support to ftplib
http://bugs.python.org/issue11072   9 msgs

#11455: issue a warning when populating a CPython type dict with non-s
http://bugs.python.org/issue11455   9 msgs

#11344: Add os.path.splitpath(path) function
http://bugs.python.org/issue11344   8 msgs

#11445: python.exe on OS X shared-llbrary build erroneously linked to 
http://bugs.python.org/issue11445   7 msgs

#11244: Negative tuple elements produce inefficient code.
http://bugs.python.org/issue11244   6 msgs

#11385: TextTestRunner methods are not documented
http://bugs.python.org/issue11385   6 msgs



Issues closed (50)
==================

#4216: subprocess.Popen hangs at communicate() when child exits
http://bugs.python.org/issue4216  closed by terry.reedy

#5622: wrong error from curses.wrapper if curses initialization fails
http://bugs.python.org/issue5622  closed by ned.deily

#6864: IDLE 2.6.1 locks up on Mac OS 10.6
http://bugs.python.org/issue6864  closed by ned.deily

#7867: Proposed FAQ entry on pass-by-? semantics and the meaning of '
http://bugs.python.org/issue7867  closed by r.david.murray

#7896: IDLE.app crashes when attempting to open a .py file
http://bugs.python.org/issue7896  closed by ned.deily

#8995: Performance issue with multiprocessing queue (3.1 VS 2.6)
http://bugs.python.org/issue8995  closed by pitrou

#9045: 2.7rc1: 64-bit OSX installer is not built with 64-bit tkinter
http://bugs.python.org/issue9045  closed by ned.deily

#9427: logging.error('...', exc_info=True) should display upper frame
http://bugs.python.org/issue9427  closed by vinay.sajip

#9796: Add summary tables for unittest API
http://bugs.python.org/issue9796  closed by ezio.melotti

#10461: Use with statement throughout the docs
http://bugs.python.org/issue10461  closed by python-dev

#10537: OS X IDLE 2.7 from 64-bit installer hangs when you paste somet
http://bugs.python.org/issue10537  closed by ned.deily

#10969: Make Tcl recommendation more prominent
http://bugs.python.org/issue10969  closed by ned.deily

#10999: os.chflags refers to stat constants, but the constants are not
http://bugs.python.org/issue10999  closed by r.david.murray

#11009: urllib.splituser is not documented
http://bugs.python.org/issue11009  closed by orsenthil

#11227: [DOC] asyncore - use 'Host' header in HTTP example
http://bugs.python.org/issue11227  closed by georg.brandl

#11239: regexp-howto - add missing } to metachars
http://bugs.python.org/issue11239  closed by georg.brandl

#11292: Curses - add A_REVERSE to attributes table
http://bugs.python.org/issue11292  closed by georg.brandl

#11294: Locale - update & uniform ERA_*_FMT doc
http://bugs.python.org/issue11294  closed by georg.brandl

#11298: unittest discovery needs better explanation
http://bugs.python.org/issue11298  closed by ezio.melotti

#11337: Nothing refers to footnote [1] on page "6. Simple Statements" 
http://bugs.python.org/issue11337  closed by georg.brandl

#11338: No list of Python hg repositories
http://bugs.python.org/issue11338  closed by blokeley

#11373: Fix 2 new typos in the docs
http://bugs.python.org/issue11373  closed by georg.brandl

#11391: mmap write segfaults if PROT_WRITE bit is not set in prot
http://bugs.python.org/issue11391  closed by pitrou

#11392: Turtle - better explain 'chaos' demo
http://bugs.python.org/issue11392  closed by georg.brandl

#11398: http_proxy on windows won't function due to incorrect case han
http://bugs.python.org/issue11398  closed by chris.nojima

#11399: cmd.exe: python.exe -u fails to parse input to the interactive
http://bugs.python.org/issue11399  closed by r.david.murray

#11400: Remove reference to pre 1.5 assignment behavior
http://bugs.python.org/issue11400  closed by georg.brandl

#11404: support /dev/null for subprocess.call() and friends
http://bugs.python.org/issue11404  closed by ned.deily

#11405: Wrong reference to string module in tutorial/inputoutput.rst
http://bugs.python.org/issue11405  closed by georg.brandl

#11408: python locks: blocking acquire calls useless gettimeofday
http://bugs.python.org/issue11408  closed by pitrou

#11411: Fix typo in Makefile
http://bugs.python.org/issue11411  closed by twouters

#11413: Idle doesn't start
http://bugs.python.org/issue11413  closed by terry.reedy

#11417: distutils' bdist_rpm fails when running with PYTHONDONTWRITEBY
http://bugs.python.org/issue11417  closed by twouters

#11422: indentation problem in if, elif, else statements
http://bugs.python.org/issue11422  closed by loewis

#11423: .py file does not open on click
http://bugs.python.org/issue11423  closed by loewis

#11424: logging fileConfig may not correctly detect children
http://bugs.python.org/issue11424  closed by vinay.sajip

#11425: Cleanup sample codes in tutorial.
http://bugs.python.org/issue11425  closed by rhettinger

#11428: with statement looks up __exit__ incorrectly
http://bugs.python.org/issue11428  closed by georg.brandl

#11431: Python 3.2 (r32:88452) F5 "Run Module" freezes IDLE
http://bugs.python.org/issue11431  closed by ned.deily

#11433: syntax error at "while" statement in IDLE/python shell
http://bugs.python.org/issue11433  closed by SilentGhost

#11434: Python 3.2 input() does not remove "\r" at the end of returned
http://bugs.python.org/issue11434  closed by r.david.murray

#11435: Links to source code should now point to hg repo
http://bugs.python.org/issue11435  closed by ezio.melotti

#11438: 2to3 does not fix izip_longest
http://bugs.python.org/issue11438  closed by benjamin.peterson

#11443: Zip password issue
http://bugs.python.org/issue11443  closed by sbojchuk

#11444: logging FileHandler.close should acquire its lock before closi
http://bugs.python.org/issue11444  closed by vinay.sajip

#11450: Py_GetBuildInfo() truncates when there are many hg tags
http://bugs.python.org/issue11450  closed by pitrou

#11451: Raw string parsing fails with backslash as last character
http://bugs.python.org/issue11451  closed by ezio.melotti

#11452: Test suite not symlink-install clean
http://bugs.python.org/issue11452  closed by sdaoden

#11458: tarfile with socket incompatability
http://bugs.python.org/issue11458  closed by r.david.murray

#11460: Attribute Error
http://bugs.python.org/issue11460  closed by ezio.melotti

From thomas at python.org  Fri Mar 11 20:23:48 2011
From: thomas at python.org (Thomas Wouters)
Date: Fri, 11 Mar 2011 11:23:48 -0800
Subject: [Python-Dev] Callable, non-descriptor class attributes.
Message-ID: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>

One of the things brought up at the language summit (and I believe at the VM
summit, although I wasn't there) was the unpredictable behaviour of
callables turning into methods when they're class attributes. Specifically,
things that are CFunctions in CPython (builtin functions, which are not
descriptors and do not turn into methods) but could be plain Python
functions in other Python implementations. (Or even turn into a plain
function in CPython itself, if the other-implementation argument isn't
persuasive enough for you.) To see the kind of thing that would be
(potentially) problematic, see for example Lib/encodings/ascii.py:

import codecs

### Codec APIs

class Codec(codecs.Codec):

    # Note: Binding these as C functions will result in the class not
    # converting them to methods. This is intended.
    encode = codecs.ascii_encode
    decode = codecs.ascii_decode

(I hope the irony of a two-line comment explaining the situation, as opposed
to the self-documenting nature of staticmethod, isn't lost on anyone :)
Obviously, if the codecs.ascii_encode and codecs.ascii_decode functions are
replaced *for whatever reason* by Python functions, this will break. Because
these kinds of class attributes are often used for dependency injection, the
potentially problematic cases are even more common in tests -- the io
testsuite, for example, specialcases pyio.open (in two different ways, no
less) but omits the same for io.open for no apparent reason (other than that
right now, in CPython, it isn't needed.)

At the summit we discussed some potential improvements here:

 1. Make staticmethod a callable object directly (it isn't, currently) and
apply it to any Python function that replaces a (in CPython) CFunction. The
change to staticmethod may be a good idea regardless, but the policy of
making other implementations comply to this quirk in CPython seems (to me)
like unnecessary descrimination[*].
 2. Make CFunctions turn into methods in CPython (after a period of warning
about the impending change, obviously.) The actual *usecase* for this is
hard to envision (I think Guido thought someone might do 'class str(str):
len = len', which doesn't seem like that big an improvement :) so it would
be a feature for symmetry's sake only.
 3. Produce a CompatibilityWarning making sure that the programmer knows
that this particular thing might not do the same thing in other Python
implementations *or versions*.
 4. Make it an error to have a callable class attribute that isn't a
descriptor (although maybe we only discussed this one in my head.)

To gauge the size of the problem I've implemented solution #3: I've uploaded
a patch that adds the warning (currently as a DeprecationWarning) and fixes
a bunch of the issues (not yet all of them):
http://bugs.python.org/issue11470. The patch currently warns for callable,
non-descriptor, *non-class* class attributes. The class check is necessary
because injected classes and -- more popularly, in some ORMs -- nested
classes would otherwise produce the warning. (Considering replacing a class
with a function has lots of other effects, like isinstance checks failing, I
don't think warning for that case is necessary anyway.) An alternate
strategy would be to warn only about uses of CFunctions in these cases, but
this misses out on a whole slew of potential issues (e.g. a module global
that is currently a bound instance method.)

If you look at the patch you'll notice it also fixes a couple of "dubious"
cases -- usually in a module's own testsuite -- where one could certainly
argue that the test is allowed to make the assumptions it's making. I don't
think writing it explicitly future-proof detracts from the readability,
stability and maintainability in most of these cases, although I should
point out that multiprocessing's testsuite produces a bunch more warnings
and isn't as easy to fix because of its use of locals().update() in a class
statement. (Yes, really.)

With regards to changing staticmethod, in an earlier iteration of the patch
I modified staticmethod to be directly callable *and* to return self in its
tp_descr_get, and this had a side-effect I hadn't considered: code that used
a staticmethod-wrapped object in any way other than calling it, broke. Right
now staticmethod is implemented as a generic container to inhibit descriptor
behaviour, in spite of its name, so it can be used to protect any kind of
descriptor in a class attribute. I'm not sure how common that use is, and
whether we should try to provide a different wrapper for those cases.
Unfortunately, without changing staticmethod to return itself, rather than
the callable it's wrapping, in tp_descr_get, code like this:

  class C:
    open = builtin.open

  class D:
    open = C.open

... would still produce different behaviour when builtin.open changes from a
CPython CFunction to a Python function wrapped in a staticmethod: C.open
would produce the Python function, and D.open would then become a method
after all. (This is why _pyio has OpenWrapper instead, I guess.)

Considering all this, I personally think we should go for solution #3 or #4
(with a long migration path through #3, of course): add a warning like the
one I implemented, add plenty of documentation explaining the issue (perhaps
even pointing to a PEP in the warning,) and fix everything in the stdlib
that produces the warning, even if it's hard to see how that particular case
could become a problem. The warning should probably be of the same kind as
DeprecationWarning to prevent end-users from being confused by it. Changing
staticmethod to be directly callable may still be a good idea, but changing
what its descr_get does is not. Making CFunctions turn into bound methods is
something that seems of little value, but could be considered at a later
point (after the warning has had time to flush out most of the problematic
cases.)

[*]-sorry-couldn't-resist'ly y'rs,
-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110311/b7a3d382/attachment.html>

From solipsis at pitrou.net  Fri Mar 11 21:24:37 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 11 Mar 2011 21:24:37 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
References: <il75tb$c8s$1@dough.gmane.org>
Message-ID: <20110311212437.15b7615d@pitrou.net>

On Wed, 09 Mar 2011 07:15:07 +0100
Stefan Behnel <stefan_ml at behnel.de> wrote:
> 
> Actually, why not put up a web page of "upcoming changes" somewhere, that 
> lists major decisions with user impact that were taken on python-dev? 
> Including a link to the relevant discussion and decision. Often enough, 
> decisions are taken inside of huge mailing list threads that get off-topic 
> before someone has "the right idea" and everyone who's still there to 
> listen agrees. Even for people lurking around on python-dev, it's easy 
> enough to miss these moments.

A better alternative IMHO would be to revive the community buildbots
(pybots.org), under the same form or another.

Regards

Antoine.



From tseaver at palladion.com  Fri Mar 11 21:53:03 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 11 Mar 2011 15:53:03 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <20110311212437.15b7615d@pitrou.net>
References: <il75tb$c8s$1@dough.gmane.org> <20110311212437.15b7615d@pitrou.net>
Message-ID: <ile24t$2tt$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/11/2011 03:24 PM, Antoine Pitrou wrote:
> On Wed, 09 Mar 2011 07:15:07 +0100
> Stefan Behnel <stefan_ml at behnel.de> wrote:
>>
>> Actually, why not put up a web page of "upcoming changes" somewhere, that 
>> lists major decisions with user impact that were taken on python-dev? 
>> Including a link to the relevant discussion and decision. Often enough, 
>> decisions are taken inside of huge mailing list threads that get off-topic 
>> before someone has "the right idea" and everyone who's still there to 
>> listen agrees. Even for people lurking around on python-dev, it's easy 
>> enough to miss these moments.
> 
> A better alternative IMHO would be to revive the community buildbots
> (pybots.org), under the same form or another.

How would more buildbots help the visibility of changes being landed to
the language or standard library?


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk16i68ACgkQ+gerLs4ltQ6RaACeMOXvAqUYByjx5lFUjMcVH0Z9
ZtIAn0MtoBD3LWc6GZsUCrQmL3DJqHVC
=rZ+o
-----END PGP SIGNATURE-----


From guido at python.org  Fri Mar 11 22:50:06 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 11 Mar 2011 16:50:06 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <A8557CC0-68C0-46A6-B2AF-DF9200FFF4B7@gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTikFXeUw477+vhEs1xfFeTJpy_Eeo54LqYbLfG90@mail.gmail.com>
	<A8557CC0-68C0-46A6-B2AF-DF9200FFF4B7@gmail.com>
Message-ID: <AANLkTikzkTtGEEbCNN18kJ4VA=PFCqOWhUq0iK8xnO9M@mail.gmail.com>

On Wed, Mar 9, 2011 at 3:40 PM, Doug Hellmann <doug.hellmann at gmail.com> wrote:
>
> On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote:
>
>> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel <stefan_ml at behnel.de> wrote:
>>> Actually, why not put up a web page of "upcoming changes" somewhere, that
>>> lists major decisions with user impact that were taken on python-dev?
>>> Including a link to the relevant discussion and decision. Often enough,
>>> decisions are taken inside of huge mailing list threads that get off-topic
>>> before someone has "the right idea" and everyone who's still there to listen
>>> agrees. Even for people lurking around on python-dev, it's easy enough to
>>> miss these moments.
>>
>> We used to do biweekly-ish Python-Dev summaries for this reason.
>>
>> The original links at python.org appear to be down, but I found an
>> example mirrored at
>> ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html
>>
>> Would resuming these and putting them back on python.org address the issue?
>>
>> It's been on my back burner for about two years now, but I want to
>> make sure I can keep up before diving in again.
>
> As Jesse mentioned, this topic came up on the board mailing list recently for a reason completely unrelated to this thread. As a result of that discussion, the board has asked me in my capacity as PSF Communications Director to help the python-dev crew set up a blog (or other forum) through which you can communicate news about major projects undertaken during development. This would be in addition to, rather than a replacement for, individual developer blogs, and would provide an official channel for the team to talk about projects publicly after they are complete.
>
> Topics proposed as part of the discussion on the board list included the hg migration, the new developer's guide, changes to the Mac installer, and the updated release process for 3.2. Those are just examples, though. This deprecation would make another good topic, and I'm sure everyone can think of others. Consider the blog as an analog to the PEP process. Where PEPs come at the beginning of a project, a blog post would come at a major milestones or the completion of a project.
>
> The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. I will provide editorial guidance to anyone that wants me to read their posts before they are published, and I will administer the tool if needed (granting access and moderating comments that look like spam).
>
> I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea. I was going to hold discussion for the mailing list until after that meeting, but since the topic came up on its own please go ahead and respond here with questions or comments, especially if you won't be in Atlanta tomorrow. Let's table discussion of tools for now, though, because I want to make sure there is enough support for the project before we spend too much energy on implementation details.

I propose we try to find an "embedded blogger" who participates in
python-dev but is focused on making regular blog posts about the
interesting tidbits. There's no requirement to be complete (which I
think always weighed the python-dev-summaries task down).

Ditto for python-ideas -- it would be nice if it was the same person
but doesn't have to be.

This might be an opportunity for increasing diversity.

-- 
--Guido van Rossum (python.org/~guido)

From solipsis at pitrou.net  Fri Mar 11 22:56:49 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 11 Mar 2011 22:56:49 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
References: <il75tb$c8s$1@dough.gmane.org> <20110311212437.15b7615d@pitrou.net>
	<ile24t$2tt$1@dough.gmane.org>
Message-ID: <20110311225649.3ea272c9@pitrou.net>

On Fri, 11 Mar 2011 15:53:03 -0500
Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/11/2011 03:24 PM, Antoine Pitrou wrote:
> > On Wed, 09 Mar 2011 07:15:07 +0100
> > Stefan Behnel <stefan_ml at behnel.de> wrote:
> >>
> >> Actually, why not put up a web page of "upcoming changes" somewhere, that 
> >> lists major decisions with user impact that were taken on python-dev? 
> >> Including a link to the relevant discussion and decision. Often enough, 
> >> decisions are taken inside of huge mailing list threads that get off-topic 
> >> before someone has "the right idea" and everyone who's still there to 
> >> listen agrees. Even for people lurking around on python-dev, it's easy 
> >> enough to miss these moments.
> > 
> > A better alternative IMHO would be to revive the community buildbots
> > (pybots.org), under the same form or another.
> 
> How would more buildbots help the visibility of changes being landed to
> the language or standard library?

They would help check that changes don't cause regressions in major
third-party packages such as CPython.

Regards

Antoine.



From solipsis at pitrou.net  Fri Mar 11 23:00:42 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 11 Mar 2011 23:00:42 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTikFXeUw477+vhEs1xfFeTJpy_Eeo54LqYbLfG90@mail.gmail.com>
	<A8557CC0-68C0-46A6-B2AF-DF9200FFF4B7@gmail.com>
Message-ID: <20110311230042.655b9b69@pitrou.net>

On Wed, 9 Mar 2011 15:40:56 -0500
Doug Hellmann <doug.hellmann at gmail.com> wrote:
> 
> The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. [...]
> 
> I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea.

If you find someone who likes to do it then it's fine.
Otherwise, I'm not sure it's a good use of our (the developers') time.
We already explain changes in the documentation, in Misc/NEWS and in the
"what's new" documents...

Regards

Antoine.



From brian.curtin at gmail.com  Fri Mar 11 23:05:16 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Fri, 11 Mar 2011 17:05:16 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
Message-ID: <AANLkTim5o-zGFshQFCVzUW5koxRoLchd8rbiCHzXz7zf@mail.gmail.com>

On Mar 11, 2011 4:52 PM, "Guido van Rossum" <guido at python.org> wrote:
>
> On Wed, Mar 9, 2011 at 3:40 PM, Doug Hellmann <doug.hellmann at gmail.com>
wrote:
> >
> > On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote:
> >
> >> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel <stefan_ml at behnel.de>
wrote:
> >>> Actually, why not put up a web page of "upcoming changes" somewhere,
that
> >>> lists major decisions with user impact that were taken on python-dev?
> >>> Including a link to the relevant discussion and decision. Often
enough,
> >>> decisions are taken inside of huge mailing list threads that get
off-topic
> >>> before someone has "the right idea" and everyone who's still there to
listen
> >>> agrees. Even for people lurking around on python-dev, it's easy enough
to
> >>> miss these moments.
> >>
> >> We used to do biweekly-ish Python-Dev summaries for this reason.
> >>
> >> The original links at python.org appear to be down, but I found an
> >> example mirrored at
> >> ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html
> >>
> >> Would resuming these and putting them back on python.org address the
issue?
> >>
> >> It's been on my back burner for about two years now, but I want to
> >> make sure I can keep up before diving in again.
> >
> > As Jesse mentioned, this topic came up on the board mailing list
recently for a reason completely unrelated to this thread. As a result of
that discussion, the board has asked me in my capacity as PSF Communications
Director to help the python-dev crew set up a blog (or other forum) through
which you can communicate news about major projects undertaken during
development. This would be in addition to, rather than a replacement for,
individual developer blogs, and would provide an official channel for the
team to talk about projects publicly after they are complete.
> >
> > Topics proposed as part of the discussion on the board list included the
hg migration, the new developer's guide, changes to the Mac installer, and
the updated release process for 3.2. Those are just examples, though. This
deprecation would make another good topic, and I'm sure everyone can think
of others. Consider the blog as an analog to the PEP process. Where PEPs
come at the beginning of a project, a blog post would come at a major
milestones or the completion of a project.
> >
> > The original request from the board was for the communications team to
write the messages, but I think it is more appropriate for the people doing
the work to talk about it. I will provide editorial guidance to anyone that
wants me to read their posts before they are published, and I will
administer the tool if needed (granting access and moderating comments that
look like spam).
> >
> > I asked Michael to add this topic to the agenda for the language summit
tomorrow to get early feedback about whether this group thinks it is a good
idea. I was going to hold discussion for the mailing list until after that
meeting, but since the topic came up on its own please go ahead and respond
here with questions or comments, especially if you won't be in Atlanta
tomorrow. Let's table discussion of tools for now, though, because I want to
make sure there is enough support for the project before we spend too much
energy on implementation details.
>
> I propose we try to find an "embedded blogger" who participates in
> python-dev but is focused on making regular blog posts about the
> interesting tidbits. There's no requirement to be complete (which I
> think always weighed the python-dev-summaries task down).
>
> Ditto for python-ideas -- it would be nice if it was the same person
> but doesn't have to be.
>
> This might be an opportunity for increasing diversity.
>
> --
> --Guido van Rossum (python.org/~guido)

I'm interested in the task and I guess I'll follow-up with Doug Hellman. I
don't follow -ideas close enough to summarize it, but I'd contribute to a
-dev blog.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110311/f1726954/attachment.html>

From solipsis at pitrou.net  Fri Mar 11 23:24:46 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 11 Mar 2011 23:24:46 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
References: <il75tb$c8s$1@dough.gmane.org> <20110311212437.15b7615d@pitrou.net>
	<ile24t$2tt$1@dough.gmane.org> <20110311225649.3ea272c9@pitrou.net>
Message-ID: <20110311232446.0bfd6156@pitrou.net>

On Fri, 11 Mar 2011 22:56:49 +0100
Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Fri, 11 Mar 2011 15:53:03 -0500
> Tres Seaver <tseaver at palladion.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 03/11/2011 03:24 PM, Antoine Pitrou wrote:
> > > On Wed, 09 Mar 2011 07:15:07 +0100
> > > Stefan Behnel <stefan_ml at behnel.de> wrote:
> > >>
> > >> Actually, why not put up a web page of "upcoming changes" somewhere, that 
> > >> lists major decisions with user impact that were taken on python-dev? 
> > >> Including a link to the relevant discussion and decision. Often enough, 
> > >> decisions are taken inside of huge mailing list threads that get off-topic 
> > >> before someone has "the right idea" and everyone who's still there to 
> > >> listen agrees. Even for people lurking around on python-dev, it's easy 
> > >> enough to miss these moments.
> > > 
> > > A better alternative IMHO would be to revive the community buildbots
> > > (pybots.org), under the same form or another.
> > 
> > How would more buildbots help the visibility of changes being landed to
> > the language or standard library?
> 
> They would help check that changes don't cause regressions in major
> third-party packages such as CPython.

Sorry, I meant Cython, not CPython...

Antoine.



From eric at trueblade.com  Sat Mar 12 00:14:46 2011
From: eric at trueblade.com (Eric Smith)
Date: Fri, 11 Mar 2011 18:14:46 -0500
Subject: [Python-Dev] [Python-checkins] devguide: Suggest using mpatch
	in the FAQ
In-Reply-To: <E1PyBMh-0006Tj-9c@dinsdale.python.org>
References: <E1PyBMh-0006Tj-9c@dinsdale.python.org>
Message-ID: <4D7AACE6.6060708@trueblade.com>

On 03/11/2011 06:03 PM, antoine.pitrou wrote:
>   If you want to try out or review a patch generated using Mercurial, do::
>
> -   hg import --no-commit somework.patch
> +   patch -p1<  somework.patch
>
>   This will apply the changes in your working copy without committing them.
>   If the patch was not created by Mercurial (for example, a patch created by
>   Subversion and thus lacking any ``a``/``b`` directory prefixes in the patch),
> -add ``-p0`` to the above command.
> +replace ``-p0`` with ``-p1``.

Do you have this backwards? There is no -p0, it's already -p1.

Eric.

From guido at python.org  Sat Mar 12 00:24:44 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 11 Mar 2011 18:24:44 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <AANLkTim5o-zGFshQFCVzUW5koxRoLchd8rbiCHzXz7zf@mail.gmail.com>
References: <AANLkTim5o-zGFshQFCVzUW5koxRoLchd8rbiCHzXz7zf@mail.gmail.com>
Message-ID: <AANLkTimpHrVnz4QfnkkhbauwvBOd0HBXRrm-B8NyHPbe@mail.gmail.com>

On Fri, Mar 11, 2011 at 5:05 PM, Brian Curtin <brian.curtin at gmail.com> wrote:
>
> On Mar 11, 2011 4:52 PM, "Guido van Rossum" <guido at python.org> wrote:
>>
>> On Wed, Mar 9, 2011 at 3:40 PM, Doug Hellmann <doug.hellmann at gmail.com>
>> wrote:
>> >
>> > On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote:
>> >
>> >> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel <stefan_ml at behnel.de>
>> >> wrote:
>> >>> Actually, why not put up a web page of "upcoming changes" somewhere,
>> >>> that
>> >>> lists major decisions with user impact that were taken on python-dev?
>> >>> Including a link to the relevant discussion and decision. Often
>> >>> enough,
>> >>> decisions are taken inside of huge mailing list threads that get
>> >>> off-topic
>> >>> before someone has "the right idea" and everyone who's still there to
>> >>> listen
>> >>> agrees. Even for people lurking around on python-dev, it's easy enough
>> >>> to
>> >>> miss these moments.
>> >>
>> >> We used to do biweekly-ish Python-Dev summaries for this reason.
>> >>
>> >> The original links at python.org appear to be down, but I found an
>> >> example mirrored at
>> >> ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html
>> >>
>> >> Would resuming these and putting them back on python.org address the
>> >> issue?
>> >>
>> >> It's been on my back burner for about two years now, but I want to
>> >> make sure I can keep up before diving in again.
>> >
>> > As Jesse mentioned, this topic came up on the board mailing list
>> > recently for a reason completely unrelated to this thread. As a result of
>> > that discussion, the board has asked me in my capacity as PSF Communications
>> > Director to help the python-dev crew set up a blog (or other forum) through
>> > which you can communicate news about major projects undertaken during
>> > development. This would be in addition to, rather than a replacement for,
>> > individual developer blogs, and would provide an official channel for the
>> > team to talk about projects publicly after they are complete.
>> >
>> > Topics proposed as part of the discussion on the board list included the
>> > hg migration, the new developer's guide, changes to the Mac installer, and
>> > the updated release process for 3.2. Those are just examples, though. This
>> > deprecation would make another good topic, and I'm sure everyone can think
>> > of others. Consider the blog as an analog to the PEP process. Where PEPs
>> > come at the beginning of a project, a blog post would come at a major
>> > milestones or the completion of a project.
>> >
>> > The original request from the board was for the communications team to
>> > write the messages, but I think it is more appropriate for the people doing
>> > the work to talk about it. I will provide editorial guidance to anyone that
>> > wants me to read their posts before they are published, and I will
>> > administer the tool if needed (granting access and moderating comments that
>> > look like spam).
>> >
>> > I asked Michael to add this topic to the agenda for the language summit
>> > tomorrow to get early feedback about whether this group thinks it is a good
>> > idea. I was going to hold discussion for the mailing list until after that
>> > meeting, but since the topic came up on its own please go ahead and respond
>> > here with questions or comments, especially if you won't be in Atlanta
>> > tomorrow. Let's table discussion of tools for now, though, because I want to
>> > make sure there is enough support for the project before we spend too much
>> > energy on implementation details.
>>
>> I propose we try to find an "embedded blogger" who participates in
>> python-dev but is focused on making regular blog posts about the
>> interesting tidbits. There's no requirement to be complete (which I
>> think always weighed the python-dev-summaries task down).
>>
>> Ditto for python-ideas -- it would be nice if it was the same person
>> but doesn't have to be.
>>
>> This might be an opportunity for increasing diversity.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>
> I'm interested in the task and I guess I'll follow-up with Doug Hellman. I
> don't follow -ideas close enough to summarize it, but I'd contribute to a
> -dev blog.

Awesome! (And we don't need to stop at one blogger. Many hands make light work.)

-- 
--Guido van Rossum (python.org/~guido)

From greg.ewing at canterbury.ac.nz  Sat Mar 12 00:49:32 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 12 Mar 2011 12:49:32 +1300
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
Message-ID: <4D7AB50C.5010405@canterbury.ac.nz>

Thomas Wouters wrote:

>  2. Make CFunctions turn into methods in CPython (after a period of 
> warning about the impending change, obviously.) The actual *usecase* for 
> this is hard to envision

While not necessary for the case being discussed here, this would
be a big help for Pyrex and Cython, where currently some awkward
things have to be done to get a Python class with methods implemented
in C.

-- 
Greg

From guido at python.org  Sat Mar 12 01:10:36 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 11 Mar 2011 19:10:36 -0500
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <4D7AB50C.5010405@canterbury.ac.nz>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
	<4D7AB50C.5010405@canterbury.ac.nz>
Message-ID: <AANLkTikutJiQfSPA8bYVp0NZFNDunkmCnaPnQwy08YLQ@mail.gmail.com>

On Fri, Mar 11, 2011 at 6:49 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Thomas Wouters wrote:
>
>> ?2. Make CFunctions turn into methods in CPython (after a period of
>> warning about the impending change, obviously.) The actual *usecase* for
>> this is hard to envision
>
> While not necessary for the case being discussed here, this would
> be a big help for Pyrex and Cython, where currently some awkward
> things have to be done to get a Python class with methods implemented
> in C.

I appreciate the use case, but I believe the right solution there is
to create a custom decorator implementing the desired descriptor
behavior. There simply are too many places where existing code depends
on a built-in function placed in a class *not* turning into a method.

Also, there is a slippery-slope argument here: if we were to add such
a descriptor to CFunctions, why not to other callables? I think we
need to stick to the rule where only Python functions have a
method-making descriptor.

Off-line, I discussed the patch with Thomas and we ended up agreeing
that the warning should only be issued for CFunctions used as class
variables.

In summary, I don't think the problem is with the difference between
CFunctions and pure-Python functions. That difference is well-defined
and shouldn't go away. The problem is that it is fairly common that
something that is a CFunction in CPython is replaced by a pure-Python
function, either in another Python VM, or in a different environment
(think heapq.py vs. _heapq.c), or when some unittest uses dependency
injection (i.e. temporarily replaces a built-in with a wrapper written
in Python). Such substitutions are generally transparent, but not when
the function is used as a class attribute. We should do all these
things to address this:

- on the "consuming" side, wrap such class variables in staticmethod() calls

- on the "producing" side (e.g. in PyPy) wrap pure-Python functions
that are substitutes for CPython builtins in a custom descriptor that
prevents method-making

- in CPython, warn whenever a built-in function is used as a class variable

-- 
--Guido van Rossum (python.org/~guido)

From p.f.moore at gmail.com  Sat Mar 12 01:12:07 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 12 Mar 2011 00:12:07 +0000
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <AANLkTimpHrVnz4QfnkkhbauwvBOd0HBXRrm-B8NyHPbe@mail.gmail.com>
References: <AANLkTim5o-zGFshQFCVzUW5koxRoLchd8rbiCHzXz7zf@mail.gmail.com>
	<AANLkTimpHrVnz4QfnkkhbauwvBOd0HBXRrm-B8NyHPbe@mail.gmail.com>
Message-ID: <AANLkTikG+SXAKZ3oAVPzzr1hAYyPcckj11SLoi5ROyfR@mail.gmail.com>

On 11 March 2011 23:24, Guido van Rossum <guido at python.org> wrote:
>> I'm interested in the task and I guess I'll follow-up with Doug Hellman. I
>> don't follow -ideas close enough to summarize it, but I'd contribute to a
>> -dev blog.
>
> Awesome! (And we don't need to stop at one blogger. Many hands make light work.)

I'm interested but probably haven't got time to take something like
this on "properly". Helping out occasionally would probably be
something I could do, though. (Was that tentative enough? :-)) I'm on
-ideas, too, so I could do something there as well.

Paul.

From eltoder at gmail.com  Sat Mar 12 02:24:09 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Fri, 11 Mar 2011 20:24:09 -0500
Subject: [Python-Dev] The purpose of SETUP_LOOP, BREAK_LOOP, CONTINUE_LOOP
Message-ID: <AANLkTikvBCMO7oNYKMwPKZ0-o6x38FmxatYVBmAy-w-p@mail.gmail.com>

Hello,

What is the purpose of SETUP_LOOP instruction? From a quick look it
seems like it just pushes the size of the loop into blocks stack; that
size is only used by BREAK_LOOP instruction.
BREAK_LOOP could just contain the target address directly, like
CONTINUE_LOOP does. This would avoid SETUP_LOOP/POP_BLOCK overhead for
all loops.
Am I missing something? Does SETUP_LOOP serve any other purpose?

Similarly, it looks like BREAK_LOOP and CONTINUE_LOOP are just jumps
that respect try/finally blocks (i.e. jumping out of try executes
finally). Is there more semantics to them than this? If not, this can
be simplified to:
1) If not in try/finally, simply generate a direct jump outside of the
loop (break) or to the start of the loop (continue).
2) If in try/finally, generate a new instruction JUMP_FROM_TRY which
replaces both BREAK_LOOP and CONTINUE_LOOP. It behaves the same way as
CONTINUE_LOOP but without restriction to only jump backwards (could
reuse CONTINUE_LOOP, but the name would be misleading).
continue statement is already handled this way, but break always uses
BREAK_LOOP.

Any comments are appreciated.

Regards,
Eugene

From raymond.hettinger at gmail.com  Sat Mar 12 03:28:54 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Fri, 11 Mar 2011 21:28:54 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive constant
	folding in the peephole optimizer)
Message-ID: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>

Today, there was a significant check-in to the peephole optimizer that I think should be reverted:
               http://hg.python.org/cpython/rev/14205d0fee45/

The peephole optimizer pre-dated the introduction of the abstract syntax tree.  Now that we have an AST, the preferred way to implement additional optimizations is with AST manipulation, upstream from code generation.  This approach is faster and much more reliable than the more brittle approach of disassembling, analyzing, and rewriting the bytecode created by the compiler.

There should no longer be any significant changes to the existing optimizer.  It took a good deal of care to get it right in the first place.  The code is stable and has been proven successful by many years of deployment.  The nature of the peephole optimizer  is that changes to it are high risk, that the procedure is brittle, and that it is easily mucked-up in ways that are hard to detect. Accordingly, we've kept to simple conservative transformations and have assiduously avoided more complex (and interesting) optimizations.

FWIW, I've been the maintainer (as well as the original designer and implementer) of the peephole optimizer from the beginning; however, today's committer did not accept my advice to be very conservative with changes to it and to strongly prefer AST transformations instead.  Please consider reverting this change.


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110311/e3956b40/attachment.html>

From alexander.belopolsky at gmail.com  Sat Mar 12 03:53:36 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Mar 2011 21:53:36 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
Message-ID: <AANLkTi=AZ3uscRKSzAh8NYkeGpHjYc9gWrucFQswhLZx@mail.gmail.com>

On Fri, Mar 11, 2011 at 9:28 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> Today, there was a significant check-in to the peephole optimizer that I
> think should be reverted:
> ?? ? ? ? ? ? ??http://hg.python.org/cpython/rev/14205d0fee45/

+1

I was going to comment on the corresponding issue #11244 more or less
supporting Raymond's arguments.  There is no end of optimization ideas
that can be implemented in peephole optimizer.  I know this first hand
having implemented several of those that have been ultimately
rejected.  At the end of the day, peephole optimizer is a hack that
predates proper AST design.  There is no need to continue squeezing
out last drops of juice from 10-year old technology when much better
approach is available with the modern design.

From benjamin at python.org  Sat Mar 12 04:01:47 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 11 Mar 2011 21:01:47 -0600
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
Message-ID: <AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>

2011/3/11 Raymond Hettinger <raymond.hettinger at gmail.com>:
> Today, there was a significant check-in to the peephole optimizer that I
> think should be reverted:
> ?? ? ? ? ? ? ??http://hg.python.org/cpython/rev/14205d0fee45/
> The peephole optimizer pre-dated the introduction of the abstract syntax
> tree. ?Now that we have an AST, the preferred way to implement?additional
> optimizations is with AST manipulation, upstream from code generation. ?This
> approach is faster and much more reliable than the more brittle approach
> of?disassembling, analyzing, and rewriting the bytecode created by the
> compiler.

The problem is no such AST optimizer exists. It's one thing avoid
changing old code because an improved version is in the works or
available (say argparse in lieu of getopt) and quite another when no
replacement code exists. At the moment, there is little reason not to
accept progressive improvements (with sights on overall design as
usual) to the code.

IMO, Ast or not ast statically optimizing python in any meaningful way
is a impossible task anyway. So, a better solution would be to just
rip the thing out.

> There should no longer be any significant changes to the existing
> optimizer.??It took a good deal of care to get it right in the first place.
> ?The code is stable and has been proven successful by many years of
> deployment. ?The nature of the peephole optimizer ?is that changes to it are
> high risk, that the procedure is brittle, and that it is easily mucked-up in
> ways that are hard to detect. Accordingly, we've kept to simple conservative
> transformations and have assiduously avoided more complex (and interesting)
> optimizations.

Can you point to examples where changes introduced long-term
instability? ISTM, that the peepholer is one of the better tested
parts of the interpreter if not directly from its own tests, from
running the entire stdlib tests.

> FWIW,?I've been the?maintainer (as well as the original designer and
> implementer) of the peephole optimizer from the beginning; however, today's
> committer did not accept my advice to be very conservative with changes to
> it and to strongly prefer AST transformations instead. ?Please consider
> reverting this change.



-- 
Regards,
Benjamin

From steve at pearwood.info  Sat Mar 12 04:09:32 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 12 Mar 2011 14:09:32 +1100
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
Message-ID: <4D7AE3EC.7080105@pearwood.info>

Thomas Wouters wrote:
> One of the things brought up at the language summit (and I believe at the VM
> summit, although I wasn't there) was the unpredictable behaviour of
> callables turning into methods when they're class attributes.
[...]
>  1. Make staticmethod a callable object directly (it isn't, currently) and
> apply it to any Python function that replaces a (in CPython) CFunction. The
> change to staticmethod may be a good idea regardless, but the policy of
> making other implementations comply to this quirk in CPython seems (to me)
> like unnecessary descrimination[*].

I've been bitten by the (to me) surprising fact that staticmethod 
objects are not directly callable. It's hard to write a method/function 
inside a class which is callable both when the class is being created, 
and afterwards, even though naively staticmethod seems like it should do 
the job. A toy example:


class Toy(object):
     @staticmethod
     def spam(n):
         return ' '.join(['spam']*n)
     lunch = spam(5) + "with a fried egg on top"


+1 on making staticmethods callable. I would have found that useful in 
the past.


>  4. Make it an error to have a callable class attribute that isn't a
> descriptor (although maybe we only discussed this one in my head.)

Do you mean to make one, or both, of these an error?

class C:
     spam = len

C.__dict__['ham'] = lambda: None




-- 
Steven


From guido at python.org  Sat Mar 12 04:38:48 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 11 Mar 2011 22:38:48 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
Message-ID: <AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>

I recall several occasions where the peephole optimizer was subtly
buggy -- on one occasion the bug remained undetected for at least a
whole release cycle. (Sorry, I can't recall the details.) In fact, the
bug reported in http://bugs.python.org/issue11244 is another example
of how subtle the peephole optimizer is. Adding more complexity to it
just increases the chances that it will be broken by seemingly
unrelated changes.

As far as Antoine's commit goes, it looks like it went in hastily,
without review, and before any discussion. Clearly it *is*
controversial, and controversial fixes always need to be held back
until at least rough consensus is reached or until a BDFL decision.
Also it is not a fix to the bug reported in the issue, so the
Misc/NEWS text is misleading. A much simpler fix was proposed in the
bug and even approved by Antoine. (One note on the patch: it allocates
an extra stack which is dynamically grown; but there is no unittest to
exercise the stack-growing code. This note does constitute a full
review.)

I have always felt uncomfortable with *any* kind of optimization --
whether AST-based or bytecode-based. I feel the cost in code
complexity is pretty high and in most cases the optimization is not
worth the effort. Also I don't see the point in optimizing expressions
like "3 * 4 * 5" in Python. In C, this type of thing occurs frequently
due to macro expansion and the like, but in Python your code usually
looks pretty silly if you write that. So this is basically a solution
to a non-problem. The only two places where I personally see a need
for compile-time optimization are unary minus (since there is no way
to write negative constants otherwise) and string literal
concatenation (which is a common way to break long string literals).

Now, should Antoine's checkin be rolled back? I think the case is in
Antoine's court to convince us that his patch is correct *and* to help
at least one or two others feel comfortable they understand how it
works -- if only Antoine understands it, it is too complex. If Antoine
does not succeed with this task he should roll it back. Or he can
choose to roll it back immediately, and then we can continue the
discussion under a lot less pressure, and come to a conclusion
amiably.

--Guido

On Fri, Mar 11, 2011 at 10:01 PM, Benjamin Peterson <benjamin at python.org> wrote:
> 2011/3/11 Raymond Hettinger <raymond.hettinger at gmail.com>:
>> Today, there was a significant check-in to the peephole optimizer that I
>> think should be reverted:
>> ?? ? ? ? ? ? ??http://hg.python.org/cpython/rev/14205d0fee45/
>> The peephole optimizer pre-dated the introduction of the abstract syntax
>> tree. ?Now that we have an AST, the preferred way to implement?additional
>> optimizations is with AST manipulation, upstream from code generation. ?This
>> approach is faster and much more reliable than the more brittle approach
>> of?disassembling, analyzing, and rewriting the bytecode created by the
>> compiler.
>
> The problem is no such AST optimizer exists. It's one thing avoid
> changing old code because an improved version is in the works or
> available (say argparse in lieu of getopt) and quite another when no
> replacement code exists. At the moment, there is little reason not to
> accept progressive improvements (with sights on overall design as
> usual) to the code.
>
> IMO, Ast or not ast statically optimizing python in any meaningful way
> is a impossible task anyway. So, a better solution would be to just
> rip the thing out.
>
>> There should no longer be any significant changes to the existing
>> optimizer.??It took a good deal of care to get it right in the first place.
>> ?The code is stable and has been proven successful by many years of
>> deployment. ?The nature of the peephole optimizer ?is that changes to it are
>> high risk, that the procedure is brittle, and that it is easily mucked-up in
>> ways that are hard to detect. Accordingly, we've kept to simple conservative
>> transformations and have assiduously avoided more complex (and interesting)
>> optimizations.
>
> Can you point to examples where changes introduced long-term
> instability? ISTM, that the peepholer is one of the better tested
> parts of the interpreter if not directly from its own tests, from
> running the entire stdlib tests.
>
>> FWIW,?I've been the?maintainer (as well as the original designer and
>> implementer) of the peephole optimizer from the beginning; however, today's
>> committer did not accept my advice to be very conservative with changes to
>> it and to strongly prefer AST transformations instead. ?Please consider
>> reverting this change.
>
>
>
> --
> Regards,
> Benjamin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)

From guido at python.org  Sat Mar 12 04:48:41 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 11 Mar 2011 22:48:41 -0500
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <4D7AE3EC.7080105@pearwood.info>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
	<4D7AE3EC.7080105@pearwood.info>
Message-ID: <AANLkTi=P-256xMJcsn5TWTCwuivGdKG4fh4Jjobg1wZR@mail.gmail.com>

On Fri, Mar 11, 2011 at 10:09 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> Thomas Wouters wrote:
>>
>> One of the things brought up at the language summit (and I believe at the
>> VM
>> summit, although I wasn't there) was the unpredictable behaviour of
>> callables turning into methods when they're class attributes.
>
> [...]
>>
>> ?1. Make staticmethod a callable object directly (it isn't, currently) and
>> apply it to any Python function that replaces a (in CPython) CFunction.
>> The
>> change to staticmethod may be a good idea regardless, but the policy of
>> making other implementations comply to this quirk in CPython seems (to me)
>> like unnecessary descrimination[*].
>
> I've been bitten by the (to me) surprising fact that staticmethod objects
> are not directly callable. It's hard to write a method/function inside a
> class which is callable both when the class is being created, and
> afterwards, even though naively staticmethod seems like it should do the
> job. A toy example:
>
>
> class Toy(object):
> ? ?@staticmethod
> ? ?def spam(n):
> ? ? ? ?return ' '.join(['spam']*n)
> ? ?lunch = spam(5) + "with a fried egg on top"
>
>
> +1 on making staticmethods callable. I would have found that useful in the
> past.

IIUC Thomas found that this breaks some current use of staticmethod.

>> ?4. Make it an error to have a callable class attribute that isn't a
>> descriptor (although maybe we only discussed this one in my head.)
>
> Do you mean to make one, or both, of these an error?
>
> class C:
> ? ?spam = len

Making this illegal is what #4 means, yes. But I find it unacceptable.

> C.__dict__['ham'] = lambda: None

This is already illegal (except for classic classes in Python 2). Also
lambda creates a standard function object so it *is* (or *has*?) a
descriptor.

-- 
--Guido van Rossum (python.org/~guido)

From eltoder at gmail.com  Sat Mar 12 05:11:17 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Fri, 11 Mar 2011 23:11:17 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
Message-ID: <AANLkTikwiu7TCRkCohoXdzHL6PUK7DjHNDxMUfBooQ71@mail.gmail.com>

Experience shows that optimizations are always error prone, no matter
what framework or internal representation you use. I don't think we
should assume that simply rewriting all optimizations to work on AST
will make them bug free once and for all. On the contrary, I think
such a rewrite will introduce some bugs of it's own.

The remedy against this is well known. Instead of being afraid to
touch the code we should add more tests and verifiers. If had written
tests are not enough, test generator that produces python programs
with different structures can be written. Such generators are used by
many compiler writers. For verifiers, a function that checks that
bytecode is sane (doesn't reference invalid names or consts, doesn't
jump between instructions, all joins have same stack depth? etc) that
runs after optimizer in debug builds can save a lot of time.

Eugene

From raymond.hettinger at gmail.com  Sat Mar 12 05:43:31 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Fri, 11 Mar 2011 23:43:31 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
	constant folding in the peephole optimizer)
In-Reply-To: <AANLkTikwiu7TCRkCohoXdzHL6PUK7DjHNDxMUfBooQ71@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTikwiu7TCRkCohoXdzHL6PUK7DjHNDxMUfBooQ71@mail.gmail.com>
Message-ID: <00D0D3B5-4ED2-4B06-A8B5-F9238F71D71F@gmail.com>


On Mar 11, 2011, at 11:11 PM, Eugene Toder wrote:

> Experience shows that optimizations are always error prone, no matter
> what framework or internal representation you use.

On that basis, I believe that we ought to declare peephole.c as being
somewhat off-limits for further development (except for small
adaptations if the underlying opcodes change meaning).

The code is stable and most of the low-hanging fruit has already been taken.

The bright ideas for other enhancements aren't actually new ideas.
They were considered at the outset and not included for a reason.
We were intentionally very conservative with the optimizer.


> I don't think we
> should assume that simply rewriting all optimizations to work on AST
> will make them bug free once and for all. On the contrary, I think
> such a rewrite will introduce some bugs of it's own.

You make an automatic truth when say, "I don't think we should assume X".

It would be more correct to say that peepholing is the wrong technique
for constant folding because:

1) much of the semantic information available the AST has been lost
by the time the bytecode is generated

2) peephole.c is having to disassemble the bytecode, reconstruct
semantic relationships as well as it can, recognize transformation
patterns and then regenerate bytecode.
Moving constant folding to the AST means that the disassembly and reassembly
don't have to be done and that more semantic information is available.

In other words, the two techniques are equal just because it is always
possible to make a mistake using any technique.


> The remedy against this is well known.
> Instead of being afraid to
> touch the code we should add more tests and verifiers.

Not really.  It is darned difficult to design tests to catch all the corner cases.
You've got wishful thinking if you think a handful of tests can catch
errors in code that sophisticated.  Look at GCC's bug history to get
a sense for what can go wrong with optimization.

I admire your and Antoine's enthusiasm for wanting to optimize,
but think your efforts are misdirected and that you should be
taking some advice from the guy who wrote thing in the first place.


Raymond


From eltoder at gmail.com  Sat Mar 12 06:39:55 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Sat, 12 Mar 2011 00:39:55 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <00D0D3B5-4ED2-4B06-A8B5-F9238F71D71F@gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTikwiu7TCRkCohoXdzHL6PUK7DjHNDxMUfBooQ71@mail.gmail.com>
	<00D0D3B5-4ED2-4B06-A8B5-F9238F71D71F@gmail.com>
Message-ID: <AANLkTimrr7Dy3xXeNe1tJb0vGvosJr8oHhxxxnMoY0En@mail.gmail.com>

>> Experience shows that optimizations are always error prone, no matter
>> what framework or internal representation you use.
>
> On that basis, I believe that we ought to declare peephole.c as being
> somewhat off-limits for further development (except for small
> adaptations if the underlying opcodes change meaning).

With this attitude, it would be more logical to remove the whole thing
completely. Even if you don't touch the optimizer, any changes in the
compiler can start producing code that exposes a previously hidden
bug.

> The bright ideas for other enhancements aren't actually new ideas.
> They were considered at the outset and not included for a reason.

It would help if these were documented.

> It would be more correct

How can you be more correct than tautological truth? :)

> 1) much of the semantic information available the AST has been lost
> by the time the bytecode is generated

Not really. Many systems use stack based bytecode as an intermediate
form and reconstruct different IRs from it. Examples are JVM, CLR and
PyPy.
The real problem with bytecode is that it's a representation optimized
for storage and interpretation. Transforming it is harder, less
efficient and more error-prone than transforming a tree structure. But
transformations of trees are in no way automatically bug free.

> 2) peephole.c is having to disassemble the bytecode, reconstruct
> semantic relationships as well as it can, recognize transformation
> patterns and then regenerate bytecode.

v8 does peephole directly on x86 machine code. No kittens were harmed.

Now, I do agree with you that moving optimizations to AST is a step
forward. Moving them to a specialized IR in SSA form would be even
better.
If there was a framework for AST-based optimizations in the current
code, I'd write my code to use it. However, I couldn't find it.

What I don't understand is why doing 90% of the work and refuse to do
the last 10%. Looking at the actual patches, I do not see significant
increase in complexity or code size -- all the complex cases are
already handled by existing code. In some cases the code became
cleaner and simpler.

> Not really. ?It is darned difficult to design tests to catch all the corner cases.

You either do that or do not write optimizations. No one said it should be easy.

> You've got wishful thinking if you think a handful of tests can catch
> errors in code that sophisticated.

Why limit yourself with a handful of tests? Python is widespread,
there's *a lot* of code in Python. Unlike with libraries, any code you
run tests the optimizer, so just run a lot of code. And, as I've said,
write a test generator.

Cheers,
Eugene

From cesare.di.mauro at gmail.com  Sat Mar 12 06:44:08 2011
From: cesare.di.mauro at gmail.com (Cesare Di Mauro)
Date: Sat, 12 Mar 2011 06:44:08 +0100
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
Message-ID: <AANLkTikA7TSOb+01h3HYgBpSwVj9JBAyrBOmmhRzdbmj@mail.gmail.com>

2011/3/12 Benjamin Peterson <benjamin at python.org>

> 2011/3/11 Raymond Hettinger <raymond.hettinger at gmail.com>:
> > Today, there was a significant check-in to the peephole optimizer that I
> > think should be reverted:
> >                http://hg.python.org/cpython/rev/14205d0fee45/
> > The peephole optimizer pre-dated the introduction of the abstract syntax
> > tree.  Now that we have an AST, the preferred way to implement additional
> > optimizations is with AST manipulation, upstream from code generation.
>  This
> > approach is faster and much more reliable than the more brittle approach
> > of disassembling, analyzing, and rewriting the bytecode created by the
> > compiler.
>
> The problem is no such AST optimizer exists. It's one thing avoid
> changing old code because an improved version is in the works or
> available (say argparse in lieu of getopt) and quite another when no
> replacement code exists. At the moment, there is little reason not to
> accept progressive improvements (with sights on overall design as
> usual) to the code.
>
> IMO, Ast or not ast statically optimizing python in any meaningful way
> is a impossible task anyway. So, a better solution would be to just
>  rip the thing out.
>
> --
> Regards,
> Benjamin


It's not true. I already moved almost all peephole optimizations
(introducing others, as well) from peephole.c to
ast.c<http://code.google.com/p/wpython2/source/browse/Python/ast.c?repo=wpython11>and
compiler.c<http://code.google.com/p/wpython2/source/browse/Python/compile.c?repo=wpython11>in
WPython 1.1.

Take a look at pages 21-23 of
this<http://wpython2.googlecode.com/files/Cleanup%20and%20new%20optimizations%20in%20WPython%201.1.pdf>
.

Also, optimizations can be done not only for numbers, but even for tuples,
lists, dictionaries, and... slices (pag. 22). See pages 21-24 of
this<http://wpython2.googlecode.com/files/Beyond%20Bytecode%20-%20A%20Wordcode-based%20Python.pdf>
.

Cesare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/17cc4ecd/attachment.html>

From ncoghlan at gmail.com  Sat Mar 12 06:44:41 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Mar 2011 00:44:41 -0500
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <AANLkTi=P-256xMJcsn5TWTCwuivGdKG4fh4Jjobg1wZR@mail.gmail.com>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
	<4D7AE3EC.7080105@pearwood.info>
	<AANLkTi=P-256xMJcsn5TWTCwuivGdKG4fh4Jjobg1wZR@mail.gmail.com>
Message-ID: <AANLkTinAG0fNWB_urV1qKUAx0_KFT55QjtcVSkEi94Jg@mail.gmail.com>

On Fri, Mar 11, 2011 at 10:48 PM, Guido van Rossum <guido at python.org> wrote:
>> +1 on making staticmethods callable. I would have found that useful in the
>> past.
>
> IIUC Thomas found that this breaks some current use of staticmethod.

>From his first post, I understood the compatibility issue to more be
the fact that even if we make it callable, it still needs to return
the underlying function from __get__ rather than itself. So making it
callable didn't break anything, but changing the behaviour of __get__
did.

So long as people follow the policy of applying staticmethod() when
stashing things they don't want to turn into methods in class
namespaces, that should be fine.

The difference between @staticmethod and a "@nondescriptor" decorator
that mimics CFunction behaviour would then largely be in whether or
not they implemented __get__ at all.

>>> hasattr(len, "__get__")
False
>>> hasattr(staticmethod(len), "__get__")
True
>>> staticmethod(len).__get__(type) is len
True
>>> set(dir(len)) - set(dir(staticmethod(len)))
{'__call__', '__name__', '__module__', '__self__'}
>>> set(dir(staticmethod(len))) - set(dir(len))
{'__func__', '__get__'}

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From steve at pearwood.info  Sat Mar 12 06:48:51 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 12 Mar 2011 16:48:51 +1100
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <AANLkTi=P-256xMJcsn5TWTCwuivGdKG4fh4Jjobg1wZR@mail.gmail.com>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
	<4D7AE3EC.7080105@pearwood.info>
	<AANLkTi=P-256xMJcsn5TWTCwuivGdKG4fh4Jjobg1wZR@mail.gmail.com>
Message-ID: <4D7B0943.3040605@pearwood.info>

Guido van Rossum wrote:

>> +1 on making staticmethods callable. I would have found that useful in the
>> past.
> 
> IIUC Thomas found that this breaks some current use of staticmethod.


As I understand it, Thomas found that having staticmethod callable AND 
have staticmethod.__get__ return self breaks code. His exact words were:

"With regards to changing staticmethod, in an earlier iteration of the 
patch I modified staticmethod to be directly callable *and* to return 
self in its tp_descr_get, and this had a side-effect I hadn't 
considered: code that used a staticmethod-wrapped object in any way 
other than calling it, broke."

I am suggesting that staticmethod should leave __get__ as is, but add a 
__call__ method equivalent to this:

def __call__(self, *args, **kwargs):
     func = self.__get__(self)
     return func(*args, **kwargs)

This won't fix the problem with inconsistent behaviour between C and 
Python callables in classes, but it will reduce the surprising fact that 
staticmethods aren't callable. Sure, it's easy enough to subclass 
staticmethod, but the fact that you need to is a gotcha.



> This is already illegal (except for classic classes in Python 2). Also
> lambda creates a standard function object so it *is* (or *has*?) a
> descriptor.

So it is. I learn something new.



-- 
Steven

From eltoder at gmail.com  Sat Mar 12 07:15:03 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Sat, 12 Mar 2011 01:15:03 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
Message-ID: <AANLkTikz7AoCXYbwFu4DXBuN5ZbCRDDRgE739e5wvZ3q@mail.gmail.com>

> One note on the patch: it allocates an extra stack which is dynamically grown;
> but there is no unittest to exercise the stack-growing code.

Isn't this doing it?

1.20 +        # Long tuples should be folded too.
1.21 +        asm = dis_single(repr(tuple(range(10000))))
1.22 +        # One LOAD_CONST for the tuple, one for the None return value
1.23 +        self.assertEqual(asm.count('LOAD_CONST'), 2)
1.24 +        self.assertNotIn('BUILD_TUPLE', asm)

Eugene

From steve at pearwood.info  Sat Mar 12 07:49:36 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 12 Mar 2011 17:49:36 +1100
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTikA7TSOb+01h3HYgBpSwVj9JBAyrBOmmhRzdbmj@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTikA7TSOb+01h3HYgBpSwVj9JBAyrBOmmhRzdbmj@mail.gmail.com>
Message-ID: <4D7B1780.4040004@pearwood.info>

Cesare Di Mauro wrote:

> Also, optimizations can be done not only for numbers, but even for tuples,
> lists, dictionaries, and... slices (pag. 22). See pages 21-24 of
> this<http://wpython2.googlecode.com/files/Beyond%20Bytecode%20-%20A%20Wordcode-based%20Python.pdf>

For the record, constant-folding, and the lack of it, does seem to come 
up in users' requests. Whether they *need* constant-folding or not, it 
seems that some people have come to expect it. E.g. see this recent 
thread on python-list:

http://code.activestate.com/lists/python-list/596506/



-- 
Steven


From eliben at gmail.com  Sat Mar 12 08:32:50 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Sat, 12 Mar 2011 09:32:50 +0200
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
Message-ID: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>

The devguide's recommendation is to "forward-port" changes withing a major
release line, i.e. if I need something in all 3.[123], then start with 3.1
and forward-port (by "hg merge <branch>") to 3.2 and then 3.3

Just to clarify - does this mean that all changesets that are applied to 3.2
eventually get to 3.3 as well? Since we just do "hg merge 3.2" in the 3.3
clone, I guess this must be true. But then what happens if there's a change
in 3.2 that shouldn't get into 3.3? (say a bug fix for a feature that has
disappeared)?

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/b463c9bc/attachment.html>

From nadeem.vawda at gmail.com  Sat Mar 12 09:10:05 2011
From: nadeem.vawda at gmail.com (Nadeem Vawda)
Date: Sat, 12 Mar 2011 10:10:05 +0200
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
In-Reply-To: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>
References: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>
Message-ID: <AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>

On Sat, Mar 12, 2011 at 9:32 AM, Eli Bendersky <eliben at gmail.com> wrote:
> The devguide's recommendation is to "forward-port" changes withing a major
> release line, i.e. if I need something in all 3.[123], then start with 3.1
> and forward-port (by "hg merge <branch>") to 3.2 and then 3.3
>
> Just to clarify - does this mean that all changesets that are applied to 3.2
> eventually get to 3.3 as well? Since we just do "hg merge 3.2" in the 3.3
> clone, I guess this must be true. But then what happens if there's a change
> in 3.2 that shouldn't get into 3.3? (say a bug fix for a feature that has
> disappeared)?

The "Note:" box two paragraphs down from
<http://docs.python.org/devguide/committing.html#porting-within-a-major-version>
explains how prevent a changeset from propagating: you do a dummy merge
where you revert the changes before committing. This marks the changeset from
3.2 as having been merged into default/3.3 without actually applying
the changes.

Nadeem

From nadeem.vawda at gmail.com  Sat Mar 12 10:03:29 2011
From: nadeem.vawda at gmail.com (Nadeem Vawda)
Date: Sat, 12 Mar 2011 11:03:29 +0200
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
In-Reply-To: <AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>
References: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>
	<AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>
Message-ID: <AANLkTinEM6ycw-ba5z2KJTmEEFrY9tk_QAtpv4MkgNUo@mail.gmail.com>

Hmm... it seems that the given instructions don't actually work. "hg
revert -a" fails,
saying that a specific revision needs to be provided. The command should be
"hg revert -ar default".

From solipsis at pitrou.net  Sat Mar 12 10:16:42 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 12 Mar 2011 10:16:42 +0100
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
Message-ID: <20110312101642.1699902d@pitrou.net>


Hello,

> I recall several occasions where the peephole optimizer was subtly
> buggy -- on one occasion the bug remained undetected for at least a
> whole release cycle. (Sorry, I can't recall the details.) In fact, the
> bug reported in http://bugs.python.org/issue11244 is another example
> of how subtle the peephole optimizer is.

Well, the regression stems from a commit in the ast code, not in the
peepholer code (and it's only a regression as in "misses an
optimization opportunity", not "produces bogus code").

The peepholer is actually not very subtle, and that's why it missed the
obvious optimization here.

> As far as Antoine's commit goes, it looks like it went in hastily,
> without review, and before any discussion. Clearly it *is*
> controversial, and controversial fixes always need to be held back
> until at least rough consensus is reached or until a BDFL decision.

I didn't get any comments against the patch before committing it, and
I trusted Eugene's comment that the second patch was fine (Eugene
proposed other, decent patches for the peepholer and thus seems
acquainted with the code). Also, as Eugene pointed out, running the
whole test suite in itself stresses the peepholer quite a bit if you
take care of removing pyc files beforehand (which the buildbots do).

Any further review is obviously welcome, as usual.

> Also it is not a fix to the bug reported in the issue, so the
> Misc/NEWS text is misleading. A much simpler fix was proposed in the
> bug and even approved by Antoine.

Well, the "much simpler fix" fixes a separate issue with -0; it is
orthogonal to the original issue, and doesn't fix it (Eugene should
probably have filed it it in a separate issue).

The patch I committed, OTOH, *is* a fix to the original issue (there's
even a test for that ;).
The fact that the fix implies a more general improvement to the
peepholer might be seen as an annoyance, or a benefit, depending on
your point of view (although I'm not sure why a general improvement
would be an annoyance).

> (One note on the patch: it allocates
> an extra stack which is dynamically grown; but there is no unittest to
> exercise the stack-growing code. This note does constitute a full
> review.)

As Eugene answered, there is actually an unittest for that.

> I have always felt uncomfortable with *any* kind of optimization --
> whether AST-based or bytecode-based. I feel the cost in code
> complexity is pretty high and in most cases the optimization is not
> worth the effort. Also I don't see the point in optimizing expressions
> like "3 * 4 * 5" in Python.

But then, as others pointed out, why don't we rip out the peepholer?
If it's fragile and doesn't serve a purpose, it doesn't deserve staying.

There is, by the way, recent history for adding optimizations to the
peepholer, which was even approved by Raymond:
http://bugs.python.org/issue6690
... so I'm not sure why there is opposition to fixing a regression,
when apparently new optimizations are uncontroversial.

> In C, this type of thing occurs frequently
> due to macro expansion and the like, but in Python your code usually
> looks pretty silly if you write that. So this is basically a solution
> to a non-problem.

The original issue was about constant-folding of tuples containing
negative numbers, which doesn't sound like an exotic situation. The
obvious solution (enabling propagation of constant-folding) also
entails constant-folding of arbitrarily complex expressions, which is
why I have added tests for it, and suitably described it in the
Misc/NEWS. Having more tests is always worthwhile IMO (even if we later
choose to change them for whatever reason).

> Now, should Antoine's checkin be rolled back? I think the case is in
> Antoine's court to convince us that his patch is correct *and* to help
> at least one or two others feel comfortable they understand how it
> works -- if only Antoine understands it, it is too complex.

I really don't think the patch is complicated. It adds a stack to
manage the current run of constants. This replaces the previous code
where that run of constants was implicitly managed through the "lastlc"
and "cumlc" variables and hand-computed indices into the bytecode; the
new approach seems less clumsy to me.

(Eugene apparently understood the patch, so hopefully I'm not alone :-))

Now, if a majority is in favour of rolling it back ("backout" in
hg terminology), let's do it. That regression obviously isn't
killing anyone. Should we ask for a vote?

Regards

Antoine.

From dickinsm at gmail.com  Sat Mar 12 11:07:22 2011
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sat, 12 Mar 2011 10:07:22 +0000
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <20110312101642.1699902d@pitrou.net>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
Message-ID: <AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>

FWIW, I'm -1 on backing out Antoine's patch.  In addition to fixing
the minor optimization regression, it makes the peepholer
significantly more consistent in what it can and can't fold.  One of
the first times that I delved into the peepholer code was to try to
understand why expressions like:  2 * 3 * 4 and 3**2 * 7 were constant
folded, when 2 * (3 * 4) and 7 * 3**2 were not;  with Antoine's patch,
they're all folded.  That both Antoine and Eugene are happy with the
code gives me confidence in its correctness.

I can also see the case for ripping out the peepholer entirely.  But
reverting Antoine's patch seems like a step backwards.

Mark

From solipsis at pitrou.net  Sat Mar 12 11:59:01 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 12 Mar 2011 11:59:01 +0100
Subject: [Python-Dev] The purpose of SETUP_LOOP, BREAK_LOOP,
	CONTINUE_LOOP
References: <AANLkTikvBCMO7oNYKMwPKZ0-o6x38FmxatYVBmAy-w-p@mail.gmail.com>
Message-ID: <20110312115901.5389fe69@pitrou.net>


Hello,

> Am I missing something? Does SETUP_LOOP serve any other purpose?

Not to my knowledge.

> Similarly, it looks like BREAK_LOOP and CONTINUE_LOOP are just jumps
> that respect try/finally blocks (i.e. jumping out of try executes
> finally). Is there more semantics to them than this?

There are also "with" blocks :-) (which use separate opcodes, although
they are similar in principle to try/finally blocks)

> 1) If not in try/finally, simply generate a direct jump outside of the
> loop (break) or to the start of the loop (continue).

Right.

> 2) If in try/finally, generate a new instruction JUMP_FROM_TRY which
> replaces both BREAK_LOOP and CONTINUE_LOOP. It behaves the same way as
> CONTINUE_LOOP but without restriction to only jump backwards (could
> reuse CONTINUE_LOOP, but the name would be misleading).

There may be complications with nested try/finally blocks. You either
need to generate separate bytecode for when the "finally" clause is
entered following a given continue/break (so as to hardcode the jump
offset at the end of the clause), or save the jump offsets somewhere on
a stack for each finally clause to pop, IMO.

(the current code does the latter with various complications, see
WITH_CLEANUP for some aspects of the fun)

Regards

Antoine.



From ncoghlan at gmail.com  Sat Mar 12 12:28:04 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Mar 2011 06:28:04 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>
Message-ID: <AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>

On Sat, Mar 12, 2011 at 5:07 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
> I can also see the case for ripping out the peepholer entirely. ?But
> reverting Antoine's patch seems like a step backwards.

+1 to what Mark says here.

If the day comes when the peepholer can be ripped out in favour of AST
based optimisation, then yay. In the meantime, having it work as
consistently as possible in picking up and optimising literal
expressions makes for potentially valuable micro-optimisations that
people don't have to worry about doing by hand.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Sat Mar 12 12:29:16 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Mar 2011 06:29:16 -0500
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
In-Reply-To: <AANLkTinEM6ycw-ba5z2KJTmEEFrY9tk_QAtpv4MkgNUo@mail.gmail.com>
References: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>	<AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>
	<AANLkTinEM6ycw-ba5z2KJTmEEFrY9tk_QAtpv4MkgNUo@mail.gmail.com>
Message-ID: <4D7B590C.309@v.loewis.de>

Am 12.03.11 04:03, schrieb Nadeem Vawda:
> Hmm... it seems that the given instructions don't actually work. "hg
> revert -a" fails,
> saying that a specific revision needs to be provided. The command should be
> "hg revert -ar default".

Isn't that command correct only if you are merging into default?
ISTM that it should be "hg revert -ar <targetbranch>".

Regards,
Martin

From doug.hellmann at gmail.com  Sat Mar 12 12:37:16 2011
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Sat, 12 Mar 2011 06:37:16 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
	it's too late" (was: PyCObject_AsVoidPtr removed from python
	3.2 - is this documented?)
In-Reply-To: <AANLkTikG+SXAKZ3oAVPzzr1hAYyPcckj11SLoi5ROyfR@mail.gmail.com>
References: <AANLkTim5o-zGFshQFCVzUW5koxRoLchd8rbiCHzXz7zf@mail.gmail.com>
	<AANLkTimpHrVnz4QfnkkhbauwvBOd0HBXRrm-B8NyHPbe@mail.gmail.com>
	<AANLkTikG+SXAKZ3oAVPzzr1hAYyPcckj11SLoi5ROyfR@mail.gmail.com>
Message-ID: <01DC265B-82B5-4A96-9692-854AC5CBEFC8@gmail.com>


On Mar 11, 2011, at 7:12 PM, Paul Moore wrote:

> On 11 March 2011 23:24, Guido van Rossum <guido at python.org> wrote:
>>> I'm interested in the task and I guess I'll follow-up with Doug Hellman. I
>>> don't follow -ideas close enough to summarize it, but I'd contribute to a
>>> -dev blog.
>> 
>> Awesome! (And we don't need to stop at one blogger. Many hands make light work.)
> 
> I'm interested but probably haven't got time to take something like
> this on "properly". Helping out occasionally would probably be
> something I could do, though. (Was that tentative enough? :-)) I'm on
> -ideas, too, so I could do something there as well.

Thanks Brian and Paul! I have sent you both invitations to join the communications team mailing list so we can work out the details.

Doug


From ncoghlan at gmail.com  Sat Mar 12 12:43:50 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Mar 2011 06:43:50 -0500
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
	(and those that are!)
Message-ID: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>

I posted my rough notes and additional write-ups for Wednesday's VM
summit and Thursday's language summit:

http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
http://www.boredomandlaziness.org/2011/03/python-vm-summit-somewhat-coherent.html
http://www.boredomandlaziness.org/2011/03/python-language-summit-rough-notes.html
http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html

I believe Brian Curtin will also be posting a write-up for Thursday,
but I don't know if that is online anywhere yet.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From john.arbash.meinel at gmail.com  Sat Mar 12 14:21:15 2011
From: john.arbash.meinel at gmail.com (John Arbash Meinel)
Date: Sat, 12 Mar 2011 14:21:15 +0100
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
Message-ID: <4D7B734B.1030505@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

> I have always felt uncomfortable with *any* kind of optimization --
> whether AST-based or bytecode-based. I feel the cost in code
> complexity is pretty high and in most cases the optimization is not
> worth the effort. Also I don't see the point in optimizing expressions
> like "3 * 4 * 5" in Python. In C, this type of thing occurs frequently
> due to macro expansion and the like, but in Python your code usually
> looks pretty silly if you write that. 

Just as a side comment here, I often do this sort of thing when dealing
with time based comments, or large constants. It is a bit more obvious that:
 10*1024*1024 vs 10485760 is 10MiB
especially since you can't put commas in your constants. 10,485,760
would at least make it immediately obvious it was 10M not 104M or
something else.

Similarly is 10,800s 3 hours? 3*60*60 certainly is.

I don't think I've done that sort of thing in anything performance
critical. But I did want to point out that writing "X*Y*Z" as a constant
isn't always "pretty silly".

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk17c0sACgkQJdeBCYSNAAMUrQCdEhissWuvTElIc6Wy/2qotzaU
xz4AnRO+ND/3NkKWC7Bbu78ACjs2X920
=QR/2
-----END PGP SIGNATURE-----

From eltoder at gmail.com  Sat Mar 12 14:25:04 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Sat, 12 Mar 2011 08:25:04 -0500
Subject: [Python-Dev] The purpose of SETUP_LOOP, BREAK_LOOP,
	CONTINUE_LOOP
In-Reply-To: <20110312115901.5389fe69@pitrou.net>
References: <AANLkTikvBCMO7oNYKMwPKZ0-o6x38FmxatYVBmAy-w-p@mail.gmail.com>
	<20110312115901.5389fe69@pitrou.net>
Message-ID: <AANLkTimbqSFsz5hqLqunfd2LaYuf2NLBRdCqqmVRcc5R@mail.gmail.com>

> There are also "with" blocks :-) (which use separate opcodes, although
> they are similar in principle to try/finally blocks)

IIUC they use separate opcode, but the same block type (SETUP_FINALLY).

> There may be complications with nested try/finally blocks. You either
> need to generate separate bytecode for when the "finally" clause is
> entered following a given continue/break (so as to hardcode the jump
> offset at the end of the clause), or save the jump offsets somewhere on
> a stack for each finally clause to pop, IMO.

Right, I'm not suggesting to remove all blocks, only SETUP_LOOP
blocks. Do you see the problem in that case?

Eugene

From lac at openend.se  Sat Mar 12 14:33:20 2011
From: lac at openend.se (Laura Creighton)
Date: Sat, 12 Mar 2011 14:33:20 +0100
Subject: [Python-Dev] About raising NotPortableWarning for CPython specific
	code
Message-ID: <201103121333.p2CDXKW0032170@theraft.openend.se>

For those of you not at the Language Summit at PyCON the day before yesterday,
there was talk of identifying non-portable behaviour, such as relying on
CPython's reference counting garbage collector to close files for you as
soon as they become unreachable.  And then warning about them.

We have a real live user who has a large code base that relies on
the CPython behaviour that an object's __radd__ method will take precedence
over a list's inplace add behaviour.

The thread with the whole gory details begins here:
http://codespeak.net/pipermail/pypy-dev/2011q1/006958.html

My inclination is to declare code that relies on this as broken, rather
than patch every wretched container type in PyPy.  Can this become 
blessed as a 'you shouldn't have done this'?

Laura


From ncoghlan at gmail.com  Sat Mar 12 14:59:13 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Mar 2011 08:59:13 -0500
Subject: [Python-Dev] About raising NotPortableWarning for CPython
 specific code
In-Reply-To: <201103121333.p2CDXKW0032170@theraft.openend.se>
References: <201103121333.p2CDXKW0032170@theraft.openend.se>
Message-ID: <AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>

On Sat, Mar 12, 2011 at 8:33 AM, Laura Creighton <lac at openend.se> wrote:
> For those of you not at the Language Summit at PyCON the day before yesterday,
> there was talk of identifying non-portable behaviour, such as relying on
> CPython's reference counting garbage collector to close files for you as
> soon as they become unreachable. ?And then warning about them.
>
> We have a real live user who has a large code base that relies on
> the CPython behaviour that an object's __radd__ method will take precedence
> over a list's inplace add behaviour.
>
> The thread with the whole gory details begins here:
> http://codespeak.net/pipermail/pypy-dev/2011q1/006958.html
>
> My inclination is to declare code that relies on this as broken, rather
> than patch every wretched container type in PyPy. ?Can this become
> blessed as a 'you shouldn't have done this'?

Given that the meat of the difference in semantics lies in the
CPython-specific distinction between nb_add and sq_concat, I'm
inclined to agree with you.

I'm actually tempted to call the current CPython semantics flatout
*wrong*. When a given operation has multiple C level slots, shouldn't
we be checking all the LHS slots before checking any of the RHS slots?
There's nothing in the language spec that I'm aware of that justifies
us doing otherwise.

(obviously, history now means that changing our behaviour would
require a deprecation period)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From eric at trueblade.com  Sat Mar 12 15:26:12 2011
From: eric at trueblade.com (Eric Smith)
Date: Sat, 12 Mar 2011 09:26:12 -0500
Subject: [Python-Dev] Python 3.4 version in the tracker
Message-ID: <4D7B8284.4040202@trueblade.com>

Could someone with the right access add a "Python 3.4" version to the 
tracker? I have a deprecation warning that I need to make an error in 3.4.

I'd also like to make it a release blocker in 3.4 so I don't forget 
about it. If I do that, will it screw up any release workflow?

Thanks.

From rosslagerwall at gmail.com  Sat Mar 12 15:41:02 2011
From: rosslagerwall at gmail.com (Ross Lagerwall)
Date: Sat, 12 Mar 2011 16:41:02 +0200
Subject: [Python-Dev] Introductions
In-Reply-To: <1299396471.3699.3.camel@localhost.localdomain>
References: <1299396471.3699.3.camel@localhost.localdomain>
Message-ID: <1299940862.1632.7.camel@hobo>

Hi,

I have been offered commit rights for Python after making a few patches
on subprocess and the os module.

Antoine suggested that I should introduce myself on the python-dev list
so here we go:

I am a student from South Africa and decided to do some work on Python
in my spare time. I think I chose the Python project because it
definitely seems to be one of the friendliest projects around and the
easiest to get started with - the dev guide helps a lot! Also, with the
big standard library, there is place for people with all different
levels of experience to contribute.

Cheers
Ross


From martin at v.loewis.de  Sat Mar 12 16:11:45 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Mar 2011 10:11:45 -0500
Subject: [Python-Dev] Python 3.4 version in the tracker
In-Reply-To: <4D7B8284.4040202@trueblade.com>
References: <4D7B8284.4040202@trueblade.com>
Message-ID: <4D7B8D31.3010107@v.loewis.de>

Am 12.03.11 09:26, schrieb Eric Smith:
> Could someone with the right access add a "Python 3.4" version to the
> tracker?

Done.

> I'd also like to make it a release blocker in 3.4 so I don't forget
> about it. If I do that, will it screw up any release workflow?

I don't think so. As release managers can easily find out, they
tend to switch those to "deferred blocker" just before a release,
and switch them back afterwards.

Regards,
Martin

From merwok at netwok.org  Sat Mar 12 16:55:30 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 12 Mar 2011 16:55:30 +0100
Subject: [Python-Dev] Python 3.4 version in the tracker
In-Reply-To: <4D7B8284.4040202@trueblade.com>
References: <4D7B8284.4040202@trueblade.com>
Message-ID: <4D7B9772.3010803@netwok.org>

> I have a deprecation warning that I need to make an error in 3.4.

A neat trick to remember to do those changes is using a test that fails
if something does not raise a DeprecationWarning if sys.version_info[:2]
== (3, 3), or an error if sys.version_info[:3] == (3, 4).  You write
those tests once and let ?make test? remind you as soon as the Python
version changes.

Regards

From lukas.lueg at googlemail.com  Sat Mar 12 16:13:49 2011
From: lukas.lueg at googlemail.com (Lukas Lueg)
Date: Sat, 12 Mar 2011 16:13:49 +0100
Subject: [Python-Dev] Builtin open() too slow
Message-ID: <AANLkTikRZdLtb3RLeuYXqvp44urLnsH7NmweU=zKHs6H@mail.gmail.com>

Hi,

i've a storage engine that stores a lot of files (e.g. > 10.000) in
one path. Running the code under cProfile, I found that with a total
CPU-time of 1,118 seconds, 121 seconds are spent in 27.013 calls to
open(). The number of calls is not the problem; however I find it
*very* discomforting that Python spends about 2 minutes out of 18
minutes of cpu time just to get a file-handle after which it can spend
some other time to read from them.

May this be a problem with the way Python 2.7 gets filehandles from
the OS or is it a problem with large directories itself?

Best regards
Lukas

From solipsis at pitrou.net  Sat Mar 12 16:58:29 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 12 Mar 2011 16:58:29 +0100
Subject: [Python-Dev] Python 3.4 version in the tracker
References: <4D7B8284.4040202@trueblade.com>
	<4D7B9772.3010803@netwok.org>
Message-ID: <20110312165829.1f4e90d5@pitrou.net>

On Sat, 12 Mar 2011 16:55:30 +0100
?ric Araujo <merwok at netwok.org> wrote:
> > I have a deprecation warning that I need to make an error in 3.4.
> 
> A neat trick to remember to do those changes is using a test that fails
> if something does not raise a DeprecationWarning if sys.version_info[:2]
> == (3, 3), or an error if sys.version_info[:3] == (3, 4).  You write
> those tests once and let ?make test? remind you as soon as the Python
> version changes.

And magically break all the buildbots :)

Regards

Antoine.



From eltoder at gmail.com  Sat Mar 12 17:03:43 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Sat, 12 Mar 2011 11:03:43 -0500
Subject: [Python-Dev] Builtin open() too slow
In-Reply-To: <AANLkTikRZdLtb3RLeuYXqvp44urLnsH7NmweU=zKHs6H@mail.gmail.com>
References: <AANLkTikRZdLtb3RLeuYXqvp44urLnsH7NmweU=zKHs6H@mail.gmail.com>
Message-ID: <AANLkTinmWHORVWw-w=Po=nC5usF_e2rX_DPShVUgcYsQ@mail.gmail.com>

Hi

What OS and what file system you are using? Many file systems (e,g.
ext2/3fs) handle large directories very poorly.
A quick way to check if this has anything to do with Python is writing
a small C program that opens these files and time it.

Eugene

On Sat, Mar 12, 2011 at 10:13 AM, Lukas Lueg <lukas.lueg at googlemail.com> wrote:
> Hi,
>
> i've a storage engine that stores a lot of files (e.g. > 10.000) in
> one path. Running the code under cProfile, I found that with a total
> CPU-time of 1,118 seconds, 121 seconds are spent in 27.013 calls to
> open(). The number of calls is not the problem; however I find it
> *very* discomforting that Python spends about 2 minutes out of 18
> minutes of cpu time just to get a file-handle after which it can spend
> some other time to read from them.
>
> May this be a problem with the way Python 2.7 gets filehandles from
> the OS or is it a problem with large directories itself?
>
> Best regards
> Lukas
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/eltoder%40gmail.com
>

From raymond.hettinger at gmail.com  Sat Mar 12 17:05:38 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 12 Mar 2011 11:05:38 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
	constant folding in the peephole optimizer)
In-Reply-To: <AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>
	<AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>
Message-ID: <795F80F1-CB8F-41D0-B5C3-910E4C81D906@gmail.com>

There are separate social, strategic, and tactical questions.

The social question:  if the person who designed, implemented, and maintained the optimizer recommends against a patch and another committer just checks it in anyway, do we care?  I've taken responsibility for this code and have treated it will a good deal of care.  I don't believe the patch should go in because the risk/reward ratio is too low and because a better solution exists.

The strategic question:  constant folding in the peephole optimizer pre-dates the AST branch.  When AST landed, there was general agreement among myself and those involved that any future optimizations which could be done with the AST, should be done there.  It is the correct technological solution.  

At one point, we had strategic agreement to stop building-out the peepholer in any significant way.   In fairness to Antoine, the conversations took place several years before he became a committer.  The strategic question is do we want to come to that agreement again?  Can we agree to not have significant changes to the peepholer, to treat it with great care and restraint?   This patch doesn't have to go in.  Py3.3 won't be out for 18 to 24 months anyway.  There is a lot of time to do the job right and not add weight to a house of cards.

The tactical question:  is this particular patch correct?  Maybe it is.  I don't know, I didn't get past all the new macros.  I do know that I could have whipped up something similar years ago but chose not to based on advice from Thomas, Andrew, Tim, and Guido.   The only change since then is that there is a newer committer doesn't buy into that reasoning.

Constant folding is the most complex part of the optimizer.  Why would we add to it, when a better and more reliable approach exists?  The patch hasn't even been demonstrated to be necessary in any real-world code.  


Raymond


From merwok at netwok.org  Sat Mar 12 17:08:34 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 12 Mar 2011 17:08:34 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
Message-ID: <4D7B9A82.6070309@netwok.org>

Hi,

> I posted my rough notes and additional write-ups for Wednesday's VM
> summit and Thursday's language summit:

Thanks for doing that!

About this bit from the VM meeting notes:
  - original Python-on-Parrot ran into problems due to semantic
  mismatches between Perl 6 and Python - reached the limits of the
  degree of difference the Perl 6 toolchain was willing to tolerate)

Would you have any pointers to more info about that?

Regards

From eric at trueblade.com  Sat Mar 12 17:09:18 2011
From: eric at trueblade.com (Eric Smith)
Date: Sat, 12 Mar 2011 11:09:18 -0500
Subject: [Python-Dev] Python 3.4 version in the tracker
In-Reply-To: <4D7B9772.3010803@netwok.org>
References: <4D7B8284.4040202@trueblade.com> <4D7B9772.3010803@netwok.org>
Message-ID: <4D7B9AAE.9060909@trueblade.com>

On 03/12/2011 10:55 AM, ?ric Araujo wrote:
>> I have a deprecation warning that I need to make an error in 3.4.
>
> A neat trick to remember to do those changes is using a test that fails
> if something does not raise a DeprecationWarning if sys.version_info[:2]
> == (3, 3), or an error if sys.version_info[:3] == (3, 4).  You write
> those tests once and let ?make test? remind you as soon as the Python
> version changes.

I like the idea, but it seems a little hostile to the person who 
actually changes the version number!

Eric.

From lists at cheimes.de  Sat Mar 12 17:14:27 2011
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 12 Mar 2011 17:14:27 +0100
Subject: [Python-Dev] Builtin open() too slow
In-Reply-To: <AANLkTikRZdLtb3RLeuYXqvp44urLnsH7NmweU=zKHs6H@mail.gmail.com>
References: <AANLkTikRZdLtb3RLeuYXqvp44urLnsH7NmweU=zKHs6H@mail.gmail.com>
Message-ID: <ilg654$2rb$1@dough.gmane.org>

Am 12.03.2011 16:13, schrieb Lukas Lueg:
> i've a storage engine that stores a lot of files (e.g. > 10.000) in
> one path. Running the code under cProfile, I found that with a total
> CPU-time of 1,118 seconds, 121 seconds are spent in 27.013 calls to
> open(). The number of calls is not the problem; however I find it
> *very* discomforting that Python spends about 2 minutes out of 18
> minutes of cpu time just to get a file-handle after which it can spend
> some other time to read from them.
> 
> May this be a problem with the way Python 2.7 gets filehandles from
> the OS or is it a problem with large directories itself?

Your issue is most like not a Python bug. The open() function in 2.7 is
a thin wrapper around fopen(3). You didn't tell us how you profiled your
program and what's your operating system, configuration (file system)
and hardware. Are you sure you have measured two CPU minutes and not two
minutes runtime mostly spent in I/O?

Recently I've seen a system that sometimes takes more than a minute or
two just to create and remove 16 files in 16 directories on a remote NFS
cluster. 10k files in one directory are not a bottleneck, if you use a
good file system (XFS, ext* with hashed btree index). I've over a
million files in one directory because it's as fast as 1000 directories
with 1000 files each for all my performance relevant operations --
sometimes even faster.

Christian


From ncoghlan at gmail.com  Sat Mar 12 17:17:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Mar 2011 11:17:17 -0500
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <4D7B9A82.6070309@netwok.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<4D7B9A82.6070309@netwok.org>
Message-ID: <AANLkTimmCL9FrFpakkQNJH5mo6F9_s5y7Uz5-WPLYDmH@mail.gmail.com>

On Sat, Mar 12, 2011 at 11:08 AM, ?ric Araujo <merwok at netwok.org> wrote:
> Hi,
>
>> I posted my rough notes and additional write-ups for Wednesday's VM
>> summit and Thursday's language summit:
>
> Thanks for doing that!
>
> About this bit from the VM meeting notes:
> ?- original Python-on-Parrot ran into problems due to semantic
> ?mismatches between Perl 6 and Python - reached the limits of the
> ?degree of difference the Perl 6 toolchain was willing to tolerate)
>
> Would you have any pointers to more info about that?

No, it was something Allison Randal said during the summit. I don't if
anything more detailed has been written about the topic anywhere else.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From raymond.hettinger at gmail.com  Sat Mar 12 19:08:26 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 12 Mar 2011 13:08:26 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
	constant folding in the peephole optimizer)
In-Reply-To: <20110312101642.1699902d@pitrou.net>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
Message-ID: <B6E14BD9-DCFF-45E9-BCF8-F2386CE42998@gmail.com>

I would like to withdraw my suggestion for the recursive constant folding patch to be reverted.  I value social harmony much more than a decision about whether a particular patch is a good idea.  I apologize to anyone who is upset over the discussion.


Raymond

From martin at v.loewis.de  Sat Mar 12 19:14:26 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Mar 2011 13:14:26 -0500
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
Message-ID: <4D7BB802.9060200@v.loewis.de>

> http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
> http://www.boredomandlaziness.org/2011/03/python-vm-summit-somewhat-coherent.html

Wrt. the remark that other implementations should be referenced more 
prominently: I added them to

http://www.python.org/download/

Regards,
Martin

From guido at python.org  Sat Mar 12 19:41:13 2011
From: guido at python.org (Guido van Rossum)
Date: Sat, 12 Mar 2011 13:41:13 -0500
Subject: [Python-Dev] About raising NotPortableWarning for CPython
 specific code
In-Reply-To: <AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>
References: <201103121333.p2CDXKW0032170@theraft.openend.se>
	<AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>
Message-ID: <AANLkTimiQfKtUoLpHZsjcaehyXLQudKAqfPO5WmCp+pS@mail.gmail.com>

On Sat, Mar 12, 2011 at 8:59 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, Mar 12, 2011 at 8:33 AM, Laura Creighton <lac at openend.se> wrote:
>> For those of you not at the Language Summit at PyCON the day before yesterday,
>> there was talk of identifying non-portable behaviour, such as relying on
>> CPython's reference counting garbage collector to close files for you as
>> soon as they become unreachable. ?And then warning about them.
>>
>> We have a real live user who has a large code base that relies on
>> the CPython behaviour that an object's __radd__ method will take precedence
>> over a list's inplace add behaviour.
>>
>> The thread with the whole gory details begins here:
>> http://codespeak.net/pipermail/pypy-dev/2011q1/006958.html
>>
>> My inclination is to declare code that relies on this as broken, rather
>> than patch every wretched container type in PyPy. ?Can this become
>> blessed as a 'you shouldn't have done this'?
>
> Given that the meat of the difference in semantics lies in the
> CPython-specific distinction between nb_add and sq_concat, I'm
> inclined to agree with you.
>
> I'm actually tempted to call the current CPython semantics flatout
> *wrong*. When a given operation has multiple C level slots, shouldn't
> we be checking all the LHS slots before checking any of the RHS slots?
> There's nothing in the language spec that I'm aware of that justifies
> us doing otherwise.
>
> (obviously, history now means that changing our behaviour would
> require a deprecation period)

Yeah, indeed, on everything you said. The code dispatching based on
internal slots is horribly ad-hoc and likely wrong in subtle ways. Has
any of this improved in Python 3?

-- 
--Guido van Rossum (python.org/~guido)

From allison at python.org  Sat Mar 12 19:42:52 2011
From: allison at python.org (Allison Randal)
Date: Sat, 12 Mar 2011 13:42:52 -0500
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTimmCL9FrFpakkQNJH5mo6F9_s5y7Uz5-WPLYDmH@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<4D7B9A82.6070309@netwok.org>
	<AANLkTimmCL9FrFpakkQNJH5mo6F9_s5y7Uz5-WPLYDmH@mail.gmail.com>
Message-ID: <4D7BBEAC.7060803@python.org>

On 03/12/2011 11:17 AM, Nick Coghlan wrote:
>> About this bit from the VM meeting notes:
>>   - original Python-on-Parrot ran into problems due to semantic
>>   mismatches between Perl 6 and Python - reached the limits of the
>>   degree of difference the Perl 6 toolchain was willing to tolerate)
>>
>> Would you have any pointers to more info about that?
>
> No, it was something Allison Randal said during the summit. I don't if
> anything more detailed has been written about the topic anywhere else.

I haven't posted/written about it anywhere yet. Happy to answer any 
questions, probably off-list so as not to bore people here. :) If the 
questions are particularly insightful, I might convert it directly into 
a Q&A blog post.

Allison

From guido at python.org  Sat Mar 12 19:43:50 2011
From: guido at python.org (Guido van Rossum)
Date: Sat, 12 Mar 2011 13:43:50 -0500
Subject: [Python-Dev] Introductions
In-Reply-To: <1299940862.1632.7.camel@hobo>
References: <1299396471.3699.3.camel@localhost.localdomain>
	<1299940862.1632.7.camel@hobo>
Message-ID: <AANLkTimtMnW=Ay8Re1zQGMJ7MTUjSCu9RxoKWC4WW-vn@mail.gmail.com>

Welcome Ross! Glad you like the new dev guide. (Brett and the
community should be proud of their recent work on that.) Remember,
there are no stupid questions. And while occasionally it may appear as
if someone tries to bite your head off, our bite is not as bad as our
bark.

--Guido

On Sat, Mar 12, 2011 at 9:41 AM, Ross Lagerwall <rosslagerwall at gmail.com> wrote:
> Hi,
>
> I have been offered commit rights for Python after making a few patches
> on subprocess and the os module.
>
> Antoine suggested that I should introduce myself on the python-dev list
> so here we go:
>
> I am a student from South Africa and decided to do some work on Python
> in my spare time. I think I chose the Python project because it
> definitely seems to be one of the friendliest projects around and the
> easiest to get started with - the dev guide helps a lot! Also, with the
> big standard library, there is place for people with all different
> levels of experience to contribute.
>
> Cheers
> Ross
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)

From tjreedy at udel.edu  Sat Mar 12 19:55:08 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Mar 2011 13:55:08 -0500
Subject: [Python-Dev] Introductions
In-Reply-To: <1299940862.1632.7.camel@hobo>
References: <1299396471.3699.3.camel@localhost.localdomain>
	<1299940862.1632.7.camel@hobo>
Message-ID: <ilgfi7$g1f$1@dough.gmane.org>

On 3/12/2011 9:41 AM, Ross Lagerwall wrote:
> Hi,
>
> I have been offered commit rights for Python after making a few patches
> on subprocess and the os module.
>
> Antoine suggested that I should introduce myself on the python-dev list
> so here we go:
>
> I am a student from South Africa and decided to do some work on Python
> in my spare time. I think I chose the Python project because it
> definitely seems to be one of the friendliest projects around and the
> easiest to get started with - the dev guide helps a lot! Also, with the
> big standard library, there is place for people with all different
> levels of experience to contribute.

Great to have you with us!

-- 
Terry Jan Reedy


From fijall at gmail.com  Sat Mar 12 20:02:28 2011
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 12 Mar 2011 14:02:28 -0500
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <4D7BB802.9060200@v.loewis.de>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<4D7BB802.9060200@v.loewis.de>
Message-ID: <AANLkTimRLrWDbRmFOWiKCpzH=ojAmvkHisXS_XeigCnx@mail.gmail.com>

On Sat, Mar 12, 2011 at 1:14 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>
>> http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
>>
>> http://www.boredomandlaziness.org/2011/03/python-vm-summit-somewhat-coherent.html
>
> Wrt. the remark that other implementations should be referenced more
> prominently: I added them to
>
> http://www.python.org/download/

Cool. Would you mind mentioning JIT for PyPy in description?

>
> Regards,
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

From pje at telecommunity.com  Sat Mar 12 20:04:07 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 12 Mar 2011 14:04:07 -0500
Subject: [Python-Dev] The purpose of SETUP_LOOP, BREAK_LOOP,
 CONTINUE_LOOP
In-Reply-To: <AANLkTimbqSFsz5hqLqunfd2LaYuf2NLBRdCqqmVRcc5R@mail.gmail.c
 om>
References: <AANLkTikvBCMO7oNYKMwPKZ0-o6x38FmxatYVBmAy-w-p@mail.gmail.com>
	<20110312115901.5389fe69@pitrou.net>
	<AANLkTimbqSFsz5hqLqunfd2LaYuf2NLBRdCqqmVRcc5R@mail.gmail.com>
Message-ID: <20110312190422.20EF03A4077@sparrow.telecommunity.com>

At 08:25 AM 3/12/2011 -0500, Eugene Toder wrote:
>Right, I'm not suggesting to remove all blocks, only SETUP_LOOP
>blocks. Do you see the problem in that case?

I think you guys are forgetting about FOR_ITER, listcomps, and the like.

That is, IIRC, the reason loops use the block stack is because they 
put things on the regular stack, that need to be cleared off the 
stack when the loop is exited (whether normally or via an exception).

In other words, just jumping out of a loop without popping the block 
stack would leave junk on the regular stack, thereby failing to 
deallocate the loop iterator.  In the case of a nested loop, this 
would also mean that the outer loop would start using the inner 
loop's iterator, and all sorts of hilarity would then ensue.




From ncoghlan at gmail.com  Sat Mar 12 20:05:23 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Mar 2011 14:05:23 -0500
Subject: [Python-Dev] About raising NotPortableWarning for CPython
 specific code
In-Reply-To: <AANLkTimiQfKtUoLpHZsjcaehyXLQudKAqfPO5WmCp+pS@mail.gmail.com>
References: <201103121333.p2CDXKW0032170@theraft.openend.se>
	<AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>
	<AANLkTimiQfKtUoLpHZsjcaehyXLQudKAqfPO5WmCp+pS@mail.gmail.com>
Message-ID: <AANLkTin1tTOOcjjsKHW=qr9Q0Gf8QGuG2DzRtS-j-53f@mail.gmail.com>

On Sat, Mar 12, 2011 at 1:41 PM, Guido van Rossum <guido at python.org> wrote:
> Yeah, indeed, on everything you said. The code dispatching based on
> internal slots is horribly ad-hoc and likely wrong in subtle ways. Has
> any of this improved in Python 3?

Not that I know of - I was definitely able to replicate the weirdness in 3.2.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From guido at python.org  Sat Mar 12 20:31:05 2011
From: guido at python.org (Guido van Rossum)
Date: Sat, 12 Mar 2011 14:31:05 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <795F80F1-CB8F-41D0-B5C3-910E4C81D906@gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>
	<AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>
	<795F80F1-CB8F-41D0-B5C3-910E4C81D906@gmail.com>
Message-ID: <AANLkTinqXhr4OEKfsOaQ3kyXJr4QkzHKsLH7wxhCtGpC@mail.gmail.com>

On Sat, Mar 12, 2011 at 11:05 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> There are separate social, strategic, and tactical questions.
>
> The social question: ?if the person who designed, implemented, and maintained the optimizer recommends against a patch and another committer just checks it in anyway, do we care? ?I've taken responsibility for this code and have treated it will a good deal of care. ?I don't believe the patch should go in because the risk/reward ratio is too low and because a better solution exists.

Hm. A few comments:

- you're dangerously close here to putting your ego ahead of things
- further review of the patch may give a better understanding of the risk
- a "better solution" that doesn't exist yet shouldn't be too strong
an argument against "good enough"

> The strategic question: ?constant folding in the peephole optimizer pre-dates the AST branch. ?When AST landed, there was general agreement among myself and those involved that any future optimizations which could be done with the AST, should be done there. ?It is the correct technological solution.
>
> At one point, we had strategic agreement to stop building-out the peepholer in any significant way. ? In fairness to Antoine, the conversations took place several years before he became a committer. ?The strategic question is do we want to come to that agreement again? ?Can we agree to not have significant changes to the peepholer, to treat it with great care and restraint? ? This patch doesn't have to go in. ?Py3.3 won't be out for 18 to 24 months anyway. ?There is a lot of time to do the job right and not add weight to a house of cards.

Feel free to go ahead and start it. Write a PEP, or just write a patch
and get people to review and understand it. If it's successful, we can
delete peephole.c and the effect of Antoine's checkin will be
nullified. If it's not successful, Antoine's code has the advantage of
possibly being good enough, and will have had those same 18-24 months
to have its tires kicked a bit.

> The tactical question: ?is this particular patch correct? ?Maybe it is. ?I don't know, I didn't get past all the new macros. ?I do know that I could have whipped up something similar years ago but chose not to based on advice from Thomas, Andrew, Tim, and Guido. ? The only change since then is that there is a newer committer doesn't buy into that reasoning.

A recurring problem I hear about is that there is too much resistance
to new ideas coming from new developers. Clearly new developers may
not be aware of where the skeletons are hiding. But just as clearly
the old guard isn't always right. Antoine is by now not a newbie any
more. So please consider Antoine's patch on its own merit and not just
from the perspective of a decision made years ago.

> Constant folding is the most complex part of the optimizer. ?Why would we add to it, when a better and more reliable approach exists? ?The patch hasn't even been demonstrated to be necessary in any real-world code.

peephole.c is now 773 lines; it was 700 lines, so it grew by about
10%. But that's not very large: ceval.c is 4500 lines (many of which
are much deeper magic which I personally don't feel I understand at
all :-). I am not at all sure that you can create an AST-based
optimizer in less than 700 lines. (Nor am I sure that you can't -- nor
am I sure it matters. I'm, just saying. :-)

All in all I think it would be more productive to try and understand
Antoine's patch than to try to get it revert based on "because I [or
Tim Peters] said so" arguments.

Finally: There appears to be some disagreement on who said what, in
particular Raymond claims that he told Antoine not to commit whereas
Antoine claims he did not hear this feedback. I'm guessing it happened
in IRC (#python-dev), which is intentionally not logged anywhere. This
is an illustration of what is wrong with using IRC for important
decisions. I would have been much happier if the discussion about the
desirability of the patch could have happened *before* it was
committed, and I think maybe we need to have a stricter rule requiring
code reviews and possibly cool-off periods.

-- 
--Guido van Rossum (python.org/~guido)

From tjreedy at udel.edu  Sat Mar 12 20:52:41 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Mar 2011 14:52:41 -0500
Subject: [Python-Dev] About raising NotPortableWarning for CPython
	specific code
In-Reply-To: <AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>
References: <201103121333.p2CDXKW0032170@theraft.openend.se>
	<AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>
Message-ID: <ilgiu6$o6$1@dough.gmane.org>

On 3/12/2011 8:59 AM, Nick Coghlan wrote:
> On Sat, Mar 12, 2011 at 8:33 AM, Laura Creighton<lac at openend.se>  wrote:
>> For those of you not at the Language Summit at PyCON the day before yesterday,
>> there was talk of identifying non-portable behaviour, such as relying on
>> CPython's reference counting garbage collector to close files for you as
>> soon as they become unreachable.  And then warning about them.
>>
>> We have a real live user who has a large code base that relies on
>> the CPython behaviour that an object's __radd__ method will take precedence
>> over a list's inplace add behaviour.
>>
>> The thread with the whole gory details begins here:
>> http://codespeak.net/pipermail/pypy-dev/2011q1/006958.html
>>
>> My inclination is to declare code that relies on this as broken, rather
>> than patch every wretched container type in PyPy.  Can this become
>> blessed as a 'you shouldn't have done this'?
>
> Given that the meat of the difference in semantics lies in the
> CPython-specific distinction between nb_add and sq_concat, I'm
> inclined to agree with you.

Me too. Consider filing a tracker issue with the += and * examples from 
the link above as new unit tests.

> I'm actually tempted to call the current CPython semantics flatout
> *wrong*. When a given operation has multiple C level slots, shouldn't
> we be checking all the LHS slots before checking any of the RHS slots?

Yes.

> There's nothing in the language spec that I'm aware of that justifies
> us doing otherwise.

The current CPython behavior strikes me as a buggy optimization. If 
class 'list' were written in Python, it would have an '__iadd__' method 
that would implement +=. No question. I gather that this is what PyPy 
(correctly) does. The CPython implementation makes a (false) distinction 
between numeric + and * and sequence + and * that does not exist in 
Python the language. The reference manual only lists __add__, and not 
__nadd__ and __sadd__ as separate special methods. The fact that CPython 
has both (with different names) should *not* leak into Python semantics 
and behavior.

> (obviously, history now means that changing our behaviour would
> require a deprecation period)

I disagree. Behavior that contradicts intent and doc is a bug and should 
be fixed. Otherwise, the doc should be changed to say that for 
C-implmented objects, the precedence between forward and reverse methods 
depends on the category of object. This would mean that subclasses of 
builtins *should* act differently from their parent, as they can now. 
Example derived from the link:

# 3.2
class C(object):
     def __iter__(self):
         yield 'yes!'
     def __radd__(self, other):
         other.append('bug!')
         return other

class L(list):
     def __iadd__(self, other):
         list.__iadd__(self,other)
         return self

z1,z2 = [], L()
z1 += C()
z2 += C()
print(z1, z2)

 >>>
['bug!'] ['yes!']

Such a change would make the definition of the language more 
C-dependent, which is what Laura is rightly complaining about, rather 
than less. It would also work against efforts to make Python and C 
versions of stdlib modules work the same and pass the same tests.

-- 
Terry Jan Reedy


From thomas at python.org  Sat Mar 12 21:04:27 2011
From: thomas at python.org (Thomas Wouters)
Date: Sat, 12 Mar 2011 15:04:27 -0500
Subject: [Python-Dev] About raising NotPortableWarning for CPython
 specific code
In-Reply-To: <ilgiu6$o6$1@dough.gmane.org>
References: <201103121333.p2CDXKW0032170@theraft.openend.se>
	<AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>
	<ilgiu6$o6$1@dough.gmane.org>
Message-ID: <AANLkTimEp4wODmhBVmGEcv9eVjBr1YMgZUotRFv_gDmo@mail.gmail.com>

On Sat, Mar 12, 2011 at 14:52, Terry Reedy <tjreedy at udel.edu> wrote:

> On 3/12/2011 8:59 AM, Nick Coghlan wrote:
>
>> (obviously, history now means that changing our behaviour would
>
> require a deprecation period)
>>
>
> I disagree. Behavior that contradicts intent and doc is a bug and should be
> fixed.


It should be fixed, yes, but breaking existing code is going to piss off a
lot of people (like me) who already have enough worries when upgrading
Python. It is apparent that there *is* code out there that relies on this
behaviour, we shouldn't break it wlily-nilly. A warning when CPython
encounters the case that will change behaviour in the next CPython release
and in other implementations is almost as good as changing the behaviour.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/6d25e140/attachment.html>

From guido at python.org  Sat Mar 12 21:44:46 2011
From: guido at python.org (Guido van Rossum)
Date: Sat, 12 Mar 2011 15:44:46 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
Message-ID: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>

I was just reminded that in Python 3, list.sort() and sorted() no
longer support the cmp (comparator) function argument. The reason is
that the key function argument is always better. But now I have a
nagging doubt about this:

I recently advised a Googler who was sorting a large dataset and
running out of memory. My analysis of the situation was that he was
sorting a huge list of short lines of the form "shortstring,integer"
with a key function that returned a tuple of the form ("shortstring",
integer). Using the key function argument, in addition to N short
string objects, this creates N tuples of length 2, N more slightly
shorter string objects, and N integer objects. (Not to count a
parallel array of N more pointers.) Given the object overhead, this
dramatically increased the memory usage. It so happens that in this
particular Googler's situation, memory is constrained but CPU time is
not, and it would be better to parse the strings over and over again
in a comparator function.

But in Python 3 this solution is no longer available. How bad is that?
I'm not sure. But I'd like to at least get the issue out in the open.

-- 
--Guido van Rossum (python.org/~guido)

From tjreedy at udel.edu  Sat Mar 12 22:01:43 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Mar 2011 16:01:43 -0500
Subject: [Python-Dev] About raising NotPortableWarning for CPython
	specific code
In-Reply-To: <AANLkTimEp4wODmhBVmGEcv9eVjBr1YMgZUotRFv_gDmo@mail.gmail.com>
References: <201103121333.p2CDXKW0032170@theraft.openend.se>	<AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>	<ilgiu6$o6$1@dough.gmane.org>
	<AANLkTimEp4wODmhBVmGEcv9eVjBr1YMgZUotRFv_gDmo@mail.gmail.com>
Message-ID: <ilgmvj$jej$1@dough.gmane.org>

On 3/12/2011 3:04 PM, Thomas Wouters wrote:

> It should be fixed, yes, but breaking existing code is going to piss off
> a lot of people (like me) who already have enough worries when upgrading
> Python. It is apparent that there *is* code out there that relies on
> this behaviour, we shouldn't break it wlily-nilly. A warning when
> CPython encounters the case that will change behaviour in the next
> CPython release and in other implementations is almost as good as
> changing the behaviour.

Every bug fix breaks code that depends on the bug. That said, we do not 
backport every bug fix. I think in the long run it would be good to fix 
at least 2.7 and 3.2, but that could be debated.

Greg Price, who started the thread wanting PyPy to replicate the 
somewhat undefined and crazy behavior of CPython, admits
"I think a strict reading of the language reference would clearly 
identify this as wrong behavior by CPython."
http://codespeak.net/pipermail/pypy-dev/2011q1/006966.html
So he can hardly complain if we fix the 'wrong behavior'.

He is not a newbie: he is the one who diagnosed why CPython behaves as 
it does. He also knows how to fix their code: simply add to each 
appended class an __iter__ method just like I did, except yield the same 
thing as the __radd__ method appends rather than something different. 
With such a fix, his software would work with buggy and fixed CPython as 
well PyPy. He should just do that.

He apparently is not the original author. Too bad *that* programmer did 
not recognize and report that he had discovered a bug. I doubt that too 
many other people have encountered it because I expect someone would 
have posted something.

-- 
Terry Jan Reedy


From solipsis at pitrou.net  Sat Mar 12 22:09:17 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 12 Mar 2011 22:09:17 +0100
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTinqXhr4OEKfsOaQ3kyXJr4QkzHKsLH7wxhCtGpC@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>
	<AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>
	<795F80F1-CB8F-41D0-B5C3-910E4C81D906@gmail.com>
	<AANLkTinqXhr4OEKfsOaQ3kyXJr4QkzHKsLH7wxhCtGpC@mail.gmail.com>
Message-ID: <1299964157.3702.119.camel@localhost.localdomain>


Hello,

> Finally: There appears to be some disagreement on who said what, in
> particular Raymond claims that he told Antoine not to commit whereas
> Antoine claims he did not hear this feedback. I'm guessing it happened
> in IRC (#python-dev), which is intentionally not logged anywhere.

Raymond did tell me he was objecting on a patch, but unless I
misunderstood him he was talking about http://bugs.python.org/issue11462
(which he indeed closed later), not the present issue.

I agree IRC is a poor platform for making decisions (and I've probably
been guilty of this too).

Regards

Antoine.




From tjreedy at udel.edu  Sat Mar 12 22:25:24 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Mar 2011 16:25:24 -0500
Subject: [Python-Dev] About raising NotPortableWarning for CPython
	specific code
In-Reply-To: <201103121333.p2CDXKW0032170@theraft.openend.se>
References: <201103121333.p2CDXKW0032170@theraft.openend.se>
Message-ID: <ilgoc1$pt5$1@dough.gmane.org>

On 3/12/2011 8:33 AM, Laura Creighton wrote:

> The thread with the whole gory details begins here:
> http://codespeak.net/pipermail/pypy-dev/2011q1/006958.html

The second, multiplication issue does appears to be the same issue.
Augmenting my previous test:

class C(object):
     def __iter__(self):
         yield 'yes!'
     def __radd__(self, other):
         other.append('bug!')
         return other
     def __rmul__(self, other):
         other *= 2
         return other
     def __index__(self):
           return 3

class L(list):
     def __iadd__(self, other):
         list.__iadd__(self,other)
         return self
     def __mul__(self, other):
         return L(list.__imul__(self,other))

z1, z2, c = [], L(), C()
z1 += c
z2 += c
print(z1, z2, [1]*c, L([1])*c)
 >>>
['bug!'] ['yes!'] [1, 1] [1, 1, 1] # PyPy prints ['yes!'], [1, 1, 1]

I opened http://bugs.python.org/issue11477

-- 
Terry Jan Reedy


From solipsis at pitrou.net  Sat Mar 12 22:29:14 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 12 Mar 2011 22:29:14 +0100
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <B6E14BD9-DCFF-45E9-BCF8-F2386CE42998@gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<B6E14BD9-DCFF-45E9-BCF8-F2386CE42998@gmail.com>
Message-ID: <20110312222914.2b12c12b@pitrou.net>

On Sat, 12 Mar 2011 13:08:26 -0500
Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
> I would like to withdraw my suggestion for the recursive constant folding patch to be reverted.  I value social harmony much more than a decision about whether a particular patch is a good idea.  I apologize to anyone who is upset over the discussion.

Thank you Raymond.
Of course, if there turns out to be a technical issue that can't
be fixed, the patch should still be backed out.

Regards

Antoine.

From reid.kleckner at gmail.com  Sat Mar 12 22:50:43 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Sat, 12 Mar 2011 16:50:43 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
Message-ID: <AANLkTimK9YmKvSo85pindjvDQcTTxR40cDJjqB_+fvp0@mail.gmail.com>

They should be able to use a slotted cmp_to_key style class:
http://docs.python.org/howto/sorting.html

That will allocate 1 Python object with no dict per key, but that
might not be good enough.

Reid

On Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum <guido at python.org> wrote:
> I was just reminded that in Python 3, list.sort() and sorted() no
> longer support the cmp (comparator) function argument. The reason is
> that the key function argument is always better. But now I have a
> nagging doubt about this:
>
> I recently advised a Googler who was sorting a large dataset and
> running out of memory. My analysis of the situation was that he was
> sorting a huge list of short lines of the form "shortstring,integer"
> with a key function that returned a tuple of the form ("shortstring",
> integer). Using the key function argument, in addition to N short
> string objects, this creates N tuples of length 2, N more slightly
> shorter string objects, and N integer objects. (Not to count a
> parallel array of N more pointers.) Given the object overhead, this
> dramatically increased the memory usage. It so happens that in this
> particular Googler's situation, memory is constrained but CPU time is
> not, and it would be better to parse the strings over and over again
> in a comparator function.
>
> But in Python 3 this solution is no longer available. How bad is that?
> I'm not sure. But I'd like to at least get the issue out in the open.
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/reid.kleckner%40gmail.com
>

From fredrik.johansson at gmail.com  Sat Mar 12 22:55:07 2011
From: fredrik.johansson at gmail.com (Fredrik Johansson)
Date: Sat, 12 Mar 2011 22:55:07 +0100
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
Message-ID: <AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>

On Sat, Mar 12, 2011 at 9:44 PM, Guido van Rossum <guido at python.org> wrote:
> I was just reminded that in Python 3, list.sort() and sorted() no
> longer support the cmp (comparator) function argument. The reason is
> that the key function argument is always better. But now I have a
> nagging doubt about this:
>
> I recently advised a Googler who was sorting a large dataset and
> running out of memory. My analysis of the situation was that he was
> sorting a huge list of short lines of the form "shortstring,integer"
> with a key function that returned a tuple of the form ("shortstring",
> integer). Using the key function argument, in addition to N short
> string objects, this creates N tuples of length 2, N more slightly
> shorter string objects, and N integer objects. (Not to count a
> parallel array of N more pointers.) Given the object overhead, this
> dramatically increased the memory usage. It so happens that in this
> particular Googler's situation, memory is constrained but CPU time is
> not, and it would be better to parse the strings over and over again
> in a comparator function.
>
> But in Python 3 this solution is no longer available. How bad is that?
> I'm not sure. But I'd like to at least get the issue out in the open.

The removal of cmp and especially sort(cmp=...) was probably my least
favorite change in Python 3.

Sorting with a key only makes sense when the data can be mapped onto
builtin types (typically ints, strings, and tuples thereof) in an
order-preserving way. When this is not possible, you have to map it
onto a custom type and effectively implement a cmp function via the
comparison methods of that type. This is an ugly and slow substitute
for something that used to be elegant and fast.

Consider sorting a list of pairs representing fractions. This can be
done easily in Python 2.x with the comparison function lambda
(p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times
faster than using fractions.Fraction as a key function.

Fredrik

From ncoghlan at gmail.com  Sat Mar 12 22:58:44 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Mar 2011 16:58:44 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTimK9YmKvSo85pindjvDQcTTxR40cDJjqB_+fvp0@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<AANLkTimK9YmKvSo85pindjvDQcTTxR40cDJjqB_+fvp0@mail.gmail.com>
Message-ID: <AANLkTi=tNh-5kVCjW-jOnpkooyS5g3T6VCBvCkhm9HMG@mail.gmail.com>

On Sat, Mar 12, 2011 at 4:50 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote:
> They should be able to use a slotted cmp_to_key style class:
> http://docs.python.org/howto/sorting.html
>
> That will allocate 1 Python object with no dict per key, but that
> might not be good enough.

Tuples are already slotted, so that isn't likely to help in this case.

The basic point is that cmp vs key is actually a classic space vs
speed trade-off, and by removing the "cmp" option, we prevent people
from making that trade-off for themselves.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From greg.ewing at canterbury.ac.nz  Sat Mar 12 23:08:42 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 13 Mar 2011 11:08:42 +1300
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <AANLkTi=P-256xMJcsn5TWTCwuivGdKG4fh4Jjobg1wZR@mail.gmail.com>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
	<4D7AE3EC.7080105@pearwood.info>
	<AANLkTi=P-256xMJcsn5TWTCwuivGdKG4fh4Jjobg1wZR@mail.gmail.com>
Message-ID: <4D7BEEEA.2020600@canterbury.ac.nz>

Guido van Rossum wrote:

> IIUC Thomas found that this breaks some current use of staticmethod.

I*I*UC, it wasn't making it callable that was the problem,
it was changing the behaviour so that the staticmethod
wrapper returns itself instead of the underlying object
when accessed as a descriptor.

The reason for doing *that* appears to be so that you
can transplant a staticmethod-wrapped object from one
class to another without surprises. But is that really
a common enough thing to do that it warrants special
attention? Would it be so bad to require applying
staticmethod() again in such a situation?

-- 
Greg

From tjreedy at udel.edu  Sat Mar 12 23:09:39 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Mar 2011 17:09:39 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
Message-ID: <ilgqv0$5f0$1@dough.gmane.org>

On 3/12/2011 3:44 PM, Guido van Rossum wrote:
> I was just reminded that in Python 3, list.sort() and sorted() no
> longer support the cmp (comparator) function argument. The reason is
> that the key function argument is always better. But now I have a
> nagging doubt about this:
>
> I recently advised a Googler who was sorting a large dataset and
> running out of memory. My analysis of the situation was that he was
> sorting a huge list of short lines of the form "shortstring,integer"
> with a key function that returned a tuple of the form ("shortstring",
> integer).

I believe that if the integer field were padded with leading blanks as 
needed so that all are the same length, then no key would be needed.

ll = ['a,11111', 'ab,    3', 'a,    1', 'a,  111']
ll.sort()
print(ll)
 >>>
['a,    1', 'a,  111', 'a,11111', 'ab,    3']

If most ints are near the max len, this would add little space, and be 
even faster than with the key.

 > Using the key function argument, in addition to N short
> string objects, this creates N tuples of length 2, N more slightly
> shorter string objects, and N integer objects. (Not to count a
> parallel array of N more pointers.) Given the object overhead, this
> dramatically increased the memory usage. It so happens that in this
> particular Googler's situation, memory is constrained but CPU time is
> not, and it would be better to parse the strings over and over again
> in a comparator function.

Was 3.2 used? It has a patch that reduces the extra memory that might 
not be in the last 3.1 release.

> But in Python 3 this solution is no longer available. How bad is that?
> I'm not sure. But I'd like to at least get the issue out in the open.

This removal has been one of the more contentious issues about (not) 
using 3.x. I believe Raymond had been more involved in the defense of 
the decision than I. However, the discussion/complaint has mostly been 
about the relative difficulty of writing a key function versus a compare 
function.

-- 
Terry Jan Reedy


From reid.kleckner at gmail.com  Sat Mar 12 23:09:29 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Sat, 12 Mar 2011 17:09:29 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTi=tNh-5kVCjW-jOnpkooyS5g3T6VCBvCkhm9HMG@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<AANLkTimK9YmKvSo85pindjvDQcTTxR40cDJjqB_+fvp0@mail.gmail.com>
	<AANLkTi=tNh-5kVCjW-jOnpkooyS5g3T6VCBvCkhm9HMG@mail.gmail.com>
Message-ID: <AANLkTinngg=XGye75FN=iVVmJ7q6N8gjbBv7ixLPMf6w@mail.gmail.com>

On Sat, Mar 12, 2011 at 4:58 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, Mar 12, 2011 at 4:50 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote:
>> They should be able to use a slotted cmp_to_key style class:
>> http://docs.python.org/howto/sorting.html
>>
>> That will allocate 1 Python object with no dict per key, but that
>> might not be good enough.
>
> Tuples are already slotted, so that isn't likely to help in this case.

It's three allocations vs. one.  The first is tuple + str + int, while
the adapter is just one object.  I'm not sure how it eventually shakes
out, though.

That said, it's still worse than Python 2, which is zero allocations.  :)

Reid

From v+python at g.nevcal.com  Sat Mar 12 23:13:28 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Sat, 12 Mar 2011 14:13:28 -0800
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <4D7BBEAC.7060803@python.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<4D7B9A82.6070309@netwok.org>	<AANLkTimmCL9FrFpakkQNJH5mo6F9_s5y7Uz5-WPLYDmH@mail.gmail.com>
	<4D7BBEAC.7060803@python.org>
Message-ID: <4D7BF008.4020307@g.nevcal.com>

On 3/12/2011 10:42 AM, Allison Randal wrote:
> I might convert it directly into a Q&A blog post. 

I'd like to see that, or a summary, posted here.  As a Perl-to-Python 
convertee, I'm curious about the problematic semantic differences.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/059be5e5/attachment.html>

From nadeem.vawda at gmail.com  Sat Mar 12 23:24:07 2011
From: nadeem.vawda at gmail.com (Nadeem Vawda)
Date: Sun, 13 Mar 2011 00:24:07 +0200
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
In-Reply-To: <4D7B590C.309@v.loewis.de>
References: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>
	<AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>
	<AANLkTinEM6ycw-ba5z2KJTmEEFrY9tk_QAtpv4MkgNUo@mail.gmail.com>
	<4D7B590C.309@v.loewis.de>
Message-ID: <AANLkTikWd=ZKAZUcur8oGtBNv72NkrHKMrCPoa34yjhx@mail.gmail.com>

On Sat, Mar 12, 2011 at 1:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Isn't that command correct only if you are merging into default?
> ISTM that it should be "hg revert -ar <targetbranch>".

In general, yes. However, the existing text refers specifically to the
case of merging 3.2
into default, so I was trying to be consistent with that.

The current text, after my proposed change, will be:

hg update default
hg merge 3.2
hg revert -ar default
hg commit

For full generality, you might want to say:

hg update <targetbranch>
hg merge <sourcebranch>
hg revert -ar <targetbranch>
hg commit

However, the entire section on forward-porting is framed in terms of
concrete examples
(and that specific subsection refers explicitly to the "3.2 ->
default" case). The existing
text makes sense to me, so I don't see any need to change this.

Regards,
Nadeem

From eltoder at gmail.com  Sat Mar 12 23:29:29 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Sat, 12 Mar 2011 17:29:29 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTinngg=XGye75FN=iVVmJ7q6N8gjbBv7ixLPMf6w@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<AANLkTimK9YmKvSo85pindjvDQcTTxR40cDJjqB_+fvp0@mail.gmail.com>
	<AANLkTi=tNh-5kVCjW-jOnpkooyS5g3T6VCBvCkhm9HMG@mail.gmail.com>
	<AANLkTinngg=XGye75FN=iVVmJ7q6N8gjbBv7ixLPMf6w@mail.gmail.com>
Message-ID: <AANLkTimOCc4phPF_dSgRnJaegze=ALO3F+EwphB8pzDp@mail.gmail.com>

Can sort have an option (and/or try to figure it itself) to calculate
key for every comparison instead of caching them? This will have the
same memory requirements as with cmp, but doesn't require rewriting
code if you decide to trade speed for memory. Will this be much slower
than with cmp?

If going that route sort can also cache a limited amount of keys
(instead of all or nothing), using, for example, a LRU cache with
fixed size.

Eugene

From solipsis at pitrou.net  Sat Mar 12 23:38:41 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 12 Mar 2011 23:38:41 +0100
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
References: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>
	<AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>
	<AANLkTinEM6ycw-ba5z2KJTmEEFrY9tk_QAtpv4MkgNUo@mail.gmail.com>
	<4D7B590C.309@v.loewis.de>
	<AANLkTikWd=ZKAZUcur8oGtBNv72NkrHKMrCPoa34yjhx@mail.gmail.com>
Message-ID: <20110312233841.1308895d@pitrou.net>

On Sun, 13 Mar 2011 00:24:07 +0200
Nadeem Vawda <nadeem.vawda at gmail.com> wrote:
> On Sat, Mar 12, 2011 at 1:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Isn't that command correct only if you are merging into default?
> > ISTM that it should be "hg revert -ar <targetbranch>".
> 
> In general, yes. However, the existing text refers specifically to the
> case of merging 3.2
> into default, so I was trying to be consistent with that.
> 
> The current text, after my proposed change, will be:
> 
> hg update default
> hg merge 3.2
> hg revert -ar default
> hg commit

Thanks for pointing this out. I've fixed the error.

Regards

Antoine.



From martin at v.loewis.de  Sat Mar 12 23:41:56 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Mar 2011 17:41:56 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTi=tNh-5kVCjW-jOnpkooyS5g3T6VCBvCkhm9HMG@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>	<AANLkTimK9YmKvSo85pindjvDQcTTxR40cDJjqB_+fvp0@mail.gmail.com>
	<AANLkTi=tNh-5kVCjW-jOnpkooyS5g3T6VCBvCkhm9HMG@mail.gmail.com>
Message-ID: <4D7BF6B4.5050206@v.loewis.de>

Am 12.03.11 16:58, schrieb Nick Coghlan:
> On Sat, Mar 12, 2011 at 4:50 PM, Reid Kleckner<reid.kleckner at gmail.com>  wrote:
>> They should be able to use a slotted cmp_to_key style class:
>> http://docs.python.org/howto/sorting.html
>>
>> That will allocate 1 Python object with no dict per key, but that
>> might not be good enough.
>
> Tuples are already slotted, so that isn't likely to help in this case.

Why not? IIUC, the current key function creates three objects: the 
tuple, the short string, and the int. With the class

class cmp_to_key:
   __slots__=['obj']
   def __init__(self, obj):
       self.obj = obj
   def __lt__(self):
       ...

you would only create a single object, so you save the string and the 
integer. In addition, on a 64-bit system, the size of a cmp_to_key
instance is 56 bytes, whereas a two-tuple is 72 bytes, so you also
save 16 bytes per object. Whether that would already create a sufficient
reduction for the case at hand, I don't know.

Regards,
Martin

From benjamin at python.org  Sat Mar 12 23:42:17 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 12 Mar 2011 16:42:17 -0600
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTimRLrWDbRmFOWiKCpzH=ojAmvkHisXS_XeigCnx@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<4D7BB802.9060200@v.loewis.de>
	<AANLkTimRLrWDbRmFOWiKCpzH=ojAmvkHisXS_XeigCnx@mail.gmail.com>
Message-ID: <AANLkTimsQsDK38jJPL7+5Pa=cB59psGSgDO+7s299fas@mail.gmail.com>

2011/3/12 Maciej Fijalkowski <fijall at gmail.com>:
> On Sat, Mar 12, 2011 at 1:14 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>>
>>> http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
>>>
>>> http://www.boredomandlaziness.org/2011/03/python-vm-summit-somewhat-coherent.html
>>
>> Wrt. the remark that other implementations should be referenced more
>> prominently: I added them to
>>
>> http://www.python.org/download/
>
> Cool. Would you mind mentioning JIT for PyPy in description?

Done.



-- 
Regards,
Benjamin

From __peter__ at web.de  Sat Mar 12 23:43:24 2011
From: __peter__ at web.de (Peter Otten)
Date: Sat, 12 Mar 2011 23:43:24 +0100
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
Message-ID: <ilgsst$dk8$1@dough.gmane.org>

Guido van Rossum wrote:

> I was just reminded that in Python 3, list.sort() and sorted() no
> longer support the cmp (comparator) function argument. The reason is
> that the key function argument is always better. But now I have a
> nagging doubt about this:
> 
> I recently advised a Googler who was sorting a large dataset and
> running out of memory. My analysis of the situation was that he was
> sorting a huge list of short lines of the form "shortstring,integer"
> with a key function that returned a tuple of the form ("shortstring",
> integer). Using the key function argument, in addition to N short
> string objects, this creates N tuples of length 2, N more slightly
> shorter string objects, and N integer objects. (Not to count a
> parallel array of N more pointers.) Given the object overhead, this
> dramatically increased the memory usage. It so happens that in this
> particular Googler's situation, memory is constrained but CPU time is
> not, and it would be better to parse the strings over and over again
> in a comparator function.
> 
> But in Python 3 this solution is no longer available. How bad is that?
> I'm not sure. But I'd like to at least get the issue out in the open.

While there are other arguments to reintroduce cmp (or less_than instead?) 
the memory problem could also be addressed with a dont_cache_keys flag or 
max_cache_keys limit.

Peter


From merwok at netwok.org  Sat Mar 12 23:43:52 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 12 Mar 2011 23:43:52 +0100
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
In-Reply-To: <20110312233841.1308895d@pitrou.net>
References: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>	<AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>	<AANLkTinEM6ycw-ba5z2KJTmEEFrY9tk_QAtpv4MkgNUo@mail.gmail.com>	<4D7B590C.309@v.loewis.de>	<AANLkTikWd=ZKAZUcur8oGtBNv72NkrHKMrCPoa34yjhx@mail.gmail.com>
	<20110312233841.1308895d@pitrou.net>
Message-ID: <4D7BF728.3040209@netwok.org>

> hg revert -ar default

You can?t combine the -r option with other options.  (Yes, it?s a known
bug.)

On an unrelated note, you can use ?-r .? to tell Mercurial to find the
branch name from the working directory instead of having to remember and
retype it.

Regards

From ncoghlan at gmail.com  Sat Mar 12 23:45:43 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Mar 2011 17:45:43 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <4D7BF6B4.5050206@v.loewis.de>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<AANLkTimK9YmKvSo85pindjvDQcTTxR40cDJjqB_+fvp0@mail.gmail.com>
	<AANLkTi=tNh-5kVCjW-jOnpkooyS5g3T6VCBvCkhm9HMG@mail.gmail.com>
	<4D7BF6B4.5050206@v.loewis.de>
Message-ID: <AANLkTim2zDnzq9CaJK+nJbjRjo990GWa1Ta4apPVrGoW@mail.gmail.com>

On Sat, Mar 12, 2011 at 5:41 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Why not? IIUC, the current key function creates three objects: the tuple,
> the short string, and the int. With the class

Yeah, I misread the example. Using cmp_to_key would indeed save quite
a lot of memory in this case.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Sat Mar 12 23:53:20 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Mar 2011 17:53:20 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
Message-ID: <4D7BF960.9010500@v.loewis.de>

> But in Python 3 this solution is no longer available. How bad is that?
> I'm not sure. But I'd like to at least get the issue out in the open.

Rather than reintroducing cmp=, I'd add a cached=True parameter.
If this is set to False, the key results wouldn't be put into a
list, but recreated every time two objects need to be compared.

Regards,
Martin


From nadeem.vawda at gmail.com  Sat Mar 12 23:54:11 2011
From: nadeem.vawda at gmail.com (Nadeem Vawda)
Date: Sun, 13 Mar 2011 00:54:11 +0200
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
In-Reply-To: <4D7BF728.3040209@netwok.org>
References: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>
	<AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>
	<AANLkTinEM6ycw-ba5z2KJTmEEFrY9tk_QAtpv4MkgNUo@mail.gmail.com>
	<4D7B590C.309@v.loewis.de>
	<AANLkTikWd=ZKAZUcur8oGtBNv72NkrHKMrCPoa34yjhx@mail.gmail.com>
	<20110312233841.1308895d@pitrou.net> <4D7BF728.3040209@netwok.org>
Message-ID: <AANLkTim6i08CmXSHMk6j5vTipEPOey9TfZ3xWyzA0eZy@mail.gmail.com>

On Sun, Mar 13, 2011 at 12:43 AM, ?ric Araujo <merwok at netwok.org> wrote:
>> hg revert -ar default
>
> You can?t combine the -r option with other options. ?(Yes, it?s a known bug.)

It seems to work for me (Mercurial 1.6.3 on Ubuntu). But I suppose it
wouldn't hurt
to split the options up.

Regards,
Nadeem

From v+python at g.nevcal.com  Sun Mar 13 00:00:34 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Sat, 12 Mar 2011 15:00:34 -0800
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>
Message-ID: <4D7BFB12.8050400@g.nevcal.com>

On 3/12/2011 1:55 PM, Fredrik Johansson wrote:
> Consider sorting a list of pairs representing fractions. This can be
> done easily in Python 2.x with the comparison function lambda
> (p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times
> faster than using fractions.Fraction as a key function.

Am I correct in concluding that various ideas to eliminate or limit the 
size of the key= cache would not help this use case at all?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/b71131eb/attachment.html>

From solipsis at pitrou.net  Sun Mar 13 00:00:55 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 13 Mar 2011 00:00:55 +0100
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
References: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>
	<AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>
	<AANLkTinEM6ycw-ba5z2KJTmEEFrY9tk_QAtpv4MkgNUo@mail.gmail.com>
	<4D7B590C.309@v.loewis.de>
	<AANLkTikWd=ZKAZUcur8oGtBNv72NkrHKMrCPoa34yjhx@mail.gmail.com>
	<20110312233841.1308895d@pitrou.net> <4D7BF728.3040209@netwok.org>
Message-ID: <20110313000055.4b317841@pitrou.net>

On Sat, 12 Mar 2011 23:43:52 +0100
?ric Araujo <merwok at netwok.org> wrote:
> > hg revert -ar default
> 
> You can?t combine the -r option with other options.  (Yes, it?s a known
> bug.)

Are you sure? It just worked here:

$ hg rev -ar default
reverting README

(perhaps you're thinking of -R instead?)

> On an unrelated note, you can use ?-r .? to tell Mercurial to find the
> branch name from the working directory instead of having to remember and
> retype it.

Does it work with merges?

Regards

Antoine.



From thomas at python.org  Sun Mar 13 00:04:48 2011
From: thomas at python.org (Thomas Wouters)
Date: Sat, 12 Mar 2011 18:04:48 -0500
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <4D7BEEEA.2020600@canterbury.ac.nz>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
	<4D7AE3EC.7080105@pearwood.info>
	<AANLkTi=P-256xMJcsn5TWTCwuivGdKG4fh4Jjobg1wZR@mail.gmail.com>
	<4D7BEEEA.2020600@canterbury.ac.nz>
Message-ID: <AANLkTikX=s1s=BGrJZUSuZa27wV7B4K+PVOjd1uvbS2x@mail.gmail.com>

On Sat, Mar 12, 2011 at 17:08, Greg Ewing <greg.ewing at canterbury.ac.nz>wrote:

> Guido van Rossum wrote:
>
>  IIUC Thomas found that this breaks some current use of staticmethod.
>>
>
> I*I*UC, it wasn't making it callable that was the problem,
> it was changing the behaviour so that the staticmethod
> wrapper returns itself instead of the underlying object
> when accessed as a descriptor.
>
> The reason for doing *that* appears to be so that you
> can transplant a staticmethod-wrapped object from one
> class to another without surprises. But is that really
> a common enough thing to do that it warrants special
> attention? Would it be so bad to require applying
> staticmethod() again in such a situation?
>

There's two different things in play: the traditional use of staticmethod()
when you are storing something that isn't in your control as a class
attribute, and wrapping a Python function to have it be treated like a
PyCFunction, where you have no control (and no desire to control) what
happens with the function. Of course, if you do contor both the 'consumer'
and the 'producer' side, you can fix it either way you want.

For the emulate-builtins wrapper to do a proper job (and not leave subtle
differences lying around), the wrapper should not be a descriptor (or it
should return itself from __get__.) I suspect people will also want it to
expose the original function's attributes, like bound method wrappers do. If
we just have staticmethods be callable and tell people to use that, there
will still be cases where PyCFunctions and wrapped Python functions do
different things. But changing staticmethod to do these things would make
code that relies on staticmethod simply encapsulating objects (like, all my
own uses of staticmethod) break in fascinating ways. (I know, I tried.) And
I don't think having staticmethod do something different depending on the
type of object it's passed is worth considering.

I would much rather loudly warn people to fix their code, instead of forcing
other implementations (and, more importantly to me personally, future
CPython changes :) to deal with the distinction forever. But if we declare a
wrapper to be the right way to deal with this, let's at least do it right,
not half-assed again. And if we do add the nondescriptor wrapper for that, I
wonder if there are still cases where staticmethods should be callable; it
seems to me it would have no real benefit, and it would lure people into a
false sense of security when mistakenly using staticmethod as the wrapper
(which is, after all, a lot more visible.)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/77995433/attachment.html>

From v+python at g.nevcal.com  Sun Mar 13 00:04:32 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Sat, 12 Mar 2011 15:04:32 -0800
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
Message-ID: <4D7BFC00.9040907@g.nevcal.com>

On 3/12/2011 3:43 AM, Nick Coghlan wrote:
> I posted my rough notes and additional write-ups for Wednesday's VM
> summit and Thursday's language summit:
>
> http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html

> 2.7 to 3.2
>   - treat PyPy Python 3 dialect like a major Python library (e.g. 
> sponsored by PSF)

Can someone expound on what this means?  (context in above link)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/ad63d3a2/attachment.html>

From merwok at netwok.org  Sun Mar 13 00:11:34 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 13 Mar 2011 00:11:34 +0100
Subject: [Python-Dev] forward-porting from 3.1 to 3.2 to 3.3
In-Reply-To: <20110313000055.4b317841@pitrou.net>
References: <AANLkTim4mPT32T8foQPKM=WLyotC8qPZVwHX=O7pHNFE@mail.gmail.com>	<AANLkTik7ggbQSQqQVKXEd_WBnOaFwcNfZn6-YsKMrsQ1@mail.gmail.com>	<AANLkTinEM6ycw-ba5z2KJTmEEFrY9tk_QAtpv4MkgNUo@mail.gmail.com>	<4D7B590C.309@v.loewis.de>	<AANLkTikWd=ZKAZUcur8oGtBNv72NkrHKMrCPoa34yjhx@mail.gmail.com>	<20110312233841.1308895d@pitrou.net>
	<4D7BF728.3040209@netwok.org> <20110313000055.4b317841@pitrou.net>
Message-ID: <4D7BFDA6.8050409@netwok.org>

>> You can?t combine the -r option with other options.  (Yes, it?s a known
>> bug.)
> Are you sure? It just worked here: [...]
> (perhaps you're thinking of -R instead?)

Exactly.

>> On an unrelated note, you can use ?-r .? to tell Mercurial to find the
>> branch name from the working directory instead of having to remember and
>> retype it.
> Does it work with merges?

It does.  hg help revs:

    The reserved name "." indicates the working directory parent. If no
    working directory is checked out, it is equivalent to null. If an
    uncommitted merge is in progress, "." is the revision of the first
    parent.

Gotta love consistency, DTRT, Just Working and all that :)

Regards

From nad at acm.org  Sat Mar 12 23:59:58 2011
From: nad at acm.org (Ned Deily)
Date: Sat, 12 Mar 2011 14:59:58 -0800
Subject: [Python-Dev] Introductions
References: <1299396471.3699.3.camel@localhost.localdomain>
	<1299940862.1632.7.camel@hobo>
Message-ID: <nad-F0ECE1.14595812032011@dough.gmane.org>

In article <1299940862.1632.7.camel at hobo>,
 Ross Lagerwall <rosslagerwall at gmail.com> wrote:
> I have been offered commit rights for Python after making a few patches
> on subprocess and the os module.
> 
> Antoine suggested that I should introduce myself on the python-dev list
> so here we go:
> 
> I am a student from South Africa and decided to do some work on Python
> in my spare time. I think I chose the Python project because it
> definitely seems to be one of the friendliest projects around and the
> easiest to get started with - the dev guide helps a lot! Also, with the
> big standard library, there is place for people with all different
> levels of experience to contribute.

Welcome, Ross!  2011 is turning out to be a good year for new 
committers, if I do say so myself (and being one myself).  I hope you 
get the opportunity to meet others here in person, too, to hear and see 
our barks.

It was good to meet some more of you all in person, if all too briefly, 
at the language summit on Thursday.  Alas, I was unable to stay for the 
rest of PyCon but Ronald and I had a chance to spend some quality time 
together again brainstorming issues in the OS X area.  Onward!

-- 
 Ned Deily,
 nad at acm.org


From ncoghlan at gmail.com  Sun Mar 13 00:32:25 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Mar 2011 18:32:25 -0500
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <4D7BFC00.9040907@g.nevcal.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<4D7BFC00.9040907@g.nevcal.com>
Message-ID: <AANLkTi=To4oaKWZc-Y4r-ykkf5R4H6v4vZHOr_7kGBp+@mail.gmail.com>

On Sat, Mar 12, 2011 at 6:04 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> On 3/12/2011 3:43 AM, Nick Coghlan wrote:
>
> I posted my rough notes and additional write-ups for Wednesday's VM
> summit and Thursday's language summit:
>
> http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
>
> 2.7 to 3.2
> ? - treat PyPy Python 3 dialect like a major Python library (e.g. sponsored
> by PSF)
>
> Can someone expound on what this means?? (context in above link)

The context where this came up was the fact that the PSF has the
ability to fund specific, concrete proposals targeted at porting key
libraries to Python 3 (e.g. this already happened with PyOpenSSL). The
structure of PyPy means that Python 3 support is about implementing a
new front end without needing to change the backend (the latter
includes the JIT, etc), so it was mentioned as something the PyPy
folks might want to consider seeking funding for.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From greg.ewing at canterbury.ac.nz  Sun Mar 13 00:40:37 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 13 Mar 2011 12:40:37 +1300
Subject: [Python-Dev] About raising NotPortableWarning for CPython
 specific code
In-Reply-To: <AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>
References: <201103121333.p2CDXKW0032170@theraft.openend.se>
	<AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>
Message-ID: <4D7C0475.9060100@canterbury.ac.nz>

Nick Coghlan wrote:

> I'm actually tempted to call the current CPython semantics flatout
> *wrong*.

So am I. It seems to result from the hisorical mess
of distinguishing between numeric and sequence operations
at the C level but not the Python level. I think CPython
should be moving in the direction of eliminating that
distinction, not expecting all other Python implementations
to copy it.

-- 
Greg

From martin at v.loewis.de  Sun Mar 13 00:41:23 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Mar 2011 18:41:23 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <4D7BFB12.8050400@g.nevcal.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>	<AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>
	<4D7BFB12.8050400@g.nevcal.com>
Message-ID: <4D7C04A3.9090703@v.loewis.de>

Am 12.03.11 18:00, schrieb Glenn Linderman:
>   On 3/12/2011 1:55 PM, Fredrik Johansson wrote:
>> Consider sorting a list of pairs representing fractions. This can be
>> done easily in Python 2.x with the comparison function lambda
>> (p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times
>> faster than using fractions.Fraction as a key function.
>
> Am I correct in concluding that various ideas to eliminate or limit the
> size of the key= cache would not help this use case at all?

That's correct. However, there is a straight-forward day of getting
the same comparison algorithm with the cmp_to_key class in 3.x.
Fredrik classified this as "ugly and slow"; I'm not sure where this
classification comes from.

Regards,
Martin

From allison at python.org  Sun Mar 13 00:49:10 2011
From: allison at python.org (Allison Randal)
Date: Sat, 12 Mar 2011 18:49:10 -0500
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <4D7BF008.4020307@g.nevcal.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<4D7B9A82.6070309@netwok.org>
	<AANLkTimmCL9FrFpakkQNJH5mo6F9_s5y7Uz5-WPLYDmH@mail.gmail.com>
	<4D7BBEAC.7060803@python.org> <4D7BF008.4020307@g.nevcal.com>
Message-ID: <4D7C0676.5020901@python.org>

On 03/12/2011 05:13 PM, Glenn Linderman wrote:
> On 3/12/2011 10:42 AM, Allison Randal wrote:
>> I might convert it directly into a Q&A blog post.
>
> I'd like to see that, or a summary, posted here. As a Perl-to-Python
> convertee, I'm curious about the problematic semantic differences.

The short summary is that the Parrot VM is a very good semantic fit for 
Python (AFAICT, a better fit than it is for Perl 6, though I haven't 
done the feature-by-feature comparison). But, the initial implementation 
of Pynie (Python-on-Parrot) used NQP for parsing Python syntax and 
compiling it down to Parrot's AST. NQP is a library of Perl 6 regexes 
plus a stripped-down version of Perl 6 syntax, roughly the same general 
idea as PyPy's RPython. As with any Turing-complete system, it is 
certainly possible to implement a Python parser in NQP, but it required 
some ugly hacks, and it got to the point that I just hated working on it.

To be fair, the failure wasn't entirely technological, the project was 
also slowed by my PhD work, and by my new very intense and very 
interesting job.

I'd like to see Python-on-Parrot implementation work proceed in a more 
naturally Pythonic way, possibly as an alternate backend for PyPy or as 
an alternate output from the CPython grammar. I have a couple of 
volunteers who I'll be mentoring in the coming months, so we'll see what 
grows out of it.

Allison

From fredrik.johansson at gmail.com  Sun Mar 13 00:59:20 2011
From: fredrik.johansson at gmail.com (Fredrik Johansson)
Date: Sun, 13 Mar 2011 00:59:20 +0100
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <4D7C04A3.9090703@v.loewis.de>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>
	<4D7BFB12.8050400@g.nevcal.com> <4D7C04A3.9090703@v.loewis.de>
Message-ID: <AANLkTi=yXqE+pKqOursqA0Dd03wdHj5WTaV0Y8BCOnn7@mail.gmail.com>

On Sun, Mar 13, 2011 at 12:41 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 12.03.11 18:00, schrieb Glenn Linderman:
>>
>> ?On 3/12/2011 1:55 PM, Fredrik Johansson wrote:
>>>
>>> Consider sorting a list of pairs representing fractions. This can be
>>> done easily in Python 2.x with the comparison function lambda
>>> (p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times
>>> faster than using fractions.Fraction as a key function.
>>
>> Am I correct in concluding that various ideas to eliminate or limit the
>> size of the key= cache would not help this use case at all?
>
> That's correct. However, there is a straight-forward day of getting
> the same comparison algorithm with the cmp_to_key class in 3.x.
> Fredrik classified this as "ugly and slow"; I'm not sure where this
> classification comes from.

It's ugly because it involves creating a class wrapping a comparison
function, or importing some obscure magic from the standard library,
instead of just using a comparison function.

It's slow because it's slow (and less memory-efficient). Even with
cmp_to_key, the example with fractions is still 2.6 times slower than
with a direct cmp function.

Fredrik

From list-sink at trainedmonkeystudios.org  Sun Mar 13 00:42:49 2011
From: list-sink at trainedmonkeystudios.org (Terrence Cole)
Date: Sat, 12 Mar 2011 15:42:49 -0800
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <4D7AB50C.5010405@canterbury.ac.nz>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>
	<4D7AB50C.5010405@canterbury.ac.nz>
Message-ID: <1299973369.10117.8.camel@localhost>

On Sat, 2011-03-12 at 12:49 +1300, Greg Ewing wrote:
> Thomas Wouters wrote:
> 
> >  2. Make CFunctions turn into methods in CPython (after a period of 
> > warning about the impending change, obviously.) The actual *usecase* for 
> > this is hard to envision
> 
> While not necessary for the case being discussed here, this would
> be a big help for Pyrex and Cython, where currently some awkward
> things have to be done to get a Python class with methods implemented
> in C.

Just so.  I implemented a new C-level function type for Melano[1] just 2
days ago so that I can have the descriptor slot set (and get
__defaults__, __kw_defaults__, __annotations__, and any other missing
details from PyFunction that I want or need).

[1] https://github.com/terrence2/melano


From skip at pobox.com  Sun Mar 13 01:35:16 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 12 Mar 2011 18:35:16 -0600
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTinqXhr4OEKfsOaQ3kyXJr4QkzHKsLH7wxhCtGpC@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>
	<AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>
	<795F80F1-CB8F-41D0-B5C3-910E4C81D906@gmail.com>
	<AANLkTinqXhr4OEKfsOaQ3kyXJr4QkzHKsLH7wxhCtGpC@mail.gmail.com>
Message-ID: <19836.4420.725695.356644@montanaro.dyndns.org>


    Raymond> The social question: ?if the person who designed, implemented,
    Raymond> and maintained the optimizer recommends against a patch and
    Raymond> another committer just checks it in anyway, do we care?

    Guido> - you're dangerously close here to putting your ego ahead of
    Guido>   things

Maybe, but we have historically tended to give some extra weight to the
primary author of at least modules and packages.  If someone wanted to make
a significant change to xml.etree, I think we would give reasonably large
weight to Fredrik Lundh's opinion on the change.  If the peephole optimizer
is largely Raymond's work, why should that be treated any differently?  Is
it just because it can't practically be distributed outside of Python proper
the way ElementTree can?

Skip

From martin at v.loewis.de  Sun Mar 13 01:56:49 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Mar 2011 19:56:49 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <19836.4420.725695.356644@montanaro.dyndns.org>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>	<20110312101642.1699902d@pitrou.net>	<AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>	<AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>	<795F80F1-CB8F-41D0-B5C3-910E4C81D906@gmail.com>	<AANLkTinqXhr4OEKfsOaQ3kyXJr4QkzHKsLH7wxhCtGpC@mail.gmail.com>
	<19836.4420.725695.356644@montanaro.dyndns.org>
Message-ID: <4D7C1651.1070408@v.loewis.de>

> Maybe, but we have historically tended to give some extra weight to the
> primary author of at least modules and packages.  If someone wanted to make
> a significant change to xml.etree, I think we would give reasonably large
> weight to Fredrik Lundh's opinion on the change.  If the peephole optimizer
> is largely Raymond's work, why should that be treated any differently?  Is
> it just because it can't practically be distributed outside of Python proper
> the way ElementTree can?

These cases are certainly different. For Elementtree, /F has explicitly
asked that it be included into Python only under the condition that he
has the last say in all changes, and that the only exception to this
would be urgent security fixes, or systematic changes that apply to all
modules.

Whether such a privilege should have been granted in the first place is
a different question, but I personally feel obliged to honor it, until
some of the involved parties change their minds.

I don't think any of the regular core committers got any such explicit
veto powers on any code, and I don't think it should be granted to
anybody.

Regards,
Martin

From tjreedy at udel.edu  Sun Mar 13 02:16:27 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Mar 2011 20:16:27 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTinngg=XGye75FN=iVVmJ7q6N8gjbBv7ixLPMf6w@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>	<AANLkTimK9YmKvSo85pindjvDQcTTxR40cDJjqB_+fvp0@mail.gmail.com>	<AANLkTi=tNh-5kVCjW-jOnpkooyS5g3T6VCBvCkhm9HMG@mail.gmail.com>
	<AANLkTinngg=XGye75FN=iVVmJ7q6N8gjbBv7ixLPMf6w@mail.gmail.com>
Message-ID: <ilh5t6$gho$1@dough.gmane.org>

On 3/12/2011 5:09 PM, Reid Kleckner wrote:
> On Sat, Mar 12, 2011 at 4:58 PM, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>> On Sat, Mar 12, 2011 at 4:50 PM, Reid Kleckner<reid.kleckner at gmail.com>  wrote:
>>> They should be able to use a slotted cmp_to_key style class:
>>> http://docs.python.org/howto/sorting.html
>>>
>>> That will allocate 1 Python object with no dict per key, but that
>>> might not be good enough.
>>
>> Tuples are already slotted, so that isn't likely to help in this case.
>
> It's three allocations vs. one.  The first is tuple + str + int, while
> the adapter is just one object.  I'm not sure how it eventually shakes
> out, though.
>
> That said, it's still worse than Python 2, which is zero allocations.  :)

And revising the data so that no key and no cmp function is needed is 
zero allocations and faster. See my other post.

-- 
Terry Jan Reedy


From nas at arctrix.com  Sun Mar 13 02:23:05 2011
From: nas at arctrix.com (Neil Schemenauer)
Date: Sun, 13 Mar 2011 01:23:05 +0000 (UTC)
Subject: [Python-Dev] About raising NotPortableWarning for CPython
	specific code
References: <201103121333.p2CDXKW0032170@theraft.openend.se>
	<AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>
	<4D7C0475.9060100@canterbury.ac.nz>
Message-ID: <ilh69o$im8$1@dough.gmane.org>

Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> So am I. It seems to result from the hisorical mess
> of distinguishing between numeric and sequence operations
> at the C level but not the Python level. I think CPython
> should be moving in the direction of eliminating that
> distinction, not expecting all other Python implementations
> to copy it.

As a person responsible for part of the mess, I agree.  I would hope
this could be cleaned up in Python 3 without causing too much
trouble for developers.

  Neil


From steve at pearwood.info  Sun Mar 13 02:27:46 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 13 Mar 2011 12:27:46 +1100
Subject: [Python-Dev] Callable, non-descriptor class attributes.
In-Reply-To: <AANLkTikX=s1s=BGrJZUSuZa27wV7B4K+PVOjd1uvbS2x@mail.gmail.com>
References: <AANLkTin5DuS4+FVpcXwqn1DpTA0Ttmc3hng0bA=u9MYi@mail.gmail.com>	<4D7AE3EC.7080105@pearwood.info>	<AANLkTi=P-256xMJcsn5TWTCwuivGdKG4fh4Jjobg1wZR@mail.gmail.com>	<4D7BEEEA.2020600@canterbury.ac.nz>
	<AANLkTikX=s1s=BGrJZUSuZa27wV7B4K+PVOjd1uvbS2x@mail.gmail.com>
Message-ID: <4D7C1D92.2010706@pearwood.info>

Thomas Wouters wrote:

> I would much rather loudly warn people to fix their code, instead of forcing
> other implementations (and, more importantly to me personally, future
> CPython changes :) to deal with the distinction forever. But if we declare a
> wrapper to be the right way to deal with this, let's at least do it right,
> not half-assed again. And if we do add the nondescriptor wrapper for that, I
> wonder if there are still cases where staticmethods should be callable; it
> seems to me it would have no real benefit, and it would lure people into a
> false sense of security when mistakenly using staticmethod as the wrapper
> (which is, after all, a lot more visible.)


The primary benefit to my mind is two avoid breaking the Principle of 
Least Astonishment (PLA). Given:

class C(object):
     @staticmethod
     def spam():
         pass

spam looks like a callable. It is a callable when referenced via C.spam 
or C().spam. But inside the class block, it isn't callable. That comes 
as an unpleasant surprise to anyone who, like me, has tried to use a 
staticmethod as a helper function during class construction:

class C(object):
     @staticmethod
     def spam():
         pass
     result = spam()

That something that looks like a function fails to be callable violates 
PLA. There are work-arounds, but none of them are pretty or obvious:

     # the underlying function doesn't seem to be available directly
     result = spam.__get__(object())


or something like this:

class C(object):
     def spam():
         pass
     result = spam()
     spam = staticmethod(spam)

Making staticmethod callable would, in my opinion, be the obvious way to 
do it.


-- 
Steven


From steve at pearwood.info  Sun Mar 13 02:28:25 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 13 Mar 2011 12:28:25 +1100
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>
Message-ID: <4D7C1DB9.9070502@pearwood.info>

Fredrik Johansson wrote:

> Consider sorting a list of pairs representing fractions. This can be
> done easily in Python 2.x with the comparison function lambda
> (p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times
> faster than using fractions.Fraction as a key function.


[steve at sylar ~]$ python2.7 -m timeit -s "L = [(1,2), (3,4), (0,5), 
(9,100), (3,7), (2,8)]" "sorted(L, lambda (p,q),(r,s): cmp(p*s, q*r))"
10000 loops, best of 3: 25.1 usec per loop

[steve at sylar ~]$ python2.7 -m timeit -s "L = [(1,2), (3,4), (0,5), 
(9,100), (3,7), (2,8)]" -s "from fractions import Fraction" "sorted(L, 
key=lambda t: Fraction(*t))"
1000 loops, best of 3: 236 usec per loop


So for a short list, I get a factor of ten difference. For a longer 
list, I'd expect the key function to win out. Much to my astonishment, 
it doesn't -- I get similar results regardless of the size of L.

Size of L   key/cmp
==========  =========
6           9.4
600         13.9
60000       7.0
6000000     6.7




-- 
Steven


From v+python at g.nevcal.com  Sun Mar 13 02:47:58 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Sat, 12 Mar 2011 17:47:58 -0800
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <ilgqv0$5f0$1@dough.gmane.org>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<ilgqv0$5f0$1@dough.gmane.org>
Message-ID: <4D7C224E.3060400@g.nevcal.com>

On 3/12/2011 2:09 PM, Terry Reedy wrote:
> I believe that if the integer field were padded with leading blanks as 
> needed so that all are the same length, then no key would be needed. 

Did you mean that "if the integer field were" converted to string and 
"padded with leading blanks..."?

Otherwise I'm not sure how to pad an integer with leading blanks.

Also, what appears to be your revised data structure,   strval + ',' + 
'%5.5d' % intval , assumes the strval is fixed length, also.  Consider  
the following strval, intval pairs, using your syntax:

['a,997,    1','a, 1000']

Nothing says the strval wouldn't contain data that look like your 
structure... and just because they were short, didn't mean they were 
fixed length.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/29292f05/attachment.html>

From rdmurray at bitdance.com  Sun Mar 13 03:13:34 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 12 Mar 2011 21:13:34 -0500
Subject: [Python-Dev] another message to release
Message-ID: <20110313021334.3233F24A20F@kimball.webabinitio.net>

I believe the tracker sent an error message to python-dev as a
result of a failed hook execution.  If someone with the
power would release that message so we can see what the error
was, I'd appreciate it :)

--David

From tjreedy at udel.edu  Sun Mar 13 03:17:39 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Mar 2011 21:17:39 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <4D7C1DB9.9070502@pearwood.info>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>	<AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>
	<4D7C1DB9.9070502@pearwood.info>
Message-ID: <ilh9fv$uv1$1@dough.gmane.org>

On 3/12/2011 8:28 PM, Steven D'Aprano wrote:
> Fredrik Johansson wrote:
>
>> Consider sorting a list of pairs representing fractions. This can be
>> done easily in Python 2.x with the comparison function lambda
>> (p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times
>> faster than using fractions.Fraction as a key function.
>
>
> [steve at sylar ~]$ python2.7 -m timeit -s "L = [(1,2), (3,4), (0,5),
> (9,100), (3,7), (2,8)]" "sorted(L, lambda (p,q),(r,s): cmp(p*s, q*r))"
> 10000 loops, best of 3: 25.1 usec per loop
>
> [steve at sylar ~]$ python2.7 -m timeit -s "L = [(1,2), (3,4), (0,5),
> (9,100), (3,7), (2,8)]" -s "from fractions import Fraction" "sorted(L,
> key=lambda t: Fraction(*t))"
> 1000 loops, best of 3: 236 usec per loop
>
>
> So for a short list, I get a factor of ten difference. For a longer
> list, I'd expect the key function to win out. Much to my astonishment,
> it doesn't -- I get similar results regardless of the size of L.
>
> Size of L key/cmp
> ========== =========
> 6 9.4
> 600 13.9
> 60000 7.0
> 6000000 6.7

Interesting. Comparing two Fractions must do the same thing as the cmp 
function, compare two products, but it does so with a *lot* more overhead:

571     def _richcmp(self, other, op):
572         """Helper for comparison operators, for internal use
574         Implement comparison between a Rational instance and
575         either another Rational instance or a float `other`. If
576         `other` is not a Rational instance or a float, return
577         NotImplemented. `op` should be one of the six standard
578         comparison operators.
580         """
581         # convert other to a Rational instance where reasonable.
582         if isinstance(other, numbers.Rational):
583             return op(self._numerator * other.denominator,
584                       self._denominator * other.numerator)
585         if isinstance(other, float):
586             if math.isnan(other) or math.isinf(other):
587                 return op(0.0, other)
588             else:
589                 return op(self, self.from_float(other))
590         else:
591             return NotImplemented
592
593     def __lt__(a, b):
594         """a < b"""
595         return a._richcmp(b, operator.lt)

For this example, and any with suitably restricted values, key=float 
would work and should beat the cmp version. But of course, someone will 
have a use case for which that will not work. (But then, one could do a 
near linear scan to properly re-sort slices with equal float keys.)

Hmm. As I remember, one rationale for deleting cmp is that nlogn slow 
cmp() calls are slower than n slow key() calls, but that only matters if 
the nlogn '<' comparisions of stored keys are fast compared to cmp calls 
(as tends to be the case when the keys are builtin class instances).

But in this case, they are much slower. To be faster, one would need 
something like "key=lambda p,q:p*(lcm//q)", where lcm is the least 
common multiple of of all the q's (denominators). For the example above, 
lcm = 700. But for longer lists, it could be outrageously large.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Sun Mar 13 03:19:44 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Mar 2011 21:19:44 -0500
Subject: [Python-Dev] About raising NotPortableWarning for CPython
	specific code
In-Reply-To: <ilh69o$im8$1@dough.gmane.org>
References: <201103121333.p2CDXKW0032170@theraft.openend.se>	<AANLkTi=PJ_Xvc32G1TS1Xd=NCf7W3HEMHAaRqjwnV1ze@mail.gmail.com>	<4D7C0475.9060100@canterbury.ac.nz>
	<ilh69o$im8$1@dough.gmane.org>
Message-ID: <ilh9jq$uv1$2@dough.gmane.org>

On 3/12/2011 8:23 PM, Neil Schemenauer wrote:
> Greg Ewing<greg.ewing at canterbury.ac.nz>  wrote:
>> So am I. It seems to result from the hisorical mess
>> of distinguishing between numeric and sequence operations
>> at the C level but not the Python level. I think CPython
>> should be moving in the direction of eliminating that
>> distinction, not expecting all other Python implementations
>> to copy it.
>
> As a person responsible for part of the mess, I agree.  I would hope
> this could be cleaned up in Python 3 without causing too much
> trouble for developers.

I opened the issue http://bugs.python.org/issue11477
but I won't be writing the patch ;-).

-- 
Terry Jan Reedy


From martin at v.loewis.de  Sun Mar 13 03:29:10 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Mar 2011 21:29:10 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <4D7C1DB9.9070502@pearwood.info>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>	<AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>
	<4D7C1DB9.9070502@pearwood.info>
Message-ID: <4D7C2BF6.6050509@v.loewis.de>

> [steve at sylar ~]$ python2.7 -m timeit -s "L = [(1,2), (3,4), (0,5),
> (9,100), (3,7), (2,8)]" "sorted(L, lambda (p,q),(r,s): cmp(p*s, q*r))"
> 10000 loops, best of 3: 25.1 usec per loop
>
> [steve at sylar ~]$ python2.7 -m timeit -s "L = [(1,2), (3,4), (0,5),
> (9,100), (3,7), (2,8)]" -s "from fractions import Fraction" "sorted(L,
> key=lambda t: Fraction(*t))"
> 1000 loops, best of 3: 236 usec per loop
>
>
> So for a short list, I get a factor of ten difference. For a longer
> list, I'd expect the key function to win out. Much to my astonishment,
> it doesn't -- I get similar results regardless of the size of L.

This shouldn't be surprising. The cost is primarily in the comparisons,
not in the creation of the Fraction objects. Now, the number of
comparisons won't change whether you use a cmp function or key objects;
the algorithm will compare and switch the same objects in the same
order. So if a Fraction.__lt__ takes seven times as long as a cmp call,
this ratio is preserved even for very long lists.

A lot can be saved if the __lt__ would assume that the other object
is of the same kind:

class Fcomp(tuple):
     def __lt__(self, other):
         return self[0]*other[1] < self[1]*other[0]

python -m timeit -s "L = [(1,2), (3,4), (0,5), (9,100), (3,7), (2,8)]" 
-s "from fcomp import Fcomp" "sorted(L, key=Fcomp)"

Regards,
Martin


From raymond.hettinger at gmail.com  Sun Mar 13 04:00:00 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 12 Mar 2011 22:00:00 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
Message-ID: <D0ACF24F-6B5F-472E-B249-541571A7FB43@gmail.com>


On Mar 12, 2011, at 3:44 PM, Guido van Rossum wrote:

> I was just reminded that in Python 3, list.sort() and sorted() no
> longer support the cmp (comparator) function argument. The reason is
> that the key function argument is always better. But now I have a
> nagging doubt about this:
> 
> I recently advised a Googler who was sorting a large dataset and
> running out of memory. 

. . .

> But in Python 3 this solution is no longer available. How bad is that?
> I'm not sure. But I'd like to at least get the issue out in the open.
> 


Python3.2 should be substantially better in this regard.
It no longer wraps key objects around every input.  Instead, it
sorts two parallel arrays of pointers.   You can thank Daniel
Stutzbach (another Googler I believe) for this effort.


Raymond


From tjreedy at udel.edu  Sun Mar 13 04:21:12 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Mar 2011 22:21:12 -0500
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <4D7C224E.3060400@g.nevcal.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>	<ilgqv0$5f0$1@dough.gmane.org>
	<4D7C224E.3060400@g.nevcal.com>
Message-ID: <ilhd74$cg9$1@dough.gmane.org>

On 3/12/2011 8:47 PM, Glenn Linderman wrote:
> On 3/12/2011 2:09 PM, Terry Reedy wrote:
>> I believe that if the integer field were padded with leading blanks as
>> needed so that all are the same length, then no key would be needed.
>
> Did you mean that "if the integer field were" converted to string and
> "padded with leading blanks..."?

Guido presented a use case of a list a strings, each of form '%s,%d', 
where the %s part is a 'word'. 'Integer field' refers to the part of 
each string after the comma.

> Otherwise I'm not sure how to pad an integer with leading blanks.

The integers are already in string form. The *existing* key function his 
colleague used converted that part to an int as the second part of a 
tuple. I presume the integer field was separated by split(','), so the 
code was something like

def sikey(s):
   s,i = s.split(',')
   return s,int(i)

longlist.sort(key=sikey)

It does not matter if the splitting method is more complicated, because 
it is already part of the problem spec. I proposed instead

def sirep(s):
   s,i = s.split(',') # or whatever current key func does
   return '%s,%#s' % (s,i)
   # where appropriate value of # is known from application

longlist = map(sirep, longlist)
longlist.sort()

# or assuming that a simple split is correct

longlist = ['%s,%#s' % tuple(s.split(',')) for s in longlist]
longlist.sort()

> Also, what appears to be your revised data structure, strval + ',' +
> '%5.5d' % intval , assumes the strval is fixed length, also.

No it does not, and need not. ',' precedes all letters in ascii order. 
(Ok, I assumed that the 'word' field does not include any of 
!"#$%&'()*+. If that is not true, replace comma with space or even a 
control char such as '\a' which even precedes \t and \n.) Given the 
context of Google, I assumed that 'word' meant word, as in a web 
document, while the int might be a position or doc number (or both). The 
important point is that the separator cause all word-int pairs with the 
same word to string-sort before all word-int pairs with the same word + 
a suffix. My example intentionally tested that.

>Consider the following strval, intval pairs, using your syntax:
>
> ['a,997, 1','a, 1000']
>
> Nothing says the strval wouldn't contain data that look like your
> structure...

The problem as presented. 'a,997' is not a word. In any case, as I said 
before, the method of correctly parsing the strings into two fields is 
already specified. I am only suggesting a change in how to proceed 
thereafter.

-- 
Terry Jan Reedy


From skip at pobox.com  Sun Mar 13 04:36:28 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 12 Mar 2011 21:36:28 -0600
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <4D7C1651.1070408@v.loewis.de>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>
	<AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>
	<795F80F1-CB8F-41D0-B5C3-910E4C81D906@gmail.com>
	<AANLkTinqXhr4OEKfsOaQ3kyXJr4QkzHKsLH7wxhCtGpC@mail.gmail.com>
	<19836.4420.725695.356644@montanaro.dyndns.org>
	<4D7C1651.1070408@v.loewis.de>
Message-ID: <19836.15292.63708.433145@montanaro.dyndns.org>

    Martin> I don't think any of the regular core committers got any such
    Martin> explicit veto powers on any code...

"Veto powers" is your term, not mine.  I suggested that Raymond's opinion
should be accorded extra weight.  This isn't the UN Security Council.

Skip

From martin at v.loewis.de  Sun Mar 13 04:48:23 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Mar 2011 22:48:23 -0500
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <19836.15292.63708.433145@montanaro.dyndns.org>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>
	<AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>
	<795F80F1-CB8F-41D0-B5C3-910E4C81D906@gmail.com>
	<AANLkTinqXhr4OEKfsOaQ3kyXJr4QkzHKsLH7wxhCtGpC@mail.gmail.com>
	<19836.4420.725695.356644@montanaro.dyndns.org>
	<4D7C1651.1070408@v.loewis.de>
	<19836.15292.63708.433145@montanaro.dyndns.org>
Message-ID: <4D7C3E87.90006@v.loewis.de>

Am 12.03.11 22:36, schrieb skip at pobox.com:
>      Martin>  I don't think any of the regular core committers got any such
>      Martin>  explicit veto powers on any code...
>
> "Veto powers" is your term, not mine.  I suggested that Raymond's opinion
> should be accorded extra weight.  This isn't the UN Security Council.

Yes, but you were comparing it with ElementTree, where Fredrik *does*
have veto powers. I was pointing out that the case at hand is different.

Regards,
Martin

From v+python at g.nevcal.com  Sun Mar 13 04:52:24 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Sat, 12 Mar 2011 19:52:24 -0800
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <ilhd74$cg9$1@dough.gmane.org>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>	<ilgqv0$5f0$1@dough.gmane.org>	<4D7C224E.3060400@g.nevcal.com>
	<ilhd74$cg9$1@dough.gmane.org>
Message-ID: <4D7C3F78.7070105@g.nevcal.com>

On 3/12/2011 7:21 PM, Terry Reedy wrote:
> (Ok, I assumed that the 'word' field does not include any of 
> !"#$%&'()*+. If that is not true, replace comma with space or even a 
> control char such as '\a' which even precedes \t and \n.)

OK, I agree the above was your worst assumption, although you need to 
add "," to your list also, because that allows for the data puns.

You also rewrote Guido's text from "shortstring" to "word" and assumed 
it had certain content semantics, but since only integer is after the 
",", rsplit would work to separate the fields even if shortstring 
contains ",".

And the choice of delimiter really determines whether data puns can 
exist.  If and only if you know that there is a character that is lower 
in sort order than any of the characters in the sort strings, can you 
"cheat" and put a variable length string into a sort key field, by 
terminating it with such a character.  The safest such character is \0, 
unless you are coding in C, then \a as you now suggest, but only if you 
can be 100% sure it is not found in the data.  If you cannot guarantee 
the data doesn't contain them, there will be the possibility of data 
puns among variable length strings, and the algorithms will sort wrong 
in pathological cases.

I wouldn't have called you on this, except that it really is important 
not to give people the idea that you can blithely use a variable length 
string anywhere except at the tail of a multi-field sort string.  In 
general, you can't.  I've long since lost track of the number of times 
I've helped people understand the fix to programs that tried that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/57631b52/attachment.html>

From skip at pobox.com  Sun Mar 13 04:54:03 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 12 Mar 2011 21:54:03 -0600
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <4D7C3E87.90006@v.loewis.de>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<AANLkTi=pv_c_q8zkVnUu+BKA32+R6zsSGXTvm=HU8gDj@mail.gmail.com>
	<AANLkTimA7ea+wrYMEamGOLbh1esd59pgRFbgXmYt+atR@mail.gmail.com>
	<795F80F1-CB8F-41D0-B5C3-910E4C81D906@gmail.com>
	<AANLkTinqXhr4OEKfsOaQ3kyXJr4QkzHKsLH7wxhCtGpC@mail.gmail.com>
	<19836.4420.725695.356644@montanaro.dyndns.org>
	<4D7C1651.1070408@v.loewis.de>
	<19836.15292.63708.433145@montanaro.dyndns.org>
	<4D7C3E87.90006@v.loewis.de>
Message-ID: <19836.16347.414437.522579@montanaro.dyndns.org>

>>>>> "Martin" == Martin v L?wis <martin at v.loewis.de> writes:

    Martin> Am 12.03.11 22:36, schrieb skip at pobox.com:
    Martin> I don't think any of the regular core committers got any such
    Martin> explicit veto powers on any code...
    >> 
    >> "Veto powers" is your term, not mine.  I suggested that Raymond's opinion
    >> should be accorded extra weight.  This isn't the UN Security Council.

    Martin> Yes, but you were comparing it with ElementTree, where Fredrik
    Martin> *does* have veto powers. I was pointing out that the case at
    Martin> hand is different.

I didn't know that, nor did I infer that Fredrik had veto power.  I wrote:

    I think we would give reasonably large weight to Fredrik Lundh's opinion
    on the change.

Skip

From tjreedy at udel.edu  Sun Mar 13 08:02:36 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 13 Mar 2011 03:02:36 -0400
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <4D7C3F78.7070105@g.nevcal.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>	<ilgqv0$5f0$1@dough.gmane.org>	<4D7C224E.3060400@g.nevcal.com>	<ilhd74$cg9$1@dough.gmane.org>
	<4D7C3F78.7070105@g.nevcal.com>
Message-ID: <ilhq67$p9r$1@dough.gmane.org>

On 3/12/2011 10:52 PM, Glenn Linderman wrote:
> On 3/12/2011 7:21 PM, Terry Reedy wrote:

> The safest such character is \0,\

Works fine in Python.

> unless you are coding in C,

Then \01 is next best.

> I wouldn't have called you on this, except that it really is important
> not to give people the idea that you can blithely use a variable length
> string anywhere except at the tail of a multi-field sort string.

Sorry, my initial brief comment was for people on this list who I 
assumed understood the issue.

> general, you can't. I've long since lost track of the number of times
> I've helped people understand the fix to programs that tried that.

Thanks for explaining. I also get fussy about things I have explained 
too many time ;-).

-- 
Terry Jan Reedy


From g.brandl at gmx.net  Sun Mar 13 11:49:24 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 13 Mar 2011 11:49:24 +0100
Subject: [Python-Dev] Python 3.4 version in the tracker
In-Reply-To: <4D7B9AAE.9060909@trueblade.com>
References: <4D7B8284.4040202@trueblade.com> <4D7B9772.3010803@netwok.org>
	<4D7B9AAE.9060909@trueblade.com>
Message-ID: <ili7h5$d2p$1@dough.gmane.org>

On 12.03.2011 17:09, Eric Smith wrote:
> On 03/12/2011 10:55 AM, ?ric Araujo wrote:
>>> I have a deprecation warning that I need to make an error in 3.4.
>>
>> A neat trick to remember to do those changes is using a test that fails
>> if something does not raise a DeprecationWarning if sys.version_info[:2]
>> == (3, 3), or an error if sys.version_info[:3] == (3, 4).  You write
>> those tests once and let ?make test? remind you as soon as the Python
>> version changes.
> 
> I like the idea, but it seems a little hostile to the person who 
> actually changes the version number!

If it helps to remember these things (usually deprecations) that we've often
forgotten in the past, I don't mind being the one to innocently break the
buildbots by increasing the version number.

cheers,
Georg


From ncoghlan at gmail.com  Sun Mar 13 12:25:46 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 13 Mar 2011 07:25:46 -0400
Subject: [Python-Dev] Using feature branches for local development
Message-ID: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>

I'm experimenting with creating some local branches for things I'd
like to work on during the sprints this week, and have a couple of
questions about the associated workflow.

1. While the feature branches are active, is it correct that I can't
use a bare "hg push" any more, since I don't want to push the feature
branches to hg.python.org? Instead, I need to name all the branches I
want to push explicitly.

2. Once I'm done with the feature branch, I need to nuke it somehow
(e.g. by enabling the mq extension to gain access to "hg strip"
command)

If those are both accurate, I may actually create a new subclone,
leaving the main local repository with only the changes I actually
want to push upstream.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From stephen at xemacs.org  Sun Mar 13 12:56:04 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 13 Mar 2011 20:56:04 +0900
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
Message-ID: <AANLkTi=JYWBG2wBoEqmn31r8uEmdS5cJ6-Qv+RjotzDF@mail.gmail.com>

On Sun, Mar 13, 2011 at 8:25 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 1. While the feature branches are active, is it correct that I can't
> use a bare "hg push" any more, since I don't want to push the feature
> branches to hg.python.org? Instead, I need to name all the branches I
> want to push explicitly.

More or less.  If you only want to push the default branch, you could put

[alias]
pdef = push -r default

in the .hg/hgrc as an alias.

> 2. Once I'm done with the feature branch, I need to nuke it somehow
> (e.g. by enabling the mq extension to gain access to "hg strip"
> command)

You may *want* to do that, but hg branch obsolete-branch;
hg commit -m "I'm done" --close should also do the trick of getting
it out of the way of most commands.

> If those are both accurate, I may actually create a new subclone,
> leaving the main local repository with only the changes I actually
> want to push upstream.

This is also a good way to work for many people, I think.

I personally manage my not-ready-for-prime time code with mq, though.
This should protect you from pushing code you're not ready to publish.
(hg will tell you

wideload:test/b 20:54$ hg push
pushing to /private/tmp/test/a
abort: source has mq patches applied

if you try to push with patches applied to the workspace.)

From dirkjan at ochtman.nl  Sun Mar 13 12:57:33 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Sun, 13 Mar 2011 12:57:33 +0100
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
Message-ID: <AANLkTimRGm_m2ENZZT=WyaeyHzh7J69F9boRfcdp0HfN@mail.gmail.com>

On Sun, Mar 13, 2011 at 12:25, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I'm experimenting with creating some local branches for things I'd
> like to work on during the sprints this week, and have a couple of
> questions about the associated workflow.

By local branches, do you mean named branches (using the hg branch
command to set a branch name), or unnamed extra heads/extra clones?

> 1. While the feature branches are active, is it correct that I can't
> use a bare "hg push" any more, since I don't want to push the feature
> branches to hg.python.org? Instead, I need to name all the branches I
> want to push explicitly.

The easy solution is to use a local clone and not push from it to
hg.p.o at all. hg push does indeed push all branches (named and
unnamed) by default.

> 2. Once I'm done with the feature branch, I need to nuke it somehow
> (e.g. by enabling the mq extension to gain access to "hg strip"
> command)

You're implying you want to smash the feature branch down to a single
patch? In that case, yeah.

> If those are both accurate, I may actually create a new subclone,
> leaving the main local repository with only the changes I actually
> want to push upstream.

That's the easy solution. The slightly harder, but more powerful,
solution is to learn MQ.

Cheers,

Dirkjan

From ncoghlan at gmail.com  Sun Mar 13 13:05:42 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 13 Mar 2011 08:05:42 -0400
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <AANLkTi=JYWBG2wBoEqmn31r8uEmdS5cJ6-Qv+RjotzDF@mail.gmail.com>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
	<AANLkTi=JYWBG2wBoEqmn31r8uEmdS5cJ6-Qv+RjotzDF@mail.gmail.com>
Message-ID: <AANLkTik8DQ1abPfD+9uY1jX3T5qR5uEuxUG6RrqSaTMi@mail.gmail.com>

On Sun, Mar 13, 2011 at 7:56 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>> 2. Once I'm done with the feature branch, I need to nuke it somehow
>> (e.g. by enabling the mq extension to gain access to "hg strip"
>> command)
>
> You may *want* to do that, but hg branch obsolete-branch;
> hg commit -m "I'm done" --close should also do the trick of getting
> it out of the way of most commands.

Alas, "hg outgoing" isn't one of those commands.

Since I've enabled mq anyway, I may just start learning how to use it :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From p.f.moore at gmail.com  Sun Mar 13 13:14:25 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 13 Mar 2011 12:14:25 +0000
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <D0ACF24F-6B5F-472E-B249-541571A7FB43@gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<D0ACF24F-6B5F-472E-B249-541571A7FB43@gmail.com>
Message-ID: <AANLkTi=rP=_oQVgO1JQ6EWCcApwAaN9Y_Q6wZx+4d88r@mail.gmail.com>

On 13 March 2011 03:00, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
>> But in Python 3 this solution is no longer available. How bad is that?
>> I'm not sure. But I'd like to at least get the issue out in the open.
>>
>
> Python3.2 should be substantially better in this regard.
> It no longer wraps key objects around every input. ?Instead, it
> sorts two parallel arrays of pointers. ? You can thank Daniel
> Stutzbach (another Googler I believe) for this effort.

For what it's worth:

PS D:\Data> D:\Apps\Python27\python.exe -m timeit -s "L = [(1,2),
(3,4), (0,5), (9,100), (3,7), (2,8)]" "sorted(L, lambda (p,q),(r,s):
cmp(p*s, q*r))"
100000 loops, best of 3: 5.19 usec per loop
PS D:\Data> D:\Apps\Python27\python.exe -m timeit -s "L = [(1,2),
(3,4), (0,5), (9,100), (3,7), (2,8)]" -s "from fractions import
Fraction" "sorted(L, key=lambda t: Fraction(*t))"
10000 loops, best of 3: 51.6 usec per loop
PS D:\Data> D:\Apps\Python27\python.exe -m timeit -s "L = [(1,2),
(3,4), (0,5), (9,100), (3,7), (2,8)]" -s "from fcomp import Fcomp"
"sorted(L, key=Fcomp)"
100000 loops, best of 3: 8.6 usec per loop
PS D:\Data> D:\Apps\Python32\python.exe -m timeit -s "L = [(1,2),
(3,4), (0,5), (9,100), (3,7), (2,8)]" -s "from fractions import
Fraction" "sorted(L, key=lambda t: Fraction(*t))"
10000 loops, best of 3: 64.4 usec per loop
PS D:\Data> D:\Apps\Python32\python.exe -m timeit -s "L = [(1,2),
(3,4), (0,5), (9,100), (3,7), (2,8)]" -s "from fcomp import Fcomp"
"sorted(L, key=Fcomp)"
100000 loops, best of 3: 8.41 usec per loop

This says to me that using Fraction as a key is substantially worse
(and worse still in 3.2 over 2.7). Using a custom key is closer to a
comparison function (but still 60-70% slower) and is marginally faster
in 3.2. Clearly, the nature of the key is critical here, so take this
with even more of a pinch of salt than you normally would with a
benchmark.

None of my real code is affected either way, but it seems to me that
the removal of the comparison function option was (sadly) a case of
purity being allowed to beat practicality. Luckily, adding it back
wouldn't be a backward compatibility issue :-) Whether it's worth
doing, I'll leave to those who would be doing the work to judge...

Paul.

From eliben at gmail.com  Sun Mar 13 13:32:55 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Sun, 13 Mar 2011 14:32:55 +0200
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
Message-ID: <AANLkTik7u1eE9rsXHA1rWje3qwwGCnqorMqY78LWVXQu@mail.gmail.com>

On Sun, Mar 13, 2011 at 13:25, Nick Coghlan <ncoghlan at gmail.com> wrote:

> I'm experimenting with creating some local branches for things I'd
> like to work on during the sprints this week, and have a couple of
> questions about the associated workflow.
>

The way to do this, IMHO, is just create a local clone and work on it. Then
you can keep checking partial changes in without ever worrying about
accidentally modifying the official repo. Especially if some of this work is
experimental and bound to eventually be thrown away, I think it's a more
flexible way to work than use MQ.

One thing to keep in mind though is backup. I may be paranoid, but I just
can't do anything of importance on a local machine (especially a laptop) for
any prolonged period of time without occasional backups. Thankfully, a
Mercurial repo is about the best tool you have for backing things up - just
remote clone it to bitbucket, google code or some place of your own and
periodically push there.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110313/d487a32f/attachment.html>

From ncoghlan at gmail.com  Sun Mar 13 13:41:18 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 13 Mar 2011 08:41:18 -0400
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <AANLkTik7u1eE9rsXHA1rWje3qwwGCnqorMqY78LWVXQu@mail.gmail.com>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
	<AANLkTik7u1eE9rsXHA1rWje3qwwGCnqorMqY78LWVXQu@mail.gmail.com>
Message-ID: <AANLkTinYSM=0OUERiP2GgGqr0+bj+Y=geEQS4uz=KZj3@mail.gmail.com>

On Sun, Mar 13, 2011 at 8:32 AM, Eli Bendersky <eliben at gmail.com> wrote:
> The way to do this, IMHO, is just create a local clone and work on it. Then
> you can keep checking partial changes in without ever worrying about
> accidentally modifying the official repo. Especially if some of this work is
> experimental and bound to eventually be thrown away, I think it's a more
> flexible way to work than use MQ.
>
> One thing to keep in mind though is backup. I may be paranoid, but I just
> can't do anything of importance on a local machine (especially a laptop) for
> any prolonged period of time without occasional backups. Thankfully, a
> Mercurial repo is about the best tool you have for backing things up - just
> remote clone it to bitbucket, google code or some place of your own and
> periodically push there.

Since I have multiple machines to keep in sync, I'm actually thinking
a server side sandbox clone is the way to go. That will solve my local
issue as well (since the sandbox clone will be separate from the main
clone).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Sun Mar 13 13:47:29 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 13 Mar 2011 08:47:29 -0400
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
Message-ID: <4D7CBCE1.8030708@v.loewis.de>

Am 13.03.11 07:25, schrieb Nick Coghlan:
> I'm experimenting with creating some local branches for things I'd
> like to work on during the sprints this week, and have a couple of
> questions about the associated workflow.
>
> 1. While the feature branches are active, is it correct that I can't
> use a bare "hg push" any more, since I don't want to push the feature
> branches to hg.python.org?

Despite what anybody told so far: yes, you can continue to use a bare
"hg push". In the clone, edit .hg/hgrc, and have "default" point to the
remote repository you want to push to. As the remote repository, you
can use one of those you created with a remote clone.

If you want to continue to pull from cpython to merge upstream
changes, set up a default-push path in .hg/hgrc. Then pull will
get incoming changes cpython, outgoing changes go to the sandbox
repository.

> 2. Once I'm done with the feature branch, I need to nuke it somehow
> (e.g. by enabling the mq extension to gain access to "hg strip"
> command)

I think this will need reconsidertion. Apparently, the recommendation
is that you need to flatten all changes into a single commit when
integrating is. The way I would do it is to produce a diff, and apply
a patch to cpython. One way of producing the patch is to use "hg 
outgoing", another is to use a named branch in your clone and do
"hg diff default feature".

The mercurial-recommended way is that you just push your changes to 
cpython when done, which puts all your individual commits into Python's 
history.

I tried to find an official statement on which way it should be in the 
devguide, but couldn't find anything.

Regards,
Martin

From roundup-admin at psf.upfronthosting.co.za  Sat Mar 12 18:58:26 2011
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Sat, 12 Mar 2011 17:58:26 +0000
Subject: [Python-Dev] Failed issue tracker submission
Message-ID: <20110312175826.8FA5E1CE83@psf.upfronthosting.co.za>


You are not permitted to edit property stage of class issue.
-------------- next part --------------
Return-Path: <python-dev at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id 2E3A11CD34
	for <report at bugs.python.org>; Sat, 12 Mar 2011 18:58:26 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id E301AEE981
	for <report at bugs.python.org>; Sat, 12 Mar 2011 18:58:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1299952705; bh=qYZ+1soa1lYFkl/MBhE0kMaEkm6EP9xi0HD2EZzhmNM=;
	h=Date:Message-Id:Content-Type:MIME-Version:
	 Content-Transfer-Encoding:From:To:Subject;
	b=wHQXREQx40bwINh4NztNuqvbAdeCrdv15TW2zjpZfVksU2wtp/dnIR2PMJhst3tak
	 Awt/95dyrM5Q/9bbYgphd8Zs0Ldnhr8halDZNoPWv/cFbpDyAn4SUQUNBZzc02MGjC
	 gxzVgik0GgKUPQrnX5YwTnofVxzLkEE2dqzDMP2U=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 12 Mar 2011 18:58:25 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.python.org (Postfix) with ESMTPS
	for <report at bugs.python.org>; Sat, 12 Mar 2011 18:58:25 +0100 (CET)
Received: from localhost
	([127.0.0.1] helo=dinsdale.python.org ident=hg)
	by dinsdale.python.org with esmtp (Exim 4.72)
	(envelope-from <python-dev at python.org>)
	id 1PyT56-0007cT-FG
	for report at bugs.python.org; Sat, 12 Mar 2011 18:58:24 +0100
Date: Sat, 12 Mar 2011 18:58:24 +0100
Message-Id: <E1PyT56-0007cT-FG at dinsdale.python.org>
Content-Type: text/plain; charset="utf8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
From: python-dev at python.org
To: report at bugs.python.org
Subject: [issue11475] [status=closed; resolution=fixed;
	stage=committed/rejected]

TmV3IGNoYW5nZXNldCA3ZmQwNjc3M2MzYzIgYnkgQmVuamFtaW4gUGV0ZXJzb24gaW4gYnJhbmNo
ICczLjEnOgp0cnVuYyAtPiBtYXRoLnRydW5jIChjbG9zZXMgIzExNDc1KQpodHRwOi8vaGcucHl0
aG9uLm9yZy9jcHl0aG9uL3Jldi83ZmQwNjc3M2MzYzIKCgpOZXcgY2hhbmdlc2V0IDBlYjIzZGVk
YjAzYyBieSBCZW5qYW1pbiBQZXRlcnNvbiBpbiBicmFuY2ggJzIuNyc6CnRydW5jIC0+IG1hdGgu
dHJ1bmMgKGNsb3NlcyAjMTE0NzUpCmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2LzBl
YjIzZGVkYjAzYwo=

From roundup-admin at psf.upfronthosting.co.za  Sun Mar 13 00:11:29 2011
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Sat, 12 Mar 2011 23:11:29 +0000
Subject: [Python-Dev] Failed issue tracker submission
Message-ID: <20110312231129.6BC041CCEF@psf.upfronthosting.co.za>


You are not permitted to edit property stage of class issue.
-------------- next part --------------
Return-Path: <python-dev at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id 075991CE7D
	for <report at bugs.python.org>; Sun, 13 Mar 2011 00:11:29 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id C23D6EEB44
	for <report at bugs.python.org>; Sun, 13 Mar 2011 00:11:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1299971488; bh=ZO2sKQ6jd1TrEYAI+tiEvF5y9+PgMMuHX2WWQDp0bnw=;
	h=Date:Message-Id:Content-Type:MIME-Version:
	 Content-Transfer-Encoding:From:To:Subject;
	b=qcbzdeBjE9gfe3Ndft/j0SP7zLwuFGa++K1MsuhJ1Uor8zkuv61hyDeKzW0ZY6OB+
	 Go+whgYoMvp0qWvxE4kBNMfV5pVIlOLeTH3wcnL3jDmTdIKd60qfFKMdB3LpSzYPo3
	 fCY2j5P3m3chXfY9YTjJGJbK4ybtI0uC4kpA9xJU=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 13 Mar 2011 00:11:28 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.python.org (Postfix) with ESMTPS
	for <report at bugs.python.org>; Sun, 13 Mar 2011 00:11:28 +0100 (CET)
Received: from localhost
	([127.0.0.1] helo=dinsdale.python.org ident=hg)
	by dinsdale.python.org with esmtp (Exim 4.72)
	(envelope-from <python-dev at python.org>)
	id 1PyXy4-0003JY-Jx
	for report at bugs.python.org; Sun, 13 Mar 2011 00:11:28 +0100
Date: Sun, 13 Mar 2011 00:11:28 +0100
Message-Id: <E1PyXy4-0003JY-Jx at dinsdale.python.org>
Content-Type: text/plain; charset="utf8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
From: python-dev at python.org
To: report at bugs.python.org
Subject: [issue11312] [status=closed; resolution=fixed;
	stage=committed/rejected]

TmV3IGNoYW5nZXNldCBjMDE3Njk1YWNmMTkgYnkgQmVuamFtaW4gUGV0ZXJzb24gaW4gYnJhbmNo
ICcyLjcnOgpjbGFyaWZ5IGNvbmRpdGlvbiBmb3IgcmVhZGxpbmUgdG8gcmV0dXJuIEVPRiAoY2xv
c2VzICMxMTMxMikKaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvYzAxNzY5NWFjZjE5
Cg==

From roundup-admin at psf.upfronthosting.co.za  Sun Mar 13 00:30:55 2011
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Sat, 12 Mar 2011 23:30:55 +0000
Subject: [Python-Dev] Failed issue tracker submission
Message-ID: <20110312233055.37FD71CD34@psf.upfronthosting.co.za>


You are not permitted to edit property stage of class issue.
-------------- next part --------------
Return-Path: <python-dev at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id D03D11CCEF
	for <report at bugs.python.org>; Sun, 13 Mar 2011 00:30:54 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id 91C45EEA3B
	for <report at bugs.python.org>; Sun, 13 Mar 2011 00:30:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1299972654; bh=YEfRd87zUD9hUNRPQ0gW/hovinbL3pZoGbabcdfUpGU=;
	h=Date:Message-Id:Content-Type:MIME-Version:
	 Content-Transfer-Encoding:From:To:Subject;
	b=Lne+0Te3eUe78ACgJ/bd+w5w1kpdpCqG/g9KvpoyrohiMrDY0TU8ejIMhpYO8hx/W
	 OtEH1COtBcujwb6w0O8pGyDLovo8D4+GFKJ+S2ziOn+kYEjyHYfiJZIbEj+BPswhXq
	 f1LkEzapQxWETAOMqoj6xFbZ5S/+9zlTYqgtQSTU=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 13 Mar 2011 00:30:54 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.python.org (Postfix) with ESMTPS
	for <report at bugs.python.org>; Sun, 13 Mar 2011 00:30:54 +0100 (CET)
Received: from localhost
	([127.0.0.1] helo=dinsdale.python.org ident=hg)
	by dinsdale.python.org with esmtp (Exim 4.72)
	(envelope-from <python-dev at python.org>)
	id 1PyYGs-0005xP-GA
	for report at bugs.python.org; Sun, 13 Mar 2011 00:30:54 +0100
Date: Sun, 13 Mar 2011 00:30:54 +0100
Message-Id: <E1PyYGs-0005xP-GA at dinsdale.python.org>
Content-Type: text/plain; charset="utf8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
From: python-dev at python.org
To: report at bugs.python.org
Subject: [issue2771] [status=closed; resolution=fixed;
	stage=committed/rejected]

TmV3IGNoYW5nZXNldCBkMGY5N2QyN2I4ZjggYnkgQW50b2luZSBQaXRyb3UgaW4gYnJhbmNoICdk
ZWZhdWx0JzoKY2xvc2VzICMyNzcxCmh0dHA6Ly9oZy5weXRob24ub3JnL3Rlc3QvcmV2L2QwZjk3
ZDI3YjhmOAo=

From roundup-admin at psf.upfronthosting.co.za  Sun Mar 13 00:31:58 2011
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Sat, 12 Mar 2011 23:31:58 +0000
Subject: [Python-Dev] Failed issue tracker submission
Message-ID: <20110312233158.4827A1CD34@psf.upfronthosting.co.za>


You are not permitted to edit property stage of class issue.
-------------- next part --------------
Return-Path: <python-dev at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id E18F41CCEF
	for <report at bugs.python.org>; Sun, 13 Mar 2011 00:31:57 +0100 (CET)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id A71FEEE9D3
	for <report at bugs.python.org>; Sun, 13 Mar 2011 00:31:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1299972717; bh=Ibp6eWhVeNrklL/k3hji/5Ii1lOezo53S23METjDw1I=;
	h=Date:Message-Id:Content-Type:MIME-Version:
	 Content-Transfer-Encoding:From:To:Subject;
	b=SFvsALnuTMjXJDF/BlVNobKujYGwQR3VvGbWp+BoRydAeuxb4zXAnjJI1eZl5owoM
	 /Qj50uWq8D/7SlkGBPGrzYamqa2N4j0xyaWH4UZIhXYFJuO5aywdJY3/sNI3WlGRyC
	 X0/K3wAlalv9IHS1LddFM+0jQau87LgY/CqpA8S8=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 13 Mar 2011 00:31:57 +0100
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.python.org (Postfix) with ESMTPS
	for <report at bugs.python.org>; Sun, 13 Mar 2011 00:31:57 +0100 (CET)
Received: from localhost
	([127.0.0.1] helo=dinsdale.python.org ident=hg)
	by dinsdale.python.org with esmtp (Exim 4.72)
	(envelope-from <python-dev at python.org>)
	id 1PyYHt-000633-JZ
	for report at bugs.python.org; Sun, 13 Mar 2011 00:31:57 +0100
Date: Sun, 13 Mar 2011 00:31:57 +0100
Message-Id: <E1PyYHt-000633-JZ at dinsdale.python.org>
Content-Type: text/plain; charset="utf8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
From: python-dev at python.org
To: report at bugs.python.org
Subject: [issue2771] [status=closed; resolution=fixed;
	stage=committed/rejected]

TmV3IGNoYW5nZXNldCA3N2Q0Nzg2YWFlMjkgYnkgQW50b2luZSBQaXRyb3UgaW4gYnJhbmNoICdk
ZWZhdWx0JzoKY2xvc2VzICMyNzcxCmh0dHA6Ly9oZy5weXRob24ub3JnL3Rlc3QvcmV2Lzc3ZDQ3
ODZhYWUyOQo=

From eliben at gmail.com  Sun Mar 13 14:19:06 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Sun, 13 Mar 2011 15:19:06 +0200
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <AANLkTinYSM=0OUERiP2GgGqr0+bj+Y=geEQS4uz=KZj3@mail.gmail.com>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
	<AANLkTik7u1eE9rsXHA1rWje3qwwGCnqorMqY78LWVXQu@mail.gmail.com>
	<AANLkTinYSM=0OUERiP2GgGqr0+bj+Y=geEQS4uz=KZj3@mail.gmail.com>
Message-ID: <AANLkTim-9p-tD6JZL5p-ZbWj_7X6s=1xXLvuL3JXW3XZ@mail.gmail.com>

On Sun, Mar 13, 2011 at 14:41, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Sun, Mar 13, 2011 at 8:32 AM, Eli Bendersky <eliben at gmail.com> wrote:
> > The way to do this, IMHO, is just create a local clone and work on it.
> Then
> > you can keep checking partial changes in without ever worrying about
> > accidentally modifying the official repo. Especially if some of this work
> is
> > experimental and bound to eventually be thrown away, I think it's a more
> > flexible way to work than use MQ.
> >
> > One thing to keep in mind though is backup. I may be paranoid, but I just
> > can't do anything of importance on a local machine (especially a laptop)
> for
> > any prolonged period of time without occasional backups. Thankfully, a
> > Mercurial repo is about the best tool you have for backing things up -
> just
> > remote clone it to bitbucket, google code or some place of your own and
> > periodically push there.
>
> Since I have multiple machines to keep in sync, I'm actually thinking
> a server side sandbox clone is the way to go. That will solve my local
> issue as well (since the sandbox clone will be separate from the main
> clone).
>

This is precisely what I do, since I routinely commit to personal Mercurial
repos from 3 different machines.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110313/1b5fdd63/attachment.html>

From ncoghlan at gmail.com  Sun Mar 13 14:28:28 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 13 Mar 2011 09:28:28 -0400
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <4D7CBCE1.8030708@v.loewis.de>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
	<4D7CBCE1.8030708@v.loewis.de>
Message-ID: <AANLkTinf1h7_N8LgcJ8KNw4mGstg1_Lz6SMX7SC8Mi+k@mail.gmail.com>

On Sun, Mar 13, 2011 at 8:47 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 13.03.11 07:25, schrieb Nick Coghlan:
>> 2. Once I'm done with the feature branch, I need to nuke it somehow
>> (e.g. by enabling the mq extension to gain access to "hg strip"
>> command)
>
> I think this will need reconsidertion. Apparently, the recommendation
> is that you need to flatten all changes into a single commit when
> integrating is. The way I would do it is to produce a diff, and apply
> a patch to cpython. One way of producing the patch is to use "hg outgoing",
> another is to use a named branch in your clone and do
> "hg diff default feature".

Yeah, I just created a sandbox/ncoghlan code that I'll use to track
all my "in-progress" stuff, then I'll generate a diff to apply to my
local clone of the cpython repository.

> The mercurial-recommended way is that you just push your changes to cpython
> when done, which puts all your individual commits into Python's history.
>
> I tried to find an official statement on which way it should be in the
> devguide, but couldn't find anything.

It's definitely the latter, but I don't think it is explicitly
documented yet that this applies to all pushes, not just patches from
the tracker.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Sun Mar 13 14:44:42 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 13 Mar 2011 14:44:42 +0100
Subject: [Python-Dev] Using feature branches for local development
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
	<4D7CBCE1.8030708@v.loewis.de>
	<AANLkTinf1h7_N8LgcJ8KNw4mGstg1_Lz6SMX7SC8Mi+k@mail.gmail.com>
Message-ID: <20110313144442.260c8bb4@pitrou.net>

On Sun, 13 Mar 2011 09:28:28 -0400
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> > The mercurial-recommended way is that you just push your changes to cpython
> > when done, which puts all your individual commits into Python's history.
> >
> > I tried to find an official statement on which way it should be in the
> > devguide, but couldn't find anything.
> 
> It's definitely the latter, but I don't think it is explicitly
> documented yet that this applies to all pushes, not just patches from
> the tracker.

I think we (python-dev) will need to take a decision on this.

My personal opinion is that we don't want to see all intermediate
commits which led to a patch (or feature) in the main repo. It may
also lead to many spurious buildbot builds (some of them probably
failing), and many commit notifications on python-checkins: you could
see an example of the latter with the distutils2 pushes.

The counter-argument is that preserving the development history can
make changes more understandable. That's only if the history reflects
the logical separation of changes, though.

If someone wants to split their work into several changesets, a patch
series using mq could also be the recommended way (that's how
mercurial-devel works).

Regards

Antoine.



From eric at trueblade.com  Sun Mar 13 14:47:49 2011
From: eric at trueblade.com (Eric Smith)
Date: Sun, 13 Mar 2011 09:47:49 -0400
Subject: [Python-Dev] Python 3.4 version in the tracker
In-Reply-To: <ili7h5$d2p$1@dough.gmane.org>
References: <4D7B8284.4040202@trueblade.com>
	<4D7B9772.3010803@netwok.org>	<4D7B9AAE.9060909@trueblade.com>
	<ili7h5$d2p$1@dough.gmane.org>
Message-ID: <4D7CCB05.1080508@trueblade.com>

On 03/13/2011 06:49 AM, Georg Brandl wrote:
> On 12.03.2011 17:09, Eric Smith wrote:
>> On 03/12/2011 10:55 AM, ?ric Araujo wrote:
>>>> I have a deprecation warning that I need to make an error in 3.4.
>>>
>>> A neat trick to remember to do those changes is using a test that fails
>>> if something does not raise a DeprecationWarning if sys.version_info[:2]
>>> == (3, 3), or an error if sys.version_info[:3] == (3, 4).  You write
>>> those tests once and let ?make test? remind you as soon as the Python
>>> version changes.
>>
>> I like the idea, but it seems a little hostile to the person who
>> actually changes the version number!
>
> If it helps to remember these things (usually deprecations) that we've often
> forgotten in the past, I don't mind being the one to innocently break the
> buildbots by increasing the version number.

Are you volunteering to change all of the PendingDeprecationWarnings to 
DeprecationWarnings and DeprecationWarnings to errors of some sort? It 
might be a big job.

I'm just trying to figure out what the mechanics would be.

Eric.

From benjamin at python.org  Sun Mar 13 14:49:26 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 13 Mar 2011 08:49:26 -0500
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <20110313144442.260c8bb4@pitrou.net>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
	<4D7CBCE1.8030708@v.loewis.de>
	<AANLkTinf1h7_N8LgcJ8KNw4mGstg1_Lz6SMX7SC8Mi+k@mail.gmail.com>
	<20110313144442.260c8bb4@pitrou.net>
Message-ID: <AANLkTi=nwp8n0v4n8wkisXidX3mPaD0s-EXufn6Cs=q9@mail.gmail.com>

2011/3/13 Antoine Pitrou <solipsis at pitrou.net>:
> On Sun, 13 Mar 2011 09:28:28 -0400
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> > The mercurial-recommended way is that you just push your changes to cpython
>> > when done, which puts all your individual commits into Python's history.
>> >
>> > I tried to find an official statement on which way it should be in the
>> > devguide, but couldn't find anything.
>>
>> It's definitely the latter, but I don't think it is explicitly
>> documented yet that this applies to all pushes, not just patches from
>> the tracker.
>
> I think we (python-dev) will need to take a decision on this.
>
> My personal opinion is that we don't want to see all intermediate
> commits which led to a patch (or feature) in the main repo. It may
> also lead to many spurious buildbot builds (some of them probably
> failing), and many commit notifications on python-checkins: you could
> see an example of the latter with the distutils2 pushes.

+1 for collapsing commits into logical patches. Little is more
annoying than annotating something and finding out the commit message
was "oops, fix this thingy..." completely out of context of the larger
patch.

>
> The counter-argument is that preserving the development history can
> make changes more understandable. That's only if the history reflects
> the logical separation of changes, though.
>
> If someone wants to split their work into several changesets, a patch
> series using mq could also be the recommended way (that's how
> mercurial-devel works).



-- 
Regards,
Benjamin

From stephen at xemacs.org  Sun Mar 13 15:44:44 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 13 Mar 2011 23:44:44 +0900
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <AANLkTik8DQ1abPfD+9uY1jX3T5qR5uEuxUG6RrqSaTMi@mail.gmail.com>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
	<AANLkTi=JYWBG2wBoEqmn31r8uEmdS5cJ6-Qv+RjotzDF@mail.gmail.com>
	<AANLkTik8DQ1abPfD+9uY1jX3T5qR5uEuxUG6RrqSaTMi@mail.gmail.com>
Message-ID: <AANLkTimb+fz8rzsBDkvB9RZr2QaPd_4r470hTSrHn3qh@mail.gmail.com>

On Sun, Mar 13, 2011 at 9:05 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sun, Mar 13, 2011 at 7:56 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

>> You may *want* to do that, but hg branch obsolete-branch;
>> hg commit -m "I'm done" --close should also do the trick of getting
>> it out of the way of most commands.
>
> Alas, "hg outgoing" isn't one of those commands.

missing = hg outgoing -b default

That's not quite what you want of course, but it all depends on how
averse you are to learning mq.<wink>

From stephen at xemacs.org  Sun Mar 13 16:17:18 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 14 Mar 2011 00:17:18 +0900
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <AANLkTik7u1eE9rsXHA1rWje3qwwGCnqorMqY78LWVXQu@mail.gmail.com>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>
	<AANLkTik7u1eE9rsXHA1rWje3qwwGCnqorMqY78LWVXQu@mail.gmail.com>
Message-ID: <AANLkTikDTq8aEQ1Y+aNTjTRiaveicScv1Huq2eKPEP6=@mail.gmail.com>

On Sun, Mar 13, 2011 at 9:32 PM, Eli Bendersky <eliben at gmail.com> wrote:

> The way to do this, IMHO, is just create a local clone and work on it. Then
> you can keep checking partial changes in without ever worrying about
> accidentally modifying the official repo. Especially if some of this work is
> experimental and bound to eventually be thrown away, I think it's a more
> flexible way to work than use MQ.

The problem is that you need to be working in a straight line.  If there are
several related but unordered changes involved, once you've committed to
a branch it's rather annoying to reorder things.  mq makes such reordering
easy in many cases.

From merwok at netwok.org  Sun Mar 13 16:21:30 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 13 Mar 2011 16:21:30 +0100
Subject: [Python-Dev] Using feature branches for local development
In-Reply-To: <20110313144442.260c8bb4@pitrou.net>
References: <AANLkTi=Pc4i+KTmuG7-EtcOJnwEy1+QsmS5=a1pRRZxZ@mail.gmail.com>	<4D7CBCE1.8030708@v.loewis.de>	<AANLkTinf1h7_N8LgcJ8KNw4mGstg1_Lz6SMX7SC8Mi+k@mail.gmail.com>
	<20110313144442.260c8bb4@pitrou.net>
Message-ID: <4D7CE0FA.9010705@netwok.org>

tl;dr: +1 for pushing only clean changesets.

Le 13/03/2011 14:44, Antoine Pitrou a ?crit :
> I think we (python-dev) will need to take a decision on this.
> 
> My personal opinion is that we don't want to see all intermediate
> commits which led to a patch (or feature) in the main repo. It may
> also lead to many spurious buildbot builds (some of them probably
> failing), and many commit notifications on python-checkins: you could
> see an example of the latter with the distutils2 pushes.
> 
> The counter-argument is that preserving the development history can
> make changes more understandable. That's only if the history reflects
> the logical separation of changes, though.
> 
> If someone wants to split their work into several changesets, a patch
> series using mq could also be the recommended way (that's how
> mercurial-devel works).

Agreed.  +1 on pushing only clean changesets instead of a whole series
with different versions and fixes.  Most of the time that will be one
changeset, and when it makes the changes easier to read, more than one
(say for a fix in a docstring and doc file followed by a rewrite of that
part of the doc file).  I also think that it should be allowed to merge
a feature branch (unnamed!) that has taken some time to complete and
thus has many changesets (think io-in-c), as long as they are clean too:
It will be the same situation as with Subversion, only with nicer merge
changesets.

On another hand, it can be useful to see the whole life of a patch, but
this can be achieved by saving the repo with the intermediate changesets
somewhere.  Having unclean changesets with dead ends and fixes can have
educational value and help break the impression that developers don?t
make mistakes, which can prevent people from trying to contributing (for
more about that, see The Myth of the Programmer Genius:
http://www.youtube.com/watch?v=XeJSXfXep4M).

For a previous discussion about flattening a branch into a patch or not,
see http://mail.python.org/pipermail/python-ideas/2010-July/007538.html
(thread started by Tarek).

Finally, I?d say that using named branches or clones or MQ is the choice
of the developer; history editing is built-in with MQ, extensions like
collapse and histedit can work with branches, hg diff + import can
flatten too, so we don?t have to mandate one tool.  MQ is very powerful
and can be a life-saver, but its conflict handling is not as cool as
Mercurial?s, and I?ve had good success in cleaning branches with other
tools.

Regards

From martin at v.loewis.de  Sun Mar 13 19:03:31 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 13 Mar 2011 14:03:31 -0400
Subject: [Python-Dev] Submitting changes through Mercurial
Message-ID: <4D7D06F3.7020700@v.loewis.de>

I've added a feature in the bug tracker where submitters can post 
Mercurial repository URLs, and then repeatedly create patches. Roundup 
will extract the current patch (cpython-default:submitter-default),
and attach the patch to the issue (which then allows Rietveld review
of the patch).

Regards,
Martin

From stutzbach at google.com  Sun Mar 13 19:05:25 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sun, 13 Mar 2011 14:05:25 -0400
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
Message-ID: <AANLkTimO26878ji4XifEEbz0uYoNWp9gRyvRhhppuVoE@mail.gmail.com>

On Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum <guido at python.org> wrote:

> I recently advised a Googler who was sorting a large dataset and
> running out of memory. My analysis of the situation was that he was
> sorting a huge list of short lines of the form "shortstring,integer"
> with a key function that returned a tuple of the form ("shortstring",
> integer).


As Raymond pointed out, a change I made for 3.2 significantly shrinks the
memory footprint of sorting with a key (although it's still more
memory-intensive than sorting with cmp).

He could reduce the memory footprint further by sorting in two passes
instead of using a tuple, leveraging the fact that Python guarantees a
stable sort.  In 3.2 or later, this technique will require roughly twice as
much memory as just storing the list:

biglist.sort(key=lambda s: int(s.split(',')[1]))  # Sort by the integer
biglist.sort(key=lambda s: s.split(',')[0])  # Sort by the shortstring

I think the use cases are pretty narrow where there's plenty of memory for
storing the list but not enough to store two copies.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110313/93fb7a0f/attachment.html>

From solipsis at pitrou.net  Sun Mar 13 22:24:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 13 Mar 2011 22:24:25 +0100
Subject: [Python-Dev] cpython: bump ast version
References: <E1PyZGH-0001ed-UA@dinsdale.python.org>
Message-ID: <20110313222425.79991b3c@pitrou.net>

On Sun, 13 Mar 2011 01:34:21 +0100
benjamin.peterson <python-checkins at python.org> wrote:
> http://hg.python.org/cpython/rev/52940f7f3726
> changeset:   68416:52940f7f3726
> user:        Benjamin Peterson <benjamin at python.org>
> date:        Sat Mar 12 18:35:23 2011 -0600
> summary:
>   bump ast version
> 
> files:
>   Python/Python-ast.c
> 
> diff --git a/Python/Python-ast.c b/Python/Python-ast.c
> --- a/Python/Python-ast.c
> +++ b/Python/Python-ast.c
> @@ -2,7 +2,7 @@
>  
>  
>  /*
> -   __version__ 68409:c017695acf19.
> +   __version__ 68410:0daa6ba25d9b.

Is the version number necessary? It is local to the repository of the
person regenerating the file, and therefore not very reliable (for
example, 68410 on hg.python.org points to
http://hg.python.org/cpython/rev/f757b3b79c2a).

The changeset id should be sufficient.

Regards

Antoine.



From benjamin at python.org  Sun Mar 13 22:27:28 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 13 Mar 2011 16:27:28 -0500
Subject: [Python-Dev] cpython: bump ast version
In-Reply-To: <20110313222425.79991b3c@pitrou.net>
References: <E1PyZGH-0001ed-UA@dinsdale.python.org>
	<20110313222425.79991b3c@pitrou.net>
Message-ID: <AANLkTim-Q--j0yy4YySYb24iJrdCNEWY+MVwotahypZE@mail.gmail.com>

2011/3/13 Antoine Pitrou <solipsis at pitrou.net>:
> On Sun, 13 Mar 2011 01:34:21 +0100
> benjamin.peterson <python-checkins at python.org> wrote:
>> http://hg.python.org/cpython/rev/52940f7f3726
>> changeset: ? 68416:52940f7f3726
>> user: ? ? ? ?Benjamin Peterson <benjamin at python.org>
>> date: ? ? ? ?Sat Mar 12 18:35:23 2011 -0600
>> summary:
>> ? bump ast version
>>
>> files:
>> ? Python/Python-ast.c
>>
>> diff --git a/Python/Python-ast.c b/Python/Python-ast.c
>> --- a/Python/Python-ast.c
>> +++ b/Python/Python-ast.c
>> @@ -2,7 +2,7 @@
>>
>>
>> ?/*
>> - ? __version__ 68409:c017695acf19.
>> + ? __version__ 68410:0daa6ba25d9b.
>
> Is the version number necessary? It is local to the repository of the
> person regenerating the file, and therefore not very reliable (for
> example, 68410 on hg.python.org points to
> http://hg.python.org/cpython/rev/f757b3b79c2a).
>
> The changeset id should be sufficient.

I thought people might be comparing based on version numbers.



-- 
Regards,
Benjamin

From santoso.wijaya at gmail.com  Sun Mar 13 23:15:18 2011
From: santoso.wijaya at gmail.com (Santoso Wijaya)
Date: Sun, 13 Mar 2011 15:15:18 -0700
Subject: [Python-Dev] cpython: bump ast version
In-Reply-To: <AANLkTim-Q--j0yy4YySYb24iJrdCNEWY+MVwotahypZE@mail.gmail.com>
References: <E1PyZGH-0001ed-UA@dinsdale.python.org>
	<20110313222425.79991b3c@pitrou.net>
	<AANLkTim-Q--j0yy4YySYb24iJrdCNEWY+MVwotahypZE@mail.gmail.com>
Message-ID: <AANLkTikPXGbDcPE4kY8szVCdQvEvUpwQPDiczenr8rt_@mail.gmail.com>

A revision number is, indeed, local to the working repository. A changeset
ID, however is global.

>From Mercurial's documentation:

Revision numbers referring to changesets are very likely to be different in
another copy of a repository. Do not use them to talk about changesets with
other people. Use the changeset ID instead

See: http://mercurial.selenic.com/wiki/RevisionNumber

~/santa


On Sun, Mar 13, 2011 at 2:27 PM, Benjamin Peterson <benjamin at python.org>wrote:

> 2011/3/13 Antoine Pitrou <solipsis at pitrou.net>:
> > On Sun, 13 Mar 2011 01:34:21 +0100
> > benjamin.peterson <python-checkins at python.org> wrote:
> >> http://hg.python.org/cpython/rev/52940f7f3726
> >> changeset:   68416:52940f7f3726
> >> user:        Benjamin Peterson <benjamin at python.org>
> >> date:        Sat Mar 12 18:35:23 2011 -0600
> >> summary:
> >>   bump ast version
> >>
> >> files:
> >>   Python/Python-ast.c
> >>
> >> diff --git a/Python/Python-ast.c b/Python/Python-ast.c
> >> --- a/Python/Python-ast.c
> >> +++ b/Python/Python-ast.c
> >> @@ -2,7 +2,7 @@
> >>
> >>
> >>  /*
> >> -   __version__ 68409:c017695acf19.
> >> +   __version__ 68410:0daa6ba25d9b.
> >
> > Is the version number necessary? It is local to the repository of the
> > person regenerating the file, and therefore not very reliable (for
> > example, 68410 on hg.python.org points to
> > http://hg.python.org/cpython/rev/f757b3b79c2a).
> >
> > The changeset id should be sufficient.
>
> I thought people might be comparing based on version numbers.
>
>
>
> --
> Regards,
> Benjamin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110313/1e6fbf42/attachment.html>

From stutzbach at google.com  Sun Mar 13 23:27:15 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sun, 13 Mar 2011 18:27:15 -0400
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <ilh9fv$uv1$1@dough.gmane.org>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<AANLkTik0M7vHnwrdG4eG3_NCgBHZKid2hzxu5i0pRj7X@mail.gmail.com>
	<4D7C1DB9.9070502@pearwood.info> <ilh9fv$uv1$1@dough.gmane.org>
Message-ID: <AANLkTim1HQROYBja-V3MENhBG9_-Z0Fy0DrReDjsRKR-@mail.gmail.com>

On Sat, Mar 12, 2011 at 9:17 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> But in this case, they are much slower. To be faster, one would need
> something like "key=lambda p,q:p*(lcm//q)", where lcm is the least common
> multiple of of all the q's (denominators). For the example above, lcm = 700.
> But for longer lists, it could be outrageously large.
>

You can get away with less precision.  It's okay if the key function loses
some information, as long as it still has enough to distinguish each pair of
numbers.  In other words, you just need a number that's at least as large as
the largest lcm between any pair:

max_denominator_sq = max(q for p, q in fraction_list) ** 2  # Strictly
larger than the lcm between any pair
fraction_list.sort(key=lambda p, q: p*max_denominator_sq//q)

Using the above, key is 4 times faster than cmp in Python2.6:


stutzbach-glaptop:~$ python2.6 -m timeit -s 'fractions = [(i, j) for i in
range(100) for j in range(1, 100)]'  'sorted(fractions, cmp=lambda
(p,q),(r,s): cmp(p*s, q*r))'
10 loops, best of 3: 23.3 msec per loop

stutzbach-glaptop:~$ python2.6 -m timeit -s 'fractions = [(i, j) for i in
range(100) for j in range(1, 100)]' 'max_denominator_sq = max(q for p, q in
fractions)**2' (1,2), (3,4), (0,5), (9,100), (3,7), (2,8)'sorted(fractions,
key=lambda t: t[0]*max_denominator_sq//t[1])'
100 loops, best of 3: 5.52 msec per loop


with a further speed improvement in 3.2:


stutzbach-glaptop:~$ ~/python/cpython-3.2/python -m timeit -s 'fractions =
[(i, j) for i in range(100) for j in range(1, 100)]' 'max_denominator_sq =
max(q for p, q in fractions)**2' 'sorted(fractions, key=lambda t:
t[0]*max_denominator_sq//t[1])'
100 loops, best of 3: 4.89 msec per loop


and more speed improvements with my experimental changes targeting 3.3 (not
yet in the bug tracker):   :-)


stutzbach-glaptop:~$ ~/python/cpython/python -m timeit -s 'fractions = [(i,
j) for i in range(100) for j in range(1, 100)]' 'max_denominator_sq = max(q
for p, q in fractions)**2' 'sorted(fractions, key=lambda t:
t[0]*max_denominator_sq//t[1])'
100 loops, best of 3: 3.73 msec per loop

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110313/1fc253e3/attachment.html>

From tjreedy at udel.edu  Sun Mar 13 23:45:27 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 13 Mar 2011 18:45:27 -0400
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTimO26878ji4XifEEbz0uYoNWp9gRyvRhhppuVoE@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>
	<AANLkTimO26878ji4XifEEbz0uYoNWp9gRyvRhhppuVoE@mail.gmail.com>
Message-ID: <iljhe8$nor$1@dough.gmane.org>

On 3/13/2011 2:05 PM, Daniel Stutzbach wrote:
> On Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum <guido at python.org
> <mailto:guido at python.org>> wrote:
>
>     I recently advised a Googler who was sorting a large dataset and
>     running out of memory. My analysis of the situation was that he was
>     sorting a huge list of short lines of the form "shortstring,integer"
>     with a key function that returned a tuple of the form ("shortstring",
>     integer).
>
>
> As Raymond pointed out, a change I made for 3.2 significantly shrinks
> the memory footprint of sorting with a key (although it's still more
> memory-intensive than sorting with cmp).
>
> He could reduce the memory footprint further by sorting in two passes
> instead of using a tuple, leveraging the fact that Python guarantees a
> stable sort.  In 3.2 or later, this technique will require roughly twice
> as much memory as just storing the list:
>
> biglist.sort(key=lambda s: int(s.split(',')[1]))  # Sort by the integer
> biglist.sort(key=lambda s: s.split(',')[0])  # Sort by the shortstring
>
> I think the use cases are pretty narrow where there's plenty of memory
> for storing the list but not enough to store two copies.

Here are two variations on the idea of two pass sorting, both of which 
only sort ints for duplicate shortstrings and neither of which use key=.

1. If duplication of shortstrings is (known to be) sparse, sort the 
lines as they are, then scan to detect runs (slices) of duplicate 
shortstrings and sort and replace those. (If sort had start and stop 
index keywords, this could be done in place.)

2. If duplication of shortstrings is (known to be) heavy, read the 
dataset into a shortstring-list_of_ints dict rathar than a list. Sort 
the keys in a separate (much shorted) list and sort each value (list of 
ints) separately. For some post-sort usages, this would be more useful 
than a flat sorted list.

A third idea is to presort the dataset into chunks (a-m, n-z) or however 
appropriate, perhaps as it is gathered; sort each separately; and then 
concatenate. This will handle cases where even the flat list is too big 
for memory.

-- 
Terry Jan Reedy


From tlesher at gmail.com  Mon Mar 14 03:41:08 2011
From: tlesher at gmail.com (Tim Lesher)
Date: Sun, 13 Mar 2011 22:41:08 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
Message-ID: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>

[I mentioned this to Raymond Hettinger after his PyCon talk, and I
promised a bug and hopefully a patch. I don't see an obvious solution,
though, so I'll ask here first.]

Because named tuple prefixes a single underscore to its added method
names (_asdict, _replace, and _make), those methods' docstrings are
omitted from pydoc:

>>> Point=collections.namedtuple('Point', 'x y')
>>> help(Point)
Help on class Point in module __main__:
[output omitted; it excludes _asdict, _replace, and _make]

pydoc's rules for name inclusion are in pydoc.visiblename():

* If the name is in the hidden list, omit it
* If the name looks like a __special_method__, include it
* If the there is an "all" specified, then include it if it appears in all
* Otherwise, include it if it doesn't begin with an underscore

There doesn't seem to be an obvious way to get around these rules for
named tuples... am I overlooking something?

Thanks.
-- 
Tim Lesher <tlesher at gmail.com>

From benjamin at python.org  Mon Mar 14 03:53:47 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 13 Mar 2011 21:53:47 -0500
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
Message-ID: <AANLkTik7LcFUPJJQSbPcM62CWLfXDOrAGw_NDpYa2EaP@mail.gmail.com>

2011/3/13 Tim Lesher <tlesher at gmail.com>:
> [I mentioned this to Raymond Hettinger after his PyCon talk, and I
> promised a bug and hopefully a patch. I don't see an obvious solution,
> though, so I'll ask here first.]
>
> Because named tuple prefixes a single underscore to its added method
> names (_asdict, _replace, and _make), those methods' docstrings are
> omitted from pydoc:
>
>>>> Point=collections.namedtuple('Point', 'x y')
>>>> help(Point)
> Help on class Point in module __main__:
> [output omitted; it excludes _asdict, _replace, and _make]
>
> pydoc's rules for name inclusion are in pydoc.visiblename():
>
> * If the name is in the hidden list, omit it
> * If the name looks like a __special_method__, include it
> * If the there is an "all" specified, then include it if it appears in all
> * Otherwise, include it if it doesn't begin with an underscore
>
> There doesn't seem to be an obvious way to get around these rules for
> named tuples... am I overlooking something?

No, probably we should add some sort of __yes_i_am_public__ override
attribute that pydoc looks for. It's such a pity that those methods
have to have underscores...



-- 
Regards,
Benjamin

From prologic at shortcircuit.net.au  Mon Mar 14 03:57:02 2011
From: prologic at shortcircuit.net.au (James Mills)
Date: Mon, 14 Mar 2011 12:57:02 +1000
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
Message-ID: <AANLkTi=eLUZ=OW9fi2DKpX4g237UbB21xCe_69Kbj-10@mail.gmail.com>

On Mon, Mar 14, 2011 at 12:41 PM, Tim Lesher <tlesher at gmail.com> wrote:
> [I mentioned this to Raymond Hettinger after his PyCon talk, and I
> promised a bug and hopefully a patch. I don't see an obvious solution,
> though, so I'll ask here first.]
>
> Because named tuple prefixes a single underscore to its added method
> names (_asdict, _replace, and _make), those methods' docstrings are
> omitted from pydoc:
>
>>>> Point=collections.namedtuple('Point', 'x y')
>>>> help(Point)
> Help on class Point in module __main__:
> [output omitted; it excludes _asdict, _replace, and _make]
>
> pydoc's rules for name inclusion are in pydoc.visiblename():
>
> * If the name is in the hidden list, omit it
> * If the name looks like a __special_method__, include it
> * If the there is an "all" specified, then include it if it appears in all
> * Otherwise, include it if it doesn't begin with an underscore
>
> There doesn't seem to be an obvious way to get around these rules for
> named tuples... am I overlooking something?

Works for me. Python 3.2 on 32bit Linux.

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

From prologic at shortcircuit.net.au  Mon Mar 14 03:59:44 2011
From: prologic at shortcircuit.net.au (James Mills)
Date: Mon, 14 Mar 2011 12:59:44 +1000
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTi=eLUZ=OW9fi2DKpX4g237UbB21xCe_69Kbj-10@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<AANLkTi=eLUZ=OW9fi2DKpX4g237UbB21xCe_69Kbj-10@mail.gmail.com>
Message-ID: <AANLkTikUcg7ENPo72Kz1hm5ZJmfaxbNpOrGazNh-7Phu@mail.gmail.com>

On Mon, Mar 14, 2011 at 12:57 PM, James Mills
<prologic at shortcircuit.net.au> wrote:
>> [output omitted; it excludes _asdict, _replace, and _make]

Sorry I missed this bit :)

> Works for me. Python 3.2 on 32bit Linux.

Scrap that :)

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

From tlesher at gmail.com  Mon Mar 14 04:10:08 2011
From: tlesher at gmail.com (Tim Lesher)
Date: Sun, 13 Mar 2011 23:10:08 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
Message-ID: <AANLkTimBK+mJwMj0MQuSh8isQuJJHQQqAkYbXHcvRswn@mail.gmail.com>

Addendum: this looks related to bug 1189811.

http://bugs.python.org/issue1189811

That issue seems to hinge on the definition of "private".

-- 
Tim Lesher <tlesher at gmail.com>

From greg.ewing at canterbury.ac.nz  Mon Mar 14 07:33:51 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 14 Mar 2011 19:33:51 +1300
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
Message-ID: <4D7DB6CF.5050102@canterbury.ac.nz>

Tim Lesher wrote:

> Because named tuple prefixes a single underscore to its added method
> names (_asdict, _replace, and _make), those methods' docstrings are
> omitted from pydoc:

IMO these should be called __asdict__, __replace__ and
__make__. Users are perfectly entitled to make up their
own single-underscore names, so using a single underscore
is not sufficient to prevent name collisions.

-- 
Greg

From raymond.hettinger at gmail.com  Mon Mar 14 08:04:37 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 14 Mar 2011 00:04:37 -0700
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
Message-ID: <7F3A38CC-473E-4ADA-AE7E-FDF805C27BC6@gmail.com>


On Mar 13, 2011, at 7:41 PM, Tim Lesher wrote:

> [I mentioned this to Raymond Hettinger after his PyCon talk, and I
> promised a bug and hopefully a patch. I don't see an obvious solution,
> though, so I'll ask here first.]

Just make a tracker entry and assign it to me.
I'll take a look and see what can be done.


Raymond

From ncoghlan at gmail.com  Mon Mar 14 10:45:55 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 14 Mar 2011 05:45:55 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <4D7DB6CF.5050102@canterbury.ac.nz>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
Message-ID: <AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>

On Mon, Mar 14, 2011 at 2:33 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Tim Lesher wrote:
>
>> Because named tuple prefixes a single underscore to its added method
>> names (_asdict, _replace, and _make), those methods' docstrings are
>> omitted from pydoc:
>
> IMO these should be called __asdict__, __replace__ and
> __make__. Users are perfectly entitled to make up their
> own single-underscore names, so using a single underscore
> is not sufficient to prevent name collisions.

True, but all those underscores are a PITA to type and read for
methods that are meant to be called directly. A single leading
underscore is enough to move them out of the way of the standard
public fields of a named tuple. Giving a nominally private name to a
field that is already publically accessible via index would be
nonsensical.

There are two relatively simple ways forward I can see:

A. Add a __public__ attribute that pydoc (and import *) understand.
This would overrride the default "this is private" detection and add
affected names to the public list (without needing to respecify all
the "default public" names - this is important in order to support
subclassing correctly)

B. Add a different prefix to the named tuple methods (e.g ntup_asdict,
ntup_replace, ntup_make).

There's also an even more radical alternative:

C. Add syntax for bypassing the instance lookup when accessing attributes.

If "obj..replace(*args)" (or whatever - this specific example arguably
fails the "syntax shall not look like grit on Tim's monitor" test) was
guaranteed to do the moral equivalent of "type(obj).replace(obj,
*args)", then these could all become normal public methods, with the
caveat that access via the class should be forced when using them.
This would also make a *lot* of the Python code dealing with magic
methods a fair bit cleaner (we currently have to do the type(obj)
dance manually in various places to avoid metaclass confusion issues).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Mon Mar 14 11:01:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 14 Mar 2011 06:01:17 -0400
Subject: [Python-Dev] [Python-checkins] cpython (3.2): Issue #11329:
 PyEval_InitThreads() cannot be called before Py_Initialize()
In-Reply-To: <E1Pytn2-0004rb-QJ@dinsdale.python.org>
References: <E1Pytn2-0004rb-QJ@dinsdale.python.org>
Message-ID: <AANLkTikmwu+QSUzCVFH8+4J7ij1Uv3YuBQpbNH9eNKWQ@mail.gmail.com>

On Sun, Mar 13, 2011 at 6:29 PM, antoine.pitrou
<python-checkins at python.org> wrote:
> ? ?.. index:: single: Py_Initialize()
>
> - ? This is a no-op when called for a second time. ?It is safe to call this function
> - ? before calling :c:func:`Py_Initialize`.
> + ? This is a no-op when called for a second time.

This change probably deserves a "versionchanged" tag and a note in the
"Porting to Python 3" section of What's New, since it may cause
weirdness for people embedding Python in their apps.

Cheers,
Nick.

-
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From eric at trueblade.com  Mon Mar 14 11:29:09 2011
From: eric at trueblade.com (Eric Smith)
Date: Mon, 14 Mar 2011 06:29:09 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <4D7DB6CF.5050102@canterbury.ac.nz>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
Message-ID: <4D7DEDF5.7050700@trueblade.com>

On 03/14/2011 02:33 AM, Greg Ewing wrote:
> Tim Lesher wrote:
>
>> Because named tuple prefixes a single underscore to its added method
>> names (_asdict, _replace, and _make), those methods' docstrings are
>> omitted from pydoc:
>
> IMO these should be called __asdict__, __replace__ and
> __make__. Users are perfectly entitled to make up their
> own single-underscore names, so using a single underscore
> is not sufficient to prevent name collisions.

namedtuple won't let you use names starting with an underscore, so the 
single underscore names are sufficient.

Eric.


From merwok at netwok.org  Mon Mar 14 11:43:30 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 14 Mar 2011 11:43:30 +0100
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTik7LcFUPJJQSbPcM62CWLfXDOrAGw_NDpYa2EaP@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<AANLkTik7LcFUPJJQSbPcM62CWLfXDOrAGw_NDpYa2EaP@mail.gmail.com>
Message-ID: <4D7DF152.2000402@netwok.org>

> No, probably we should add some sort of __yes_i_am_public__ override
> attribute that pydoc looks for. It's such a pity that those methods
> have to have underscores...

My opinion is that pydoc should use __dir__ (namedtuple does not
currently use it but could).

Regards

From ncoghlan at gmail.com  Mon Mar 14 12:18:20 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 14 Mar 2011 07:18:20 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <4D7DF152.2000402@netwok.org>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<AANLkTik7LcFUPJJQSbPcM62CWLfXDOrAGw_NDpYa2EaP@mail.gmail.com>
	<4D7DF152.2000402@netwok.org>
Message-ID: <AANLkTin8Wh+zG+yytJ-vN7mCi-HHoxPnfMjo9aAAqvLf@mail.gmail.com>

On Mon, Mar 14, 2011 at 6:43 AM, ?ric Araujo <merwok at netwok.org> wrote:
>> No, probably we should add some sort of __yes_i_am_public__ override
>> attribute that pydoc looks for. It's such a pity that those methods
>> have to have underscores...
>
> My opinion is that pydoc should use __dir__ (namedtuple does not
> currently use it but could).

Oh, I forgot about __dir__. However, the problem with that is that
dir() and __dir__() are designed to return *everything*, public or
private.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Mon Mar 14 12:46:52 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Mar 2011 12:46:52 +0100
Subject: [Python-Dev] pydoc for named tuples is missing methods
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<4D7DEDF5.7050700@trueblade.com>
Message-ID: <20110314124652.53465529@pitrou.net>

On Mon, 14 Mar 2011 06:29:09 -0400
Eric Smith <eric at trueblade.com> wrote:
> On 03/14/2011 02:33 AM, Greg Ewing wrote:
> > Tim Lesher wrote:
> >
> >> Because named tuple prefixes a single underscore to its added method
> >> names (_asdict, _replace, and _make), those methods' docstrings are
> >> omitted from pydoc:
> >
> > IMO these should be called __asdict__, __replace__ and
> > __make__. Users are perfectly entitled to make up their
> > own single-underscore names, so using a single underscore
> > is not sufficient to prevent name collisions.
> 
> namedtuple won't let you use names starting with an underscore, so the 
> single underscore names are sufficient.

Not for members perhaps, but nothing prevents you from defining methods
with these names in a subclass AFAIK.

Regards

Antoine.



From solipsis at pitrou.net  Mon Mar 14 12:47:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Mar 2011 12:47:25 +0100
Subject: [Python-Dev] cpython (3.2): Issue #11329: PyEval_InitThreads()
 cannot be called before Py_Initialize()
References: <E1Pytn2-0004rb-QJ@dinsdale.python.org>
	<AANLkTikmwu+QSUzCVFH8+4J7ij1Uv3YuBQpbNH9eNKWQ@mail.gmail.com>
Message-ID: <20110314124725.269d3573@pitrou.net>

On Mon, 14 Mar 2011 06:01:17 -0400
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Sun, Mar 13, 2011 at 6:29 PM, antoine.pitrou
> <python-checkins at python.org> wrote:
> > ? ?.. index:: single: Py_Initialize()
> >
> > - ? This is a no-op when called for a second time. ?It is safe to call this function
> > - ? before calling :c:func:`Py_Initialize`.
> > + ? This is a no-op when called for a second time.
> 
> This change probably deserves a "versionchanged" tag and a note in the
> "Porting to Python 3" section of What's New, since it may cause
> weirdness for people embedding Python in their apps.

Agreed, will do.

cheers

Antoine.



From eric at trueblade.com  Mon Mar 14 12:59:38 2011
From: eric at trueblade.com (Eric Smith)
Date: Mon, 14 Mar 2011 07:59:38 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <20110314124652.53465529@pitrou.net>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>	<4D7DB6CF.5050102@canterbury.ac.nz>	<4D7DEDF5.7050700@trueblade.com>
	<20110314124652.53465529@pitrou.net>
Message-ID: <4D7E032A.7020302@trueblade.com>

On 03/14/2011 07:46 AM, Antoine Pitrou wrote:
> On Mon, 14 Mar 2011 06:29:09 -0400
> Eric Smith<eric at trueblade.com>  wrote:
>> On 03/14/2011 02:33 AM, Greg Ewing wrote:
>>> Tim Lesher wrote:
>>>
>>>> Because named tuple prefixes a single underscore to its added method
>>>> names (_asdict, _replace, and _make), those methods' docstrings are
>>>> omitted from pydoc:
>>>
>>> IMO these should be called __asdict__, __replace__ and
>>> __make__. Users are perfectly entitled to make up their
>>> own single-underscore names, so using a single underscore
>>> is not sufficient to prevent name collisions.
>>
>> namedtuple won't let you use names starting with an underscore, so the
>> single underscore names are sufficient.
>
> Not for members perhaps, but nothing prevents you from defining methods
> with these names in a subclass AFAIK.

Good point. You can define methods or other attributes this way:

 >>> from collections import namedtuple
 >>> A = namedtuple('A', 'x y')
 >>> class B(A):
...   _replace = 3
...
 >>> b = B(1, 2)
 >>> b._replace
3


From tlesher at gmail.com  Mon Mar 14 13:28:11 2011
From: tlesher at gmail.com (Tim Lesher)
Date: Mon, 14 Mar 2011 08:28:11 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
Message-ID: <AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>

On Mon, Mar 14, 2011 at 05:45, Nick Coghlan <ncoghlan at gmail.com> wrote:
> There are two relatively simple ways forward I can see:
>
> A. Add a __public__ attribute that pydoc (and import *) understand.
> This would overrride the default "this is private" detection and add
> affected names to the public list (without needing to respecify all
> the "default public" names - this is important in order to support
> subclassing correctly)

I believe this was the direction the bug report was implying.

I'll be sprinting for a few hours this morning; if there are no
objections, I will try to turn this idea into a patch that makes
pydoc.visiblename look for a __public__ function attribute as "step
0".

Maybe there should also be a @public decorator to apply it, although
that name may be an attractive nuisance, tempting C++ or Java
programmers new to Python to ask for @protected and @private...

-- 
Tim Lesher <tlesher at gmail.com>

From alexander.belopolsky at gmail.com  Mon Mar 14 15:45:09 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 14 Mar 2011 10:45:09 -0400
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTi=AZ3uscRKSzAh8NYkeGpHjYc9gWrucFQswhLZx@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTi=AZ3uscRKSzAh8NYkeGpHjYc9gWrucFQswhLZx@mail.gmail.com>
Message-ID: <AANLkTimraT6vfWO03hd6asCBR-GpbxQ8i4Pn4-u63cSm@mail.gmail.com>

On Fri, Mar 11, 2011 at 9:53 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Fri, Mar 11, 2011 at 9:28 PM, Raymond Hettinger
> <raymond.hettinger at gmail.com> wrote:
>> Today, there was a significant check-in to the peephole optimizer that I
>> think should be reverted:
>> ?? ? ? ? ? ? ??http://hg.python.org/cpython/rev/14205d0fee45/
>
> +1
>
> I was going to comment on the corresponding issue #11244 more or less
> supporting Raymond's arguments.

When I wrote this, I was actually looking at the issue 11462.  I now
realize that #11462 was in fact closed as "rejected".

I am still confused, however, about [14205d0fee45].  The commit
message refers to "Issue #11244", but the comment does not match the
subject of the tracker issue:

"""
Issue #11244: The peephole optimizer is now able to constant-fold
arbitrarily complex expressions. This also fixes a 3.2 regression where
operations involving negative numbers were not constant-folded.
"""

I think issue #11244 is just the second part: "a 3.2 regression where
operations involving negative numbers were not constant-folded."

If this is the case, what is left to do for #11244?  The bug reported
in that issue seem to have been fixed:

>>> dis(lambda: (1,-2,3))
  1           0 LOAD_CONST               5 ((1, -2, 3))
              3 RETURN_VALUE

From alexander.belopolsky at gmail.com  Mon Mar 14 16:05:40 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 14 Mar 2011 11:05:40 -0400
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <B6E14BD9-DCFF-45E9-BCF8-F2386CE42998@gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<B6E14BD9-DCFF-45E9-BCF8-F2386CE42998@gmail.com>
Message-ID: <AANLkTinjtDRx+ffUf1mL_RKcUujtaRvwP=WjHrOk2Whq@mail.gmail.com>

On Sat, Mar 12, 2011 at 1:08 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> I would like to withdraw my suggestion for the recursive constant folding patch to be reverted.

So what is the status of peephole optimization now?  Is it back under
active development?   Let me quote a tracker comment that I posted two
years ago and go no response to ('>'-quote are from Raymond's
message):

"""
Constant folding promotes more readable code: 24*60*60 is more obvious
than 86400, prefixing positive numbers with + leads to better visual
alignment, etc.  Users should not be required to think twice about
which constant expressions are folded and which are not.

Here is another surprise with the current peepholer:

>>> dis(lambda:1+2*3)
  1           0 LOAD_CONST               0 (1)
              3 LOAD_CONST               3 (6)
              6 BINARY_ADD
              7 RETURN_VALUE

>>> dis(lambda:2*3+1)
  1           0 LOAD_CONST               4 (7)
              3 RETURN_VALUE

I have a fix in the works, but I will wait for your further comments
before submitting it.

>
>  More importantly, we decided that the peepholer is the wrong place to
>  do much of this work.  Most of the peepholer is going to be migrated
>  up the chain, after the AST is generated, but before the opcodes are
>  generated.  That is a faster, more reliable, and more general
>  approach.
>

I agree.   Constant folding, is an interesting case because peepholer
has to duplicate a subset of eval logic.  I wonder if the new approach
could eliminate that.

BTW, what is the rationale for leading +/- not being part of the
number literal? Unary +/- optimization seems mostly useful for the
simple +/-x case which could be handled by the tokenizer.

What is the timeline for that project?  Maybe a comment should be
placed in peephole.c explaining that there is a plan to move
uptimization logic up the compilation chain and announcing a
moratorium on further peephole.c work.  I am not the only one
submitting peephole optimizer patches recently.
""" http://bugs.python.org/issue2499#msg64638

I understand that the constant folding pass for AST is the subject of
http://bugs.python.org/issue1346238.  The first patch in that issue is
more than four years old.  Is that an indication that optimizing AST
is actually harder than optimizing bytecode?

From ned at nedbatchelder.com  Mon Mar 14 17:16:40 2011
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Mon, 14 Mar 2011 12:16:40 -0400
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTimrr7Dy3xXeNe1tJb0vGvosJr8oHhxxxnMoY0En@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>	<AANLkTikwiu7TCRkCohoXdzHL6PUK7DjHNDxMUfBooQ71@mail.gmail.com>	<00D0D3B5-4ED2-4B06-A8B5-F9238F71D71F@gmail.com>
	<AANLkTimrr7Dy3xXeNe1tJb0vGvosJr8oHhxxxnMoY0En@mail.gmail.com>
Message-ID: <4D7E3F68.4010109@nedbatchelder.com>

On 3/12/2011 12:39 AM, Eugene Toder wrote:
>> >  You've got wishful thinking if you think a handful of tests can catch
>> >  errors in code that sophisticated.
> Why limit yourself with a handful of tests? Python is widespread,
> there's*a lot*  of code in Python. Unlike with libraries, any code you
> run tests the optimizer, so just run a lot of code. And, as I've said,
> write a test generator.

As we're thinking about what the optimizer of the future should be, it 
would be great to have a way to turn it off completely.  This would 
allow the tests to run test code both with and without the optimizer, 
and to verify that the two results were the same.  Then we could 
automatically verify that the optimizer isn't changing semantics.

BTW: I also believe it would be very useful to make the 
turn-off-the-optimizer switch available for users so they can run their 
code unoptimized for times when they are more interested in program 
analysis than in execution speed.  See http://bugs.python.org/issue2506 
(closed 3 years ago) that I filed with this request.

--Ned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110314/45cc3666/attachment.html>

From solipsis at pitrou.net  Mon Mar 14 17:36:29 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Mar 2011 17:36:29 +0100
Subject: [Python-Dev] cpython: Add a 'timeout' argument to
	subprocess.Popen.
References: <E1PzARH-0007jp-FZ@dinsdale.python.org>
Message-ID: <20110314173629.224810fe@pitrou.net>

On Mon, 14 Mar 2011 17:16:11 +0100
reid.kleckner <python-checkins at python.org> wrote:
> @@ -265,34 +271,43 @@
>        generates enough output to a pipe such that it blocks waiting
>        for the OS pipe buffer to accept more data.
>  
> +   .. versionchanged:: 3.2
> +      *timeout* was added.

Unless you plan to borrow someone's time machine, this should probably
be 3.3.

Regards

Antoine.



From g.brandl at gmx.net  Mon Mar 14 17:46:06 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 14 Mar 2011 17:46:06 +0100
Subject: [Python-Dev] Python 3.4 version in the tracker
In-Reply-To: <4D7CCB05.1080508@trueblade.com>
References: <4D7B8284.4040202@trueblade.com>	<4D7B9772.3010803@netwok.org>	<4D7B9AAE.9060909@trueblade.com>	<ili7h5$d2p$1@dough.gmane.org>
	<4D7CCB05.1080508@trueblade.com>
Message-ID: <illgof$cae$1@dough.gmane.org>

Am 13.03.2011 14:47, schrieb Eric Smith:
> On 03/13/2011 06:49 AM, Georg Brandl wrote:
>> On 12.03.2011 17:09, Eric Smith wrote:
>>> On 03/12/2011 10:55 AM, ?ric Araujo wrote:
>>>>> I have a deprecation warning that I need to make an error in 3.4.
>>>>
>>>> A neat trick to remember to do those changes is using a test that fails
>>>> if something does not raise a DeprecationWarning if sys.version_info[:2]
>>>> == (3, 3), or an error if sys.version_info[:3] == (3, 4).  You write
>>>> those tests once and let ?make test? remind you as soon as the Python
>>>> version changes.
>>>
>>> I like the idea, but it seems a little hostile to the person who
>>> actually changes the version number!
>>
>> If it helps to remember these things (usually deprecations) that we've often
>> forgotten in the past, I don't mind being the one to innocently break the
>> buildbots by increasing the version number.
> 
> Are you volunteering to change all of the PendingDeprecationWarnings to 
> DeprecationWarnings and DeprecationWarnings to errors of some sort? It 
> might be a big job.
> 
> I'm just trying to figure out what the mechanics would be.

No, I'll still forward these failures to whoever put them into the modules :)

Georg


From jcea at jcea.es  Mon Mar 14 17:48:59 2011
From: jcea at jcea.es (Jesus Cea)
Date: Mon, 14 Mar 2011 17:48:59 +0100
Subject: [Python-Dev] PEPs migrated to mercurial?
Message-ID: <4D7E46FB.3000502@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I see <http://hg.python.org/peps/>, but last change was a year ago.

I changes PEP 11 time ago, and I can't see the changes there. So the
repository seems a bit outdated. Or, maybe, are we still using SVN for
PEPs?.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTX5G+5lgi5GaxT1NAQKBtAP/bROH6dye23+w+nK/D8deKtxEqQlIFeVh
3Dtuo9IhtmkhhFlXeD50WNyLBZPRpbdA97Lo1WL65Fgvj94EDwbI83ex83Bs5DGH
UXfawy635NbxVzJvWL1VXI5rCzcjKY6WrmAgzTPDFyoD1KvzSz6E+kR3IEVohKh3
EihPnrygIA8=
=B44H
-----END PGP SIGNATURE-----

From jcea at jcea.es  Mon Mar 14 17:59:27 2011
From: jcea at jcea.es (Jesus Cea)
Date: Mon, 14 Mar 2011 17:59:27 +0100
Subject: [Python-Dev] Have we lost changeset info in the buildbots
Message-ID: <4D7E496F.8050302@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Traditionally I could see who was the committer who push change to the
buildbots. This info seems not to be (easily) available.

For instance, I see
<http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable>.
I just pushed a changeset. I can't see easily if my changeset is being
tested now, or when...

Ideally I would like to see WHO pushed the changeset under test and,
moving my mouse over it, see the commit message and a link to the mercurial.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTX5Jb5lgi5GaxT1NAQJUNQP+OQjp9HgMpVETViizGOnOSHImY2imR78e
jBsuRWp4Jcsh6h9lui0vrSpXxLtd065PR1CtOloOjXMR2dAUKGeMYKcsqTfb6p9n
oRZWlnXWpwnEg38Lkgkk9Mz4uYcmljUs7kmn+jEbqS7jWsO2rPZGtab5CV+5ZG0o
kqB8ZUB/YX8=
=9+B2
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Mon Mar 14 18:07:56 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Mar 2011 18:07:56 +0100
Subject: [Python-Dev] Have we lost changeset info in the buildbots
References: <4D7E496F.8050302@jcea.es>
Message-ID: <20110314180756.45711629@pitrou.net>

On Mon, 14 Mar 2011 17:59:27 +0100
Jesus Cea <jcea at jcea.es> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Traditionally I could see who was the committer who push change to the
> buildbots. This info seems not to be (easily) available.

That info was lost quite before the hg migration, when the buildbot
version was upgraded on the server.

I suggest you try http://code.google.com/p/bbreport/, which provides a
very nice command-line interface.

Regards

Antoine.



From g.brandl at gmx.net  Mon Mar 14 18:18:30 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 14 Mar 2011 18:18:30 +0100
Subject: [Python-Dev] PEPs migrated to mercurial?
In-Reply-To: <4D7E46FB.3000502@jcea.es>
References: <4D7E46FB.3000502@jcea.es>
Message-ID: <illil7$rff$1@dough.gmane.org>

Am 14.03.2011 17:48, schrieb Jesus Cea:
> I see <http://hg.python.org/peps/>, but last change was a year ago.
> 
> I changes PEP 11 time ago, and I can't see the changes there. So the
> repository seems a bit outdated. Or, maybe, are we still using SVN for
> PEPs?.

Yes.  Not for much longer though.

Georg


From reid.kleckner at gmail.com  Mon Mar 14 19:17:35 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Mon, 14 Mar 2011 14:17:35 -0400
Subject: [Python-Dev] cpython: Add a 'timeout' argument to
	subprocess.Popen.
In-Reply-To: <20110314173629.224810fe@pitrou.net>
References: <E1PzARH-0007jp-FZ@dinsdale.python.org>
	<20110314173629.224810fe@pitrou.net>
Message-ID: <AANLkTi=S53M3rT4zfWJjt=neu9NoPYjNOJj0VYNmRn8C@mail.gmail.com>

On Mon, Mar 14, 2011 at 12:36 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 14 Mar 2011 17:16:11 +0100
> reid.kleckner <python-checkins at python.org> wrote:
>> @@ -265,34 +271,43 @@
>> ? ? ? ?generates enough output to a pipe such that it blocks waiting
>> ? ? ? ?for the OS pipe buffer to accept more data.
>>
>> + ? .. versionchanged:: 3.2
>> + ? ? ?*timeout* was added.
>
> Unless you plan to borrow someone's time machine, this should probably
> be 3.3.

Fixed soon after in http://hg.python.org/cpython/rev/72e49cb7fcf5 .

Reid

From jcea at jcea.es  Mon Mar 14 20:00:30 2011
From: jcea at jcea.es (Jesus Cea)
Date: Mon, 14 Mar 2011 20:00:30 +0100
Subject: [Python-Dev] Have we lost changeset info in the buildbots
In-Reply-To: <20110314180756.45711629@pitrou.net>
References: <4D7E496F.8050302@jcea.es> <20110314180756.45711629@pitrou.net>
Message-ID: <4D7E65CE.8030606@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/03/11 18:07, Antoine Pitrou wrote:
> On Mon, 14 Mar 2011 17:59:27 +0100
> Jesus Cea <jcea at jcea.es> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Traditionally I could see who was the committer who push change to the
>> buildbots. This info seems not to be (easily) available.
> 
> That info was lost quite before the hg migration, when the buildbot
> version was upgraded on the server.
> 
> I suggest you try http://code.google.com/p/bbreport/, which provides a
> very nice command-line interface.

Thanks for the suggestion.

Sniff...

"""
[jcea at babylon5 bbreport]$ python bbreport.py  -r 15b090c9442a
Usage: bbreport.py [options] branch ...

bbreport.py: error: option -r: invalid integer value: '15b090c9442a'
"""

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTX5lzplgi5GaxT1NAQJ8iwQAmnFHvjxh/OB1OsnUOy4s4RLizgK5Jqo0
N2yynyErx1wdgxB1TGzfMxpZxrWrgGzQrQBiZ5/XuNN6BcUTPW9Lu+np/muKB+qm
3AL864XOqxzbAh2/p4FleZJIqGBnniFUlB3AclI6KLhjumvJFDHLeKczRGPVWFE+
Ref0AtQBVNg=
=mQiJ
-----END PGP SIGNATURE-----

From Sebastian at SSpaeth.de  Mon Mar 14 16:36:25 2011
From: Sebastian at SSpaeth.de (Sebastian Spaeth)
Date: Mon, 14 Mar 2011 16:36:25 +0100
Subject: [Python-Dev] imaplib: Time2Internaldate() returns localized strings
Message-ID: <87hbb5r9xi.fsf@SSpaeth.de>

Hi there,

imaplib has an issue (well, more than one :-)), but in this specific
case there is even a patch that I want to lobby.

http://bugs.python.org/issue11024
imaplib: Time2Internaldate() returns localized strings while the IMAP
RFC requires English month names. As that function is used for every
.append(), this outright prevents some international users during some
months from adding messages. :-)

There is a patch that fixes imaplib and I would be grateful if someone
with commit access would have a look at it, and consider pushing it in.

Thank you so much,
Sebastian

P.S., please keep me CC'd

From db3l.net at gmail.com  Mon Mar 14 20:36:03 2011
From: db3l.net at gmail.com (David Bolen)
Date: Mon, 14 Mar 2011 15:36:03 -0400
Subject: [Python-Dev] Have we lost changeset info in the buildbots
References: <4D7E496F.8050302@jcea.es> <20110314180756.45711629@pitrou.net>
Message-ID: <m2sjupv6jg.fsf@valheru.db3l.homeip.net>

Antoine Pitrou <solipsis at pitrou.net> writes:

> I suggest you try http://code.google.com/p/bbreport/, which provides a
> very nice command-line interface.

Speaking of bbreport, I sometimes use the published page on that site
(http://code.google.com/p/bbreport/wiki/PythonBuildbotReport) to check
over things, but looking at it today, it seems to most recently have been
generated back in January.  Or is the generated date line wrong?

-- David


From fuzzyman at voidspace.org.uk  Mon Mar 14 20:40:45 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 14 Mar 2011 15:40:45 -0400
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <20110309213119.9F22D3A4116@sparrow.telecommunity.com>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
	<20110304120743.22042ded@neurotica.wooz.org>
	<4D7122D1.30505@voidspace.org.uk>
	<20110309213119.9F22D3A4116@sparrow.telecommunity.com>
Message-ID: <4D7E6F3D.306@voidspace.org.uk>

On 09/03/2011 16:30, P.J. Eby wrote:
> At 05:35 PM 3/4/2011 +0000, Michael Foord wrote:
>> That (below) is not distutils it is setuptools. distutils just uses 
>> `scripts=[...]`, which annoyingly *doesn't* work with setuptools.
>
> Er, what?  That's news to me.  Could you file a bug report about what 
> doesn't work, specifically?
Ok. I'm afraid I was relying on anecdotal evidence (the people who 
wanted setuptools specific features in my setup.py told me I *had* to 
use entry points for scripts instead of the standard distutils scripts 
machinery). I'll try out a vanilla "scripts" entry in a setuptools 
setup.py and report back.

All the best,

Michael

-- 
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


From ziade.tarek at gmail.com  Mon Mar 14 20:39:55 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 14 Mar 2011 15:39:55 -0400
Subject: [Python-Dev] packaging
Message-ID: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>

Hey,

I just wanted to summarize what we've started at the sprint (and
hopefully finish 1 to 7 this week):

1/ distutils2 is merged as the "packaging" Python package in the
standard library
2/ distutils2 will provide a "pysetup" script in Python to run all
packaging tools (pysetup is a wrapper that will run
"packaging.run.main")
3/ pkgutil gets the new API (PEP 376) we implemented in distutils2._backport
4/ sysconfig installations paths are moved to a sysconfig.cfg file.
5/ the sysconfig,cfg file will be located besides sysconfig.py in the
standard library
6/ sysconfig will lookup for sysconfig.cfg in several places and merge
sections from down to bottom:
     1/ current directory
     2/ per-user site-packages
     3/ global site-packages
7/ a backport for 2.4 to 3.2 will be provided for "packaging" using
the "distutils2" name
8/ we will release distutils2 in the next 18 months
9/ once 3.3 is out, the backport will just get bug fixes


Cheers
Tarek

-- 
Tarek Ziad? | http://ziade.org

From jnoller at gmail.com  Mon Mar 14 21:10:23 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Mon, 14 Mar 2011 16:10:23 -0400
Subject: [Python-Dev] New committers coming online
Message-ID: <AANLkTi=VWOS0x+merSc_T_GNYhW88VHhY3zZLxZC62nh@mail.gmail.com>

As agreed to at the language summit, I have pinged the IronPython,
Jython and PyPy teams for committers on their respective teams who
(do/did not) have commit rights prior to PyCon. These people are:

Jeff Hardy (IronPython)
Alex Gaynor (PyPy)
Carl Friedrich Bolz (PyPy)
Maciej Fijalkowski (PyPy)
Antonio Cuni (PyPy)

And one other whose CLA I have in my bag (still haven't unpacked from
PyCon). So if you see them committing, this is a heads up.

A side note: The Jython guys would really love to join us in our HG
future-land. Frank Wierzbicki expressed a lot of interest in this.

Jesse

From martin at v.loewis.de  Mon Mar 14 21:10:45 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 14 Mar 2011 16:10:45 -0400
Subject: [Python-Dev] PEP 382 Master
Message-ID: <4D7E7645.4050902@v.loewis.de>

I'd like to appoint Eric Smith as the PEP master for PEP 382
(Namespace Packages).
I hope to complete the implementation shortly, at which point
there will be a final call for comments.

Regards,
Martin

From cesare.di.mauro at gmail.com  Mon Mar 14 21:15:58 2011
From: cesare.di.mauro at gmail.com (Cesare Di Mauro)
Date: Mon, 14 Mar 2011 21:15:58 +0100
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTinjtDRx+ffUf1mL_RKcUujtaRvwP=WjHrOk2Whq@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<B6E14BD9-DCFF-45E9-BCF8-F2386CE42998@gmail.com>
	<AANLkTinjtDRx+ffUf1mL_RKcUujtaRvwP=WjHrOk2Whq@mail.gmail.com>
Message-ID: <AANLkTikv2SK+aFdURBwzXy62tF=GDPY1Kqg_VTC2_18H@mail.gmail.com>

2011/3/14 Alexander Belopolsky <alexander.belopolsky at gmail.com>

> On Sat, Mar 12, 2011 at 1:08 PM, Raymond Hettinger
> <raymond.hettinger at gmail.com> wrote:
> > I would like to withdraw my suggestion for the recursive constant folding
> patch to be reverted.
>
> So what is the status of peephole optimization now?  Is it back under
> active development?   Let me quote a tracker comment that I posted two
> years ago and go no response to ('>'-quote are from Raymond's
> message):
>
> """
> Constant folding promotes more readable code: 24*60*60 is more obvious
> than 86400, prefixing positive numbers with + leads to better visual
> alignment, etc.  Users should not be required to think twice about
> which constant expressions are folded and which are not.
>
> Here is another surprise with the current peepholer:
>
> >>> dis(lambda:1+2*3)
>   1           0 LOAD_CONST               0 (1)
>              3 LOAD_CONST               3 (6)
>              6 BINARY_ADD
>              7 RETURN_VALUE
>
> >>> dis(lambda:2*3+1)
>  1           0 LOAD_CONST               4 (7)
>              3 RETURN_VALUE
>
> I have a fix in the works, but I will wait for your further comments
> before submitting it.
>
> >
> >  More importantly, we decided that the peepholer is the wrong place to
> >  do much of this work.  Most of the peepholer is going to be migrated
> >  up the chain, after the AST is generated, but before the opcodes are
> >  generated.  That is a faster, more reliable, and more general
> >  approach.
> >
>
> I agree.   Constant folding, is an interesting case because peepholer
> has to duplicate a subset of eval logic.  I wonder if the new approach
> could eliminate that.
>

I followed a different approach. Constant folding in WPython is made between
ASDL evalutation and AST building.

The idea is to "intercept" constant values and apply the operations
generating a new value instead of generating the classic AST node (a BinOp
for a binary operation, for example).

This way there's no need to parse the AST tree seeking for cases where to
apply the constant folding logic.

It's faster, because you don't need an additional pass through the AST:
you'll do it while building the AST...

It consumes less memory too, since you don't need to generate complex AST
nodes that must be discarded after applying the folding (which generates new
nodes). Think about a tuple of constant values, for example: you have to
generate a Tuple AST structure from the ASDL, then an AST constant folder
will generate the tuple. In WPython the tuple is generated immediately,
directly from the ADSL seq structure.

It's also efficient, since expressions such as 1 + 2 * 3 can be completely
folded generating 7, instead of 1 + 6 of the (classic) peepholer. That's
because, when parsing the ASDL structures, nodes are evaluated in respect of
operator precedence, so first we evaluate 2 * 3, which produces 6 applying
the folding, and then 1 + 6, which produces 7 in the end.

Cesare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110314/d19cf96c/attachment.html>

From solipsis at pitrou.net  Mon Mar 14 21:46:14 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Mar 2011 21:46:14 +0100
Subject: [Python-Dev] packaging
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
Message-ID: <20110314214614.2dde2518@pitrou.net>

On Mon, 14 Mar 2011 15:39:55 -0400
Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> Hey,
> 
> I just wanted to summarize what we've started at the sprint (and
> hopefully finish 1 to 7 this week):
> 
> 1/ distutils2 is merged as the "packaging" Python package in the
> standard library

Why does it get yet another name?
We already have distutils, setuptools, distribute, distutils2... now
"packaging"?

Regards

Antoine.



From greg.ewing at canterbury.ac.nz  Mon Mar 14 21:54:23 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 15 Mar 2011 09:54:23 +1300
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
Message-ID: <4D7E807F.6030602@canterbury.ac.nz>

Nick Coghlan wrote:

> True, but all those underscores are a PITA to type and read for
> methods that are meant to be called directly.

Matter of taste, I suppose. I don't find them all that
bothersome, and a double underscore name stands out very
clearly as being part of the infrastructure rather than
something user-defined.

-- 
Greg

From fuzzyman at voidspace.org.uk  Mon Mar 14 22:29:31 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 14 Mar 2011 17:29:31 -0400
Subject: [Python-Dev] [PEPs] Support
	the	/usr/bin/python2	symlink	upstream
In-Reply-To: <4D759568.9000508@g.nevcal.com>
References: <AANLkTikTfD9MRnonUeyA1MhBh4_EhR7SaOiodRq_X6ry@mail.gmail.com>	<20110303211140.1e2280fd@neurotica.wooz.org>	<20110304040954.GE3275@unaka.lan>	<AANLkTi=dBKryU3JUGp1jA-yWbNz+vooDTN2FdjhvLt3o@mail.gmail.com>	<AANLkTin5iDu6ybOJrMrs_bfiVO89BRx5mBStkoVzJdSb@mail.gmail.com>	<20110304135723.F3307249609@kimball.webabinitio.net>	<20110304101057.6b16622e@neurotica.wooz.org>	<AANLkTimGmx-96U_x8X=+kF3Pv6HC=sdzWQV011kM1E3T@mail.gmail.com>	<20110304133127.554716a0@neurotica.wooz.org>	<AANLkTinsb915rQsj8EzJFR2+EdbG5z=wMrY9xqeV1HWV@mail.gmail.com>	<4D7157EC.5090709@v.loewis.de>	<4D718816.20304@skippinet.com.au>	<AANLkTikiGWh896wsAJAr_H6VUoW3zUK5GDrNPMLKUati@mail.gmail.com>	<4D723C90.6090307@voidspace.org.uk>	<4D72F267.3050204@gmail.com>	<AANLkTinL9juZGBTbfiAOs_Ls=bxyHkcRTYS4AyAeKJNi@mail.gmail.com>	<4D743248.9060705@gmail.com>	<4D754123.7070703@voidspace.org.uk>	<4D756FCA.4070509@canterbury.ac.nz>	<4D75718B.7050908@voidspace.org.uk>
	<4D759568.9000508@g.nevcal.com>
Message-ID: <4D7E88BB.9030109@voidspace.org.uk>

On 07/03/2011 21:33, Glenn Linderman wrote:
> On 3/7/2011 4:00 PM, Michael Foord wrote:
>> On 07/03/2011 23:52, Greg Ewing wrote:
>>> Michael Foord wrote:
>>>
>>>>     - I doubt calling it python.exe will fly, but I'm not sure. If 
>>>> so what will you call what is currently 'python.exe'? - if not then 
>>>> "python foo.py" on the command line will *still* not work...
>>>
>>> However, if it's installed as the exe associated with the .py
>>> and .pyw extensions, then simply 'foo.py' on the command line
>>> *will* work, and will work better than it does now.
>>>
>> So long as '.py' and '.pyw' are set in the PATHEXT environment 
>> variable. (Which again the Python installer doesn't do by default.)
>
>
> No, PATHEXT only means you can invoke
>
> foo.py
>
> and
>
> foo
>
> and get the same results (sometimes, depending on what all in on PATH 
> and PATHEXT)

You're correct of course. My apologies.

Michael Foord

>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110314/7fd2a870/attachment-0001.html>

From barry at python.org  Mon Mar 14 22:59:55 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 14 Mar 2011 17:59:55 -0400
Subject: [Python-Dev] packaging
In-Reply-To: <20110314214614.2dde2518@pitrou.net>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
Message-ID: <20110314175955.1265bff4@neurotica>

On Mar 14, 2011, at 09:46 PM, Antoine Pitrou wrote:

>Why does it get yet another name?
>We already have distutils, setuptools, distribute, distutils2... now
>"packaging"?

We need a unique name for Python 3.3, otherwise third party modules can't be
written to conditionally depend on the batteries-included version in 3.3, or a
standalone backport for older Pythons.

Guido's already pronounced that it will be 'packaging' in 3.3.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110314/412c468e/attachment.pgp>

From ziade.tarek at gmail.com  Mon Mar 14 23:00:50 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 14 Mar 2011 18:00:50 -0400
Subject: [Python-Dev] packaging
In-Reply-To: <20110314214614.2dde2518@pitrou.net>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
Message-ID: <AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>

On Mon, Mar 14, 2011 at 4:46 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 14 Mar 2011 15:39:55 -0400
> Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> Hey,
>>
>> I just wanted to summarize what we've started at the sprint (and
>> hopefully finish 1 to 7 this week):
>>
>> 1/ distutils2 is merged as the "packaging" Python package in the
>> standard library
>
> Why does it get yet another name?
> We already have distutils, setuptools, distribute, distutils2... now
> "packaging"?

For  it makes sense to have a "packaging" namespace in the standard
library, where we'll be able to add more modules, features etc.

"Distutils" becomes a misnomer now that we'll have features like:

- display the list of installed projects
- search projects at PyPI
- ...

And it's also a good way to prevent any conflict with 3.3 : the
standalone version for 2.4 to 3.2 is "distutils2", and people won't
have to deal with the same package being in the stdlib and at PyPI.
(like json vs simplejson, unittest vs unittest2...)

Cheers
Tarek

> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>



-- 
Tarek Ziad? | http://ziade.org

From solipsis at pitrou.net  Mon Mar 14 23:23:58 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Mar 2011 23:23:58 +0100
Subject: [Python-Dev] packaging
In-Reply-To: <AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
	<AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
Message-ID: <20110314232358.3a1d3b34@pitrou.net>

On Mon, 14 Mar 2011 18:00:50 -0400
Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> 
> And it's also a good way to prevent any conflict with 3.3 : the
> standalone version for 2.4 to 3.2 is "distutils2", and people won't
> have to deal with the same package being in the stdlib and at PyPI.
> (like json vs simplejson, unittest vs unittest2...)

But doesn't it also mean many setup.py scripts will have very tedious
import sequences, such as:

try:
    from packaging.compiler import FooCompiler
    from packaging.commands import BarCommand
except ImportError:
    try:
        from distutils2.compiler import FooCompiler
        from distutils2.commands import BarCommand
    except ImportError:
        try:
            from setuptools.compiler import FooCompiler
            from setuptools.commands import OtherNameForBarCommand as \
                                            BarCommand
        except ImportError:
            from distutils.compiler import FooCompiler
            from distutils.commands import OtherNameForBarCommand as \
                                           BarCommand

(I'm still remembering the import dances which were necessary to get
cElementTree/ElementTree in the 2.4-2.5 days)

Regards

Antoine.

From regebro at gmail.com  Mon Mar 14 23:30:17 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 14 Mar 2011 18:30:17 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <il75tb$c8s$1@dough.gmane.org>
References: <il75tb$c8s$1@dough.gmane.org>
Message-ID: <AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>

On Wed, Mar 9, 2011 at 01:15, Stefan Behnel <stefan_ml at behnel.de> wrote:
> I can confirm that the Cython project was as surprised of the PyCapsule
> change in Python 3.2 as (I guess) most other users, and I would claim that
> we are a project with one of the highest probabilities of being impacted by
> C-API changes.

And so was I. I discovered it today.

And personally, I don't mind being surprised. And I'm sorry I didn't
have time to try out the zope.* packages that support Python 3 on 3.2,
but then again the difference was supposed to be between 2.x and 3.x.
I didn't expect 3.2 to suddenly be backwards incompatible. Of the
eight packages that currently support 3.1 (in trunk), two packages do
not compile, and one gets massive test failures (which may only be
test failures, and not actual failures). That is *not* good. Perhaps
there is a easy way to map the API's with #defines, but if this is the
case, why was the change done in the first place?

But the problem here is not the surprise. If I had known about this
beforehand, that would only have helped, if I could have convinced
others that the API shouldn't have been removed!

The problem is the deprecation period!

Many projects, not only the Zope Toolkit needs to support a lot of
versions. The Zope component architecture currently supports 2.4, 2.5
and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can
be dropped, but it definitely will be *years* until we can drop
support for 2.6.  But if I move the PyCObject API to the PyCapsule
API, the zope packages will **only work on Python 2.7 and 3.2**. This
is obviously not an option. If I do *not* switch, I can't support
Python 3.2. That's bad.

**We can't deprecate an API in one version and drop the API in the
next. This is not acceptable. The deprecation period must be much
longer!**

In fact, since the deprecation in the Python 2 line happened in 2.7,
the deprecation period of this API in practice was between July 3rd
2010 and February 20 2011. That is a deprecation period of somewhat
longer than seven months. Nobody obviously though 2.6 was out of
practical use by now, so why did you decide to remove one if it's
API's?


Let's make no bones about this: The PyCObject API should *not* have
been removed in 3.2. In fact, the removal should be reversed, and
3.2.1 should be released ASAP, making 3.2 a moot and unsupported
version. It can possibly be removed in 3.3, but better would be 3.4.
It must be possible to support 3-4 releases of Python with the current
release speed. We need to support python versions that are five years
old or so. In fact the deprecation period should probably be somewhat
similar to the security fix period.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python3porting.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Mon Mar 14 23:34:24 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 14 Mar 2011 18:34:24 -0400
Subject: [Python-Dev] packaging
In-Reply-To: <20110314232358.3a1d3b34@pitrou.net>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
	<AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
	<20110314232358.3a1d3b34@pitrou.net>
Message-ID: <AANLkTinwudCqe5W8HkSvzZnYxGGoGH7tnLqGjqQaLzka@mail.gmail.com>

Setup.py is gone in distutils2 and therefore in packaging
Le 14 mars 2011 18:27, "Antoine Pitrou" <solipsis at pitrou.net> a ?crit :
> On Mon, 14 Mar 2011 18:00:50 -0400
> Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>
>> And it's also a good way to prevent any conflict with 3.3 : the
>> standalone version for 2.4 to 3.2 is "distutils2", and people won't
>> have to deal with the same package being in the stdlib and at PyPI.
>> (like json vs simplejson, unittest vs unittest2...)
>
> But doesn't it also mean many setup.py scripts will have very tedious
> import sequences, such as:
>
> try:
> from packaging.compiler import FooCompiler
> from packaging.commands import BarCommand
> except ImportError:
> try:
> from distutils2.compiler import FooCompiler
> from distutils2.commands import BarCommand
> except ImportError:
> try:
> from setuptools.compiler import FooCompiler
> from setuptools.commands import OtherNameForBarCommand as \
> BarCommand
> except ImportError:
> from distutils.compiler import FooCompiler
> from distutils.commands import OtherNameForBarCommand as \
> BarCommand
>
> (I'm still remembering the import dances which were necessary to get
> cElementTree/ElementTree in the 2.4-2.5 days)
>
> Regards
>
> Antoine.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110314/c065aa7e/attachment.html>

From p.f.moore at gmail.com  Tue Mar 15 00:03:04 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 14 Mar 2011 23:03:04 +0000
Subject: [Python-Dev] packaging
In-Reply-To: <AANLkTinwudCqe5W8HkSvzZnYxGGoGH7tnLqGjqQaLzka@mail.gmail.com>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
	<AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
	<20110314232358.3a1d3b34@pitrou.net>
	<AANLkTinwudCqe5W8HkSvzZnYxGGoGH7tnLqGjqQaLzka@mail.gmail.com>
Message-ID: <AANLkTik=f1JPD2AsTNopKytemYnHJa6sgZOSnRH-o3RM@mail.gmail.com>

On 14 March 2011 22:34, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> Setup.py is gone in distutils2 and therefore in packaging

Where can I find the documentation? The distutils2 docs ("A simple
example") still use setup.py. See
http://packages.python.org/Distutils2/distutils/introduction.html#a-simple-example

Paul

From ziade.tarek at gmail.com  Tue Mar 15 00:14:45 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 14 Mar 2011 19:14:45 -0400
Subject: [Python-Dev] Fwd: Re:  packaging
In-Reply-To: <AANLkTin4NoPQEYnVA_zxdBT69P5cFh+zX4wXPT622amX@mail.gmail.com>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
	<AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
	<20110314232358.3a1d3b34@pitrou.net>
	<AANLkTinwudCqe5W8HkSvzZnYxGGoGH7tnLqGjqQaLzka@mail.gmail.com>
	<AANLkTik=f1JPD2AsTNopKytemYnHJa6sgZOSnRH-o3RM@mail.gmail.com>
	<AANLkTin4NoPQEYnVA_zxdBT69P5cFh+zX4wXPT622amX@mail.gmail.com>
Message-ID: <AANLkTik7+5gpkY+9zfsCvm9sPNgE0kZ8s9ToNzyCu48L@mail.gmail.com>

Sorry i am not used to my new phone .. fwding to python-dev
---------- Message transf?r? ----------
De : "Tarek Ziad?" <ziade.tarek at gmail.com>
Date : 14 mars 2011 19:12
Objet : Re: [Python-Dev] packaging
? : "Paul Moore" <p.f.moore at gmail.com>

That document is from the latest release at pypi.  You can find a fresher
doc in docs in the hg repo.  There's also a rendering at
http://distutils2.notmyidea.org which is more recent.

One task during the sprint is to consolidate all the doc ;)
Le 14 mars 2011 19:03, "Paul Moore" <p.f.moore at gmail.com> a ?crit :

> On 14 March 2011 22:34, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> Setup.py is gone in distutils2 and therefore in packaging
>
> Where can I find the documentation? The distutils2 docs ("A simple
> example") still use setup.py. See
>
http://packages.python.org/Distutils2/distutils/introduction.html#a-simple-example
>
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110314/3dfc72e2/attachment.html>

From reid.kleckner at gmail.com  Tue Mar 15 00:22:34 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Mon, 14 Mar 2011 19:22:34 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
Message-ID: <AANLkTi=S7GDGYJiwaiPaOTqPV8TJ5nLq=Wc4dLE0O7c4@mail.gmail.com>

On Mon, Mar 14, 2011 at 6:30 PM, Lennart Regebro <regebro at gmail.com> wrote:
> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> I can confirm that the Cython project was as surprised of the PyCapsule
>> change in Python 3.2 as (I guess) most other users, and I would claim that
>> we are a project with one of the highest probabilities of being impacted by
>> C-API changes.
>
> And so was I. I discovered it today.
>
> And personally, I don't mind being surprised. And I'm sorry I didn't
> have time to try out the zope.* packages that support Python 3 on 3.2,
> but then again the difference was supposed to be between 2.x and 3.x.
> I didn't expect 3.2 to suddenly be backwards incompatible. Of the
> eight packages that currently support 3.1 (in trunk), two packages do
> not compile, and one gets massive test failures (which may only be
> test failures, and not actual failures). That is *not* good. Perhaps
> there is a easy way to map the API's with #defines, but if this is the
> case, why was the change done in the first place?

I don't know how your code works, but handling either type from C
seems very straightforward to me.  You can simply use #ifdef
Py_COBJECT_H to see if the cobject.h header was pulled into Python.h.
Similarly for Py_CAPSULE_H.  All you lose is that if you do get a
PyCObject, there is no way of knowing if the void pointer is of the
right type.

> Many projects, not only the Zope Toolkit needs to support a lot of
> versions. The Zope component architecture currently supports 2.4, 2.5
> and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can
> be dropped, but it definitely will be *years* until we can drop
> support for 2.6. ?But if I move the PyCObject API to the PyCapsule
> API, the zope packages will **only work on Python 2.7 and 3.2**. This
> is obviously not an option. If I do *not* switch, I can't support
> Python 3.2. That's bad.
>
> **We can't deprecate an API in one version and drop the API in the
> next. This is not acceptable. The deprecation period must be much
> longer!**

Surely, you must be joking.  Python already has a long release cycle.
I'm not familiar with this feature, but suppose it is decided that
there is sufficient cause to remove a feature.  First, we have to wait
until the next release to deprecate it.  Then we have to wait yet one
more release to remove it.  With an 18-month release cycle, that's 27
months on average.  To me, that is a very long time to wait.

> In fact, since the deprecation in the Python 2 line happened in 2.7,
> the deprecation period of this API in practice was between July 3rd
> 2010 and February 20 2011. That is a deprecation period of somewhat
> longer than seven months. Nobody obviously though 2.6 was out of
> practical use by now, so why did you decide to remove one if it's
> API's?

PyCObject was deprecated in 3.1, as well as 2.7.
http://docs.python.org/release/3.1.3/c-api/cobject.html#PyCObject

Reid

From nadeem.vawda at gmail.com  Tue Mar 15 00:34:17 2011
From: nadeem.vawda at gmail.com (Nadeem Vawda)
Date: Tue, 15 Mar 2011 01:34:17 +0200
Subject: [Python-Dev] Copyright notices
Message-ID: <AANLkTimEqTPhSBhfRXWJa5cpitFLms_XqrYaebTtpann@mail.gmail.com>

I was wondering what the policy is regarding copyright notices and license
boilerplate text at the top of source files.

I am currently rewriting the bz2 module (see http://bugs.python.org/issue5863),
splitting the existing Modules/bz2module.c into Modules/_bz2module.c and
Lib/bz2.py.

Are new files expected to include a copyright notice and/or license boilerplate
text? Also, is it necessary for _bz2module.c (new) to retain the copyright
notices from bz2module.c (old)? In the tracker issue, Antoine said he didn't
think so, but suggested that I get some additional opinions.

Regards,
Nadeem

From rdmurray at bitdance.com  Tue Mar 15 00:48:54 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 14 Mar 2011 19:48:54 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <4D7E807F.6030602@canterbury.ac.nz>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<4D7E807F.6030602@canterbury.ac.nz>
Message-ID: <20110314234854.78C7C20074E@kimball.webabinitio.net>

On Tue, 15 Mar 2011 09:54:23 +1300, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
> 
> > True, but all those underscores are a PITA to type and read for
> > methods that are meant to be called directly.
> 
> Matter of taste, I suppose. I don't find them all that
> bothersome, and a double underscore name stands out very
> clearly as being part of the infrastructure rather than
> something user-defined.

But directly calling a __xxx__ method in Python is a very
unusual thing to do.  It would be extremely odd to have that
be the expected way to call a method on a class.

--
R. David Murray                                      www.bitdance.com

From greg.ewing at canterbury.ac.nz  Tue Mar 15 01:27:09 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 15 Mar 2011 13:27:09 +1300
Subject: [Python-Dev] packaging
In-Reply-To: <20110314232358.3a1d3b34@pitrou.net>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
	<AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
	<20110314232358.3a1d3b34@pitrou.net>
Message-ID: <4D7EB25D.3010709@canterbury.ac.nz>

Antoine Pitrou wrote:

> But doesn't it also mean many setup.py scripts will have very tedious
> import sequences, such as:
> 
> try:
>     from packaging.compiler import FooCompiler
>     from packaging.commands import BarCommand
> except ImportError:
>     try:
>         from distutils2.compiler import FooCompiler
>         from distutils2.commands import BarCommand
 > ...

Maybe this will be the killer app for the "or" enhancement
to the import statement. :-)

-- 
Greg

From prologic at shortcircuit.net.au  Tue Mar 15 01:44:07 2011
From: prologic at shortcircuit.net.au (James Mills)
Date: Tue, 15 Mar 2011 10:44:07 +1000
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <20110314234854.78C7C20074E@kimball.webabinitio.net>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<4D7E807F.6030602@canterbury.ac.nz>
	<20110314234854.78C7C20074E@kimball.webabinitio.net>
Message-ID: <AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>

On Tue, Mar 15, 2011 at 9:48 AM, R. David Murray <rdmurray at bitdance.com> wrote:
> But directly calling a __xxx__ method in Python is a very
> unusual thing to do. ?It would be extremely odd to have that
> be the expected way to call a method on a class.

Can't namedtuple be improved to support the named fields _and_
have as_dict() and replace() without leading underscores ?

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

From bill at supposedly.org  Tue Mar 15 01:51:23 2011
From: bill at supposedly.org (Bill Green)
Date: Mon, 14 Mar 2011 17:51:23 -0700
Subject: [Python-Dev] NetBSD and curses
Message-ID: <4D7EB80B.1050907@supposedly.org>

Hi all,

I ran across this issue several months ago and filed a bug report 
(#9667).  It just came up again, and it doesn't look like anything's 
been done with the bug report, so I thought I'd post here.

In _cursesmodule.c there are a lot of preprocesser conditionals that 
test if the system is NetBSD. In my case, the issue was that the module 
built lacked the KEY_UP / _DOWN / etc. constants, but there are other 
changes as well.  This is the case even if you're compiling against 
ncurses instead of the system curses.  ?ttached below is a patch against 
2.7.1 that negates the NetBSD conditionals if ncurses is present.  It 
seems to work as expected, although I haven't done any real testing.  I 
assumed this was done because NetBSD curses was missing something, but I 
looked at the headers and it seems to have most of the constants that 
the compilation directives are leaving out (A_INVIS, the aforementioned 
KEY_* constants, at least), so I'm not sure why that code isn't compiled 
in anyway.  Please let me know if I'm misunderstanding this.

Thanks,
Bill
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: _cursesmodule.c.diff
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110314/fb15c810/attachment.ksh>

From eric at trueblade.com  Tue Mar 15 02:23:10 2011
From: eric at trueblade.com (Eric Smith)
Date: Mon, 14 Mar 2011 21:23:10 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>	<4D7DB6CF.5050102@canterbury.ac.nz>	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>	<4D7E807F.6030602@canterbury.ac.nz>	<20110314234854.78C7C20074E@kimball.webabinitio.net>
	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>
Message-ID: <4D7EBF7E.8010509@trueblade.com>

On 3/14/2011 8:44 PM, James Mills wrote:
> On Tue, Mar 15, 2011 at 9:48 AM, R. David Murray<rdmurray at bitdance.com>  wrote:
>> But directly calling a __xxx__ method in Python is a very
>> unusual thing to do.  It would be extremely odd to have that
>> be the expected way to call a method on a class.
>
> Can't namedtuple be improved to support the named fields _and_
> have as_dict() and replace() without leading underscores ?

How would that work if you had a field named "replace"? I think 
Raymond's current design is as good as it's going to get.

Eric.

From tjreedy at udel.edu  Tue Mar 15 02:50:40 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 14 Mar 2011 21:50:40 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <4D7EBF7E.8010509@trueblade.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>	<4D7DB6CF.5050102@canterbury.ac.nz>	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>	<4D7E807F.6030602@canterbury.ac.nz>	<20110314234854.78C7C20074E@kimball.webabinitio.net>	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>
	<4D7EBF7E.8010509@trueblade.com>
Message-ID: <ilmglf$dl6$1@dough.gmane.org>

On 3/14/2011 9:23 PM, Eric Smith wrote:
> On 3/14/2011 8:44 PM, James Mills wrote:
>> On Tue, Mar 15, 2011 at 9:48 AM, R. David
>> Murray<rdmurray at bitdance.com> wrote:
>>> But directly calling a __xxx__ method in Python is a very
>>> unusual thing to do. It would be extremely odd to have that
>>> be the expected way to call a method on a class.
>>
>> Can't namedtuple be improved to support the named fields _and_
>> have as_dict() and replace() without leading underscores ?
>
> How would that work if you had a field named "replace"? I think
> Raymond's current design is as good as it's going to get.

'as_dict' is an unlikely fieldname. 're_place' is too, but that just 
shift the '_' from '_replace'. No gain. I might prefer _asdict to 
_as_dict, but not enough to change.

-- 
Terry Jan Reedy


From prologic at shortcircuit.net.au  Tue Mar 15 03:02:30 2011
From: prologic at shortcircuit.net.au (James Mills)
Date: Tue, 15 Mar 2011 12:02:30 +1000
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <ilmglf$dl6$1@dough.gmane.org>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<4D7E807F.6030602@canterbury.ac.nz>
	<20110314234854.78C7C20074E@kimball.webabinitio.net>
	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>
	<4D7EBF7E.8010509@trueblade.com> <ilmglf$dl6$1@dough.gmane.org>
Message-ID: <AANLkTinLXhP9G9OFzJJfYeG1j=dRY_hoyZ71C-nnT54c@mail.gmail.com>

On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>> How would that work if you had a field named "replace"? I think
>> Raymond's current design is as good as it's going to get.
>
> 'as_dict' is an unlikely fieldname. 're_place' is too, but that just shift
> the '_' from '_replace'. No gain. I might prefer _asdict to _as_dict, but
> not enough to change.

Probably a stupid idea (sorry) but one could just
make asdict() and replace() public methods
with the caveat that developers not use those
as field names.

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

From guido at python.org  Tue Mar 15 03:58:07 2011
From: guido at python.org (Guido van Rossum)
Date: Mon, 14 Mar 2011 19:58:07 -0700
Subject: [Python-Dev] PEP 382 Master
In-Reply-To: <4D7E7645.4050902@v.loewis.de>
References: <4D7E7645.4050902@v.loewis.de>
Message-ID: <AANLkTinn8j65X2wjRBV3j_SqVrxxRYJP7h5OD4B=eoJ1@mail.gmail.com>

On Mon, Mar 14, 2011 at 1:10 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I'd like to appoint Eric Smith as the PEP master for PEP 382
> (Namespace Packages).

Eric has ample experience with PEPs and strikes me as pretty
even-keeled (hi Eric! :-) so +1 from me.

> I hope to complete the implementation shortly, at which point
> there will be a final call for comments.

Great, ideally we should have reference implementations for all PEPs
before their final review.

-- 
--Guido van Rossum (python.org/~guido)

From eltoder at gmail.com  Tue Mar 15 05:56:55 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Tue, 15 Mar 2011 00:56:55 -0400
Subject: [Python-Dev] Suggest reverting today's checkin (recursive
 constant folding in the peephole optimizer)
In-Reply-To: <AANLkTikv2SK+aFdURBwzXy62tF=GDPY1Kqg_VTC2_18H@mail.gmail.com>
References: <1CF13F75-6CB8-4EA6-B758-75E6FDAC6EE7@gmail.com>
	<AANLkTinFy6bkxeL48JKmxFJv=Mz7gauKYM1vZATnYP_D@mail.gmail.com>
	<AANLkTi=xmq1qUv5HP_QTf=aJ=oZaFg4_BqtTUUJpEUed@mail.gmail.com>
	<20110312101642.1699902d@pitrou.net>
	<B6E14BD9-DCFF-45E9-BCF8-F2386CE42998@gmail.com>
	<AANLkTinjtDRx+ffUf1mL_RKcUujtaRvwP=WjHrOk2Whq@mail.gmail.com>
	<AANLkTikv2SK+aFdURBwzXy62tF=GDPY1Kqg_VTC2_18H@mail.gmail.com>
Message-ID: <AANLkTi=k=d=+bozapiQc-GSpNq89BSyMotsFWXbPWtDQ@mail.gmail.com>

To give this a positive spin, here's a patch that implements constant
folding on AST (it does few other optimizations on compiler data
structures, so it replaces "peephole over bytecode" completely).

http://bugs.python.org/issue11549

It passes make test, but of course more testing is needed. Comments are welcome.

Eugene

From eric at trueblade.com  Tue Mar 15 09:20:27 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 15 Mar 2011 04:20:27 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTinLXhP9G9OFzJJfYeG1j=dRY_hoyZ71C-nnT54c@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>	<4D7DB6CF.5050102@canterbury.ac.nz>	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>	<4D7E807F.6030602@canterbury.ac.nz>	<20110314234854.78C7C20074E@kimball.webabinitio.net>	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>	<4D7EBF7E.8010509@trueblade.com>
	<ilmglf$dl6$1@dough.gmane.org>
	<AANLkTinLXhP9G9OFzJJfYeG1j=dRY_hoyZ71C-nnT54c@mail.gmail.com>
Message-ID: <4D7F214B.1000104@trueblade.com>

On 03/14/2011 10:02 PM, James Mills wrote:
> On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedy<tjreedy at udel.edu>  wrote:
>>> How would that work if you had a field named "replace"? I think
>>> Raymond's current design is as good as it's going to get.
>>
>> 'as_dict' is an unlikely fieldname. 're_place' is too, but that just shift
>> the '_' from '_replace'. No gain. I might prefer _asdict to _as_dict, but
>> not enough to change.
>
> Probably a stupid idea (sorry) but one could just
> make asdict() and replace() public methods
> with the caveat that developers not use those
> as field names.

The field names are not always under direct control of the developer, 
such as when they are database column names. Not that using _replace 
completely gets rid of this problem, but I agree with Raymond's decision 
that a field name can be any valid identifier not starting with an 
underscore. It's the simplest thing for the developer using namedtuple.

Eric.


From ncoghlan at gmail.com  Tue Mar 15 12:50:39 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 21:50:39 +1000
Subject: [Python-Dev] packaging
In-Reply-To: <4D7EB25D.3010709@canterbury.ac.nz>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
	<AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
	<20110314232358.3a1d3b34@pitrou.net>
	<4D7EB25D.3010709@canterbury.ac.nz>
Message-ID: <AANLkTi=h_NPsRm2X9=wcR2RJsAVHXzD=UQEzs3KXX=T0@mail.gmail.com>

On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Maybe this will be the killer app for the "or" enhancement
> to the import statement. :-)

Except that won't help, since even if it were added right now, pre-3.3
compatible code couldn't use it :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Mar 15 12:59:16 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 21:59:16 +1000
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <4D7F214B.1000104@trueblade.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<4D7E807F.6030602@canterbury.ac.nz>
	<20110314234854.78C7C20074E@kimball.webabinitio.net>
	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>
	<4D7EBF7E.8010509@trueblade.com> <ilmglf$dl6$1@dough.gmane.org>
	<AANLkTinLXhP9G9OFzJJfYeG1j=dRY_hoyZ71C-nnT54c@mail.gmail.com>
	<4D7F214B.1000104@trueblade.com>
Message-ID: <AANLkTi=r0hku_fXUjKPAj5=XPRqABnwwzb5ufKwcQb3P@mail.gmail.com>

On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith <eric at trueblade.com> wrote:
> The field names are not always under direct control of the developer, such
> as when they are database column names. Not that using _replace completely
> gets rid of this problem, but I agree with Raymond's decision that a field
> name can be any valid identifier not starting with an underscore. It's the
> simplest thing for the developer using namedtuple.

While I actually think the current API design is a decent compromise,
another option to consider would be to move the underscore to the
*end* (as_dict_, replace_, make_) as is sometimes done for code that
needs to avoid conflicting with a keyword.

Namespace collisions with actual fields would remain unlikely, while
pydoc would pick up the new names correctly.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Tue Mar 15 14:20:06 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 15 Mar 2011 09:20:06 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
Message-ID: <4D7F6786.1060902@v.loewis.de>

 > In fact, since the deprecation in the Python 2 line happened in 2.7,
 > the deprecation period of this API in practice was between July 3rd
 > 2010 and February 20 2011. That is a deprecation period of somewhat
 > longer than seven months. Nobody obviously though 2.6 was out of
 > practical use by now, so why did you decide to remove one if it's
 > API's?

Python 2.6's API wasn't removed in 2.7. It remains available.

If you go from 2.7 to 3.2, you should expect things to break. That's
why the major version changed.

For 3.x, as Reid points out, the API was deprecated in 3.1, so the
deprecation period was rather 19 months, not 7.

 > Let's make no bones about this: The PyCObject API should *not* have
 > been removed in 3.2. In fact, the removal should be reversed, and
 > 3.2.1 should be released ASAP, making 3.2 a moot and unsupported
 > version.

This change conforms to PEP 5:

"There must be at least a one-year transition period between the
release of the transitional version of Python and the release
of the backwards incompatible version.  Users will have at
least a year to test their programs and migrate them from use
of the deprecated construct to the alternative one."

If you think a year is too little, you should lobby for a PEP 5
change.

Regards,
Martin


From greg at krypto.org  Tue Mar 15 14:38:20 2011
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 15 Mar 2011 09:38:20 -0400
Subject: [Python-Dev] NetBSD and curses
In-Reply-To: <4D7EB80B.1050907@supposedly.org>
References: <4D7EB80B.1050907@supposedly.org>
Message-ID: <AANLkTikczOtF3x1rjtnp-0VXspSuGHh2jg6RctpBBEAo@mail.gmail.com>

Would you please post this to bugs.python.org so that it doesn't get lost?
 thanks!

-gps

On Mon, Mar 14, 2011 at 8:51 PM, Bill Green <bill at supposedly.org> wrote:

> Hi all,
>
> I ran across this issue several months ago and filed a bug report (#9667).
>  It just came up again, and it doesn't look like anything's been done with
> the bug report, so I thought I'd post here.
>
> In _cursesmodule.c there are a lot of preprocesser conditionals that test
> if the system is NetBSD. In my case, the issue was that the module built
> lacked the KEY_UP / _DOWN / etc. constants, but there are other changes as
> well.  This is the case even if you're compiling against ncurses instead of
> the system curses.  ?ttached below is a patch against 2.7.1 that negates the
> NetBSD conditionals if ncurses is present.  It seems to work as expected,
> although I haven't done any real testing.  I assumed this was done because
> NetBSD curses was missing something, but I looked at the headers and it
> seems to have most of the constants that the compilation directives are
> leaving out (A_INVIS, the aforementioned KEY_* constants, at least), so I'm
> not sure why that code isn't compiled in anyway.  Please let me know if I'm
> misunderstanding this.
>
> Thanks,
> Bill
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110315/6f1faa93/attachment.html>

From tlesher at gmail.com  Tue Mar 15 14:42:38 2011
From: tlesher at gmail.com (Tim Lesher)
Date: Tue, 15 Mar 2011 09:42:38 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>
Message-ID: <AANLkTim+ustociR9UB4Qff_99qtC8h1j+xebcPph8jju@mail.gmail.com>

On Mon, Mar 14, 2011 at 08:28, Tim Lesher <tlesher at gmail.com> wrote:
> On Mon, Mar 14, 2011 at 05:45, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> There are two relatively simple ways forward I can see:
>>
>> A. Add a __public__ attribute that pydoc (and import *) understand.
>> This would overrride the default "this is private" detection and add
>> affected names to the public list (without needing to respecify all
>> the "default public" names - this is important in order to support
>> subclassing correctly)
>
> I believe this was the direction the bug report was implying.
>
> I'll be sprinting for a few hours this morning; if there are no
> objections, I will try to turn this idea into a patch that makes
> pydoc.visiblename look for a __public__ function attribute as "step
> 0".
>
> Maybe there should also be a @public decorator to apply it, although
> that name may be an attractive nuisance, tempting C++ or Java
> programmers new to Python to ask for @protected and @private...

I implemented this on Monday, and it worked great... for instance
methods.  Unfortunately, it doesn't do a thing for classmethods or
data attributes, which are 2/4 of the original namedtuple use cases,
so it feels like a bad idea.

In the process of implementing it, though, I realized that the __all__
mechanism for modules could still be reused.  Two implementations came
to mind:

1. Allow an __all__ class attribute that affects pydoc for classes the
same way it does for modules.
Pro: it's familiar, easy to explain, and easy to implement (four lines of code)
Con: the original use case (adding a small number of
otherwise-excluded attributes to existing documentation) is
cumbersome. Because __all__ means "don't document anything but
__special_names__ and the contents of __all__, you'd have to manually
add names that pydoc would normally pick up.  Also, __all__ itself
will show up in the documentation, which seems to me like useless
clutter to a reader of help().

2. Add a new class attribute that uses the same mechanism, with a
different name (e.g., __api__).
Pro: fairly easy to explain; because it doesn't share a name with
__all__ its semantics can be tweaked without confusing people.
Con: slight additional cognitive burden of a new feature

I'm implementing both of these separately this week to see which works
better in practice.  So far I'm liking __api__ better, with these
semantics:

1. Classes without __api__ are treated just as they are today.
2. __api__ on classes works just like __all__ on modules (only special
names, plus its contents are documented)
3. Additionally, __api__ can take an Ellipsis.  That makes the __api__
list additive--pydoc documents everything it normally would, *plus*
the contents of __api__
4. __api__ is added to pydoc's "hidden names" list; since its only
purpose is to help generate docs, its value would be of little use in
the generated docs themselves.

Point 3 (Ellipsis) is unusual, but to me it makes the declaration read
well and solves the namedtuple case succinctly and compatibly, without
changing a published API.  It also could be used to address the issue
of stdlib classes that have non-underscored members that really
shouldn't be considered part of the "public" API, but can't be renamed
now for fear of breaking code.

Usage example:

class C1:
    __api__ = ['meth1', '_data2'] # read as "The API consists of meth1
and _data2."
    def __init__(self):
        """documented because it's a special name"""
    def meth1(self):
        """documented because it's in __api__"""
    def meth2(self):
        """Shouldn't really have been exposed, but it was released that way,
           and we don't want to break users' code.
           NOT documented because it's not in __api__
           """
    def _meth3(self):
        """NOT documented because it's not in __api__"""
    data1 = None # not documented--not in __api__
    _data2 = None # documented--it's in __api__

class C2:
    __api__ = ['_data2', ...] # read as "The API includes _data2."
    def __init__(self):
        """This is documented because it's a special name"""
    def meth1(self):
        """documented because it follows the normal rules"""
    def meth2(self):
        """documented because it follows the normal rules"""
    def _meth3(self):
        """NOT documented because it's not in __api__ and starts with
underscore"""
    data1 = # documented because it follows the normal rules
    _data2 = None # documented--it's in __api__

Comments and criticisms welcome.

-- 
Tim Lesher <tlesher at gmail.com>

From ziade.tarek at gmail.com  Tue Mar 15 14:48:18 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Mar 2011 09:48:18 -0400
Subject: [Python-Dev] packaging
In-Reply-To: <AANLkTi=h_NPsRm2X9=wcR2RJsAVHXzD=UQEzs3KXX=T0@mail.gmail.com>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
	<AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
	<20110314232358.3a1d3b34@pitrou.net>
	<4D7EB25D.3010709@canterbury.ac.nz>
	<AANLkTi=h_NPsRm2X9=wcR2RJsAVHXzD=UQEzs3KXX=T0@mail.gmail.com>
Message-ID: <AANLkTikSjuDFDOUNT1HrdMB60ar4kj9XJbWnQubrjZ31@mail.gmail.com>

On Tue, Mar 15, 2011 at 7:50 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing
> <greg.ewing at canterbury.ac.nz> wrote:
>> Maybe this will be the killer app for the "or" enhancement
>> to the import statement. :-)
>
> Except that won't help, since even if it were added right now, pre-3.3
> compatible code couldn't use it :)

or if you backport it, we could add a new fallback ;)

try:
    from __future__ import or_importer
except ImportError:
    XXX <-- previous proposal
 else:
    or based proposal




>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>



-- 
Tarek Ziad? | http://ziade.org

From fuzzyman at voidspace.org.uk  Tue Mar 15 15:22:44 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 15 Mar 2011 10:22:44 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTi=r0hku_fXUjKPAj5=XPRqABnwwzb5ufKwcQb3P@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>	<4D7DB6CF.5050102@canterbury.ac.nz>	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>	<4D7E807F.6030602@canterbury.ac.nz>	<20110314234854.78C7C20074E@kimball.webabinitio.net>	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>	<4D7EBF7E.8010509@trueblade.com>
	<ilmglf$dl6$1@dough.gmane.org>	<AANLkTinLXhP9G9OFzJJfYeG1j=dRY_hoyZ71C-nnT54c@mail.gmail.com>	<4D7F214B.1000104@trueblade.com>
	<AANLkTi=r0hku_fXUjKPAj5=XPRqABnwwzb5ufKwcQb3P@mail.gmail.com>
Message-ID: <4D7F7634.40908@voidspace.org.uk>

On 15/03/2011 07:59, Nick Coghlan wrote:
> On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith<eric at trueblade.com>  wrote:
>> The field names are not always under direct control of the developer, such
>> as when they are database column names. Not that using _replace completely
>> gets rid of this problem, but I agree with Raymond's decision that a field
>> name can be any valid identifier not starting with an underscore. It's the
>> simplest thing for the developer using namedtuple.
> While I actually think the current API design is a decent compromise,
> another option to consider would be to move the underscore to the
> *end* (as_dict_, replace_, make_) as is sometimes done for code that
> needs to avoid conflicting with a keyword.
>
> Namespace collisions with actual fields would remain unlikely, while
> pydoc would pick up the new names correctly.
>

Although it's a backwards incompatible change. Teaching pydoc to 
recognise the private methods isn't.

Michael

> Cheers,
> Nick.
>


-- 
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


From solipsis at pitrou.net  Tue Mar 15 15:44:05 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 15 Mar 2011 15:44:05 +0100
Subject: [Python-Dev] cpython: Fix #11509. Significantly increase test
 coverage for fileinput.
References: <E1PzVG3-000067-0I@dinsdale.python.org>
Message-ID: <20110315154405.67b59e2b@pitrou.net>

On Tue, 15 Mar 2011 15:29:59 +0100
brian.curtin <python-checkins at python.org> wrote:
> +
> +    def test_gz_ext(self):
[...]
> +
> +    def test_bz2_ext(self):
[...]
> +
> +    def test_Gz_ext(self):
> +        self.do_test_use_builtin_open("abcd.Gz", 6)
> +
> +    def test_Bz2_ext(self):
> +        self.do_test_use_builtin_open("abcd.Bz2", 7)

Just a stylistic nit, but perhaps we should avoid having methods names
which differ in casing only?

Regards

Antoine.



From brian.curtin at gmail.com  Tue Mar 15 15:52:05 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Tue, 15 Mar 2011 10:52:05 -0400
Subject: [Python-Dev] cpython: Fix #11509. Significantly increase test
 coverage for fileinput.
In-Reply-To: <20110315154405.67b59e2b@pitrou.net>
References: <E1PzVG3-000067-0I@dinsdale.python.org>
	<20110315154405.67b59e2b@pitrou.net>
Message-ID: <AANLkTikNCMqVe8qSfXiL=fzXEJv==0YeztXxk6h=4eHi@mail.gmail.com>

On Tue, Mar 15, 2011 at 10:44, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Tue, 15 Mar 2011 15:29:59 +0100
> brian.curtin <python-checkins at python.org> wrote:
> > +
> > +    def test_gz_ext(self):
> [...]
> > +
> > +    def test_bz2_ext(self):
> [...]
> > +
> > +    def test_Gz_ext(self):
> > +        self.do_test_use_builtin_open("abcd.Gz", 6)
> > +
> > +    def test_Bz2_ext(self):
> > +        self.do_test_use_builtin_open("abcd.Bz2", 7)
>
> Just a stylistic nit, but perhaps we should avoid having methods names
> which differ in casing only?


Agreed. I'll rename them to be more expressive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110315/52a7946f/attachment.html>

From regebro at gmail.com  Tue Mar 15 16:01:37 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 15 Mar 2011 11:01:37 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <4D7F6786.1060902@v.loewis.de>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
Message-ID: <AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>

On Tue, Mar 15, 2011 at 09:20, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> In fact, since the deprecation in the Python 2 line happened in 2.7,
>> the deprecation period of this API in practice was between July 3rd
>> 2010 and February 20 2011. That is a deprecation period of somewhat
>> longer than seven months. Nobody obviously though 2.6 was out of
>> practical use by now, so why did you decide to remove one if it's
>> API's?
>
> Python 2.6's API wasn't removed in 2.7. It remains available.

But not in 3.2. And the new API appeared in 2.7. That is a deprecation
period of seven and a half months.

> If you go from 2.7 to 3.2, you should expect things to break. That's
> why the major version changed.

And 3.1 to 3.2? There is no major version break there.

> For 3.x, as Reid points out, the API was deprecated in 3.1, so the
> deprecation period was rather 19 months, not 7.

Yes, but we are now in a period of parallell support for Python 2 and
Python 3. So it doesn't work like that. We need to support both Python
2 and Python 3 at the same time. Therefore, the deprecation period was
seven and a half month, because it was impossible to support the new
API before, and impossible to support the new API after, if you need
to support both Python 2 and Python 3.

>> Let's make no bones about this: The PyCObject API should *not* have
>> been removed in 3.2. In fact, the removal should be reversed, and
>> 3.2.1 should be released ASAP, making 3.2 a moot and unsupported
>> version.
>
> This change conforms to PEP 5:
>
> "There must be at least a one-year transition period between the
> release of the transitional version of Python and the release
> of the backwards incompatible version. ?Users will have at
> least a year to test their programs and migrate them from use
> of the deprecated construct to the alternative one."

It is too short, and so is 19 months, but this change does *not* conform.

//Lennart

From regebro at gmail.com  Tue Mar 15 16:10:17 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 15 Mar 2011 11:10:17 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <AANLkTi=S7GDGYJiwaiPaOTqPV8TJ5nLq=Wc4dLE0O7c4@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<AANLkTi=S7GDGYJiwaiPaOTqPV8TJ5nLq=Wc4dLE0O7c4@mail.gmail.com>
Message-ID: <AANLkTi=Mf80MrkdNa5y_mo3R9Z20riLObLABK3WTTM6c@mail.gmail.com>

On Mon, Mar 14, 2011 at 19:22, Reid Kleckner <reid.kleckner at gmail.com> wrote:
> I don't know how your code works, but handling either type from C
> seems very straightforward to me. ?You can simply use #ifdef
> Py_COBJECT_H to see if the cobject.h header was pulled into Python.h.
> Similarly for Py_CAPSULE_H. ?All you lose is that if you do get a
> PyCObject, there is no way of knowing if the void pointer is of the
> right type.

Good to know.

>> **We can't deprecate an API in one version and drop the API in the
>> next. This is not acceptable. The deprecation period must be much
>> longer!**
>
> Surely, you must be joking.

No.

//Lennart

From ncoghlan at gmail.com  Tue Mar 15 16:15:29 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 11:15:29 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTim+ustociR9UB4Qff_99qtC8h1j+xebcPph8jju@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>
	<AANLkTim+ustociR9UB4Qff_99qtC8h1j+xebcPph8jju@mail.gmail.com>
Message-ID: <AANLkTimrH3tSX5jXZ4NZa0Y2FkFgWMSoaF_58LsisrRV@mail.gmail.com>

On Tue, Mar 15, 2011 at 9:42 AM, Tim Lesher <tlesher at gmail.com> wrote:
> 2. Add a new class attribute that uses the same mechanism, with a
> different name (e.g., __api__).
> Pro: fairly easy to explain; because it doesn't share a name with
> __all__ its semantics can be tweaked without confusing people.
> Con: slight additional cognitive burden of a new feature
>
> I'm implementing both of these separately this week to see which works
> better in practice. ?So far I'm liking __api__ better, with these
> semantics:
>
> 1. Classes without __api__ are treated just as they are today.
> 2. __api__ on classes works just like __all__ on modules (only special
> names, plus its contents are documented)
> 3. Additionally, __api__ can take an Ellipsis. ?That makes the __api__
> list additive--pydoc documents everything it normally would, *plus*
> the contents of __api__
> 4. __api__ is added to pydoc's "hidden names" list; since its only
> purpose is to help generate docs, its value would be of little use in
> the generated docs themselves.
>
> Point 3 (Ellipsis) is unusual, but to me it makes the declaration read
> well and solves the namedtuple case succinctly and compatibly, without
> changing a published API. ?It also could be used to address the issue
> of stdlib classes that have non-underscored members that really
> shouldn't be considered part of the "public" API, but can't be renamed
> now for fear of breaking code.

The challenge here is how it would interact with inheritance. pydoc
couldn't use normal attribute lookup, it would have to walk the MRO
manually, only applying __api__ to the specific class that defined it.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Mar 15 16:17:18 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 11:17:18 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <4D7F7634.40908@voidspace.org.uk>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<4D7E807F.6030602@canterbury.ac.nz>
	<20110314234854.78C7C20074E@kimball.webabinitio.net>
	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>
	<4D7EBF7E.8010509@trueblade.com> <ilmglf$dl6$1@dough.gmane.org>
	<AANLkTinLXhP9G9OFzJJfYeG1j=dRY_hoyZ71C-nnT54c@mail.gmail.com>
	<4D7F214B.1000104@trueblade.com>
	<AANLkTi=r0hku_fXUjKPAj5=XPRqABnwwzb5ufKwcQb3P@mail.gmail.com>
	<4D7F7634.40908@voidspace.org.uk>
Message-ID: <AANLkTin5ij_Sh0h+mmQw1qt8aPT+kQReDmt0V6EWNwH-@mail.gmail.com>

On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 15/03/2011 07:59, Nick Coghlan wrote:
>> While I actually think the current API design is a decent compromise,
>> another option to consider would be to move the underscore to the
>> *end* (as_dict_, replace_, make_) as is sometimes done for code that
>> needs to avoid conflicting with a keyword.
>>
>> Namespace collisions with actual fields would remain unlikely, while
>> pydoc would pick up the new names correctly.
>>
>
> Although it's a backwards incompatible change. Teaching pydoc to recognise
> the private methods isn't.

If we can find a good way to do it, making pydoc smarter would
definitely be a nicer option.

If we went the "moving the underscore" route, the old names would
indeed have to remain for compatibility. Just one of many reasons it
isn't a great solution :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Mar 15 16:23:09 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 11:23:09 -0400
Subject: [Python-Dev] packaging
In-Reply-To: <AANLkTikSjuDFDOUNT1HrdMB60ar4kj9XJbWnQubrjZ31@mail.gmail.com>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
	<AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
	<20110314232358.3a1d3b34@pitrou.net>
	<4D7EB25D.3010709@canterbury.ac.nz>
	<AANLkTi=h_NPsRm2X9=wcR2RJsAVHXzD=UQEzs3KXX=T0@mail.gmail.com>
	<AANLkTikSjuDFDOUNT1HrdMB60ar4kj9XJbWnQubrjZ31@mail.gmail.com>
Message-ID: <AANLkTikd0A7biCfcPMCnDM-QJAFdRgr6WSzpQ0BVRpbA@mail.gmail.com>

On Tue, Mar 15, 2011 at 9:48 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> or if you backport it, we could add a new fallback ;)
>
> try:
> ? ?from __future__ import or_importer
> except ImportError:
> ? ?XXX <-- previous proposal
> ?else:
> ? ?or based proposal

Alas, the fallback trick doesn't work for the from __future__ compiler hacks.

What you could do though, is isolate the logic for the import
fallbacks and then do:

from myproject.import_fallbacks import compiler, commands

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Tue Mar 15 16:24:09 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 15 Mar 2011 16:24:09 +0100
Subject: [Python-Dev] pydoc for named tuples is missing methods
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<4D7E807F.6030602@canterbury.ac.nz>
	<20110314234854.78C7C20074E@kimball.webabinitio.net>
	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>
	<4D7EBF7E.8010509@trueblade.com> <ilmglf$dl6$1@dough.gmane.org>
	<AANLkTinLXhP9G9OFzJJfYeG1j=dRY_hoyZ71C-nnT54c@mail.gmail.com>
	<4D7F214B.1000104@trueblade.com>
	<AANLkTi=r0hku_fXUjKPAj5=XPRqABnwwzb5ufKwcQb3P@mail.gmail.com>
	<4D7F7634.40908@voidspace.org.uk>
	<AANLkTin5ij_Sh0h+mmQw1qt8aPT+kQReDmt0V6EWNwH-@mail.gmail.com>
Message-ID: <20110315162409.7dee0476@pitrou.net>

On Tue, 15 Mar 2011 11:17:18 -0400
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
> > On 15/03/2011 07:59, Nick Coghlan wrote:
> >> While I actually think the current API design is a decent compromise,
> >> another option to consider would be to move the underscore to the
> >> *end* (as_dict_, replace_, make_) as is sometimes done for code that
> >> needs to avoid conflicting with a keyword.
> >>
> >> Namespace collisions with actual fields would remain unlikely, while
> >> pydoc would pick up the new names correctly.
> >>
> >
> > Although it's a backwards incompatible change. Teaching pydoc to recognise
> > the private methods isn't.
> 
> If we can find a good way to do it, making pydoc smarter would
> definitely be a nicer option.

Wouldn't a decorator be adequate?

    @pydoc.public_api
    def _asdict(self):
        """some docstring"""
        ...

Regards

Antoine.



From ncoghlan at gmail.com  Tue Mar 15 16:28:00 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 11:28:00 -0400
Subject: [Python-Dev] cpython: Fix #11509. Significantly increase test
 coverage for fileinput.
In-Reply-To: <AANLkTikNCMqVe8qSfXiL=fzXEJv==0YeztXxk6h=4eHi@mail.gmail.com>
References: <E1PzVG3-000067-0I@dinsdale.python.org>
	<20110315154405.67b59e2b@pitrou.net>
	<AANLkTikNCMqVe8qSfXiL=fzXEJv==0YeztXxk6h=4eHi@mail.gmail.com>
Message-ID: <AANLkTimDkL4dbmra8EkX6V7joEZtT=5ZCupGdRYKG_6Z@mail.gmail.com>

On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin <brian.curtin at gmail.com> wrote:
> Agreed. I'll rename them to be more expressive.

Don't forget NEWS and ACKS updates as well.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From eltoder at gmail.com  Tue Mar 15 16:49:49 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Tue, 15 Mar 2011 11:49:49 -0400
Subject: [Python-Dev] The purpose of SETUP_LOOP, BREAK_LOOP,
	CONTINUE_LOOP
In-Reply-To: <20110312190422.20EF03A4077@sparrow.telecommunity.com>
References: <AANLkTikvBCMO7oNYKMwPKZ0-o6x38FmxatYVBmAy-w-p@mail.gmail.com>
	<20110312115901.5389fe69@pitrou.net>
	<AANLkTimbqSFsz5hqLqunfd2LaYuf2NLBRdCqqmVRcc5R@mail.gmail.com>
	<20110312190422.20EF03A4077@sparrow.telecommunity.com>
Message-ID: <AANLkTikm+oF1oRc89Nnsv7BDbLPXFa99Eew6zo4XqNEr@mail.gmail.com>

> I think you guys are forgetting about FOR_ITER, listcomps, and the like.
>
> That is, IIRC, the reason loops use the block stack is because they put
> things on the regular stack, that need to be cleared off the stack when the
> loop is exited (whether normally or via an exception).

Good point. However, for exit via exception you always unwind till try
block, having loop block in the way seems unneeded?
While loops don't keep anything on values stack, so sounds like they
can avoid SETUP_LOOP?
Comprehensions don't use SETUP_LOOP already as you can't break from them.
Sounds like the only use case is for loop with explicit break. In this
case break can be compiled into POP and JUMP at the expense of
bytecode size if there are multiple breaks.

Eugene

From brian.curtin at gmail.com  Tue Mar 15 16:57:02 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Tue, 15 Mar 2011 11:57:02 -0400
Subject: [Python-Dev] cpython: Fix #11509. Significantly increase test
 coverage for fileinput.
In-Reply-To: <AANLkTimDkL4dbmra8EkX6V7joEZtT=5ZCupGdRYKG_6Z@mail.gmail.com>
References: <E1PzVG3-000067-0I@dinsdale.python.org>
	<20110315154405.67b59e2b@pitrou.net>
	<AANLkTikNCMqVe8qSfXiL=fzXEJv==0YeztXxk6h=4eHi@mail.gmail.com>
	<AANLkTimDkL4dbmra8EkX6V7joEZtT=5ZCupGdRYKG_6Z@mail.gmail.com>
Message-ID: <AANLkTin6PU6W3j5i3LUeBO2PFJXKVPA_-UEu5ffA04zF@mail.gmail.com>

On Tue, Mar 15, 2011 at 11:28, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin <brian.curtin at gmail.com>
> wrote:
> > Agreed. I'll rename them to be more expressive.
>
> Don't forget NEWS and ACKS updates as well.


Got the news update in 9448691fe084. Had him in acks from another patch last
night. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110315/fe39d247/attachment.html>

From martin at v.loewis.de  Tue Mar 15 17:02:59 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 15 Mar 2011 12:02:59 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
Message-ID: <4D7F8DB3.3000901@v.loewis.de>


>> Python 2.6's API wasn't removed in 2.7. It remains available.
>
> But not in 3.2. And the new API appeared in 2.7.

No, it didn't. It first appeared in 3.1.

> That is a deprecation period of seven and a half months.

Not true. It's a deprecation period of 19 months and two
releases (3.1 and 2.7).

>> If you go from 2.7 to 3.2, you should expect things to break. That's
>> why the major version changed.
>
> And 3.1 to 3.2? There is no major version break there.

Right. So for things to be removed there, they have to be deprecated
first (and that's what happened).

>> For 3.x, as Reid points out, the API was deprecated in 3.1, so the
>> deprecation period was rather 19 months, not 7.
>
> Yes, but we are now in a period of parallell support for Python 2 and
> Python 3. So it doesn't work like that. We need to support both Python
> 2 and Python 3 at the same time. Therefore, the deprecation period was
> seven and a half month, because it was impossible to support the new
> API before, and impossible to support the new API after, if you need
> to support both Python 2 and Python 3.

If you actually had been supporting 2.x and 3.x in parallel for the last 
two years, you would have had a deprecation period of 19 months
and two releases. It's only if you are now migrating from 2 to 3
that you notice the breakage for the first time.

Regards,
Martin

From greg at krypto.org  Tue Mar 15 17:07:12 2011
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 15 Mar 2011 12:07:12 -0400
Subject: [Python-Dev] NetBSD and curses
In-Reply-To: <AANLkTikczOtF3x1rjtnp-0VXspSuGHh2jg6RctpBBEAo@mail.gmail.com>
References: <4D7EB80B.1050907@supposedly.org>
	<AANLkTikczOtF3x1rjtnp-0VXspSuGHh2jg6RctpBBEAo@mail.gmail.com>
Message-ID: <AANLkTi=6JQW-8AzkzLGx1UYcLxaft89e-G3SOLQrZa63@mail.gmail.com>

Hi, Sorry, it was just laughingly pointed out to me that I responded to your
complaint about a bug being ignored by asking you to file a bug. :)  Thats
what I get for "reading" things late at night.

regardless, any time you have a patch for something, please attach it to the
issue, things on the mailing list get lost.  I've gone ahead and attached
the patch and accepted the issue.  I have a netbsd ec2 instance to test with
now but haven't had time to get it setup for python development.

None of the devs currently run netbsd on a regular basis or have much
experience with it as a platform so patches are a great help.  Any chance
you can also make a version of the patch that applies against hg cpython tip
(3.3)?

-gps

2011/3/15 Gregory P. Smith <greg at krypto.org>

> Would you please post this to bugs.python.org so that it doesn't get lost?
>  thanks!
>
> -gps
>
> On Mon, Mar 14, 2011 at 8:51 PM, Bill Green <bill at supposedly.org> wrote:
>
>> Hi all,
>>
>> I ran across this issue several months ago and filed a bug report (#9667).
>>  It just came up again, and it doesn't look like anything's been done with
>> the bug report, so I thought I'd post here.
>>
>> In _cursesmodule.c there are a lot of preprocesser conditionals that test
>> if the system is NetBSD. In my case, the issue was that the module built
>> lacked the KEY_UP / _DOWN / etc. constants, but there are other changes as
>> well.  This is the case even if you're compiling against ncurses instead of
>> the system curses.  ?ttached below is a patch against 2.7.1 that negates the
>> NetBSD conditionals if ncurses is present.  It seems to work as expected,
>> although I haven't done any real testing.  I assumed this was done because
>> NetBSD curses was missing something, but I looked at the headers and it
>> seems to have most of the constants that the compilation directives are
>> leaving out (A_INVIS, the aforementioned KEY_* constants, at least), so I'm
>> not sure why that code isn't compiled in anyway.  Please let me know if I'm
>> misunderstanding this.
>>
>> Thanks,
>> Bill
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110315/50778b7b/attachment.html>

From tlesher at gmail.com  Tue Mar 15 17:20:48 2011
From: tlesher at gmail.com (Tim Lesher)
Date: Tue, 15 Mar 2011 12:20:48 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <20110315162409.7dee0476@pitrou.net>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<4D7E807F.6030602@canterbury.ac.nz>
	<20110314234854.78C7C20074E@kimball.webabinitio.net>
	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>
	<4D7EBF7E.8010509@trueblade.com> <ilmglf$dl6$1@dough.gmane.org>
	<AANLkTinLXhP9G9OFzJJfYeG1j=dRY_hoyZ71C-nnT54c@mail.gmail.com>
	<4D7F214B.1000104@trueblade.com>
	<AANLkTi=r0hku_fXUjKPAj5=XPRqABnwwzb5ufKwcQb3P@mail.gmail.com>
	<4D7F7634.40908@voidspace.org.uk>
	<AANLkTin5ij_Sh0h+mmQw1qt8aPT+kQReDmt0V6EWNwH-@mail.gmail.com>
	<20110315162409.7dee0476@pitrou.net>
Message-ID: <AANLkTinc0qiJJeV-4872JqACm6s2rKNWVyLxX0BhEcwp@mail.gmail.com>

On Tue, Mar 15, 2011 at 11:24, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Wouldn't a decorator be adequate?
>
> ? ?@pydoc.public_api
> ? ?def _asdict(self):
> ? ? ? ?"""some docstring"""
> ? ? ? ?...

That was my first attempt. Unfortunately, it didn't work well with
classmethods or immutable data members, and forcing the module to
import pydoc had some bad side effects (particularly in the eval-ed
code for namedtuple).

-- 
Tim Lesher <tlesher at gmail.com>

From tlesher at gmail.com  Tue Mar 15 17:27:43 2011
From: tlesher at gmail.com (Tim Lesher)
Date: Tue, 15 Mar 2011 12:27:43 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTimrH3tSX5jXZ4NZa0Y2FkFgWMSoaF_58LsisrRV@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>
	<AANLkTim+ustociR9UB4Qff_99qtC8h1j+xebcPph8jju@mail.gmail.com>
	<AANLkTimrH3tSX5jXZ4NZa0Y2FkFgWMSoaF_58LsisrRV@mail.gmail.com>
Message-ID: <AANLkTin+H-agrz_60qbpM7r5A_7n=XMhSjUCePaMuaDh@mail.gmail.com>

On Tue, Mar 15, 2011 at 11:15, Nick Coghlan <ncoghlan at gmail.com> wrote:
> The challenge here is how it would interact with inheritance. pydoc
> couldn't use normal attribute lookup, it would have to walk the MRO
> manually, only applying __api__ to the specific class that defined it.

Great catch. I know pydoc already looks at this in the
attrs-processing loop (to group attrs by their defining class), but my
current implementation applies __api__ too early to deal with that.
I'll fix it.

Any test cases should definitely throw some diamond-pattern or even
more degenerate cases at the implementation.  What *is* the worst case
for MRO complexity?

Overall, this is becoming more interesting than I'd thought at first.
Is this something that should require a PEP?
-- 
Tim Lesher <tlesher at gmail.com>

From robert.kern at gmail.com  Tue Mar 15 17:34:55 2011
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 15 Mar 2011 11:34:55 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
Message-ID: <ilo4fg$rlg$1@dough.gmane.org>

On 3/14/11 5:30 PM, Lennart Regebro wrote:

> Many projects, not only the Zope Toolkit needs to support a lot of
> versions. The Zope component architecture currently supports 2.4, 2.5
> and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can
> be dropped, but it definitely will be *years* until we can drop
> support for 2.6.  But if I move the PyCObject API to the PyCapsule
> API, the zope packages will **only work on Python 2.7 and 3.2**. This
> is obviously not an option. If I do *not* switch, I can't support
> Python 3.2. That's bad.

For what it's worth, numpy simultaneously supports Python 2.5-2.7 and 3.1-3.2. 
It uses PyCObject or PyCapsule APIs as appropriate. We do this from the same 
codebase. We had to add another layer of indirection, but nothing too bad. You 
can steal our code here:

https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/npy_3kcompat.h#L299

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From solipsis at pitrou.net  Tue Mar 15 18:00:29 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 15 Mar 2011 18:00:29 +0100
Subject: [Python-Dev] cpython (3.1): #11515: fix several typos. Patch by
 Piotr Kasprzyk.
References: <E1PzKn6-0005WM-2a@dinsdale.python.org>
Message-ID: <20110315180029.5c4e3bb7@pitrou.net>

On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melotti <python-checkins at python.org> wrote:
>   Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
>   Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c

libffi is a third-party library and you should probably not introduce
gratuitous changes in these files. It will make tracking changes with
upstream more tedious.

Regards

Antoine.



From ncoghlan at gmail.com  Tue Mar 15 19:30:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 14:30:17 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTin+H-agrz_60qbpM7r5A_7n=XMhSjUCePaMuaDh@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>
	<AANLkTim+ustociR9UB4Qff_99qtC8h1j+xebcPph8jju@mail.gmail.com>
	<AANLkTimrH3tSX5jXZ4NZa0Y2FkFgWMSoaF_58LsisrRV@mail.gmail.com>
	<AANLkTin+H-agrz_60qbpM7r5A_7n=XMhSjUCePaMuaDh@mail.gmail.com>
Message-ID: <AANLkTimvcLZPU38NFw1EzGzu09MDhi9E=Dr-wDwzSVSM@mail.gmail.com>

On Tue, Mar 15, 2011 at 12:27 PM, Tim Lesher <tlesher at gmail.com> wrote:
> Overall, this is becoming more interesting than I'd thought at first.
> Is this something that should require a PEP?

Yeah, just to thrash out the semantics and give some visibility into
the design decisions.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From raymond.hettinger at gmail.com  Tue Mar 15 19:40:51 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Tue, 15 Mar 2011 11:40:51 -0700
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTin+H-agrz_60qbpM7r5A_7n=XMhSjUCePaMuaDh@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>
	<AANLkTim+ustociR9UB4Qff_99qtC8h1j+xebcPph8jju@mail.gmail.com>
	<AANLkTimrH3tSX5jXZ4NZa0Y2FkFgWMSoaF_58LsisrRV@mail.gmail.com>
	<AANLkTin+H-agrz_60qbpM7r5A_7n=XMhSjUCePaMuaDh@mail.gmail.com>
Message-ID: <97ED8715-C4A0-4F74-8EA6-248972560695@gmail.com>

One of simplest and least invasive ways to get help()
to show the underscore methods and attributes is to 
make pydoc aware of named tuples by checking for the 
presence of _fields. 

* That leaves the named tuple code as simple as possible
(which is important because the self-documenting code
is exposed to the user through the verbose option).

* It supports the _1, _2 attributes created by the rename
option, and it works with user supplied underscore methods
and attributes in a subclass.

* It doesn't exaggerate the importance of help issue
which AFAICT hasn't ever been noticed or cared about
since the introduction of named tuples a few years ago
or since the publication of its recipe in years prior to that.


Raymond


P.S.  There are other ways like creating an abstract
base class to identify a class as having underscored
names that aren't private (like _from_iterable in the
ABC for sets), but this seems to me like trying to 
kill a mosquito with a cannon.  The underlying issue
is so minor that it rules out invasive or heavy-weight
efforts.

From regebro at gmail.com  Tue Mar 15 20:00:43 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 15 Mar 2011 15:00:43 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <4D7F8DB3.3000901@v.loewis.de>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
Message-ID: <AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>

On Tue, Mar 15, 2011 at 12:02, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> If you actually had been supporting 2.x and 3.x in parallel for the last two
> years, you would have had a deprecation period of 19 months
> and two releases. It's only if you are now migrating from 2 to 3
> that you notice the breakage for the first time.

The code in question was ported to Python 3 last year, before both 2.7 and 3.2.

I noticed the API change now because it's gone from 3.2. That's how
most API changes gets noticed: Things stop working. And that's OK.
Deprecation periods are there to help you support multiple versions at
the same time. Deprecation notices are helpful, of course, but in this
case it doesn't help. Even if I had noticed the deprecation warning in
3.1, I wouldn't have been able to do anything about that, because 2.7
had then not been released, and the new API isn't supported in 2.6. I
therefore could not have moved to the new API *because* I support both
Python 2.x and 3.x

I could have (and still can) support it by using compatibility macros
or #ifdefs, sure. But you can do that without a deprecation period.

So: without compatibility preprocessing I can no longer support 2.6.
2.7 came out seven and a half months before 3.2. Hence the deprecation
period was in practice seven and a half months.

Admittedly, in C with the preprocessing it's less of an issue, but the
C-extensions is rapidly reaching a position where there seems to be as
much compatibility macros as there is C code... :-) How long is this
going to continue. What API's are going to be needlessly removed in
Python 3.3? Could we please cool down with the backwards
incompatibility?

//Lennart

From martin at v.loewis.de  Tue Mar 15 20:39:06 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 15 Mar 2011 15:39:06 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>	<4D7F6786.1060902@v.loewis.de>	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
Message-ID: <4D7FC05A.7010305@v.loewis.de>

> I noticed the API change now because it's gone from 3.2. That's how
> most API changes gets noticed: Things stop working. And that's OK.
> Deprecation periods are there to help you support multiple versions at
> the same time.

That may be the source of misunderstanding. In my understanding, that's
*not* what deprecation periods are there. Instead, they are there to
give people time to adjust to the changes before their code will break
for good. So during the deprecation period, they should start using
the new way of doing things, so that the code is ready when the old
way goes away.

> Deprecation notices are helpful, of course, but in this
> case it doesn't help. Even if I had noticed the deprecation warning in
> 3.1, I wouldn't have been able to do anything about that

Of course you could have. You could have added a version of your code
that uses capsules (just as you are probably doing now). Then, the
could would not have been broken in 3.2.

> I could have (and still can) support it by using compatibility macros
> or #ifdefs, sure. But you can do that without a deprecation period.

Right - and that's why the deprecation period is not about supporting
multiple versions, but to reduce the need for people to adjust their
code on a quick notice.

> Could we please cool down with the backwards
> incompatibility?

That's another motivation for deprecation. It gives people a chance
to intervene and ask for an extension of the deprecation period, so that
they have more time to adjust.

Regards,
Martin

From tjreedy at udel.edu  Tue Mar 15 21:11:20 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 15 Mar 2011 16:11:20 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTin5ij_Sh0h+mmQw1qt8aPT+kQReDmt0V6EWNwH-@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>	<4D7DB6CF.5050102@canterbury.ac.nz>	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>	<4D7E807F.6030602@canterbury.ac.nz>	<20110314234854.78C7C20074E@kimball.webabinitio.net>	<AANLkTikR7b-reF1zsBn+R83bD_uVJDXK07FiLzQ7U64o@mail.gmail.com>	<4D7EBF7E.8010509@trueblade.com>
	<ilmglf$dl6$1@dough.gmane.org>	<AANLkTinLXhP9G9OFzJJfYeG1j=dRY_hoyZ71C-nnT54c@mail.gmail.com>	<4D7F214B.1000104@trueblade.com>	<AANLkTi=r0hku_fXUjKPAj5=XPRqABnwwzb5ufKwcQb3P@mail.gmail.com>	<4D7F7634.40908@voidspace.org.uk>
	<AANLkTin5ij_Sh0h+mmQw1qt8aPT+kQReDmt0V6EWNwH-@mail.gmail.com>
Message-ID: <iloh57$bmq$1@dough.gmane.org>

On 3/15/2011 11:17 AM, Nick Coghlan wrote:
> On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>> On 15/03/2011 07:59, Nick Coghlan wrote:
>>> While I actually think the current API design is a decent compromise,
>>> another option to consider would be to move the underscore to the
>>> *end* (as_dict_, replace_, make_) as is sometimes done for code that
>>> needs to avoid conflicting with a keyword.
>>>
>>> Namespace collisions with actual fields would remain unlikely, while
>>> pydoc would pick up the new names correctly.
>>>
>>
>> Although it's a backwards incompatible change. Teaching pydoc to recognise
>> the private methods isn't.
>
> If we can find a good way to do it, making pydoc smarter would
> definitely be a nicer option.
>
> If we went the "moving the underscore" route, the old names would
> indeed have to remain for compatibility.

However, pydoc left alone would only pick up (and publicize) the new 
names. One can argue that since the methods are not really private, they 
should have had a trailing rather than leading underscore in the first 
place. Other module classes have recently had method names aliased and 
deprecated for eventual removal, so this would not be a unique move, 
though a class factory is slightly different from a class.

-- 
Terry Jan Reedy


From martin at v.loewis.de  Tue Mar 15 21:14:34 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 15 Mar 2011 16:14:34 -0400
Subject: [Python-Dev] Have we lost changeset info in the buildbots
In-Reply-To: <4D7E496F.8050302@jcea.es>
References: <4D7E496F.8050302@jcea.es>
Message-ID: <4D7FC8AA.8060104@v.loewis.de>

> Traditionally I could see who was the committer who push change to the
> buildbots. This info seems not to be (easily) available.

I have now restored that information in the buildbot. However, only 
includes the committer, not the pusher. Traditionally, they were the
same thing, but they are not anymore since the mercurial switch.
I don't know whether the pushlog is available remotely.

Regards,
Martin

From tjreedy at udel.edu  Tue Mar 15 21:18:07 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 15 Mar 2011 16:18:07 -0400
Subject: [Python-Dev] cpython: Fix #11509. Significantly increase test
 coverage for fileinput.
In-Reply-To: <AANLkTin6PU6W3j5i3LUeBO2PFJXKVPA_-UEu5ffA04zF@mail.gmail.com>
References: <E1PzVG3-000067-0I@dinsdale.python.org>	<20110315154405.67b59e2b@pitrou.net>	<AANLkTikNCMqVe8qSfXiL=fzXEJv==0YeztXxk6h=4eHi@mail.gmail.com>	<AANLkTimDkL4dbmra8EkX6V7joEZtT=5ZCupGdRYKG_6Z@mail.gmail.com>
	<AANLkTin6PU6W3j5i3LUeBO2PFJXKVPA_-UEu5ffA04zF@mail.gmail.com>
Message-ID: <ilohht$dfl$2@dough.gmane.org>

On 3/15/2011 11:57 AM, Brian Curtin wrote:
> On Tue, Mar 15, 2011 at 11:28, Nick Coghlan <ncoghlan at gmail.com
> <mailto:ncoghlan at gmail.com>> wrote:
>
>     On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin
>     <brian.curtin at gmail.com <mailto:brian.curtin at gmail.com>> wrote:
>      > Agreed. I'll rename them to be more expressive.
>
>     Don't forget NEWS and ACKS updates as well.
>
>
> Got the news update in 9448691fe084. Had him in acks from another patch
> last night. Thanks.

Great to see significant patches coming from the sprint. I hope we can 
keep some of the newer people involved in the future.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Tue Mar 15 21:15:38 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 15 Mar 2011 16:15:38 -0400
Subject: [Python-Dev] cpython (3.1): #11515: fix several typos. Patch by
	Piotr Kasprzyk.
In-Reply-To: <20110315180029.5c4e3bb7@pitrou.net>
References: <E1PzKn6-0005WM-2a@dinsdale.python.org>
	<20110315180029.5c4e3bb7@pitrou.net>
Message-ID: <ilohd9$dfl$1@dough.gmane.org>

On 3/15/2011 1:00 PM, Antoine Pitrou wrote:
> On Tue, 15 Mar 2011 04:19:24 +0100
> ezio.melotti<python-checkins at python.org>  wrote:
>>    Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
>>    Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
>
> libffi is a third-party library and you should probably not introduce
> gratuitous changes in these files. It will make tracking changes with
> upstream more tedious.

This answers my question elsewhere of why revert real fixes. Perhaps the 
fixes could be submitted upstream.

Is that status and the restriction on changes indicated in the file?

-- 
Terry Jan Reedy


From benjamin at python.org  Tue Mar 15 21:48:16 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 15 Mar 2011 15:48:16 -0500
Subject: [Python-Dev] cpython (3.1): #11515: fix several typos. Patch by
 Piotr Kasprzyk.
In-Reply-To: <ilohd9$dfl$1@dough.gmane.org>
References: <E1PzKn6-0005WM-2a@dinsdale.python.org>
	<20110315180029.5c4e3bb7@pitrou.net> <ilohd9$dfl$1@dough.gmane.org>
Message-ID: <AANLkTikQFZRFv=v__KueV4MURGg+-Zuq5ZN=mWQtQ3fY@mail.gmail.com>

2011/3/15 Terry Reedy <tjreedy at udel.edu>:
> On 3/15/2011 1:00 PM, Antoine Pitrou wrote:
>>
>> On Tue, 15 Mar 2011 04:19:24 +0100
>> ezio.melotti<python-checkins at python.org> ?wrote:
>>>
>>> ? Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
>>> ? Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
>>
>> libffi is a third-party library and you should probably not introduce
>> gratuitous changes in these files. It will make tracking changes with
>> upstream more tedious.
>
> This answers my question elsewhere of why revert real fixes. Perhaps the
> fixes could be submitted upstream.

It really doesn't matter if there's typos in 3rd party libraries which
we distribute.

>
> Is that status and the restriction on changes indicated in the file?

No, because that would make updating it annoying, too. :)



-- 
Regards,
Benjamin

From jcea at jcea.es  Tue Mar 15 22:26:55 2011
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 15 Mar 2011 22:26:55 +0100
Subject: [Python-Dev] Have we lost changeset info in the buildbots
In-Reply-To: <4D7FC8AA.8060104@v.loewis.de>
References: <4D7E496F.8050302@jcea.es> <4D7FC8AA.8060104@v.loewis.de>
Message-ID: <4D7FD99F.5080209@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/03/11 21:14, "Martin v. L?wis" wrote:
>> Traditionally I could see who was the committer who push change to the
>> buildbots. This info seems not to be (easily) available.
> 
> I have now restored that information in the buildbot. However, only
> includes the committer, not the pusher. Traditionally, they were the
> same thing, but they are not anymore since the mercurial switch.
> I don't know whether the pushlog is available remotely.

Thanks for bringing this back!.

Recording the pusher is useful, since anybody (with push privileges) can
fake commit attributions. I know that people like Mozilla actually store
this information (via a push hook, if I am not mistaken).

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTX/Zn5lgi5GaxT1NAQLkyAP/WmXHtvSrx2UKkH8ubRvPVNoOqJChsPor
BLjOZD3oxiM9l0EUBtgmJPVsH9yvB0fdvFj+2T3sc9Jt5eWgSE4bzgIHXsgA7aXZ
sq24yK0Vdot+F9aDTDmeHlHrv0UzpJSBQm0iI+mkUQIVCK0da/Fy/1BMuyCxjR0C
7DZCGVOzQyg=
=jmsM
-----END PGP SIGNATURE-----

From fuzzyman at voidspace.org.uk  Tue Mar 15 23:26:13 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 15 Mar 2011 18:26:13 -0400
Subject: [Python-Dev] Mercurial workflow: merging from 3.2
Message-ID: <4D7FE785.2020803@voidspace.org.uk>

Hey all,

I realise that we're still getting used to the workflows, but there are 
currently unmerged changesets (in test_peepholer and friends) on the 3.2 
branch that seem to have been applied *separately* to 3.3. This causes 
problems for anyone else who wants to merge changes from 3.2 to 3.3 as 
these unmerged changesets appear as conflicts.

If you do work in 3.2 (or earlier) please merge those changesets to default.

All the best,

Michael

-- 
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


From regebro at gmail.com  Tue Mar 15 23:46:37 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 15 Mar 2011 18:46:37 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <4D7FC05A.7010305@v.loewis.de>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
Message-ID: <AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>

On Tue, Mar 15, 2011 at 15:39, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Of course you could have. You could have added a version of your code
> that uses capsules (just as you are probably doing now).

No I'm not.

> Right - and that's why the deprecation period is not about supporting
> multiple versions, but to reduce the need for people to adjust their
> code on a quick notice.

I think we need to adjust PEP 5 then. We can't keep on breaking
backwards compatibility like this. People are already freaked out
about Python 2 to Python 3, and the argument is often used against
Python that it's not a language to be used in enterprise situations
because Python keeps on breaking backwards compatibility. Up until 3.2
that statement was not actually true. Python 2.x was very backwards
compatible. The next time somebody tells me that Python isn't stable
and breaks backwards compatibility all the time, and says that's why
you should use Java, what can I now say? OK, it's just the C-API, but
that excuse isn't going to fly...

//Lennart

From ncoghlan at gmail.com  Tue Mar 15 23:56:57 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 18:56:57 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
Message-ID: <AANLkTin8upF4PaNVocpQ3=Nr8M6WByAvLEjcHNUYkLXZ@mail.gmail.com>

On Tue, Mar 15, 2011 at 6:46 PM, Lennart Regebro <regebro at gmail.com> wrote:
> On Tue, Mar 15, 2011 at 15:39, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Of course you could have. You could have added a version of your code
>> that uses capsules (just as you are probably doing now).
>
> No I'm not.

The numpy folks have shown it is quite possible to support 3.2 without
sacrificing compatibility with earlier versions.

>> Right - and that's why the deprecation period is not about supporting
>> multiple versions, but to reduce the need for people to adjust their
>> code on a quick notice.
>
> I think we need to adjust PEP 5 then. We can't keep on breaking
> backwards compatibility like this. People are already freaked out
> about Python 2 to Python 3, and the argument is often used against
> Python that it's not a language to be used in enterprise situations
> because Python keeps on breaking backwards compatibility. Up until 3.2
> that statement was not actually true. Python 2.x was very backwards
> compatible. The next time somebody tells me that Python isn't stable
> and breaks backwards compatibility all the time, and says that's why
> you should use Java, what can I now say? OK, it's just the C-API, but
> that excuse isn't going to fly...

But given that this situation was unique to the parallel development
of 2.x and 3.x, and PEP 5 was applied correctly within each of the
parallel lines of development, why not just consider this another
instance of the 2.x/3.x incompatibility? That's what it is after all.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Mar 16 00:01:51 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 19:01:51 -0400
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
Message-ID: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>

For years, urlparse (and subsequently urlib.parse) has opted to
implement the semantics from the older URL processing RFCs, rather
than updating to the new semantics as the RFCs are superseded.

With RFC 3986 passing its 6th birthday, and with it being well past
its 7th by the time 3.3 comes out, can we finally switch to supporting
the current semantics rather than the obsolete behaviour?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From regebro at gmail.com  Wed Mar 16 00:04:55 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 15 Mar 2011 19:04:55 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTin8upF4PaNVocpQ3=Nr8M6WByAvLEjcHNUYkLXZ@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<AANLkTin8upF4PaNVocpQ3=Nr8M6WByAvLEjcHNUYkLXZ@mail.gmail.com>
Message-ID: <AANLkTimc5GXjh1gubq7TD_5Hbt6+HgpUJ5fUCVRNm7wX@mail.gmail.com>

On Tue, Mar 15, 2011 at 18:56, Nick Coghlan <ncoghlan at gmail.com> wrote:
> why not just consider this another
> instance of the 2.x/3.x incompatibility? That's what it is after all.

Apparently not, as the code already ran under Python 3.1.

//Lennart

From orsenthil at gmail.com  Wed Mar 16 00:14:29 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 16 Mar 2011 07:14:29 +0800
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
Message-ID: <AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>

On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> With RFC 3986 passing its 6th birthday, and with it being well past
> its 7th by the time 3.3 comes out, can we finally switch to supporting
> the current semantics rather than the obsolete behaviour?

We do infact, support RFC 3986, expect for the cases where those
conflict with the previous RFCs. (IOW, backwards compatible).
The tests can give you a good picture here. Do you mean, we should
just do away with backwards  compatibility? Or you had anything else
specifically in mind?

-- 
Senthil

From solipsis at pitrou.net  Wed Mar 16 00:14:42 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 16 Mar 2011 00:14:42 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
Message-ID: <20110316001442.4f3c1c5f@pitrou.net>

On Tue, 15 Mar 2011 18:46:37 -0400
Lennart Regebro <regebro at gmail.com> wrote:
> 
> > Right - and that's why the deprecation period is not about supporting
> > multiple versions, but to reduce the need for people to adjust their
> > code on a quick notice.
> 
> I think we need to adjust PEP 5 then. We can't keep on breaking
> backwards compatibility like this.

"We"?
You must understand that compatibility rules are quite a burden when it
comes to evolving Python's APIs. Making these rules even stricter would
probably reduce motivation to contribute to Python for at least some
developers (be they core developers or not).

Beside, if you need long-term support, there is a well-known solution:
turn to a company that provides such support. That company can be called
Redhat, Canonical, ActiveState or even Apple. The community of
volunteers called python-dev is already doing quite a lot in that area.

> People are already freaked out
> about Python 2 to Python 3, and the argument is often used against
> Python that it's not a language to be used in enterprise situations
> because Python keeps on breaking backwards compatibility.

This sounds like FUD. Again, such companies can just rely on a
commercial vendor to provide support.

Regards

Antoine.



From greg.ewing at canterbury.ac.nz  Wed Mar 16 00:31:23 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 16 Mar 2011 12:31:23 +1300
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <4D7F6786.1060902@v.loewis.de>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
Message-ID: <4D7FF6CB.2030309@canterbury.ac.nz>

Martin v. L?wis wrote:

> "There must be at least a one-year transition period between the
> release of the transitional version of Python and the release
> of the backwards incompatible version.

I still think this is going to result in rude shocks to
people switching from 2 to 3 and jumping several releases
into the 3.x line.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Wed Mar 16 00:46:08 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 16 Mar 2011 12:46:08 +1300
Subject: [Python-Dev] packaging
In-Reply-To: <AANLkTikSjuDFDOUNT1HrdMB60ar4kj9XJbWnQubrjZ31@mail.gmail.com>
References: <AANLkTin49DtrcTQr+bXgzUfaorqPdmnnLDun+3OJrPtX@mail.gmail.com>
	<20110314214614.2dde2518@pitrou.net>
	<AANLkTimy1m16em2a9YSvz0_gDfH8xtPvMKX6qcaqxojj@mail.gmail.com>
	<20110314232358.3a1d3b34@pitrou.net>
	<4D7EB25D.3010709@canterbury.ac.nz>
	<AANLkTi=h_NPsRm2X9=wcR2RJsAVHXzD=UQEzs3KXX=T0@mail.gmail.com>
	<AANLkTikSjuDFDOUNT1HrdMB60ar4kj9XJbWnQubrjZ31@mail.gmail.com>
Message-ID: <4D7FFA40.9080603@canterbury.ac.nz>

Tarek Ziad? wrote:

> try:
>     from __future__ import or_importer
> except ImportError:
>     XXX <-- previous proposal
>  else:
>     or based proposal

This could easily be fixed if we allowed run-time access
to the time machine:

   from __future__ import temporal_mechanics, or_importer
   import timemachine
   timemachine.backport_feature("or_importer", from_version = "3.4")
   ...

(For obvious reasons, this will work despite the future
import of or_importer occurring before the code that
backports it.)

Manual use of the time machine would be required to
backport the timemachine module itself, after which
there would never be any backwards compatibility
problems again.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Wed Mar 16 00:57:00 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 16 Mar 2011 12:57:00 +1300
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTimrH3tSX5jXZ4NZa0Y2FkFgWMSoaF_58LsisrRV@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>
	<AANLkTim+ustociR9UB4Qff_99qtC8h1j+xebcPph8jju@mail.gmail.com>
	<AANLkTimrH3tSX5jXZ4NZa0Y2FkFgWMSoaF_58LsisrRV@mail.gmail.com>
Message-ID: <4D7FFCCC.3090202@canterbury.ac.nz>

Nick Coghlan wrote:

> The challenge here is how it would interact with inheritance. pydoc
> couldn't use normal attribute lookup, it would have to walk the MRO
> manually,

This is an instance of a pattern that I've encountered a
few times in things that I've done: you have a class
attribute containing a list of things, and you want it
to be "additive" with respect to inheritance -- i.e. it
contains the items specified in a particular class plus
all those specified in its base classes.

This can obviously be arranged using appropriate metaclass
hackery, but I'm wondering whether it could be provided
using some mechanism that can be applied orthogonally
to any class attribute.

Maybe this is another reason to have a hook somewhere
in the standard class creation process that allows a
descriptor to initialise itself with knowledge of its
environment.

-- 
Greg

From andrew.svetlov at gmail.com  Wed Mar 16 01:07:27 2011
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Wed, 16 Mar 2011 02:07:27 +0200
Subject: [Python-Dev] User conversions in custom string.Formatter
Message-ID: <AANLkTim+274-HG4CGWFhppzOAvBMqsdc9PC3nJV-Q3Fb@mail.gmail.com>

As PEP 3101 http://www.python.org/dev/peps/pep-3101/ says (and current
Python does) user can specify conversions like "{0!s}".
In custom formatters (derived from string.Formatter) he can override
convert_field method to add custom conversions.

I experimented with that last month and found it very convenient.
>From my perspective custom conversions are very close to 'filters'
from html template engines (jinja2, mako, django etc).
While I like to see custom conversions simple and easy I don't wan't
to bring 'cascading' and 'parametrization' to standard formatting.

But why don't relax spec a bit and allow to use any word (with
'identifier' semantix, I mean str.isidentifier()) as conversion name?
Proposed update doesn't make any backward incompatibility (both python
and public C API are not changed), it's clean and obvious.
And it's very funny to use words instead single characters for custom
user-specific conversions.

What do you think?

From eric at trueblade.com  Wed Mar 16 01:25:22 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 15 Mar 2011 20:25:22 -0400
Subject: [Python-Dev] User conversions in custom string.Formatter
In-Reply-To: <AANLkTim+274-HG4CGWFhppzOAvBMqsdc9PC3nJV-Q3Fb@mail.gmail.com>
References: <AANLkTim+274-HG4CGWFhppzOAvBMqsdc9PC3nJV-Q3Fb@mail.gmail.com>
Message-ID: <4D800372.8000100@trueblade.com>

On 03/15/2011 08:07 PM, Andrew Svetlov wrote:
> As PEP 3101 http://www.python.org/dev/peps/pep-3101/ says (and current
> Python does) user can specify conversions like "{0!s}".
> In custom formatters (derived from string.Formatter) he can override
> convert_field method to add custom conversions.
>
> I experimented with that last month and found it very convenient.
>> From my perspective custom conversions are very close to 'filters'
> from html template engines (jinja2, mako, django etc).
> While I like to see custom conversions simple and easy I don't wan't
> to bring 'cascading' and 'parametrization' to standard formatting.
>
> But why don't relax spec a bit and allow to use any word (with
> 'identifier' semantix, I mean str.isidentifier()) as conversion name?
> Proposed update doesn't make any backward incompatibility (both python
> and public C API are not changed), it's clean and obvious.
> And it's very funny to use words instead single characters for custom
> user-specific conversions.
>
> What do you think?

This should be in python-ideas, but I don't know if Andrew is 
subscribed, so I'll reply here until it gets out of control.

Andrew: Could you give a code sample of what you'd like to see?

Eric.

From greg.ewing at canterbury.ac.nz  Wed Mar 16 01:26:15 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 16 Mar 2011 13:26:15 +1300
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <AANLkTin+H-agrz_60qbpM7r5A_7n=XMhSjUCePaMuaDh@mail.gmail.com>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>
	<4D7DB6CF.5050102@canterbury.ac.nz>
	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>
	<AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>
	<AANLkTim+ustociR9UB4Qff_99qtC8h1j+xebcPph8jju@mail.gmail.com>
	<AANLkTimrH3tSX5jXZ4NZa0Y2FkFgWMSoaF_58LsisrRV@mail.gmail.com>
	<AANLkTin+H-agrz_60qbpM7r5A_7n=XMhSjUCePaMuaDh@mail.gmail.com>
Message-ID: <4D8003A7.1010109@canterbury.ac.nz>

Tim Lesher wrote:

> Any test cases should definitely throw some diamond-pattern or even
> more degenerate cases at the implementation.  What *is* the worst case
> for MRO complexity?

I don't think that's an issue -- the MRO gets flattened into
a list at class creation time, so code that walks it never
sees any of the complexities of diamonds, etc.

-- 
Greg

From jcea at jcea.es  Wed Mar 16 02:00:42 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 16 Mar 2011 02:00:42 +0100
Subject: [Python-Dev] devguide: managing "+1 heads"
Message-ID: <4D800BBA.2070805@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As far as I remember, python-dev decided that each branch should have a
single head. We probably have even a push hook to avoid mistakes. Or we
should :).

But we don't explain what is suppose to be done when a developer is
working in a feature, she updates her repository clone, rebase her
patches, collapses all her local changesets to a single giant changeset,
commit it locally, merge them to "default" and then she tries to push.
But somebody else "raced" her and commit first, so she is trying to
generate a new head.

The standard approach in mercurial is for her to pull the changes and to
do a merge before trying to push again (and hope nobody else "raced" her
again, this time). But the merge will be visible in the project history,
and I have the feeling that python-dev tries hard to keep a lineal history.

Another usual approach would be to "pull" the changes and "rebase" the
local unpushed changesets before trying again, to get a linear history.
But no idea of what would happen when we have multiple local commits in
several different branches. Never tried in this situation, and not sure
that I want to try :).

In any case, devguide is silent about this. I would suggest to write
something to fill this gap.

See, for instance, <http://hg.python.org/cpython/rev/9a817ab166e0>,
<http://hg.python.org/cpython/graph/9a817ab166e0>.

PS: I didn't merged 9a817ab166e0 to "3.x" because I don't know what
plans Raymond has for 6544accfefc3. I guess he is waiting for buildbot
results before merging to 3.x.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/

jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYALuplgi5GaxT1NAQIpwgP/U7MTC59QKOn5/4PgFEe3L1q7tsiAs6Tb
jLYhL8vXBjyY3Ct5bOXW9MBcagHa+Bk/hz/ohGcGP+PL3ZtqgXE9Zv6ZXRydnhWb
GslPQnCnHjp8KMa3iE6wDMRskY46iDQtVh1QOo9UTi001jn5mqo2CLDugmFHVU+l
lFEnXBCotGo=
=SBiW
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Wed Mar 16 02:15:58 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 16 Mar 2011 02:15:58 +0100
Subject: [Python-Dev] devguide: managing "+1 heads"
References: <4D800BBA.2070805@jcea.es>
Message-ID: <20110316021558.309306f2@pitrou.net>

On Wed, 16 Mar 2011 02:00:42 +0100
Jesus Cea <jcea at jcea.es> wrote:
> 
> The standard approach in mercurial is for her to pull the changes and to
> do a merge before trying to push again (and hope nobody else "raced" her
> again, this time).

This is indeed the standard approach, so I'm not sure what the point of
mentioning it in the devguide would be. I don't think the devguide
should turn into a Mercurial tutorial: there are plenty of them on the
Web.

Regardless, if you want to experiment with other approaches, please go
ahead and report the results here.

Regards

Antoine.



From regebro at gmail.com  Wed Mar 16 02:16:58 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 15 Mar 2011 21:16:58 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <20110316001442.4f3c1c5f@pitrou.net>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
Message-ID: <AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>

On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Beside, if you need long-term support, there is a well-known solution:
> turn to a company that provides such support. That company can be called
> Redhat, Canonical, ActiveState or even Apple. The community of
> volunteers called python-dev is already doing quite a lot in that area.

OK, fine. I'm stopping my efforts of porting the ZTK to Python 3
unless somebody pays me then, if that is the attitude from the core
developers on this issue. Why should there be third-party libraries
available for Python 3.2!? No need, if you want them you can find
commercial support, apparently.

//Lennart

From jcea at jcea.es  Wed Mar 16 02:37:21 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 16 Mar 2011 02:37:21 +0100
Subject: [Python-Dev] devguide: managing "+1 heads"
In-Reply-To: <20110316021558.309306f2@pitrou.net>
References: <4D800BBA.2070805@jcea.es> <20110316021558.309306f2@pitrou.net>
Message-ID: <4D801451.4090808@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/03/11 02:15, Antoine Pitrou wrote:
> On Wed, 16 Mar 2011 02:00:42 +0100
> Jesus Cea <jcea at jcea.es> wrote:
>>
>> The standard approach in mercurial is for her to pull the changes and to
>> do a merge before trying to push again (and hope nobody else "raced" her
>> again, this time).
> 
> This is indeed the standard approach, so I'm not sure what the point of
> mentioning it in the devguide would be. I don't think the devguide
> should turn into a Mercurial tutorial: there are plenty of them on the
> Web.

My point is that I was getting the "+1 head" warning. I know how to
solve it by myself, but I checked the devguide to learn if there was
some kind of policy about it. The devguide is silent about it.

Maybe a simple "try to keep the history lineal, as possible" and "feel
free to merge heads in the standard mercurial way".

In fact, we have discussed here the approach of collapsing local changes
to a single changeset when pushing to the central repository, but I
don't see any reference to this policy in the devguide.

Unwritten "culture" is not good. Better for new contributors to read a
document and learn "the way" that to pick some details here, some there
after stepping over a lot of toes.

For instance, merging between branches (in which direction) is
established here, but not in the devguide.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYAUUZlgi5GaxT1NAQJp8wQAmuj5QLohUvAGRetajubTlizIMhgUEk1l
9kYn9XcfdtETHkM2t3Fmi73FscslNWXTT11kR1rqoyJUjS7XklcPGYtKQqWBAo+b
qICXLKo6C150lRe5VRDWBlJCvUTpFGQddh3ouTjfPjW43sO1Sj/OWJb4H1tSkyjL
smKW5SaSnXE=
=46ku
-----END PGP SIGNATURE-----

From benjamin at python.org  Wed Mar 16 02:42:21 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 15 Mar 2011 20:42:21 -0500
Subject: [Python-Dev] devguide: managing "+1 heads"
In-Reply-To: <4D801451.4090808@jcea.es>
References: <4D800BBA.2070805@jcea.es> <20110316021558.309306f2@pitrou.net>
	<4D801451.4090808@jcea.es>
Message-ID: <AANLkTi=Rb1nccBRqUykF=nCS953mfRCmxSQLmqu6+bw7@mail.gmail.com>

2011/3/15 Jesus Cea <jcea at jcea.es>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 16/03/11 02:15, Antoine Pitrou wrote:
>> On Wed, 16 Mar 2011 02:00:42 +0100
>> Jesus Cea <jcea at jcea.es> wrote:
>>>
>>> The standard approach in mercurial is for her to pull the changes and to
>>> do a merge before trying to push again (and hope nobody else "raced" her
>>> again, this time).
>>
>> This is indeed the standard approach, so I'm not sure what the point of
>> mentioning it in the devguide would be. I don't think the devguide
>> should turn into a Mercurial tutorial: there are plenty of them on the
>> Web.
>
> My point is that I was getting the "+1 head" warning. I know how to
> solve it by myself, but I checked the devguide to learn if there was
> some kind of policy about it. The devguide is silent about it.
>
> Maybe a simple "try to keep the history lineal, as possible" and "feel
> free to merge heads in the standard mercurial way".
>
> In fact, we have discussed here the approach of collapsing local changes
> to a single changeset when pushing to the central repository, but I
> don't see any reference to this policy in the devguide.
>
> Unwritten "culture" is not good. Better for new contributors to read a
> document and learn "the way" that to pick some details here, some there
> after stepping over a lot of toes.
>
> For instance, merging between branches (in which direction) is
> established here, but not in the devguide.

What are you talking about?
http://docs.python.org/devguide/committing.html#forward-porting



-- 
Regards,
Benjamin

From solipsis at pitrou.net  Wed Mar 16 02:42:33 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 16 Mar 2011 02:42:33 +0100
Subject: [Python-Dev] devguide: managing "+1 heads"
References: <4D800BBA.2070805@jcea.es> <20110316021558.309306f2@pitrou.net>
	<4D801451.4090808@jcea.es>
Message-ID: <20110316024233.52b937ec@pitrou.net>

On Wed, 16 Mar 2011 02:37:21 +0100
Jesus Cea <jcea at jcea.es> wrote:
> 
> Maybe a simple "try to keep the history lineal, as possible" and "feel
> free to merge heads in the standard mercurial way".

Well, can you propose a patch to add or improve wording?

> For instance, merging between branches (in which direction) is
> established here, but not in the devguide.

It is:
http://docs.python.org/devguide/committing.html#forward-porting

Regards

Antoine.



From jcea at jcea.es  Wed Mar 16 02:45:29 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 16 Mar 2011 02:45:29 +0100
Subject: [Python-Dev] devguide: managing "+1 heads"
In-Reply-To: <AANLkTi=Rb1nccBRqUykF=nCS953mfRCmxSQLmqu6+bw7@mail.gmail.com>
References: <4D800BBA.2070805@jcea.es>
	<20110316021558.309306f2@pitrou.net>	<4D801451.4090808@jcea.es>
	<AANLkTi=Rb1nccBRqUykF=nCS953mfRCmxSQLmqu6+bw7@mail.gmail.com>
Message-ID: <4D801639.7050200@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/03/11 02:42, Benjamin Peterson wrote:
>> For instance, merging between branches (in which direction) is
>> established here, but not in the devguide.
> 
> What are you talking about?
> http://docs.python.org/devguide/committing.html#forward-porting

I beg your pardon. 3AM in Spain. Time to get some sleep, it seems...

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYAWOZlgi5GaxT1NAQJD6gP5AbqT+PP/1DPmzVUXy0iqWuy+HE1PJC6X
dBzvE3abcqCsCEIhmqn8NW//jXUzGZ162dF+3xJ9IViCZhOol3n5d+E/Yna67/uh
48LJIV0bUrXDkg/nm0/VJGyx0GUqFx546mv9M3dsjMOxd7Q6ZbSfCp/clyWa8Drn
IwfdJMkGnAI=
=NW3O
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Wed Mar 16 02:54:17 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 16 Mar 2011 02:54:17 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
Message-ID: <20110316025417.24c32876@pitrou.net>

On Tue, 15 Mar 2011 21:16:58 -0400
Lennart Regebro <regebro at gmail.com> wrote:
> On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > Beside, if you need long-term support, there is a well-known solution:
> > turn to a company that provides such support. That company can be called
> > Redhat, Canonical, ActiveState or even Apple. The community of
> > volunteers called python-dev is already doing quite a lot in that area.
> 
> OK, fine. I'm stopping my efforts of porting the ZTK to Python 3
> unless somebody pays me then, if that is the attitude from the core
> developers on this issue.

I don't know what other core devs, but I don't think this discussion is
going anywhere. If porting the ZTK is a burden for you, perhaps you
should try to find some financial support for it (or let other people
do it for you), rather than accusing the python-dev community.

Regards

Antoine.

From regebro at gmail.com  Wed Mar 16 03:14:12 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 15 Mar 2011 22:14:12 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <20110316025417.24c32876@pitrou.net>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
	<20110316025417.24c32876@pitrou.net>
Message-ID: <AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>

On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou <solipsis at pitrou.net> wrote:
> I don't know what other core devs, but I don't think this discussion is
> going anywhere. If porting the ZTK is a burden for you, perhaps you
> should try to find some financial support for it (or let other people
> do it for you), rather than accusing the python-dev community.

Up until the reactions from the core Python developers on these real
world problems, it was hard work, but also fun. It isn't anymore, and
I hear your message, loud and clear, so indeed, somebody else will
have to do it. I've lost interest.

//Lennart

From orsenthil at gmail.com  Wed Mar 16 03:32:55 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 16 Mar 2011 10:32:55 +0800
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
References: <4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
	<20110316025417.24c32876@pitrou.net>
	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
Message-ID: <20110316023254.GA3113@kevin>

On Tue, Mar 15, 2011 at 10:14:12PM -0400, Lennart Regebro wrote:
> Up until the reactions from the core Python developers on these real
> world problems, it was hard work, but also fun. 

It is still. The majority of the responses were informative on
backwards compatibility and release process. And suggestive of how
things changed from between 2.7, 3.1 and 3.2. And there is a unique
problem here that 3.1 was released before 2.7.

And things which break backwards compatibility is discussed before any
changes are made. So, your comment on python 'always breaking the
compatibility' was not correct and perhaps that invoked a strong
reaction.

-- 
Senthil

From guido at python.org  Wed Mar 16 03:42:16 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Mar 2011 19:42:16 -0700
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
	<20110316025417.24c32876@pitrou.net>
	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
Message-ID: <AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>

On Tue, Mar 15, 2011 at 7:14 PM, Lennart Regebro <regebro at gmail.com> wrote:
> On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> I don't know what other core devs, but I don't think this discussion is
>> going anywhere. If porting the ZTK is a burden for you, perhaps you
>> should try to find some financial support for it (or let other people
>> do it for you), rather than accusing the python-dev community.
>
> Up until the reactions from the core Python developers on these real
> world problems, it was hard work, but also fun. It isn't anymore, and
> I hear your message, loud and clear, so indeed, somebody else will
> have to do it. I've lost interest.

This is unfortunate (and the PyCon sprints aren't even over!).

I think Lennart's complaint has *some* validity. I think PEP 5 did not
anticipate two overlapping lines of development, and in retrospect it
was unwise to kill the offending API in 3.2 (even if it is *possible*
to deal with it, it's cumbersome).

But I do not think that there is a way to undo the damage that was
done; putting the missing API back in 3.2.1 will cause other problems
(because it would break compatibility between 3.2 and 3.2.1). So
Lennart will have to put up with the pragmatics of supporting 2.7 and
3.2 (and others as he desires). But we should learn from the
experience and be more cautious with 3.3.

Fortunately there may not be any more such cases since no new major
versions of Python 2 will be released. So I'm not sure what an update
of PEP 5 will buy us.

-- 
--Guido van Rossum (python.org/~guido)

From foom at fuhm.net  Wed Mar 16 03:44:31 2011
From: foom at fuhm.net (James Y Knight)
Date: Tue, 15 Mar 2011 22:44:31 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
	it's too late"
In-Reply-To: <AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
	<20110316025417.24c32876@pitrou.net>
	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
Message-ID: <A52C6FC1-2FA3-4C9B-921F-2F422DC9BB56@fuhm.net>


On Mar 15, 2011, at 10:14 PM, Lennart Regebro wrote:

> On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> I don't know what other core devs, but I don't think this discussion is
>> going anywhere. If porting the ZTK is a burden for you, perhaps you
>> should try to find some financial support for it (or let other people
>> do it for you), rather than accusing the python-dev community.
> 
> Up until the reactions from the core Python developers on these real
> world problems, it was hard work, but also fun. It isn't anymore, and
> I hear your message, loud and clear, so indeed, somebody else will
> have to do it. I've lost interest.

It seems a bit odd for you to be so surprised about this, considering Python3 is a *huge* compatibility break that broke basically every single thing ever written in Python.

And I'm not sure why you're making such a big deal about this one corner of incompatibility -- PyCObject vs. PyCapsule seems like such a trivial and easy to work around issue compared to the massive pain-in-the-ass porting job for all the incompatibilities on the Python-language side of the fence.

James

From ncoghlan at gmail.com  Wed Mar 16 03:58:38 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 22:58:38 -0400
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
Message-ID: <AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>

On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> With RFC 3986 passing its 6th birthday, and with it being well past
>> its 7th by the time 3.3 comes out, can we finally switch to supporting
>> the current semantics rather than the obsolete behaviour?
>
> We do infact, support RFC 3986, expect for the cases where those
> conflict with the previous RFCs. (IOW, backwards compatible).
> The tests can give you a good picture here. Do you mean, we should
> just do away with backwards ?compatibility? Or you had anything else
> specifically in mind?

Backwards compatible with *what* though?

For the decimal module, we treat deviations from spec as bug fixes and
update accordingly, even if this changes behaviour.

For URL parsing, the spec has changed (6 years ago!), but we still
don't provide a spec-conformant implementation, even via a flag or new
function.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From regebro at gmail.com  Wed Mar 16 03:58:36 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 15 Mar 2011 22:58:36 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
	<20110316025417.24c32876@pitrou.net>
	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
	<AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>
Message-ID: <AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>

On Tue, Mar 15, 2011 at 22:42, Guido van Rossum <guido at python.org> wrote:
> Fortunately there may not be any more such cases since no new major
> versions of Python 2 will be released. So I'm not sure what an update
> of PEP 5 will buy us.

That is a good point. But at least making sure no more API's get
deprecated in 3.3 (and preferably 3.4) would go a long way, as we are
likely to still have to support Python 2 in parallell for those
versions as well.

//Lennart

From ncoghlan at gmail.com  Wed Mar 16 04:03:15 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Mar 2011 23:03:15 -0400
Subject: [Python-Dev] devguide: managing "+1 heads"
In-Reply-To: <20110316021558.309306f2@pitrou.net>
References: <4D800BBA.2070805@jcea.es>
	<20110316021558.309306f2@pitrou.net>
Message-ID: <AANLkTi=G1i5Z+VrR8xonxCvCFNxSyeT3k2r1N_gDpU9i@mail.gmail.com>

On Tue, Mar 15, 2011 at 9:15 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 16 Mar 2011 02:00:42 +0100
> Jesus Cea <jcea at jcea.es> wrote:
>>
>> The standard approach in mercurial is for her to pull the changes and to
>> do a merge before trying to push again (and hope nobody else "raced" her
>> again, this time).
>
> This is indeed the standard approach, so I'm not sure what the point of
> mentioning it in the devguide would be. I don't think the devguide
> should turn into a Mercurial tutorial: there are plenty of them on the
> Web.

Given our stated preference for pushing collapsed changesets, it does
seem worthwhile to explicitly mention the pull/merge/push case as a
case where a collapsed changeset isn't expected.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From regebro at gmail.com  Wed Mar 16 04:05:13 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 15 Mar 2011 23:05:13 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
	<20110316025417.24c32876@pitrou.net>
	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
	<AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>
	<AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>
Message-ID: <AANLkTimQ=JcdTuaBxwqtqDZaz4kTHumEZiuYvk2r9OdH@mail.gmail.com>

On Tue, Mar 15, 2011 at 22:58, Lennart Regebro <regebro at gmail.com> wrote:
> That is a good point. But at least making sure no more API's get
> deprecated in 3.3 (and preferably 3.4)

I meant removed.

From eric at trueblade.com  Wed Mar 16 04:12:52 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 15 Mar 2011 23:12:52 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>	<4D7F6786.1060902@v.loewis.de>	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>	<4D7F8DB3.3000901@v.loewis.de>	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>	<4D7FC05A.7010305@v.loewis.de>	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>	<20110316001442.4f3c1c5f@pitrou.net>	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>	<20110316025417.24c32876@pitrou.net>	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>	<AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>
	<AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>
Message-ID: <4D802AB4.4030908@trueblade.com>

On 3/15/2011 10:58 PM, Lennart Regebro wrote:
> On Tue, Mar 15, 2011 at 22:42, Guido van Rossum<guido at python.org>  wrote:
>> Fortunately there may not be any more such cases since no new major
>> versions of Python 2 will be released. So I'm not sure what an update
>> of PEP 5 will buy us.
>
> That is a good point. But at least making sure no more API's get
> deprecated in 3.3 (and preferably 3.4) would go a long way, as we are
> likely to still have to support Python 2 in parallell for those
> versions as well.

I think it's valid that we should consider the affect of libraries that 
are trying to support 2.x and 3.y  (for some values of x and y) at the 
same time. Speaking for myself, I'll admit I hadn't thought of this 
during any discussions of changing APIs. We'll only have to consider 
this for at most 2 more 3.x releases, if we believe the 5 year timeframe 
(since 3.0) for most projects to migrate.

But I agree that there's not much we can do in the capsule case. The 
ship has sailed on that one.

Eric.

From guido at python.org  Wed Mar 16 04:34:13 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Mar 2011 20:34:13 -0700
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
Message-ID: <AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>

On Tue, Mar 15, 2011 at 7:58 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran <orsenthil at gmail.com> wrote:
>> On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> With RFC 3986 passing its 6th birthday, and with it being well past
>>> its 7th by the time 3.3 comes out, can we finally switch to supporting
>>> the current semantics rather than the obsolete behaviour?
>>
>> We do infact, support RFC 3986, expect for the cases where those
>> conflict with the previous RFCs. (IOW, backwards compatible).
>> The tests can give you a good picture here. Do you mean, we should
>> just do away with backwards ?compatibility? Or you had anything else
>> specifically in mind?
>
> Backwards compatible with *what* though?
>
> For the decimal module, we treat deviations from spec as bug fixes and
> update accordingly, even if this changes behaviour.
>
> For URL parsing, the spec has changed (6 years ago!), but we still
> don't provide a spec-conformant implementation, even via a flag or new
> function.

Can you be specific? What is different between those RFCs?

-- 
--Guido van Rossum (python.org/~guido)

From orsenthil at gmail.com  Wed Mar 16 05:03:00 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 16 Mar 2011 12:03:00 +0800
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
Message-ID: <20110316040259.GB3113@kevin>

Nick Coghlan wrote:
> 
> Backwards compatible with *what* though?

I meant the parsing 'behavior'.

> For the decimal module, we treat deviations from spec as bug fixes and
> update accordingly, even if this changes behaviour.
> 
> For URL parsing, the spec has changed (6 years ago!), but we still
> don't provide a spec-conformant implementation, even via a flag or new
> function.

If I understand correctly, by spec-comformant implementation, you mean
having the parsed components denoted by the same terminology (as well
as behavior) as written in the RFC3986. 

Like the example in the url denote:


         foo://example.com:8042/over/there?name=ferret#nose
         \_/   \______________/\_________/ \_________/ \__/
          |           |            |            |        |
       scheme     authority       path        query   fragment
          |   _____________________|__
         / \ /                        \
         urn:example:animal:ferret:nose

If I send the same url's via urlparse at the moment, I would get:

>>> urlparse('foo://example.com:8042/over/there?name=ferret#nose')
ParseResult(scheme='foo', netloc='example.com:8042', path='/over/there?name=ferret#nose', params='', query='', fragment='')
>>> urlparse('urn:example:animal:ferret:nose')
ParseResult(scheme='urn', netloc='', path='example:animal:ferret:nose', params='', query='', fragment='')

The first one is because, we still have "old" scheme specific parsing behavior.
Where foo is an unrecognized scheme so everything was classified under path. If
we have valid scheme name, then the parsing behaviour would match the
expectation.

- A change to this would break the compatibility with older parsing behavior.

Another point to note is naming - We use 'netloc' as part name loosely, where
as 'authority' is correct term to use and then authority component has
sub-parts.  

- I think, it is good to change this and adopt the RFC terminology more rigorously.

I am +1 to any helpful improvement we can do in this module. But often it
noticed that any slightest changes in parsing behavior has caused harm and
brought us more bug-reports.

A new function, which can given this behavior is also a good idea.

-- 
Senthil

From fdrake at acm.org  Wed Mar 16 05:15:46 2011
From: fdrake at acm.org (Fred Drake)
Date: Wed, 16 Mar 2011 00:15:46 -0400
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <20110316040259.GB3113@kevin>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<20110316040259.GB3113@kevin>
Message-ID: <AANLkTimUYc5LXV1rwPSuvT1Q3ppc_3Ln0W3dWY_ZQo=f@mail.gmail.com>

On Wed, Mar 16, 2011 at 12:03 AM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> A new function, which can given this behavior is also a good idea.

I'm strongly in favor of this approach.  I know we've been bitten by
changes made in the past, and have had to introduce Python-version
specific handling.  (I don't have the details handy, but vaguely
recall the two versions involved being 2.4 and 2.6.)


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein

From stefan_ml at behnel.de  Wed Mar 16 07:42:41 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 16 Mar 2011 07:42:41 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
	it's too late"
In-Reply-To: <AANLkTimc5GXjh1gubq7TD_5Hbt6+HgpUJ5fUCVRNm7wX@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>	<4D7F6786.1060902@v.loewis.de>	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>	<4D7F8DB3.3000901@v.loewis.de>	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>	<4D7FC05A.7010305@v.loewis.de>	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>	<AANLkTin8upF4PaNVocpQ3=Nr8M6WByAvLEjcHNUYkLXZ@mail.gmail.com>
	<AANLkTimc5GXjh1gubq7TD_5Hbt6+HgpUJ5fUCVRNm7wX@mail.gmail.com>
Message-ID: <ilpm51$pqg$1@dough.gmane.org>

Lennart Regebro, 16.03.2011 00:04:
> On Tue, Mar 15, 2011 at 18:56, Nick Coghlan wrote:
>> why not just consider this another
>> instance of the 2.x/3.x incompatibility? That's what it is after all.
>
> Apparently not, as the code already ran under Python 3.1.

Personally, I would expect that breaking backwards compatibility in Python 
3.2 affects a lot less people than a similar change in the 2.x line because 
many projects still haven't ported their code to Python 3.x.

I can assure you that it's quite easy to support both PyCObject and 
PyCapsule at the same time, thus supporting a wide range of Python 2.x and 
3.x releases. NumPy does it, Cython does it, other projects probably do it 
by now, too.

So this is actually less of a problem than you are trying to make it appear.

Stefan


From stefan_ml at behnel.de  Wed Mar 16 08:20:17 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 16 Mar 2011 08:20:17 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
	it's too late"
In-Reply-To: <4D802AB4.4030908@trueblade.com>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>	<4D7F6786.1060902@v.loewis.de>	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>	<4D7F8DB3.3000901@v.loewis.de>	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>	<4D7FC05A.7010305@v.loewis.de>	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>	<20110316001442.4f3c1c5f@pitrou.net>	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>	<20110316025417.24c32876@pitrou.net>	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>	<AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>	<AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>
	<4D802AB4.4030908@trueblade.com>
Message-ID: <ilpobh$2vu$1@dough.gmane.org>

Eric Smith, 16.03.2011 04:12:
> On 3/15/2011 10:58 PM, Lennart Regebro wrote:
>> On Tue, Mar 15, 2011 at 22:42, Guido van Rossum wrote:
>>> Fortunately there may not be any more such cases since no new major
>>> versions of Python 2 will be released. So I'm not sure what an update
>>> of PEP 5 will buy us.
>>
>> That is a good point. But at least making sure no more API's get
>> deprecated in 3.3 (and preferably 3.4) would go a long way, as we are
>> likely to still have to support Python 2 in parallell for those
>> versions as well.
>
> I think it's valid that we should consider the affect of libraries that are
> trying to support 2.x and 3.y (for some values of x and y) at the same
> time.

I don't really see any for this specific change, though. It's not an issue 
of supporting "both 2.x and 3.x", it's an issue of supporting 3.2 and 
earlier CPython versions, and it's not even hard to do that. Basically, you 
can copy&adapt code from a project that already supports it and be done.

CPython has broken backwards compatibility in certain areas more than once. 
It even broke basically all existing C code in 2.5 with the introduction of 
Py_ssize_t (well, technically, it didn't break it on 32bit platforms, but 
it introduced a pretty heavy push for people to walk through their code and 
manually adapt it anyways). Other breakages had a much smaller impact than 
that. If the amount of affected code is smaller, it's unfortunate to be 
amongst those who are hit by such a change, but if there's a reason to go 
that route, well, then there's a reason.

I still consider this is mostly a communication issue. If this change had 
been properly written up, preferably in a PEP, including the reasoning for 
it to get done, I think this whole discussion would not have been necessary.

Stefan


From armin.ronacher at active-4.com  Wed Mar 16 08:29:42 2011
From: armin.ronacher at active-4.com (Armin Ronacher)
Date: Wed, 16 Mar 2011 03:29:42 -0400
Subject: [Python-Dev] Low-Level Encoding Behavior on Python 3
Message-ID: <4D8066E6.2020409@active-4.com>

Hi everybody,

We (me and Carl Meyer) did some experimentation with encoding behavior 
on Python 3.  Carl did some hacking on getting virtualenv running on 
Python 3 and it turned out that his version of virtualenv did not work 
on Python 3 on my server either.  So none of the virtulenv installations 
did though they all seemed to work for some people.

Looking closer the problem is that virtualenv was assuming that 
'open(filename).read()' works.  However on my particular system the 
default encoding in Python 3 for files was 'ASCII'.  That encoding was 
picked up because of three things: a) Python 3's default encoding for 
opening files is picked up from the system locale, b) the ssh server 
accepts the client's encoding for everything (including filenames) and 
c) the OS X default installation for many people does not initialize 
locales properly which forces the server to fall back to 'POSIX' which 
then by applications (including Python) is picked up as ASCII.

Now this showcases a couple of problems on different levels:

-   developers assume that the default for encodings is UTF-8 because
     that is the encoding on their local machine.  Now falling back to
     the platform dependent encoding is documented but does not make a
     lot of sense.  The limiting platform is probably Windows which
     historically has problems with UTF-8 in the notepad editor.

     As a compromise I recommend UTF-8 for POSIX and UTF-8-sig for
     Windows as the Windows editor feels happier with this encoding.
     As the latter reads every file of the former that should not cause
     that many problems in practice

-   Seeing that SSH happily overrides the filesystem encoding I would
     like to forward this issue to some of the linux maintainers.  Having
     the SSH client override your filesystem encoding sounds like a
     terrible decision.  Apparently Python guesses the filesystem
     encoding from LC_CTYPES which however is overriden by connecting
     SSH clients.  Seeing how ubuntu and a bunch of other distributions
     are using Gnome which uses UTF-8 for filesystems as somewhat
     established default I would argue that Python should just assume
     UTF-8 as default encoding on a Linux environment.

-   Inform Apple about the fact that some Snow Leopard machines are
     by default setting the LC_CTYPES (and all other locales) variables
     to something that is not even a valid locale.  I am not yet sure why
     it does not happen on all machines, but it happens on more than one
     at PyCon alone.  On top of that I know that issue because it broke
     the Python "Babel" package for a while which is why I added a work-
     around for that particular problem.

     I will either way file a bug report at Apple for what the SSH client
     is doing on mixed local environments.


Are we missing anything?  Any suggestions?


Regards,
Armin

From solipsis at pitrou.net  Wed Mar 16 08:48:33 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 16 Mar 2011 08:48:33 +0100
Subject: [Python-Dev] Low-Level Encoding Behavior on Python 3
References: <4D8066E6.2020409@active-4.com>
Message-ID: <20110316084833.1aa2a4bb@pitrou.net>


Hi,

> We (me and Carl Meyer) did some experimentation with encoding behavior 
> on Python 3.  Carl did some hacking on getting virtualenv running on 
> Python 3 and it turned out that his version of virtualenv did not work 
> on Python 3 on my server either.  So none of the virtulenv installations 
> did though they all seemed to work for some people.
> 
> Looking closer the problem is that virtualenv was assuming that 
> 'open(filename).read()' works.

I may be mistaken, but you seem to conflate two things: encoding of
file names, and encoding of file contents. I guess that virtualenv
chokes on the file contents, but most of your argument seems related to
encoding of file names (aka "filesystem encoding").

In any case, it would be best for virtualenv to specify the encoding
explicitly. If it doesn't know what that should be, perhaps there's a
deeper problem ;)

Regards

Antoine.



From ncoghlan at gmail.com  Wed Mar 16 13:02:21 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Mar 2011 08:02:21 -0400
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
Message-ID: <AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>

On Tue, Mar 15, 2011 at 11:34 PM, Guido van Rossum <guido at python.org> wrote:
>
> Can you be specific? What is different between those RFCs?

I finally got around to trying to backport some of the additional
urljoin tests from http://bugs.python.org/issue1500504 (specifically,
the additional ones Mike Brown provided), but got tripped up by the
behavioural changes between the earlier RFCs and RFC 3986 regarding
the way ".." is handled.

Even in test_urlparse, a bunch of the normative tests from RFC 3986
are commented out because they fail (by design) when run through
urllib.parse.urljoin. Some of the additional tests also fail because
our urljoin implementation has a whitelist of schemas that support
relative references, whereas 3986 expects relative references to work
for unknown schemas as well.

There's actually quite a few more terminology changes as well (as
Senthil pointed out in his email), but it was specifically the failing
test cases for urljoin semantics that bit me again yesterday.

The problem is that it is quite a lot of work to get fully general URI
parsing to work correctly, but the overlap with legacy URL parsing is
large enough that many (most?) use cases in practice work just fine
with the older RFC semantics.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Mar 16 13:06:15 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Mar 2011 08:06:15 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <ilpobh$2vu$1@dough.gmane.org>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
	<20110316025417.24c32876@pitrou.net>
	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
	<AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>
	<AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>
	<4D802AB4.4030908@trueblade.com> <ilpobh$2vu$1@dough.gmane.org>
Message-ID: <AANLkTiktJV9=6Bi0mGhk0Agy=1iSLd-La75ojfaqYW9U@mail.gmail.com>

On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> I still consider this is mostly a communication issue. If this change had
> been properly written up, preferably in a PEP, including the reasoning for
> it to get done, I think this whole discussion would not have been necessary.

Yes, I think we need to keep "topic of wider interest" in mind when
deciding whether or not to write up a PEP, even if the change isn't
particularly controversial amongst the core developers. We made a
similar mistake with the zipfile and directory execution changes.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From orsenthil at gmail.com  Wed Mar 16 13:52:43 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 16 Mar 2011 20:52:43 +0800
Subject: [Python-Dev] [Python-checkins] cpython (2.7): #11565: Fix
 several typos. Patch by Piotr Kasprzyk.
In-Reply-To: <E1Pzo4c-0000Uv-MI@dinsdale.python.org>
References: <E1Pzo4c-0000Uv-MI@dinsdale.python.org>
Message-ID: <AANLkTinkR88wnfFeOmu+iOu4qwihhTyFh6BO4yhOqdwA@mail.gmail.com>

On Wed, Mar 16, 2011 at 6:35 PM, ezio.melotti
<python-checkins at python.org> wrote:

> ?#11565: Fix several typos. Patch by Piotr Kasprzyk.

Woo. cool. :) For a moment I got scared if Piotr was a spam bot or
spellcheck bot.
Yes, having correct spelling definitely helps.

-- 
Senthil

From ronaldoussoren at mac.com  Wed Mar 16 14:04:48 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 16 Mar 2011 09:04:48 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <4D7FF6CB.2030309@canterbury.ac.nz>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de> <4D7FF6CB.2030309@canterbury.ac.nz>
Message-ID: <68D992BD-4FED-475A-AB25-280DFEBE1F87@mac.com>


On 15 Mar, 2011, at 19:31, Greg Ewing wrote:

> Martin v. L?wis wrote:
> 
>> "There must be at least a one-year transition period between the
>> release of the transitional version of Python and the release
>> of the backwards incompatible version.
> 
> I still think this is going to result in rude shocks to
> people switching from 2 to 3 and jumping several releases
> into the 3.x line.

You need to update the source of extensions anyway when switching from 2.x to 3.x, this additional change is a minor one.

Ronald


From martin at v.loewis.de  Wed Mar 16 14:11:29 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Mar 2011 09:11:29 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTiktJV9=6Bi0mGhk0Agy=1iSLd-La75ojfaqYW9U@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>	<4D7F6786.1060902@v.loewis.de>	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>	<4D7F8DB3.3000901@v.loewis.de>	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>	<4D7FC05A.7010305@v.loewis.de>	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>	<20110316001442.4f3c1c5f@pitrou.net>	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>	<20110316025417.24c32876@pitrou.net>	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>	<AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>	<AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>	<4D802AB4.4030908@trueblade.com>
	<ilpobh$2vu$1@dough.gmane.org>
	<AANLkTiktJV9=6Bi0mGhk0Agy=1iSLd-La75ojfaqYW9U@mail.gmail.com>
Message-ID: <4D80B701.8050707@v.loewis.de>

Am 16.03.11 08:06, schrieb Nick Coghlan:
> On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnel<stefan_ml at behnel.de>  wrote:
>> I still consider this is mostly a communication issue. If this change had
>> been properly written up, preferably in a PEP, including the reasoning for
>> it to get done, I think this whole discussion would not have been necessary.
>
> Yes, I think we need to keep "topic of wider interest" in mind when
> deciding whether or not to write up a PEP, even if the change isn't
> particularly controversial amongst the core developers. We made a
> similar mistake with the zipfile and directory execution changes.

PEP 5 actually requires that backwards-incompatible changes must be 
defined in a PEP. This wasn't done in this case; I agree it should have.

I guess it's not too late to write this PEP, even though that's after 
the fact.

Regards,
Martin

From ncoghlan at gmail.com  Wed Mar 16 14:56:15 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Mar 2011 09:56:15 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <4D80B701.8050707@v.loewis.de>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
	<20110316025417.24c32876@pitrou.net>
	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
	<AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>
	<AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>
	<4D802AB4.4030908@trueblade.com> <ilpobh$2vu$1@dough.gmane.org>
	<AANLkTiktJV9=6Bi0mGhk0Agy=1iSLd-La75ojfaqYW9U@mail.gmail.com>
	<4D80B701.8050707@v.loewis.de>
Message-ID: <AANLkTinki5KK52wQFDf48ayikbjntWGp36TMrnuysR=U@mail.gmail.com>

On Wed, Mar 16, 2011 at 9:11 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 16.03.11 08:06, schrieb Nick Coghlan:
>>
>> On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnel<stefan_ml at behnel.de>
>> ?wrote:
>>>
>>> I still consider this is mostly a communication issue. If this change had
>>> been properly written up, preferably in a PEP, including the reasoning
>>> for
>>> it to get done, I think this whole discussion would not have been
>>> necessary.
>>
>> Yes, I think we need to keep "topic of wider interest" in mind when
>> deciding whether or not to write up a PEP, even if the change isn't
>> particularly controversial amongst the core developers. We made a
>> similar mistake with the zipfile and directory execution changes.
>
> PEP 5 actually requires that backwards-incompatible changes must be defined
> in a PEP. This wasn't done in this case; I agree it should have.
>
> I guess it's not too late to write this PEP, even though that's after the
> fact.

The rationale and initial implementation of the new API are here:
http://bugs.python.org/issue5630

Interestingly, there is no definite time frame on the deprecation
warnings in that discussion. It was just the standard "deprecation in
X.Y means removal in X.Y+1" that lead to 3.2 no longer providing the
PyCObject API.

An after the fact PEP would probably be valuable, as it could document
the rationale for the removal, as well as pointing to resources to
help folks in Lennart's situation that need to support both
PyCObject-only and PyCapsule-only versions of Python from the same C
code base. Perhaps Larry would be willing to write it up if we asked?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ronaldoussoren at mac.com  Wed Mar 16 15:12:34 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 16 Mar 2011 10:12:34 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTinki5KK52wQFDf48ayikbjntWGp36TMrnuysR=U@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D7F8DB3.3000901@v.loewis.de>
	<AANLkTi=7H5CdLsSWTC+GxiJH6AV3ZjYh5DzvEYyyz=a_@mail.gmail.com>
	<4D7FC05A.7010305@v.loewis.de>
	<AANLkTi=aTt3HqWdhOuMM5-ruf3xhT8DuCef3OyYPnx4a@mail.gmail.com>
	<20110316001442.4f3c1c5f@pitrou.net>
	<AANLkTinLxYRVC1uCt83oNMbrZ5LeJy8qC1Qdn15UpLg7@mail.gmail.com>
	<20110316025417.24c32876@pitrou.net>
	<AANLkTi=xWcnXcQzpigazp2u4NYAfO1RtWTQzq7pB4ESH@mail.gmail.com>
	<AANLkTin7bHr4BMc-=TgfD7qFDiB35me05Wy3JihdnLEB@mail.gmail.com>
	<AANLkTi=qdn+9vcmtKRCZ-_8QAbS_hA-Gg3Wgij_MwmJV@mail.gmail.com>
	<4D802AB4.4030908@trueblade.com> <ilpobh$2vu$1@dough.gmane.org>
	<AANLkTiktJV9=6Bi0mGhk0Agy=1iSLd-La75ojfaqYW9U@mail.gmail.com>
	<4D80B701.8050707@v.loewis.de>
	<AANLkTinki5KK52wQFDf48ayikbjntWGp36TMrnuysR=U@mail.gmail.com>
Message-ID: <080B0701-7426-4FE4-B389-9745780CCB04@mac.com>


On 16 Mar, 2011, at 9:56, Nick Coghlan wrote:
> 
> Interestingly, there is no definite time frame on the deprecation
> warnings in that discussion. It was just the standard "deprecation in
> X.Y means removal in X.Y+1" that lead to 3.2 no longer providing the
> PyCObject API.

Speaking of deprecation warnings: GCC has an __attribute__ option to mark C functions as deprecated. Is that something we should use for C API's that are deprecated?

As an example:

int old_code (void) __attribute__((__deprecated__));

Will warn when the function is called:

t.c:12: warning: ?old_code? is deprecated (declared at t.c:6)

This would obviously have to be wrapped in a macro that expands to nothing on compilers other than GCC.

Ronald

From jcea at jcea.es  Wed Mar 16 15:31:59 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 16 Mar 2011 15:31:59 +0100
Subject: [Python-Dev] hooks: Add roundup integration hook.
In-Reply-To: <il66dc$vut$1@dough.gmane.org>
References: <E1Pwv18-0002f2-4m@dinsdale.python.org>
	<4D768C81.5080609@udel.edu> <il66dc$vut$1@dough.gmane.org>
Message-ID: <4D80C9DF.7040709@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/03/11 22:16, Georg Brandl wrote:
> But in any case, by popular demand "fix" is now removed, and only
> "close" and its variants actually closes the issue -- since there
> is not much chance that you can write "close #12345" without
> actually meaning to close the issue :)

Sorry to bother you. What would be the exact wording?. What "variants"
means?.

Yesterday I committed a changeset with a commit message of "Close issue
#8600: test_gdb	failures because innocuous warnings", and it didn't
automatically close the issue :).

Sorry for being so picky ;-).

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/

"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDJ2plgi5GaxT1NAQJ7WQQAl0gM0F4GPdY0O3K2qH4/GJc8fqDx6pRJ
rz4DwVbYRZes3JCwWNCYvK7tJ3B2c39RLi6f4yL5xVP2MDdYT3fu4uBUaSky4a7x
jevns2KraRJVxQbkqwn0agV6CyDhKoffOzHKDg20k1Q+R0/JX3cwrQGDB9QtJuMR
xkIgbhZloF4=
=syPU
-----END PGP SIGNATURE-----

From jcea at jcea.es  Wed Mar 16 15:41:57 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 16 Mar 2011 15:41:57 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
Message-ID: <4D80CC35.8020105@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/03/11 22:16, Georg Brandl wrote:
> But in any case, by popular demand "fix" is now removed, and only
> "close" and its variants actually closes the issue -- since there
> is not much chance that you can write "close #12345" without
> actually meaning to close the issue :)

Sorry to bother you. What would be the exact wording?. What "variants"
means?.

Yesterday I committed a changeset with a commit message of "Close issue
#8600: test_gdb	failures because innocuous warnings", and it didn't
automatically close the issue :).

Sorry for being so picky ;-).

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/

"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDMNZlgi5GaxT1NAQL3bAP/aey6/n0Hx59PsOW0t6v0+eOBcWGZ4r6R
20pvuYa2GJ4GUd6rTcOmIXBdwyfLe9K2r+2hYkSbn4Xg2RrAltXnPEhFuSOKRYfD
/v5S4YuwGa3QL7uiKe5qUn7u91KJzLb3vlAqq0TCzJxwLvZq5YeTB1iSXOZ3NoM8
xx/+mHpcUHI=
=eDnU
-----END PGP SIGNATURE-----

From jcea at jcea.es  Wed Mar 16 15:48:30 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 16 Mar 2011 15:48:30 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
Message-ID: <4D80CDBE.7040309@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/03/11 16:01, Lennart Regebro wrote:
>> Python 2.6's API wasn't removed in 2.7. It remains available.
> 
> But not in 3.2. And the new API appeared in 2.7. That is a deprecation
> period of seven and a half months.

I strongly opposed CObject deprecation in 2.7, as you can see in
<http://bugs.python.org/issue9675> and mailing list archives.

In (external module) pybsddb
<http://www.jcea.es/programacion/pybsddb.htm> I support Python 2.3, 2.4,
2.5, 2.6, 2.7, 3.1, 3.2 and 3.x. Having to deal with CObject/Capsule was
an undesired pain, but the actual support has been painless.

What problems are you finding trying to support both CObject and Capsule?.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDNvplgi5GaxT1NAQIZ+gP8Dtv1EBIUTYYujlY/QcjmmyY+rdXwgZq6
tSJnHsonvaBkG34yY+YM/jw54wA0GFRApvHNtXo6r1AS0Gwei6+Ypb5iGGxdsWmB
SdaZhhcEfmaP1u+5Jaq9P3Nco9LfhgxC3ahT/M8uYsGzpC6U4zgh3yjIY08Y1MAp
h5cRmF2L6CI=
=8MSH
-----END PGP SIGNATURE-----

From benjamin at python.org  Wed Mar 16 15:54:21 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 16 Mar 2011 09:54:21 -0500
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <4D80CC35.8020105@jcea.es>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D7F6786.1060902@v.loewis.de>
	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D80CC35.8020105@jcea.es>
Message-ID: <AANLkTinH24BgD1DyMCYyZyD+U0Z1o+c7oySf1Qc=ihqT@mail.gmail.com>

2011/3/16 Jesus Cea <jcea at jcea.es>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/03/11 22:16, Georg Brandl wrote:
>> But in any case, by popular demand "fix" is now removed, and only
>> "close" and its variants actually closes the issue -- since there
>> is not much chance that you can write "close #12345" without
>> actually meaning to close the issue :)
>
> Sorry to bother you. What would be the exact wording?. What "variants"
> means?.

Matching this re. :) (?:\b(?P<verb>close[sd]?|closing|)\s+)?



-- 
Regards,
Benjamin

From larry at hastings.org  Wed Mar 16 16:02:28 2011
From: larry at hastings.org (Larry Hastings)
Date: Wed, 16 Mar 2011 11:02:28 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
Message-ID: <4D80D104.7040704@hastings.org>


On 03/09/2011 01:15 AM, Stefan Behnel wrote:
> I can confirm that the Cython project was as surprised of the 
> PyCapsule change in Python 3.2 as (I guess) most other users,

I was a bit surprised by it too, and I wrote the Capsule object.  (Well, 
hacked up CObject to give it a new API.)

PyCObject_AsVoidPtr emitted a PendingDeprecationWarning in 3.1.  I was 
surprised when it was removed completely in trunk shortly after the 
release of 3.1.  I thought it was supposed to get promoted to 
DeprecationWarning in 3.2 and then removed in 3.3.  But I'm not totally 
familiar with the policy subtleties of CPython, and the CObject API had 
enough flaws that I was happy to see it gone, so I kept a still tongue.


On 03/14/2011 06:30 PM, Lennart Regebro wrote:
> But if I move the PyCObject API to the PyCapsule
> API, the zope packages will **only work on Python 2.7 and 3.2**. This
> is obviously not an option. If I do *not* switch, I can't support
> Python 3.2. That's bad.

Sorry I didn't see your email until just now; I've been tuning out 
python-dev for a while.  Nick Coghlan brought this matter to my 
attention just this morning.

The PyCapsule API is very much like the CObject API.  In fact, in Python 
3.1 CObject was actually implemented on top of PyCapsule.  It should be 
very easy to support both APIs.

Are you still at PyCon?  I'm in the core / hg room, and I'd be happy to 
help you get this code working for both 2.6 and 3.2.

> **We can't deprecate an API in one version and drop the API in the
> next. This is not acceptable. The deprecation period must be much
> longer!**

The one-year deprecation period seems to be in keeping with PEP 5, which 
states

    There must be at least a one-year transition period between the
    release of the transitional version of Python and the release of the
    backwards incompatible version.


> Let's make no bones about this: The PyCObject API should *not* have
> been removed in 3.2. In fact, the removal should be reversed, and
> 3.2.1 should be released ASAP, making 3.2 a moot and unsupported
> version.

I'm not a release manager for Python but I suspect this is unlikely.


Nick has convinced me that I should create the world's first "temporal 
inversion" PEP, discussing the justification for adding the Capsule API 
and (eventually) removing the CObject API.  I expect the PEP to discuss 
coping strategies on how to simultaneously support 2.6 and 3.2.  I'm 
enjoying PyCon too much to write the PEP this week, but I expect I can 
have a draft up next week.

Personally I'm hoping the PEP will be rejected ;)


/larry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110316/1c036c03/attachment-0001.html>

From jcea at jcea.es  Wed Mar 16 16:07:17 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 16 Mar 2011 16:07:17 +0100
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this
 documented?)
In-Reply-To: <AANLkTikzkTtGEEbCNN18kJ4VA=PFCqOWhUq0iK8xnO9M@mail.gmail.com>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTikFXeUw477+vhEs1xfFeTJpy_Eeo54LqYbLfG90@mail.gmail.com>	<A8557CC0-68C0-46A6-B2AF-DF9200FFF4B7@gmail.com>
	<AANLkTikzkTtGEEbCNN18kJ4VA=PFCqOWhUq0iK8xnO9M@mail.gmail.com>
Message-ID: <4D80D225.6070103@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/03/11 22:50, Guido van Rossum wrote:
> I propose we try to find an "embedded blogger" who participates in
> python-dev but is focused on making regular blog posts about the
> interesting tidbits. There's no requirement to be complete (which I
> think always weighed the python-dev-summaries task down).
> 
> Ditto for python-ideas -- it would be nice if it was the same person
> but doesn't have to be.
> 
> This might be an opportunity for increasing diversity.

+1. I would love to see this. Too bad I don't have the time myself to
keep up with python-dev & python-ideas... Forwarding the request to
python-es mailing list. Crossing fingers.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDSJZlgi5GaxT1NAQIEvwP+MWHZbY+xMhl27K7hC2fPH7QJsz55H0Xb
7FIWSApqdJXL5Uzu+VbGN4IKK7GBCGHXS8t/vTOXcePeqZRnTGIgxVth8NnxcK3M
O9+VJIyGaqMghb0BEgSaaryfiZNfbI0mKwAouzgzQsvP2uyX/kzCHQCnxdDsNTWo
mxLbKVicaRw=
=aA2c
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Wed Mar 16 16:13:04 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Mar 2011 11:13:04 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <4D80CDBE.7040309@jcea.es>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>	<4D7F6786.1060902@v.loewis.de>	<AANLkTinsD4THLnJzh4iqdNfBVLpFmS8gPoSCmcg9y5gx@mail.gmail.com>
	<4D80CDBE.7040309@jcea.es>
Message-ID: <4D80D380.3040101@v.loewis.de>

> I strongly opposed CObject deprecation in 2.7, as you can see in
> <http://bugs.python.org/issue9675>  and mailing list archives.

Interestingly enough, Lennart would have preferred a longer
deprecation period, not a shorter one. So he would have been even
more upset had the deprecation not be done in 2.7.

Regards,
Martin

From armin.ronacher at active-4.com  Wed Mar 16 16:57:23 2011
From: armin.ronacher at active-4.com (Armin Ronacher)
Date: Wed, 16 Mar 2011 11:57:23 -0400
Subject: [Python-Dev] Low-Level Encoding Behavior on Python 3
In-Reply-To: <20110316084833.1aa2a4bb@pitrou.net>
References: <4D8066E6.2020409@active-4.com>
	<20110316084833.1aa2a4bb@pitrou.net>
Message-ID: <4D80DDE3.5040709@active-4.com>

Hi,

On 3/16/11 3:48 AM, Antoine Pitrou wrote:
> I may be mistaken, but you seem to conflate two things: encoding of
> file names, and encoding of file contents. I guess that virtualenv
> chokes on the file contents, but most of your argument seems related to
> encoding of file names (aka "filesystem encoding").
These are two pretty unrelated problems but both are problems 
nonetheless.  The filename encoding should not be guessed from the 
environment variables as those are from the connecting client.  The 
default encoding for file contents also should not be platform 
dependent.  It *will* lead to people thinking it works when in practice 
it will break if they move their code to a remote server and SSH into it 
and then trigger the code execution.

I argue that the first is just wrong (filename encoding guessing) and 
the latter is dangerous (file content encoding being platform dependent).

virtualenv itself is already fixed and explicitly tells it to read with 
UTF-8 encoding.


Regards,
Armin

From brian.curtin at gmail.com  Wed Mar 16 17:10:09 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Wed, 16 Mar 2011 11:10:09 -0500
Subject: [Python-Dev] New contributors at the PyCon sprint
Message-ID: <AANLkTimNJ6Fhhvn0dALtL3-41kJyNjc+ARU+SfxjdtbE@mail.gmail.com>

Hi all,

As I'm sure you're all aware, the PyCon sprints are going on right now and
will run for two more days. As a result, you may have noticed an increased
number of patches over the last few days -- many of these were from
first-time contributors. The turnout for the CPython sprint has been huge
and I wanted to introduce and thank a number of people for coming out.

Scott Wilson
Denver Coneybeare
Jeff Ramnani
Alicia Arlen
Michael Henry
Natalia Bidart
Matias Bordese
Robbie Clemons
Evan Dandrea
Jonathan Hartley
Piotr Kaspyrzyk
Brandon Craig Rhodes

There were a few others from which I didn't get their name, but thanks to
everyone for your contributions!

http://wiki.python.org/moin/Pycon2011Sprint has a listing of what the new
contributors have been working on, including the issues that have been
submitted.

Additionally, I did a small write-up (with a picture!) of what everyone has
been up to:
http://blog.briancurtin.com/2011/03/16/pycon-2011-cpython-sprint-newcomers/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110316/ec7a6b33/attachment.html>

From stefan_ml at behnel.de  Wed Mar 16 17:11:21 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 16 Mar 2011 17:11:21 +0100
Subject: [Python-Dev] Low-Level Encoding Behavior on Python 3
In-Reply-To: <4D80DDE3.5040709@active-4.com>
References: <4D8066E6.2020409@active-4.com>	<20110316084833.1aa2a4bb@pitrou.net>
	<4D80DDE3.5040709@active-4.com>
Message-ID: <ilqnfa$l1e$1@dough.gmane.org>

Armin Ronacher, 16.03.2011 16:57:
> On 3/16/11 3:48 AM, Antoine Pitrou wrote:
>> I may be mistaken, but you seem to conflate two things: encoding of
>> file names, and encoding of file contents. I guess that virtualenv
>> chokes on the file contents, but most of your argument seems related to
>> encoding of file names (aka "filesystem encoding").
> These are two pretty unrelated problems but both are problems nonetheless.
> The filename encoding should not be guessed from the environment variables
> as those are from the connecting client. The default encoding for file
> contents also should not be platform dependent. It *will* lead to people
> thinking it works when in practice it will break if they move their code to
> a remote server and SSH into it and then trigger the code execution.
>
> I argue that the first is just wrong (filename encoding guessing) and the
> latter is dangerous (file content encoding being platform dependent).

Antoine was arguing that it's not the fault of CPython that virtualenv 
expects it to correctly guess the encoding of a file it wants to read. It 
tries an educated guess based on the current environment setup, and if 
that's not correctly configured, it's the user's fault. As you indicated 
yourself, it does work most of the time. That's all you should expect from 
a default.


> virtualenv itself is already fixed and explicitly tells it to read with
> UTF-8 encoding.

That's the right way to deal with encoded file content.

Stefan


From jcea at jcea.es  Wed Mar 16 17:11:20 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 16 Mar 2011 17:11:20 +0100
Subject: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
In-Reply-To: <AANLkTi=rP=_oQVgO1JQ6EWCcApwAaN9Y_Q6wZx+4d88r@mail.gmail.com>
References: <AANLkTinO+6oGCfPrHV=CDrxgkbh46vmfQ6gMs0H5JSmJ@mail.gmail.com>	<D0ACF24F-6B5F-472E-B249-541571A7FB43@gmail.com>
	<AANLkTi=rP=_oQVgO1JQ6EWCcApwAaN9Y_Q6wZx+4d88r@mail.gmail.com>
Message-ID: <4D80E128.5080204@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/03/11 13:14, Paul Moore wrote:
> None of my real code is affected either way, but it seems to me that
> the removal of the comparison function option was (sadly) a case of
> purity being allowed to beat practicality. Luckily, adding it back
> wouldn't be a backward compatibility issue :-) Whether it's worth
> doing, I'll leave to those who would be doing the work to judge...

I would +1 to reintroducing "cmp". Mapping my mental "cmp" to a "key"
is something I must think about everyday. When I have a 200 element
list, I don't mind about the "O(nlog(n))" nature of "cmp", instead of
"O(n)" of key.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYDhJJlgi5GaxT1NAQKcXQP+IX5bSb3aSNsfzu/vjNY41CNI/1CJ+r3q
vxPbi7ut1ZvXVyiMo2b+jVC1rxNVitf0pQXyQ4skv9Tiq3+L8eYbOts7hbmDB7Aw
sNPWYuvjLmTrX2lsgdQyjbiVK0lHJjzYn8+pvKqy7Tt47+sNiL/07FmM6CHj2fiU
N/vspNCa6rs=
=Zc90
-----END PGP SIGNATURE-----

From alexander.belopolsky at gmail.com  Wed Mar 16 17:39:16 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 16 Mar 2011 12:39:16 -0400
Subject: [Python-Dev] Module version variable
Message-ID: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>

I was editing the turtle module (for issue11571, if you are
interested) when I noticed that it has the following line:

_ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"

This is obviously out of date and this variable is not used anywhere
in the module.  I would simply delete it, but I wonder if there is any
recommended mechanism for maintaining module versions.

Some modules define __version__ which has a special meaning at least
for pydoc and possibly some third party tools.  In many cases it is
never updated and its format and meaning varies from module to module.
 (For example, decimal module stores the version of the spec rather
than the version of the module in __version__.)

In several instances, __version__ is set to "$Revision$" in an
apparent attempt to leverage VCS to keep it up to date, but this does
not seem to work after hg transition.  For example,

$  ./python.exe -m pydoc pydoc
..
VERSION
    $Revision$

The other affected modules are pickle and tarfile.

Do you have an advise on how these issues should be handled?

From fuzzyman at voidspace.org.uk  Wed Mar 16 17:54:33 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 16 Mar 2011 12:54:33 -0400
Subject: [Python-Dev] pydoc for named tuples is missing methods
In-Reply-To: <4D7FFCCC.3090202@canterbury.ac.nz>
References: <AANLkTik_z=TUi18SQEh1257YMSJTv-efYiu3u+Udn5Yd@mail.gmail.com>	<4D7DB6CF.5050102@canterbury.ac.nz>	<AANLkTi=25a7wWzQ1sr2K4L7SE7npGyBMNjBxrRqUZXjq@mail.gmail.com>	<AANLkTimZ4xottsWQj6GONOwcgYh+F+ETO57frWHrgsBS@mail.gmail.com>	<AANLkTim+ustociR9UB4Qff_99qtC8h1j+xebcPph8jju@mail.gmail.com>	<AANLkTimrH3tSX5jXZ4NZa0Y2FkFgWMSoaF_58LsisrRV@mail.gmail.com>
	<4D7FFCCC.3090202@canterbury.ac.nz>
Message-ID: <4D80EB49.20604@voidspace.org.uk>

On 15/03/2011 19:57, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> The challenge here is how it would interact with inheritance. pydoc
>> couldn't use normal attribute lookup, it would have to walk the MRO
>> manually,
>
> This is an instance of a pattern that I've encountered a
> few times in things that I've done: you have a class
> attribute containing a list of things, and you want it
> to be "additive" with respect to inheritance -- i.e. it
> contains the items specified in a particular class plus
> all those specified in its base classes.
>
> This can obviously be arranged using appropriate metaclass
> hackery, but I'm wondering whether it could be provided
> using some mechanism that can be applied orthogonally
> to any class attribute.
>

Right, I recently came across a similar usecase where a class needed to 
extend an object defined in a base class. What we *wanted* to do was the 
following:

class Foo(object):
      thing = Thing()

class Bar(Foo):
     thing.baz = 3

This doesn't work for obvious reasons. One potential solution was 
re-assigning 'thing' on Bar as well and using a metaclass to merge them.

I think we ended up doing this, which is *slightly* ugly but not too bad:

class Bar(Foo):
     thing = Foo.thing
     thing.baz = 3

All the best,

Michael

> Maybe this is another reason to have a hook somewhere
> in the standard class creation process that allows a
> descriptor to initialise itself with knowledge of its
> environment.
>


-- 
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


From barry at python.org  Wed Mar 16 17:53:34 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 16 Mar 2011 12:53:34 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
Message-ID: <20110316125334.4510b10d@neurotica>

On Mar 16, 2011, at 12:39 PM, Alexander Belopolsky wrote:

>I was editing the turtle module (for issue11571, if you are
>interested) when I noticed that it has the following line:
>
>_ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
>
>This is obviously out of date and this variable is not used anywhere
>in the module.  I would simply delete it, but I wonder if there is any
>recommended mechanism for maintaining module versions.
>
>Some modules define __version__ which has a special meaning at least
>for pydoc and possibly some third party tools.  In many cases it is
>never updated and its format and meaning varies from module to module.
> (For example, decimal module stores the version of the spec rather
>than the version of the module in __version__.)
>
>In several instances, __version__ is set to "$Revision$" in an
>apparent attempt to leverage VCS to keep it up to date, but this does
>not seem to work after hg transition.  For example,
>
>$  ./python.exe -m pydoc pydoc
>..
>VERSION
>    $Revision$
>
>The other affected modules are pickle and tarfile.
>
>Do you have an advise on how these issues should be handled?

MvL and I had a discussion about this at the sprint.  I am planning on writing
an informational PEP that proposes __version__ as a standard convention.  I'd
like to be able to do:

    >>> import foo
    >>> foo.__version__

It won't be mandatory (thus the informational PEP), but it should be
formalized as the preferred way to introspect a module for its version
number.  I think there should be ways to spell this easily if the information
is provided to packaging/distutils2 so that it can basically always be kept up
to date without violating DRY.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110316/e0f9de9a/attachment.pgp>

From g.brandl at gmx.net  Wed Mar 16 18:19:09 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 16 Mar 2011 18:19:09 +0100
Subject: [Python-Dev] hooks: Add roundup integration hook.
In-Reply-To: <4D80C9DF.7040709@jcea.es>
References: <E1Pwv18-0002f2-4m@dinsdale.python.org>	<4D768C81.5080609@udel.edu>
	<il66dc$vut$1@dough.gmane.org> <4D80C9DF.7040709@jcea.es>
Message-ID: <ilqred$duc$1@dough.gmane.org>

Am 16.03.2011 15:31, schrieb Jesus Cea:
> On 08/03/11 22:16, Georg Brandl wrote:
>> But in any case, by popular demand "fix" is now removed, and only
>> "close" and its variants actually closes the issue -- since there
>> is not much chance that you can write "close #12345" without
>> actually meaning to close the issue :)
> 
> Sorry to bother you. What would be the exact wording?. What "variants"
> means?.

Those I mentioned in my original email to python-committers.

> Yesterday I committed a changeset with a commit message of "Close issue
> #8600: test_gdb	failures because innocuous warnings", and it didn't
> automatically close the issue :).
> 
> Sorry for being so picky ;-).

Well, the hook recognizes "closes" as a prefix of either "issue 12345" or
"#12345", but not a combination of both.

Georg


From fuzzyman at voidspace.org.uk  Wed Mar 16 18:31:55 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 16 Mar 2011 13:31:55 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <20110316125334.4510b10d@neurotica>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<20110316125334.4510b10d@neurotica>
Message-ID: <4D80F40B.6050803@voidspace.org.uk>

On 16/03/2011 12:53, Barry Warsaw wrote:
> On Mar 16, 2011, at 12:39 PM, Alexander Belopolsky wrote:
>
>> I was editing the turtle module (for issue11571, if you are
>> interested) when I noticed that it has the following line:
>>
>> _ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
>>
>> This is obviously out of date and this variable is not used anywhere
>> in the module.  I would simply delete it, but I wonder if there is any
>> recommended mechanism for maintaining module versions.
>>
>> Some modules define __version__ which has a special meaning at least
>> for pydoc and possibly some third party tools.  In many cases it is
>> never updated and its format and meaning varies from module to module.
>> (For example, decimal module stores the version of the spec rather
>> than the version of the module in __version__.)
>>
>> In several instances, __version__ is set to "$Revision$" in an
>> apparent attempt to leverage VCS to keep it up to date, but this does
>> not seem to work after hg transition.  For example,
>>
>> $  ./python.exe -m pydoc pydoc
>> ..
>> VERSION
>>     $Revision$
>>
>> The other affected modules are pickle and tarfile.
>>
>> Do you have an advise on how these issues should be handled?
> MvL and I had a discussion about this at the sprint.  I am planning on writing
> an informational PEP that proposes __version__ as a standard convention.  I'd
> like to be able to do:
>
>      >>>  import foo
>      >>>  foo.__version__
>
> It won't be mandatory (thus the informational PEP), but it should be
> formalized as the preferred way to introspect a module for its version
> number.  I think there should be ways to spell this easily if the information
> is provided to packaging/distutils2 so that it can basically always be kept up
> to date without violating DRY.
>

+1

There is a minor difficulty with distutils2 which needs to be able to 
install from setup.cfg without executing code. This means it can't look 
in package.__version__ to get the version number (potentially requiring 
you to maintain __version__ both in your package and your setup.cfg).

The suggestion is that the version metadata should be created at package 
build time, defaulting to package.__version__. The rationale is that it 
is ok to execute code at build time if it removes the need for 
information duplication or for executing code at install time.

Also note that there is a proposed api for getting version info: 
pkgutil.get_version(module). Under the hood this looks for __version__ 
as one of the first places to find version info.

All the best,

Michael Foord

> -Barry
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110316/29c8a337/attachment-0001.html>

From fuzzyman at voidspace.org.uk  Wed Mar 16 18:33:20 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 16 Mar 2011 13:33:20 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
Message-ID: <4D80F460.6010307@voidspace.org.uk>

On 16/03/2011 12:39, Alexander Belopolsky wrote:
> I was editing the turtle module (for issue11571, if you are
> interested) when I noticed that it has the following line:
>
> _ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
>

unittest also has an outdated (and unmaintained) version number that I 
would like to remove. Standard library modules should be versioned by 
the release of Python they are packaged with (unless they are externally 
maintained I guess) and so should preferably *not* carry version info.

All the best,

Michael

> This is obviously out of date and this variable is not used anywhere
> in the module.  I would simply delete it, but I wonder if there is any
> recommended mechanism for maintaining module versions.
>
> Some modules define __version__ which has a special meaning at least
> for pydoc and possibly some third party tools.  In many cases it is
> never updated and its format and meaning varies from module to module.
>   (For example, decimal module stores the version of the spec rather
> than the version of the module in __version__.)
>
> In several instances, __version__ is set to "$Revision$" in an
> apparent attempt to leverage VCS to keep it up to date, but this does
> not seem to work after hg transition.  For example,
>
> $  ./python.exe -m pydoc pydoc
> ..
> VERSION
>      $Revision$
>
> The other affected modules are pickle and tarfile.
>
> Do you have an advise on how these issues should be handled?
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From martin at v.loewis.de  Wed Mar 16 18:49:42 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Mar 2011 13:49:42 -0400
Subject: [Python-Dev] Generating patch files
Message-ID: <4D80F836.8070701@v.loewis.de>

I think I figured out how to generate a single patch for
a clone that has all its changes on the default branch,
comparing it with cpython's default branch. The command to generate
the patch is

hg diff -r'max(p1(min(outgoing())) or p2(max(merge() and 
branch(default))))' -r default

If it's a branch different from default, replace 'default' in both 
places with the branch name.

I'd be curious for people to try this out and report whether it works 
correctly. You'll need a Mercurial release supporting revsets.

Here is the theory of operation: The diff needs to be either from
the oldest of the commits (in case no merges have been made from 
cpython), or from cpython's code in that was last merged. So:

- merge() gives all changesets that are merges
- branch(default) gives all changesets on the default branch
- 'merge() and branch(default)' gives all merges to the default
   branch
- max(merge() and branch(default)) gives the most recent merge
   to the default branch
- p2(max(merge() and branch(default))) is the second parent,
   which will be the upstream version of cpython that got last
   merged
- outgoing() gives all changes in the local repository not
   in cpython
- min(outgoing()) gives the first local change made
- p1(min(outgoing())) gives revision that was the starting
   point for the local modifications
- max(p1(...) or p2(...)) determines which of the two is
   later.

Having the revision of cpython to compare against is the
difficult part; the other revision must be default's head,
which is always called 'default'.

Enjoy,
Martin

From rdmurray at bitdance.com  Wed Mar 16 19:33:22 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 16 Mar 2011 14:33:22 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <4D80F460.6010307@voidspace.org.uk>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
Message-ID: <20110316183322.A34F424A614@kimball.webabinitio.net>

On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 16/03/2011 12:39, Alexander Belopolsky wrote:
> > I was editing the turtle module (for issue11571, if you are
> > interested) when I noticed that it has the following line:
> >
> > _ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
> >
> 
> unittest also has an outdated (and unmaintained) version number that I 
> would like to remove. Standard library modules should be versioned by 
> the release of Python they are packaged with (unless they are externally 
> maintained I guess) and so should preferably *not* carry version info.

The email package has an internal version (which changes no more often
than CPython's, but may change slower).  Existing code in the field
tests this version attribute, so I don't think it should be deleted.

The same may or may not be true of unittest, but if it hasn't been
maintained its present utility is questionable so it may be just as
well to delete it.

--
R. David Murray                                      www.bitdance.com

From ncoghlan at gmail.com  Wed Mar 16 19:48:20 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Mar 2011 14:48:20 -0400
Subject: [Python-Dev] Generating patch files
In-Reply-To: <4D80F836.8070701@v.loewis.de>
References: <4D80F836.8070701@v.loewis.de>
Message-ID: <AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>

On Wed, Mar 16, 2011 at 1:49 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I think I figured out how to generate a single patch for
> a clone that has all its changes on the default branch,
> comparing it with cpython's default branch. The command to generate
> the patch is
>
> hg diff -r'max(p1(min(outgoing())) or p2(max(merge() and branch(default))))'
> -r default
>
> If it's a branch different from default, replace 'default' in both places
> with the branch name.
>
> I'd be curious for people to try this out and report whether it works
> correctly. You'll need a Mercurial release supporting revsets.

I get "unknown revision" (listing the full expression text) when using
Mercurial 1.6.3 (default version in Ubuntu 10.10).

That version apparently supports revsets, but I'm not sure when the
runtime evaluation of the command line arguments was added.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From raymond.hettinger at gmail.com  Wed Mar 16 20:00:38 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 16 Mar 2011 12:00:38 -0700
Subject: [Python-Dev] Module version variable
In-Reply-To: <20110316183322.A34F424A614@kimball.webabinitio.net>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
Message-ID: <68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>


On Mar 16, 2011, at 11:33 AM, R. David Murray wrote:

> On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>> On 16/03/2011 12:39, Alexander Belopolsky wrote:
>>> I was editing the turtle module (for issue11571, if you are
>>> interested) when I noticed that it has the following line:
>>> 
>>> _ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
>>> 
>> 
>> unittest also has an outdated (and unmaintained) version number that I 
>> would like to remove. Standard library modules should be versioned by 
>> the release of Python they are packaged with (unless they are externally 
>> maintained I guess) and so should preferably *not* carry version info.
> 
> The email package has an internal version (which changes no more often
> than CPython's, but may change slower).  Existing code in the field
> tests this version attribute, so I don't think it should be deleted.

The version number in the decimal module refers to the version of the
spec that is being complied with.  I would like that version number
to remain in the module.

There are probably other cases where the version number is useful.


Raymond


From fuzzyman at voidspace.org.uk  Wed Mar 16 20:13:59 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 16 Mar 2011 15:13:59 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <20110316183322.A34F424A614@kimball.webabinitio.net>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
Message-ID: <4D810BF7.70906@voidspace.org.uk>

On 16/03/2011 14:33, R. David Murray wrote:
> On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord<fuzzyman at voidspace.org.uk>  wrote:
>> On 16/03/2011 12:39, Alexander Belopolsky wrote:
>>> I was editing the turtle module (for issue11571, if you are
>>> interested) when I noticed that it has the following line:
>>>
>>> _ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
>>>
>> unittest also has an outdated (and unmaintained) version number that I
>> would like to remove. Standard library modules should be versioned by
>> the release of Python they are packaged with (unless they are externally
>> maintained I guess) and so should preferably *not* carry version info.
> The email package has an internal version (which changes no more often
> than CPython's, but may change slower).  Existing code in the field
> tests this version attribute, so I don't think it should be deleted.
>
> The same may or may not be true of unittest, but if it hasn't been
> maintained its present utility is questionable so it may be just as
> well to delete it.

If you're actively maintaining the version info and are using it for api 
versioning then great. For unittest it is truly useless and much better 
not to have it.

Deprecating a module attribute is basically impossible (twisted has some 
code that makes it possible by subclassing the ModuleType I believe) so 
I will probably just delete it.

All the best,

Michael

> --
> R. David Murray                                      www.bitdance.com


-- 
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


From martin at v.loewis.de  Wed Mar 16 20:20:16 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Mar 2011 15:20:16 -0400
Subject: [Python-Dev] Generating patch files
In-Reply-To: <AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>
References: <4D80F836.8070701@v.loewis.de>
	<AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>
Message-ID: <4D810D70.6080401@v.loewis.de>

> I get "unknown revision" (listing the full expression text) when using
> Mercurial 1.6.3 (default version in Ubuntu 10.10).
>
> That version apparently supports revsets, but I'm not sure when the
> runtime evaluation of the command line arguments was added.

Apparently shortly after Debian/Ubuntu included the release; I think
I had the same issue with 1.6.4.

Regards,
Martin

From fuzzyman at voidspace.org.uk  Wed Mar 16 20:21:21 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 16 Mar 2011 15:21:21 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
Message-ID: <4D810DB1.1070109@voidspace.org.uk>

On 16/03/2011 15:00, Raymond Hettinger wrote:
> On Mar 16, 2011, at 11:33 AM, R. David Murray wrote:
>
>> On Wed, 16 Mar 2011 13:33:20 -0400, Michael Foord<fuzzyman at voidspace.org.uk>  wrote:
>>> On 16/03/2011 12:39, Alexander Belopolsky wrote:
>>>> I was editing the turtle module (for issue11571, if you are
>>>> interested) when I noticed that it has the following line:
>>>>
>>>> _ver = "turtle 1.1b- - for Python 3.1   -  4. 5. 2009"
>>>>
>>> unittest also has an outdated (and unmaintained) version number that I
>>> would like to remove. Standard library modules should be versioned by
>>> the release of Python they are packaged with (unless they are externally
>>> maintained I guess) and so should preferably *not* carry version info.
>> The email package has an internal version (which changes no more often
>> than CPython's, but may change slower).  Existing code in the field
>> tests this version attribute, so I don't think it should be deleted.
> The version number in the decimal module refers to the version of the
> spec that is being complied with.  I would like that version number
> to remain in the module.
>
> There are probably other cases where the version number is useful.
>

That's entirely fair enough, although that's not really a *module 
version number* so isn't what I was referring to. The sqlite module also 
carries version information about the version of sqlite it works with 
which is another valid use case (sqlite *also* has a module version 
number I believe, because it is externally maintained).

In the case of the unittest version number it goes back to when unittest 
*was* originally maintained externally.

As general practise is to use __version__ for module version info I 
think it would be bad (misleading) if any module (including standard 
library) reused this name for storing information that *wasn't* a module 
version but some related version info.

All the best,

Michael

> Raymond
>


-- 
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


From martin at v.loewis.de  Wed Mar 16 20:29:08 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Mar 2011 15:29:08 -0400
Subject: [Python-Dev] Generating patch files
In-Reply-To: <4D810D70.6080401@v.loewis.de>
References: <4D80F836.8070701@v.loewis.de>
	<AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>
	<4D810D70.6080401@v.loewis.de>
Message-ID: <4D810F84.5060705@v.loewis.de>

Am 16.03.11 15:20, schrieb "Martin v. L?wis":
>> I get "unknown revision" (listing the full expression text) when using
>> Mercurial 1.6.3 (default version in Ubuntu 10.10).
>>
>> That version apparently supports revsets, but I'm not sure when the
>> runtime evaluation of the command line arguments was added.
>
> Apparently shortly after Debian/Ubuntu included the release; I think
> I had the same issue with 1.6.4.

Before you upgrade: give me some time to come up with a script that
uses Mercurial API instead to compute the revset and then invoke the
diff command.

We must get something out of using a Python-based DVCS...

Regards,
Martin

From theller at ctypes.org  Wed Mar 16 20:36:30 2011
From: theller at ctypes.org (Thomas Heller)
Date: Wed, 16 Mar 2011 20:36:30 +0100
Subject: [Python-Dev] Please retract my committer rights
Message-ID: <ilr3fu$14c$1@dough.gmane.org>

I would like my committer rights to be retracted.

I have been contributing to Python here and there for 10 years now,
and it was a pleasant experience.

Unfortunately, since about a year I have lots more things to do, and
I won't be able to contribute anymore (I have not even started to
learn mercurial yet).  Plus I'm still using 2.6 or even 2.5 with my own
Python projects.

Goodbye.

Thanks,
Thomas


From raymond.hettinger at gmail.com  Wed Mar 16 20:44:35 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 16 Mar 2011 12:44:35 -0700
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <ilr3fu$14c$1@dough.gmane.org>
References: <ilr3fu$14c$1@dough.gmane.org>
Message-ID: <5EB58235-7989-465B-AF66-98EDC2D3C4D6@gmail.com>


On Mar 16, 2011, at 12:36 PM, Thomas Heller wrote:

> I would like my committer rights to be retracted.
> 
> I have been contributing to Python here and there for 10 years now,
> and it was a pleasant experience.
> 
> Unfortunately, since about a year I have lots more things to do, and
> I won't be able to contribute anymore (I have not even started to
> learn mercurial yet).  Plus I'm still using 2.6 or even 2.5 with my own
> Python projects.
> 
> Goodbye.

You will be missed.
Thanks for all your efforts.


Raymond

From nad at acm.org  Wed Mar 16 21:00:58 2011
From: nad at acm.org (Ned Deily)
Date: Wed, 16 Mar 2011 13:00:58 -0700
Subject: [Python-Dev] Generating patch files
References: <4D80F836.8070701@v.loewis.de>
	<AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>
	<4D810D70.6080401@v.loewis.de> <4D810F84.5060705@v.loewis.de>
Message-ID: <nad-65882E.13005816032011@news.gmane.org>

In article <4D810F84.5060705 at v.loewis.de>,
 "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Before you upgrade: give me some time to come up with a script that
> uses Mercurial API instead to compute the revset and then invoke the
> diff command.
> 
> We must get something out of using a Python-based DVCS...

Note the Mercurial project warns that use of the Mercurial API 'is a 
strong indication that you're creating a "derived work" subject to the 
GPL.'

http://mercurial.selenic.com/wiki/MercurialApi
http://mercurial.selenic.com/wiki/License

Would distributing a script that called the API in any way taint Python?

-- 
 Ned Deily,
 nad at acm.org


From tjreedy at udel.edu  Wed Mar 16 21:14:46 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 16 Mar 2011 16:14:46 -0400
Subject: [Python-Dev] New contributors at the PyCon sprint
In-Reply-To: <AANLkTimNJ6Fhhvn0dALtL3-41kJyNjc+ARU+SfxjdtbE@mail.gmail.com>
References: <AANLkTimNJ6Fhhvn0dALtL3-41kJyNjc+ARU+SfxjdtbE@mail.gmail.com>
Message-ID: <ilr5nl$e8m$1@dough.gmane.org>

On 3/16/2011 12:10 PM, Brian Curtin wrote:
> Hi all,
>
> As I'm sure you're all aware, the PyCon sprints are going on right now
> and will run for two more days. As a result, you may have noticed an

Yes. Emphasizing improved test coverage was a great idea. It is 
relatively easy and definitely needed, as shown by regressions due to 
lack thereof. So there is no argument about whether a good patch should 
go in.

> increased number of patches over the last few days -- many of these were
> from first-time contributors. The turnout for the CPython sprint has
> been huge and I wanted to introduce and thank a number of people for
> coming out.
>
> Scott Wilson
> Denver Coneybeare
> Jeff Ramnani
> Alicia Arlen
> Michael Henry
> Natalia Bidart
> Matias Bordese
> Robbie Clemons
> Evan Dandrea
> Jonathan Hartley
> Piotr Kaspyrzyk
> Brandon Craig Rhodes

Please let them know if they do not read pydev that we are not a closed 
club and that push rights are a reasonable aspiration within a year 
after 20 patch submissions or so (and not necessary all accepted).

-- 
Terry Jan Reedy


From doug.hellmann at gmail.com  Wed Mar 16 22:01:34 2011
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Wed, 16 Mar 2011 17:01:34 -0400
Subject: [Python-Dev] public visibility of python-dev decisions "before
	it's too late" (was: PyCObject_AsVoidPtr removed from python
	3.2 - is this documented?)
In-Reply-To: <4D80D225.6070103@jcea.es>
References: <il75tb$c8s$1@dough.gmane.org>	<AANLkTikFXeUw477+vhEs1xfFeTJpy_Eeo54LqYbLfG90@mail.gmail.com>	<A8557CC0-68C0-46A6-B2AF-DF9200FFF4B7@gmail.com>
	<AANLkTikzkTtGEEbCNN18kJ4VA=PFCqOWhUq0iK8xnO9M@mail.gmail.com>
	<4D80D225.6070103@jcea.es>
Message-ID: <E06E5C51-F094-4BF9-B9DF-71D27CAC78E6@gmail.com>


On Mar 16, 2011, at 11:07 AM, Jesus Cea wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/03/11 22:50, Guido van Rossum wrote:
>> I propose we try to find an "embedded blogger" who participates in
>> python-dev but is focused on making regular blog posts about the
>> interesting tidbits. There's no requirement to be complete (which I
>> think always weighed the python-dev-summaries task down).
>> 
>> Ditto for python-ideas -- it would be nice if it was the same person
>> but doesn't have to be.
>> 
>> This might be an opportunity for increasing diversity.
> 
> +1. I would love to see this. Too bad I don't have the time myself to
> keep up with python-dev & python-ideas... Forwarding the request to
> python-es mailing list. Crossing fingers.

Jesus, if anyone expresses interest in helping out please have them contact me directly, off list.

Thanks,
Doug


From alexander.belopolsky at gmail.com  Wed Mar 16 22:13:05 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 16 Mar 2011 17:13:05 -0400
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <5EB58235-7989-465B-AF66-98EDC2D3C4D6@gmail.com>
References: <ilr3fu$14c$1@dough.gmane.org>
	<5EB58235-7989-465B-AF66-98EDC2D3C4D6@gmail.com>
Message-ID: <AANLkTikRj_VWtnKunuHkjEjTH4n3WF7q-TW0Gzrma0r5@mail.gmail.com>

On Wed, Mar 16, 2011 at 3:44 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
> On Mar 16, 2011, at 12:36 PM, Thomas Heller wrote:
>
>> I would like my committer rights to be retracted.
..
> You will be missed.
> Thanks for all your efforts.
>

+1

In case anyone did not recognize Thomas by name, he contributed the
ctypes package, which in my opinion was a hugely successful addition.

Thanks for all your hard work!

From alexander.belopolsky at gmail.com  Wed Mar 16 22:54:13 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 16 Mar 2011 17:54:13 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
Message-ID: <AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>

On Wed, Mar 16, 2011 at 3:00 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
..
> The version number in the decimal module refers to the version of the
> spec that is being complied with. ?I would like that version number
> to remain in the module.

I mentioned this in my first post.   If the version number of the spec
is important, shouldn't it be called something else?  Note that
__version__ value appears in pydoc as the version the module, and it
is confusing to have it refer to something else.  This fact is only
mentioned in a comment inside the module and cannot be found either in
module docstrings or reST documentation.

Note that in a similar situation, another module, unicodedata defines
unidata_version variable which is properly documented:

http://docs.python.org/library/unicodedata.html?highlight=unicodedata#unicodedata.unidata_version

I think this is a better approach.  (It would be even better if it was
called "ucd_version" or "unicode_version", but  "unidata_version" is
good enough.)

I also question the utility of maintaining IBM draft version in the
decimal module.  Note that the current version 1.70 is described as
follows:

Changes in Version 1.70 (25 Mar 2009)

The document is now formatted using OpenOffice (generated from GML),
for improved PDF files with bookmarks, hot links, etc. There are no
technical changes.  See http://speleotrove.com/decimal/dachange.html

On the other hand, spot checking the changes from other versions I
immediately found that at least one change introduced in the previous
version, 1.68, was not implemented:

"The normalize operation has been renamed reduce to avoid confusion
with normal numbers."

It may actually be more useful to refer to the appropriate version of
IEEE 754 standard.  Or if no strict compliance with any particular
standard or version of specification is promised, not record spec
version in the module at all.

Given that decimal.__version__ has not changed since it was
introduced, I doubt there is a lot of code out there that relies on
it.

From eric at trueblade.com  Wed Mar 16 23:15:23 2011
From: eric at trueblade.com (Eric Smith)
Date: Wed, 16 Mar 2011 18:15:23 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>	<4D80F460.6010307@voidspace.org.uk>	<20110316183322.A34F424A614@kimball.webabinitio.net>	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
Message-ID: <4D81367B.9010808@trueblade.com>

On 3/16/2011 5:54 PM, Alexander Belopolsky wrote:
> On Wed, Mar 16, 2011 at 3:00 PM, Raymond Hettinger
> <raymond.hettinger at gmail.com>  wrote:
> ..
>> The version number in the decimal module refers to the version of the
>> spec that is being complied with.  I would like that version number
>> to remain in the module.
>
> I mentioned this in my first post.   If the version number of the spec
> is important, shouldn't it be called something else?

I agree, especially if we need to issue a new version of the library 
that implements the same spec. We couldn't upgrade __version__, since 
it's used for the spec. There'd be no way to know (by inspection) if the 
version of the library fixed a spec compliance issue.

Eric.

From raymond.hettinger at gmail.com  Thu Mar 17 00:00:25 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 16 Mar 2011 16:00:25 -0700
Subject: [Python-Dev] Hg:  inter-branch workflow
Message-ID: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>

I think devguide's suggested interbranch workflow introduces too much complexity for too little payoff.

If I need to make a fix to 3.2, I can't just fix it.  I would need to also merge the changeset into 3.3 and then revert it, and then commit both.  There is not much payoff to this style.  It brings back the ghost of svnmerge but it much more restrictive:
* it is pretty much required for every patch on a non-default branch
* you have to decide in advance how far it should be backported because only forward porting is supported
* it means you can't just fix one branch without having also decided how the change should be applied to other branches (if we look at the tracker, you can see that it is very common for the resolution on different branches to be done at different times)

I think we would be better off treating the branches as independent.  If I need to apply a patch to two of them, that's what I would do (in any order, at any time, or with or without modifications).

As far as I can tell the only benefits to the cross-linking are that it reduces the chance that a patch will be applied to an older branch but not forward ported.

I've been enjoying most of my experiences with mercurial, but as soon we start needing rebases, null merges, merges followed by null reverts, then we might as well be using git.  The version control system is supposed to make our lives easier, not introduce more workflow requirements.

I don't think the more complex workflow if worth it.  Mercurial is very user friendly right out of the box will simple commands.  But as soon as you require the branches to be inter-linked, you've made it much more difficult to get simple checkins done.


Raymond




From facundobatista at gmail.com  Thu Mar 17 00:05:19 2011
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 16 Mar 2011 19:05:19 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
Message-ID: <AANLkTikVr5Pz7k8TLWwE7Ns4euaCJMnpuZHUn6uLOEHR@mail.gmail.com>

On Wed, Mar 16, 2011 at 7:00 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:

> I don't think the more complex workflow if worth it. ?Mercurial is very user friendly right out of the box will simple commands. ?But as soon as you require the branches to be inter-linked, you've made it much more difficult to get simple checkins done.

+1 to keep it as simple as possible, at least until we get more time
using it and know better which added complexity pays off.

-- 
.? ? Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From ncoghlan at gmail.com  Thu Mar 17 00:09:21 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Mar 2011 19:09:21 -0400
Subject: [Python-Dev] Useful page in the Hg book
Message-ID: <AANLkTikLM5yb5ofZEMBb23kmet63z6yjWyvOHTuv21Zg@mail.gmail.com>

As I'm sure there will be plenty of erring as we get used to Hg:
http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html

For simple cases of attempting to push a single commit that gets
rejected by the server, hg rollback/hg pull/hg commit/hg push/ may
provide a cleaner history than doing a dummy merge.

hg backout also further emphasises the benefits of working in feature
branches - I was able to revert the default branch in my sandbox to
match upstream by backing out a single changeset.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Thu Mar 17 00:15:08 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Mar 2011 19:15:08 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
Message-ID: <AANLkTinmjcRvL+hLwsJ+4tD4WhSGuKWAAPRGOY9w4tTS@mail.gmail.com>

On Wed, Mar 16, 2011 at 7:00 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> I think devguide's suggested interbranch workflow introduces too much complexity for too little payoff.

Raymond,

We had this discussion many, many times before the transition. This
*is* the way every single experienced Hg user has recommended bugfixes
be handled. We're already deviating from common Hg practices in many
errors, please at least *try* this one for a few months before
throwing up your hands in disgust.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From greg.ewing at canterbury.ac.nz  Thu Mar 17 00:16:01 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 17 Mar 2011 12:16:01 +1300
Subject: [Python-Dev] public visibility of python-dev decisions "before
 it's too late"
In-Reply-To: <4D80D104.7040704@hastings.org>
References: <il75tb$c8s$1@dough.gmane.org>
	<AANLkTimjfiJ6r8vcYgMXwqbmb4TtfhYSP2-kMZ-sqZ-F@mail.gmail.com>
	<4D80D104.7040704@hastings.org>
Message-ID: <4D8144B1.8070107@canterbury.ac.nz>

Larry Hastings wrote:

> The PyCapsule API is very much like the CObject API.  In fact, in Python 
> 3.1 CObject was actually implemented on top of PyCapsule.  It should be 
> very easy to support both APIs.

Perhaps the code for the 3.1 implementation could be pulled
out and made available to people in a form that's easy to
include in their projects?

-- 
Greg

From ncoghlan at gmail.com  Thu Mar 17 00:16:26 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Mar 2011 19:16:26 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTinmjcRvL+hLwsJ+4tD4WhSGuKWAAPRGOY9w4tTS@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<AANLkTinmjcRvL+hLwsJ+4tD4WhSGuKWAAPRGOY9w4tTS@mail.gmail.com>
Message-ID: <AANLkTinQs30h1BnTMvRKk9H8f49n9HEM-B6dCr4SMFBn@mail.gmail.com>

On Wed, Mar 16, 2011 at 7:15 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> be handled. We're already deviating from common Hg practices in many
> errors, please at least *try* this one for a few months before
> throwing up your hands in disgust.

s/errors/areas/

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Thu Mar 17 00:20:26 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 17 Mar 2011 00:20:26 +0100
Subject: [Python-Dev] Hg:  inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
Message-ID: <20110317002026.51802b86@pitrou.net>


Hello,

> I think devguide's suggested interbranch workflow introduces too much complexity for too little payoff.
> 
> If I need to make a fix to 3.2, I can't just fix it.  I would need to also merge the changeset into 3.3 and then revert it, and then commit both.  There is not much payoff to this style.  It brings back the ghost of svnmerge but it much more restrictive:

Well, you might not have liked svnmerge, but most other devs preferred
using it instead of porting patches by hand.
I think the same argument goes for "hg merge".

> (if we look at the tracker, you can see that it is very common for the resolution on different branches to be done at different times)

That's not my experience.
Often, when the resolution on other branches is deferred, it means the
committer has actually forgotten about it.

It doesn't really make sense in practice to defer such resolution: you
want the issue to be fresh in your head when committing patches; you
don't want to have to context-switch everything back into your head,
read the discussion again, try to remember the subtleties, etc. Doing
the different branches at different times makes you lose more of your
time, cumulated, and also increases the risk of doing something wrong.

> As far as I can tell the only benefits to the cross-linking are that it reduces the chance that a patch will be applied to an older branch but not forward ported.

Well, no. The main benefit is ease of merging, by definition ;)

Regards

Antoine.



From fuzzyman at voidspace.org.uk  Thu Mar 17 00:24:05 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 16 Mar 2011 19:24:05 -0400
Subject: [Python-Dev] Hg:  inter-branch workflow
In-Reply-To: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
Message-ID: <4D814695.2040801@voidspace.org.uk>

On 16/03/2011 19:00, Raymond Hettinger wrote:
> I think devguide's suggested interbranch workflow introduces too much complexity for too little payoff.
>
The ability to merge between branches is a high payoff. *Having* to 
apply patches separately to all branches is also a nuisance, 
particularly given that easy merging between branches is one of the big 
advantages of a dvcs.

Unfortunately if some developers decide they won't merge their changes 
that puts the burden of doing it on all the other developers (with more 
pain if the patches have been applied to different branches separately 
as developers merging their own changes now have to handle unrelated 
conflicts caused by someone else).

What it should be possible for us to do is create scripts that will auto 
do the "reverse merge" for changes that shouldn't be forward ported.

All the best,

Michael Foord

> If I need to make a fix to 3.2, I can't just fix it.  I would need to also merge the changeset into 3.3 and then revert it, and then commit both.  There is not much payoff to this style.  It brings back the ghost of svnmerge but it much more restrictive:
> * it is pretty much required for every patch on a non-default branch
> * you have to decide in advance how far it should be backported because only forward porting is supported
> * it means you can't just fix one branch without having also decided how the change should be applied to other branches (if we look at the tracker, you can see that it is very common for the resolution on different branches to be done at different times)
>
> I think we would be better off treating the branches as independent.  If I need to apply a patch to two of them, that's what I would do (in any order, at any time, or with or without modifications).
>
> As far as I can tell the only benefits to the cross-linking are that it reduces the chance that a patch will be applied to an older branch but not forward ported.
>
> I've been enjoying most of my experiences with mercurial, but as soon we start needing rebases, null merges, merges followed by null reverts, then we might as well be using git.  The version control system is supposed to make our lives easier, not introduce more workflow requirements.
>
> I don't think the more complex workflow if worth it.  Mercurial is very user friendly right out of the box will simple commands.  But as soon as you require the branches to be inter-linked, you've made it much more difficult to get simple checkins done.
>
>
> Raymond
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From tseaver at palladion.com  Thu Mar 17 00:22:53 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 16 Mar 2011 19:22:53 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <4D81367B.9010808@trueblade.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>	<4D80F460.6010307@voidspace.org.uk>	<20110316183322.A34F424A614@kimball.webabinitio.net>	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com>
Message-ID: <ilrgoc$efd$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/16/2011 06:15 PM, Eric Smith wrote:
> On 3/16/2011 5:54 PM, Alexander Belopolsky wrote:
>> On Wed, Mar 16, 2011 at 3:00 PM, Raymond Hettinger
>> <raymond.hettinger at gmail.com>  wrote:
>> ..
>>> The version number in the decimal module refers to the version of the
>>> spec that is being complied with.  I would like that version number
>>> to remain in the module.
>>
>> I mentioned this in my first post.   If the version number of the spec
>> is important, shouldn't it be called something else?
> 
> I agree, especially if we need to issue a new version of the library 
> that implements the same spec. We couldn't upgrade __version__, since 
> it's used for the spec. There'd be no way to know (by inspection) if the 
> version of the library fixed a spec compliance issue.

I'm not even sure why you would want __version__ in 99% of modules:  in
the ordinary cases, a module's version should be either the Python
version (for a module shipped in the stdlib), or the release of the
distribution which shipped it.  Free-standing, separately-distributed
modules are a huge anomaly

ISTM that other cases (version of a spec targeted by the module, or of
the underlying C library it wraps), need their own attribute.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2BRkwACgkQ+gerLs4ltQ7ZnACcDNxH/pR5jb0ycNK/i3LlvsDF
AxYAnAvnPQT5iMkAONSTFYVYM5tlazYw
=2eBY
-----END PGP SIGNATURE-----


From martin at v.loewis.de  Thu Mar 17 01:47:10 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Mar 2011 20:47:10 -0400
Subject: [Python-Dev] Generating patch files
In-Reply-To: <nad-65882E.13005816032011@news.gmane.org>
References: <4D80F836.8070701@v.loewis.de>	<AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>	<4D810D70.6080401@v.loewis.de>
	<4D810F84.5060705@v.loewis.de>
	<nad-65882E.13005816032011@news.gmane.org>
Message-ID: <4D815A0E.1000209@v.loewis.de>

> Note the Mercurial project warns that use of the Mercurial API 'is a
> strong indication that you're creating a "derived work" subject to the
> GPL.'
>
> http://mercurial.selenic.com/wiki/MercurialApi
> http://mercurial.selenic.com/wiki/License
>
> Would distributing a script that called the API in any way taint Python?

Perhaps. So I'll see whether I can make use of the command line only, first.

Regards,
Martin

From stephen at xemacs.org  Thu Mar 17 01:53:19 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 17 Mar 2011 09:53:19 +0900
Subject: [Python-Dev] Generating patch files
In-Reply-To: <nad-65882E.13005816032011@news.gmane.org>
References: <4D80F836.8070701@v.loewis.de>
	<AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>
	<4D810D70.6080401@v.loewis.de> <4D810F84.5060705@v.loewis.de>
	<nad-65882E.13005816032011@news.gmane.org>
Message-ID: <AANLkTi=BMf09imHt4=iXA1AsTW14+EScvSUZG8VV8b3W@mail.gmail.com>

On Thu, Mar 17, 2011 at 5:00 AM, Ned Deily <nad at acm.org> wrote:
> In article <4D810F84.5060705 at v.loewis.de>,
> ?"Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Before you upgrade: give me some time to come up with a script that
>> uses Mercurial API instead to compute the revset and then invoke the
>> diff command.
>>
>> We must get something out of using a Python-based DVCS...
>
> Note the Mercurial project warns that use of the Mercurial API 'is a
> strong indication that you're creating a "derived work" subject to the
> GPL.'

> Would distributing a script that called the API in any way taint Python?

Yes, if used to build or run Python.

No, if used to develop Python.

From ncoghlan at gmail.com  Thu Mar 17 02:39:20 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Mar 2011 21:39:20 -0400
Subject: [Python-Dev] Useful page in the Hg book
In-Reply-To: <AANLkTikLM5yb5ofZEMBb23kmet63z6yjWyvOHTuv21Zg@mail.gmail.com>
References: <AANLkTikLM5yb5ofZEMBb23kmet63z6yjWyvOHTuv21Zg@mail.gmail.com>
Message-ID: <AANLkTimKrSbW0K=KyoEY+ULOpzS3rp31YLYZwyj-G1Mn@mail.gmail.com>

On Wed, Mar 16, 2011 at 7:09 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> As I'm sure there will be plenty of erring as we get used to Hg:
> http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html
>
> For simple cases of attempting to push a single commit that gets
> rejected by the server, hg rollback/hg pull/hg commit/hg push/ may
> provide a cleaner history than doing a dummy merge.

Having tried this, I advise against anyone else trying it. I seem to
have got my local repo into a state where it thinks I have already
merged something from 3.2 to default when I really haven't.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Thu Mar 17 02:40:49 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Mar 2011 21:40:49 -0400
Subject: [Python-Dev] Generating patch files
In-Reply-To: <4D810F84.5060705@v.loewis.de>
References: <4D80F836.8070701@v.loewis.de>	<AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>	<4D810D70.6080401@v.loewis.de>
	<4D810F84.5060705@v.loewis.de>
Message-ID: <4D8166A1.4050708@v.loewis.de>

Am 16.03.11 15:29, schrieb "Martin v. L?wis":
> Am 16.03.11 15:20, schrieb "Martin v. L?wis":
>>> I get "unknown revision" (listing the full expression text) when using
>>> Mercurial 1.6.3 (default version in Ubuntu 10.10).
>>>
>>> That version apparently supports revsets, but I'm not sure when the
>>> runtime evaluation of the command line arguments was added.
>>
>> Apparently shortly after Debian/Ubuntu included the release; I think
>> I had the same issue with 1.6.4.
>
> Before you upgrade: give me some time to come up with a script that
> uses Mercurial API instead to compute the revset and then invoke the
> diff command.

It turns out that 1.6 doesn't have the min() revset function, so I give 
up on that - the recipe can only work in 1.7 and later.

Regards,
Martin

From rdmurray at bitdance.com  Thu Mar 17 04:06:29 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 16 Mar 2011 23:06:29 -0400
Subject: [Python-Dev] Generating patch files
In-Reply-To: <4D815A0E.1000209@v.loewis.de>
References: <4D80F836.8070701@v.loewis.de>
	<AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>
	<4D810D70.6080401@v.loewis.de> <4D810F84.5060705@v.loewis.de>
	<nad-65882E.13005816032011@news.gmane.org>
	<4D815A0E.1000209@v.loewis.de>
Message-ID: <20110317030629.4673023B568@kimball.webabinitio.net>

On Wed, 16 Mar 2011 20:47:10 -0400, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin at v.loewis.de> wrote:
> > Note the Mercurial project warns that use of the Mercurial API 'is a
> > strong indication that you're creating a "derived work" subject to the
> > GPL.'
> >
> > http://mercurial.selenic.com/wiki/MercurialApi
> > http://mercurial.selenic.com/wiki/License
> >
> > Would distributing a script that called the API in any way taint Python?
> 
> Perhaps. So I'll see whether I can make use of the command line only, first.

As long as we aren't distributing mercurial itself, I don't see
how a script could be a problem.  But, then, IANAL.

--
R. David Murray                                      www.bitdance.com

From jcea at jcea.es  Thu Mar 17 04:34:08 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 04:34:08 +0100
Subject: [Python-Dev] Useful page in the Hg book
In-Reply-To: <AANLkTimKrSbW0K=KyoEY+ULOpzS3rp31YLYZwyj-G1Mn@mail.gmail.com>
References: <AANLkTikLM5yb5ofZEMBb23kmet63z6yjWyvOHTuv21Zg@mail.gmail.com>
	<AANLkTimKrSbW0K=KyoEY+ULOpzS3rp31YLYZwyj-G1Mn@mail.gmail.com>
Message-ID: <4D818130.20106@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/03/11 02:39, Nick Coghlan wrote:
> On Wed, Mar 16, 2011 at 7:09 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> As I'm sure there will be plenty of erring as we get used to Hg:
>> http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html
>>
>> For simple cases of attempting to push a single commit that gets
>> rejected by the server, hg rollback/hg pull/hg commit/hg push/ may
>> provide a cleaner history than doing a dummy merge.
> 
> Having tried this, I advise against anyone else trying it. I seem to
> have got my local repo into a state where it thinks I have already
> merged something from 3.2 to default when I really haven't.

The good thing about dummy merges is that you do the merge in your local
clone, and if you don't like it you can do a revert or a rollback. That
way, it is risk free and you can experiment locally before pushing.

Since rebase is in HG core these days, I am getting comfy with "hg pull
- --rebase". But I find rewriting history too scary when merging between
branches and complicated changeset graphs. I want to be able to drop a
bad conflict merging and try again, in a safe way.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGBMJlgi5GaxT1NAQIl2wQAllNQiQfjHygDDoGEGm+9wUAxtaGLvSkB
na/MmFTgXSXn4og7K5JVmTesc1KXHJjF+a3Kb2oDu9A3IRbjipEIc4qWpnwTlPBW
skmAMXhwLR+Y9y+nXo2ry9R71SvIa7u1RGihrPWBnnIHzlgWKPwr93BPdYygSb4g
uQJ4QGIVudU=
=LSJh
-----END PGP SIGNATURE-----

From rdmurray at bitdance.com  Thu Mar 17 04:41:14 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 16 Mar 2011 23:41:14 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317002026.51802b86@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
Message-ID: <20110317034114.0628C24A416@kimball.webabinitio.net>

On Thu, 17 Mar 2011 00:20:26 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > I think devguide's suggested interbranch workflow introduces too
> > much complexity for too little payoff.
> > 
> > If I need to make a fix to 3.2, I can't just fix it.  I would need
> > to also merge the changeset into 3.3 and then revert it, and then
> > commit both.  There is not much payoff to this style.  It brings
> > back the ghost of svnmerge but it much more restrictive:
> 
> Well, you might not have liked svnmerge, but most other devs preferred
> using it instead of porting patches by hand.
> I think the same argument goes for "hg merge".

+10.  And I've done quite a few commits here at the sprints.  I'd *really*
hate to have had to patch each branch by hand.  If I'd had to do that
I'm sure I wouldn't have bothered with 3.1.  As it is, once I applied
the patch once to 3.1, doing the merges was a piece of cake.  Patching
2.7, on the other hand, is a pain.

Dealing with a null merge when someone else has committed between the
time I started the merge dance (I always pull just before I start that)
and the time I push is not that hard either.  It pretty much amounts to
having to do an additional set of merges.  (In my case I do a strip and
restart my merge dance, but I'm not sure I should recommend that since
altering history is considered dangerous :)

Even this week, with all the commit activity surrounding the sprints,
I have only had to deal with a push race twice out of 16 patches.
I expect to hit it only very rarely in normal development work.

Alternatively, Ezio at least follows the policy of doing a pull
-u/commit/push in the first branch, and then doing pull -u/merge/push
in the next branch.  You are even less likely to hit a push race by
following that technique, since the time between the pull -u and the
push is minimized.

--
R. David Murray                                      www.bitdance.com

From jcea at jcea.es  Thu Mar 17 04:58:31 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 04:58:31 +0100
Subject: [Python-Dev] Hg:  inter-branch workflow
In-Reply-To: <20110317002026.51802b86@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
Message-ID: <4D8186E7.7050408@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/03/11 00:20, Antoine Pitrou wrote:
> That's not my experience.
> Often, when the resolution on other branches is deferred, it means the
> committer has actually forgotten about it.

I agree with this impression. Personally when I have a "pending branch",
I keep a firefox tab open in the issue, as a "reminder". It bugs me a
lot. And that is the point.

Most of the time, I push all the changesets for all branches in a single
operation. The (mainly) only time I could push a single branch is if I
want to try the patch in the buildbots first, before applying to all
relevant branches. And I try to avoid it, because I know some other
people are going to have issues when doing their own merges trying not
to merge my changeset themselves, specially newbies (the +1 head thing).

I agree that half the changesets are merges now. But that is an artifact
of our commit culture (create a patch, commit inmediatelly). Another
approach would be to spend some time writing patches, committing locally
and doing a giant merge & push at the end of the week :-).

(DIGRESS: If buildbots could download & test a remote arbitrary HG
repository, it would be a big improvement for this, and a galaxy-size
security hazard :-p... Although now any "pusher" can break-in any
buildbot machine simply pushing some ugly test code, of modified
"configure" script.

Uhm... Maybe a wiki about how to set up a "chroot" buildslave would be
something to think about... Any info about this?)

The good thing about merging so frequently is that mergin is easy,
painless and every committer must go thru it for her own patches,
instead of putting that responsability on somebody else. "hg log" can be
a bit unusual for us, but pretty moot. we are getting used to it, yet.

No forgeting up-porting changesets is a massive improvement with the
late svnmerge practice (nobody cared about automatic merging, but
merging by hand anyway, cherrypicking revisions).

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGG55lgi5GaxT1NAQLEDwP+L3AsqeXMpgEOKJFW6gqs0ahjbqF61Ao5
zThKWqXQoAyDm+21bT8aJR3Ogrix+dI37PrTRa6B8L+S2tDh3PdG984tOUOsGUvp
KNa+GSNai1OotfLUebBhCvGlPAapQnWK9xoELYjO8Lo7YTkfWspXGv5e3exIQQJp
AmunpKy1I3U=
=gS+8
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Mar 17 05:11:23 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 05:11:23 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317034114.0628C24A416@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
Message-ID: <4D8189EB.7040800@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/03/11 04:41, R. David Murray wrote:
> Dealing with a null merge when someone else has committed between the
> time I started the merge dance (I always pull just before I start that)
> and the time I push is not that hard either.  It pretty much amounts to
> having to do an additional set of merges.  (In my case I do a strip and
> restart my merge dance, but I'm not sure I should recommend that since
> altering history is considered dangerous :).

Could you possibly describe your current approach, marking it with a
huge "NOT SAFE; AT YOUR OWN RISK" banner?. I wonders how other people
manage this.

I too do a "pull" before doing the merge, but I don't push each merge
separatelly but I do the all the merges locally and then do an unique
push. Than can take some time, moreover if I run the complete testsuite
in all changed branches. Resolving a "+1 head" here is tricky, if I
*WANT* the other developer to manage her own merging by herself. As it
should.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGJ65lgi5GaxT1NAQII3wP/fiHkDs5xFP9hK/3tWxFSrovdSoOOTzKT
py7J2P1Ys1nQAw9ylfDiq6oFPGuc22pSqBrO2MgLlGs1a5i9XBSDhA6yCvRW6i4C
CoPMmVXigEeZXpEBGpYWtjSO7pIvPQxPCjMH6zlHWwD+jg6RhqBQrz/yacKQdNzw
7auugDVYyD0=
=uAdh
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Mar 17 05:14:41 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 05:14:41 +0100
Subject: [Python-Dev] Generating patch files
In-Reply-To: <4D810F84.5060705@v.loewis.de>
References: <4D80F836.8070701@v.loewis.de>	<AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>	<4D810D70.6080401@v.loewis.de>
	<4D810F84.5060705@v.loewis.de>
Message-ID: <4D818AB1.1020801@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/03/11 20:29, "Martin v. L?wis" wrote:
> Before you upgrade: give me some time to come up with a script that
> uses Mercurial API instead to compute the revset and then invoke the
> diff command.
> 
> We must get something out of using a Python-based DVCS...

Beware, mercurial API is not stable. That is, it can change anytime.
Paradoxically, the stable "API" is the commandline, IIRC.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGKsZlgi5GaxT1NAQLEegP9GlKeCi5FRICOXUe2gjQbEWQ3lI44V3ae
+XjGf1FqS5kWgGLM+DlpHZuOB8pQo80ZZFpxOY3MzVi/SCBm8i+SfjGDdS9QQS7X
Y6i7duZ7ubbHls6hnN9weHB6MXBCA+GQQQg8oMSnGiUdXLLBkUzhY+/pXb688wpE
dxFneCjN6W8=
=Xpds
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Mar 17 05:21:17 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 05:21:17 +0100
Subject: [Python-Dev] Question about GDB bindings and 32/64 bits
In-Reply-To: <4CF27941.1020200@ubuntu.com>
References: <4CEF338C.4070509@jcea.es> <4CF27941.1020200@ubuntu.com>
Message-ID: <4D818C3D.8020401@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/11/10 16:46, Matthias Klose wrote:
> On 26.11.2010 05:11, Jesus Cea wrote:
>> I have installed GDB 7.2 32 bits and 32 bits buildslaves are green.
>> Nevertheless 64 bits buildslaves are failing test_gdb.
>>
>> Is there any expectation that a 32 bits GDB be able to debug a 64 bits
>> python?. If not, gdb test should compare "platform.architecture()" (for
>> python and gdb in the system) and run only when they are the same.
> 
> that would be too restrictive, as an 64bit gdb is able to handle 32bit
> binaries too.
> 
>> If
>> this should work, I would open a bug and maybe spend some time with it.
>>
>> But before thinking about investing time, I would like to know if this
>> mix is actually expected or not to work.
>>
>> If not, I would consider to install a 64 bits GDB too and do some tricks
>> (like using an "/usr/local/bin/gdb" script wrapper to choose 32/64
>> "real" gdb version) to actually execute "test_gdb" in both buildslaves
>> (they are running in the same physical machine).
> 
> yes, and then you should be able to use this gdb for both 32 and 64bit
> builds. No need for a wrapper (Such a gdb is available in the gdb64
> package on Debian/Ubuntu).
> 
>   Matthias

I compiled GDB 64 bits to debug both 32 and 64 bits binaries. There are
some thread debugging issues when debugging 32 bits, but we can live
with them for now.

Details in <http://bugs.python.org/issue8600#msg131073>.

Thanks for the suggestion, Matthias.

Closing old threads...

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYGMPZlgi5GaxT1NAQLDNwP/Rswr2jZvxBoif98dIS7bwk/OA+uIB18k
p3dNs71cGAV4emcuz+e+fMS138WXwN5c1epo5QrAQ9eQTr0KoJIo6bBaFKHzg03m
RFNIEF4bpB4VvtSvTlIZYHQayecJGHRZxEewEzW9+562ZFa79qvhaYEPxAEVh6jT
6kvt0pQoAIw=
=v9N0
-----END PGP SIGNATURE-----

From rdmurray at bitdance.com  Thu Mar 17 06:14:25 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 17 Mar 2011 01:14:25 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D8189EB.7040800@jcea.es>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
Message-ID: <20110317051425.96F40253152@kimball.webabinitio.net>

On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea <jcea at jcea.es> wrote:
> On 17/03/11 04:41, R. David Murray wrote:
> > Dealing with a null merge when someone else has committed between the
> > time I started the merge dance (I always pull just before I start that)
> > and the time I push is not that hard either.  It pretty much amounts to
> > having to do an additional set of merges.  (In my case I do a strip and
> > restart my merge dance, but I'm not sure I should recommend that since
> > altering history is considered dangerous :).
> 
> Could you possibly describe your current approach, marking it with a
> huge "NOT SAFE; AT YOUR OWN RISK" banner?. I wonders how other people
> manage this.
> 
> I too do a "pull" before doing the merge, but I don't push each merge
> separatelly but I do the all the merges locally and then do an unique
> push. Than can take some time, moreover if I run the complete testsuite
> in all changed branches. Resolving a "+1 head" here is tricky, if I
> *WANT* the other developer to manage her own merging by herself. As it
> should.

Yes, running the entire test suite puts rather a delay into the process.
Generally what I do is run the full test suite in the first branch I'm
patching, and then only run the specific test suite in the other branches
during the merge.  This is a bit suboptimal since default will have more
code and more tests for that code than the source branch, but I figure
the buildbots will yell if something was missed.  On the other hand,
when we aren't in sprint-commit-frenzy, I may run the full test suite
on default before doing the push.

OK, so BIG DISCLAIMER: TRY THIS AT YOUR OWN RISK :)

My setup is using the share extension.  This means I have one repository
with multiple checkout directories.  I also have one pristine clone
of cpython in case I screw up and need to recreate my share setup.
The share setup looks like this:

    hg clone cpython p33
    hg share p33 p32
    hg share p33 p31
    hg share p33 p27
    cd p33; hg up default
    cd ../p32; hg up 3.2
    cd ../p31; hg up 3.1
    cd ../p27; hg up 2.7

And then I build python in each branch checkout.  With luck I only
have to do this once (in practice I've had to do it twice so far,
but I'm not really expecting to have to do it again, now that I've
learned how things work).

My working process is to cd into the checkout for the branch I'm
patching first (usually 3.1), and do an hg pull followed by an hg up.
(It's important the this be two separate commands rather than an hg
pull -u because this is a shared setup: pull -u won't update the local
working copy if there are no changesets pulled, while hg up updates
it unconditionally.)  I then apply the patch, and do whatever testing
and fixing and NEWS and ACK entries I need, including running the full
tests suite.  When I'm satisfied, I start the merge dance:

do hg pull; hg up (I could use hg
pull -u here since I know I haven't done a pull in some other checkout).

Then I:

hg diff >temp.patch
hg pull
hg up
hg ci
cd ../p32
hg up
hg merge 3.1
[run tests applicable to the patch]
hg ci
cd ../p33
hg up
hg merge 3.2
[run tests applicable to the patch]
(if needed:
 cd ../p27
 hg up
 patch -p1 <../p31/temp.patch
 [fix and test]
 [if there were a bunch of changes, hg diff >temp.patch]
 hg ci
)
hg pull

If this pull shows no changesets, I do an hg push.

The fun part comes if there are changesets.  At this point there
are two options: go through each of the branches doing an up/merge/ci,
and then pull/push.  Or, what I actually do:

hg log
hg strip <the changeset id of my first checkin>

Then I start from the top of the section above, but starting by reapplying
my temp.patch.  There's one other detail, though:  because I'm using
share, the checkouts lose their parent id when I do the strip.  So in
each checkout I also need to do 'hg debugsetparent <branch>' before
doing the hg up.

Clearly, this procedure is not for everyone, and I may decide it is
not for me by and by.  But it has worked well so far during the
sprints.  There's also some room for automation here.

I think part of the reason I like it is that it is fairly close to the
workflow I had for svn, except the merges go in the opposite direction
and they go a *lot* faster.  2.7, though, is more of a pain than with
svn because I have to use patch instead of getting the nice merge markers
that svnmerge gave me.  And I prefer to do all the merges and then push
(rather than push-per-merge like Ezio) because I have all the way until
that final push to realize I've made a mistake.

Which reminds me: I said I'd hit a race twice during the sprints, but
that isn't true.  It was only once.  The other time I used strip,
it was because I realized just before the push that I'd screwed up
the patch, so I went back and started over.  To me that's a definite
benefit of hg over svn.

The roundup update hook is also very lovely :)

--
R. David Murray                                      www.bitdance.com

From greg at krypto.org  Thu Mar 17 07:21:37 2011
From: greg at krypto.org (Gregory P. Smith)
Date: Wed, 16 Mar 2011 23:21:37 -0700
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317051425.96F40253152@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
Message-ID: <AANLkTiktF+E2VsbP-exEJRQDUYXw18zFfOM27mgvRAGL@mail.gmail.com>

On Wed, Mar 16, 2011 at 10:14 PM, R. David Murray <rdmurray at bitdance.com>wrote:

> On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea <jcea at jcea.es> wrote:
> > On 17/03/11 04:41, R. David Murray wrote:
> > > Dealing with a null merge when someone else has committed between the
> > > time I started the merge dance (I always pull just before I start that)
> > > and the time I push is not that hard either.  It pretty much amounts to
> > > having to do an additional set of merges.  (In my case I do a strip and
> > > restart my merge dance, but I'm not sure I should recommend that since
> > > altering history is considered dangerous :).
> >
> > Could you possibly describe your current approach, marking it with a
> > huge "NOT SAFE; AT YOUR OWN RISK" banner?. I wonders how other people
> > manage this.
> >
> > I too do a "pull" before doing the merge, but I don't push each merge
> > separatelly but I do the all the merges locally and then do an unique
> > push. Than can take some time, moreover if I run the complete testsuite
> > in all changed branches. Resolving a "+1 head" here is tricky, if I
> > *WANT* the other developer to manage her own merging by herself. As it
> > should.
>
> Yes, running the entire test suite puts rather a delay into the process.
> Generally what I do is run the full test suite in the first branch I'm
> patching, and then only run the specific test suite in the other branches
> during the merge.  This is a bit suboptimal since default will have more
> code and more tests for that code than the source branch, but I figure
> the buildbots will yell if something was missed.  On the other hand,
> when we aren't in sprint-commit-frenzy, I may run the full test suite
> on default before doing the push.
>
> OK, so BIG DISCLAIMER: TRY THIS AT YOUR OWN RISK :)
>
> My setup is using the share extension.  This means I have one repository
> with multiple checkout directories.  I also have one pristine clone
> of cpython in case I screw up and need to recreate my share setup.
> The share setup looks like this:
>
>    hg clone cpython p33
>    hg share p33 p32
>    hg share p33 p31
>    hg share p33 p27
>    cd p33; hg up default
>    cd ../p32; hg up 3.2
>    cd ../p31; hg up 3.1
>    cd ../p27; hg up 2.7
>
> And then I build python in each branch checkout.  With luck I only
> have to do this once (in practice I've had to do it twice so far,
> but I'm not really expecting to have to do it again, now that I've
> learned how things work).
>
> My working process is to cd into the checkout for the branch I'm
> patching first (usually 3.1), and do an hg pull followed by an hg up.
> (It's important the this be two separate commands rather than an hg
> pull -u because this is a shared setup: pull -u won't update the local
> working copy if there are no changesets pulled, while hg up updates
> it unconditionally.)  I then apply the patch, and do whatever testing
> and fixing and NEWS and ACK entries I need, including running the full
> tests suite.  When I'm satisfied, I start the merge dance:
>
> do hg pull; hg up (I could use hg
> pull -u here since I know I haven't done a pull in some other checkout).
>
> Then I:
>
> hg diff >temp.patch
> hg pull
> hg up
> hg ci
> cd ../p32
> hg up
> hg merge 3.1
> [run tests applicable to the patch]
> hg ci
> cd ../p33
> hg up
> hg merge 3.2
> [run tests applicable to the patch]
> (if needed:
>  cd ../p27
>  hg up
>  patch -p1 <../p31/temp.patch
>  [fix and test]
>  [if there were a bunch of changes, hg diff >temp.patch]
>  hg ci
> )
> hg pull
>

why do you use hg diff and patch above rather than hg export and hg import?

(not implying one is better than the other, learning here...)
-gps


>
> If this pull shows no changesets, I do an hg push.
>
> The fun part comes if there are changesets.  At this point there
> are two options: go through each of the branches doing an up/merge/ci,
> and then pull/push.  Or, what I actually do:
>
> hg log
> hg strip <the changeset id of my first checkin>
>
> Then I start from the top of the section above, but starting by reapplying
> my temp.patch.  There's one other detail, though:  because I'm using
> share, the checkouts lose their parent id when I do the strip.  So in
> each checkout I also need to do 'hg debugsetparent <branch>' before
> doing the hg up.
>
> Clearly, this procedure is not for everyone, and I may decide it is
> not for me by and by.  But it has worked well so far during the
> sprints.  There's also some room for automation here.
>
> I think part of the reason I like it is that it is fairly close to the
> workflow I had for svn, except the merges go in the opposite direction
> and they go a *lot* faster.  2.7, though, is more of a pain than with
> svn because I have to use patch instead of getting the nice merge markers
> that svnmerge gave me.  And I prefer to do all the merges and then push
> (rather than push-per-merge like Ezio) because I have all the way until
> that final push to realize I've made a mistake.
>
> Which reminds me: I said I'd hit a race twice during the sprints, but
> that isn't true.  It was only once.  The other time I used strip,
> it was because I realized just before the push that I'd screwed up
> the patch, so I went back and started over.  To me that's a definite
> benefit of hg over svn.
>
> The roundup update hook is also very lovely :)
>
> --
> R. David Murray                                      www.bitdance.com
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110316/a62d524b/attachment.html>

From orsenthil at gmail.com  Thu Mar 17 08:02:11 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Thu, 17 Mar 2011 15:02:11 +0800
Subject: [Python-Dev] buildbot error when pushing to 2.5 branch?
Message-ID: <20110317070211.GC3754@kevin>

When pushed a change to 2.5 branch, I got an error, which I think has
to do with buildbot not available for 2.5 codeline.
It asked me to notify the tracker and here it is.

remote:     state = method(*args, **kw)
remote:   File "/data/buildbot/master/master.cfg", line 87, in
perspective_addChange
remote:     changedict['category'] =
branch_to_category[changedict['branch']]
remote: exceptions.KeyError: '2.5'
remote: ]
remote: sent email to roundup at report at bugs.python.org



-- 
-------------- next part --------------
pushing to ssh://hg at hg.python.org/cpython
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 2 changes to 1 files
remote: change(s) NOT sent, something went wrong:
remote: [Failure instance: Traceback from remote host -- Traceback (most recent call last):
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/banana.py", line 153, in gotItem
remote:     self.callExpressionReceived(item)
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/banana.py", line 116, in callExpressionReceived
remote:     self.expressionReceived(obj)
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/pb.py", line 514, in expressionReceived
remote:     method(*sexp[1:])
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/pb.py", line 826, in proto_message
remote:     self._recvMessage(self.localObjectForID, requestID, objectID, message, answerRequired, netArgs, netKw)
remote: --- <exception caught here> ---
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/pb.py", line 840, in _recvMessage
remote:     netResult = object.remoteMessageReceived(self, message, netArgs, netKw)
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/pb.py", line 225, in perspectiveMessageReceived
remote:     state = method(*args, **kw)
remote:   File "/data/buildbot/master/master.cfg", line 87, in perspective_addChange
remote:     changedict['category'] = branch_to_category[changedict['branch']]
remote: exceptions.KeyError: '2.5'
remote: ]
remote: sent email to roundup at report at bugs.python.org
remote: notified python-checkins at python.org of incoming changeset e9724d7abbc2
remote: notified python-checkins at python.org of incoming changeset 8cdb95cf096e
remote: notified python-checkins at python.org of incoming changeset 6cd7de9deb1a
remote: notified python-checkins at python.org of incoming changeset 1148131b1099


From eric at trueblade.com  Thu Mar 17 09:57:40 2011
From: eric at trueblade.com (Eric Smith)
Date: Thu, 17 Mar 2011 04:57:40 -0400
Subject: [Python-Dev] Hg:  inter-branch workflow
In-Reply-To: <4D8186E7.7050408@jcea.es>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>
	<4D8186E7.7050408@jcea.es>
Message-ID: <4D81CD04.4040306@trueblade.com>

On 3/16/2011 11:58 PM, Jesus Cea wrote:
> I agree that half the changesets are merges now.

Which has basically stopped me from reviewing changes. I can't quickly 
tell the real changes from the noise of merges.

From g.brandl at gmx.net  Thu Mar 17 11:26:13 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 17 Mar 2011 11:26:13 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317051425.96F40253152@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
Message-ID: <ilsnk6$v38$1@dough.gmane.org>

Am 17.03.2011 06:14, schrieb R. David Murray:
> On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea <jcea at jcea.es> wrote:
>> On 17/03/11 04:41, R. David Murray wrote:
>> > Dealing with a null merge when someone else has committed between the
>> > time I started the merge dance (I always pull just before I start that)
>> > and the time I push is not that hard either.  It pretty much amounts to
>> > having to do an additional set of merges.  (In my case I do a strip and
>> > restart my merge dance, but I'm not sure I should recommend that since
>> > altering history is considered dangerous :).
>> 
>> Could you possibly describe your current approach, marking it with a
>> huge "NOT SAFE; AT YOUR OWN RISK" banner?. I wonders how other people
>> manage this.
>> 
>> I too do a "pull" before doing the merge, but I don't push each merge
>> separatelly but I do the all the merges locally and then do an unique
>> push. Than can take some time, moreover if I run the complete testsuite
>> in all changed branches. Resolving a "+1 head" here is tricky, if I
>> *WANT* the other developer to manage her own merging by herself. As it
>> should.
> 
> Yes, running the entire test suite puts rather a delay into the process.
> Generally what I do is run the full test suite in the first branch I'm
> patching, and then only run the specific test suite in the other branches
> during the merge.  This is a bit suboptimal since default will have more
> code and more tests for that code than the source branch, but I figure
> the buildbots will yell if something was missed.  On the other hand,
> when we aren't in sprint-commit-frenzy, I may run the full test suite
> on default before doing the push.
> 
> OK, so BIG DISCLAIMER: TRY THIS AT YOUR OWN RISK :)
> 
> My setup is using the share extension.  This means I have one repository
> with multiple checkout directories.  I also have one pristine clone
> of cpython in case I screw up and need to recreate my share setup.
> The share setup looks like this:
> 
>     hg clone cpython p33
>     hg share p33 p32
>     hg share p33 p31
>     hg share p33 p27
>     cd p33; hg up default
>     cd ../p32; hg up 3.2
>     cd ../p31; hg up 3.1
>     cd ../p27; hg up 2.7
> 
> And then I build python in each branch checkout.  With luck I only
> have to do this once (in practice I've had to do it twice so far,
> but I'm not really expecting to have to do it again, now that I've
> learned how things work).
> 
> My working process is to cd into the checkout for the branch I'm
> patching first (usually 3.1), and do an hg pull followed by an hg up.
> (It's important the this be two separate commands rather than an hg
> pull -u because this is a shared setup: pull -u won't update the local
> working copy if there are no changesets pulled, while hg up updates
> it unconditionally.)  I then apply the patch, and do whatever testing
> and fixing and NEWS and ACK entries I need, including running the full
> tests suite.  When I'm satisfied, I start the merge dance:
> 
> do hg pull; hg up (I could use hg
> pull -u here since I know I haven't done a pull in some other checkout).
> 
> Then I:
> 
> hg diff >temp.patch
> hg pull
> hg up
> hg ci
> cd ../p32
> hg up
> hg merge 3.1
> [run tests applicable to the patch]
> hg ci
> cd ../p33
> hg up
> hg merge 3.2
> [run tests applicable to the patch]
> (if needed:
>  cd ../p27
>  hg up
>  patch -p1 <../p31/temp.patch
>  [fix and test]
>  [if there were a bunch of changes, hg diff >temp.patch]
>  hg ci
> )
> hg pull
> 
> If this pull shows no changesets, I do an hg push.
> 
> The fun part comes if there are changesets.  At this point there
> are two options: go through each of the branches doing an up/merge/ci,
> and then pull/push.  Or, what I actually do:
> 
> hg log
> hg strip <the changeset id of my first checkin>

Uh... wouldn't using the rebase extension make this much easier?

Georg


From g.brandl at gmx.net  Thu Mar 17 11:28:15 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 17 Mar 2011 11:28:15 +0100
Subject: [Python-Dev] Hg:  inter-branch workflow
In-Reply-To: <4D81CD04.4040306@trueblade.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<4D8186E7.7050408@jcea.es>
	<4D81CD04.4040306@trueblade.com>
Message-ID: <ilsno0$v38$2@dough.gmane.org>

Am 17.03.2011 09:57, schrieb Eric Smith:
> On 3/16/2011 11:58 PM, Jesus Cea wrote:
>> I agree that half the changesets are merges now.
> 
> Which has basically stopped me from reviewing changes. I can't quickly 
> tell the real changes from the noise of merges.

Even though every merge changeset mail has "merge" in its subject?

Also, we don't really have more revisions than before: for every merge
now we typically had a svnmerge then.  (Or not, in which case a bugfix
wasn't applied to a branch just because it would have been a bother.)

Georg


From eric at trueblade.com  Thu Mar 17 11:43:20 2011
From: eric at trueblade.com (Eric Smith)
Date: Thu, 17 Mar 2011 06:43:20 -0400
Subject: [Python-Dev] Hg:  inter-branch workflow
In-Reply-To: <ilsno0$v38$2@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<4D8186E7.7050408@jcea.es>	<4D81CD04.4040306@trueblade.com>
	<ilsno0$v38$2@dough.gmane.org>
Message-ID: <4D81E5C8.1060800@trueblade.com>

On 3/17/2011 6:28 AM, Georg Brandl wrote:
> Am 17.03.2011 09:57, schrieb Eric Smith:
>> On 3/16/2011 11:58 PM, Jesus Cea wrote:
>>> I agree that half the changesets are merges now.
>>
>> Which has basically stopped me from reviewing changes. I can't quickly
>> tell the real changes from the noise of merges.
>
> Even though every merge changeset mail has "merge" in its subject?
>
> Also, we don't really have more revisions than before: for every merge
> now we typically had a svnmerge then.  (Or not, in which case a bugfix
> wasn't applied to a branch just because it would have been a bother.)

Maybe it's just the overall volume of the commits during the sprints. 
Plus, I've always thought it would be a good way to sneak malicious code 
in by labeling it as an svnmerge or now hg merge, so I've tried to 
review everything. I find myself slipping behind, and I'm not happy with 
it. I'm just being cranky, and hg is a convenient target.

Just ignore me.

From ncoghlan at gmail.com  Thu Mar 17 11:49:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 17 Mar 2011 06:49:17 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <ilsno0$v38$2@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net> <4D8186E7.7050408@jcea.es>
	<4D81CD04.4040306@trueblade.com> <ilsno0$v38$2@dough.gmane.org>
Message-ID: <AANLkTi=6RMRXhVpVqW47Hgm+UWkt9CdK3Uuq5+boYM8=@mail.gmail.com>

On Thu, Mar 17, 2011 at 6:28 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> Am 17.03.2011 09:57, schrieb Eric Smith:
>> On 3/16/2011 11:58 PM, Jesus Cea wrote:
>>> I agree that half the changesets are merges now.
>>
>> Which has basically stopped me from reviewing changes. I can't quickly
>> tell the real changes from the noise of merges.
>
> Even though every merge changeset mail has "merge" in its subject?

I just set up a mail rule to further split up python-checkins email so
that they all get tagged with "python-checkins-all", while only those
that aren't merges get tagged with "python-checkins". That should make
the latter far less noisy than it has been.

> Also, we don't really have more revisions than before: for every merge
> now we typically had a svnmerge then. ?(Or not, in which case a bugfix
> wasn't applied to a branch just because it would have been a bother.)

I think it has been exacerbated by the flurry of activity from the
sprints. It should be less noticeable once things settle down.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Thu Mar 17 11:50:24 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 17 Mar 2011 06:50:24 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <ilsnk6$v38$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
Message-ID: <AANLkTi=FsnZvV=Z6qQ8UHW3s0x3FHGqXFsid-45VB9LR@mail.gmail.com>

On Thu, Mar 17, 2011 at 6:26 AM, Georg Brandl <g.brandl at gmx.net> wrote:
>
> Uh... wouldn't using the rebase extension make this much easier?

Perhaps, but I/we haven't figured out how to get rebasing to do anything useful.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From baptiste13z at free.fr  Thu Mar 17 12:30:37 2011
From: baptiste13z at free.fr (Baptiste Carvello)
Date: Thu, 17 Mar 2011 12:30:37 +0100
Subject: [Python-Dev] Generating patch files
In-Reply-To: <4D80F836.8070701@v.loewis.de>
References: <4D80F836.8070701@v.loewis.de>
Message-ID: <ilsrc2$kib$1@dough.gmane.org>

Le 16/03/2011 18:49, "Martin v. L?wis" a ?crit :

> Having the revision of cpython to compare against is the
> difficult part;

how about: 'max( ancestors(default) and not outgoing() )' ?


From jcea at jcea.es  Thu Mar 17 13:35:50 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 13:35:50 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317051425.96F40253152@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
Message-ID: <4D820026.9050308@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/03/11 06:14, R. David Murray wrote:
> The fun part comes if there are changesets.  At this point there
> are two options: go through each of the branches doing an up/merge/ci,
> and then pull/push.  Or, what I actually do:
> 
> hg log
> hg strip <the changeset id of my first checkin>
> 
> Then I start from the top of the section above, but starting by reapplying
> my temp.patch.  There's one other detail, though:  because I'm using
> share, the checkouts lose their parent id when I do the strip.  So in
> each checkout I also need to do 'hg debugsetparent <branch>' before
> doing the hg up.
> 
> Clearly, this procedure is not for everyone

Clearly not :).

So you do a "hg strip" and start over again.

The problem with this is that your patch will be applied on top of the
incoming changeset, and your merge will merge that patch too, if the
original pusher haven't done it yet.

Tonight I was thinking about doing a merge inside the branch, to solve
the "+1 branch". Something like transforming:

branch 3.2 -----My patch----incoming patch---
branch 3.x ----------------------------------

to

                    +--------------------------+
                    |                          |
                    |                          v
branch 3.2 -----My patch----incoming patch---merge---
                    |
                    V
branch 3.x --------merge------------------------

So I merge my patch to the other branches, preserving history and
keeping only a single head in the 3.2 branch, that the other developer
must merge to 3.x.

The bad thing about this is that the new head (the merge) will be
assigned to me, but the developer that must merge that head to 3.x is
the other guy.

The other committer could merge her changeset to 3.x and, if my merge
between the two heads is not trivial, she must notice it and do a second
merge.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYIAJplgi5GaxT1NAQJ+XAP+On4tEhylQ7gxtTsfnBNKVG4sLwR697cw
GneD9Mi79cEGN5ANjkfflhUkd9kwrPgpkPjzLOXUHU1t7w5ozrWYkRpPHRM44rPA
7VL/Mm6/OMhYehnebwiCriEu6CcUBUFAQMC8BfOdaUb3EQsGFqhZkH9sHepOg+MQ
ggSv5OGblic=
=h7q8
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Mar 17 13:41:46 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 13:41:46 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D820026.9050308@jcea.es>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>
	<4D820026.9050308@jcea.es>
Message-ID: <4D82018A.209@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/03/11 13:35, Jesus Cea wrote:
> Tonight I was thinking about doing a merge inside the branch, to solve
> the "+1 branch". Something like transforming:

Another thing I was thinking about tonight was... dropping the "+1 head"
banning. Embrace it. Embrace the mercurial way completely.

Each developer is responsible of merging HIS heads. If somebody
"forgets", nothing wrong will happens. And no patch is left behind,
because you can see unmerged patches with "hg heads", and bug their owners.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYIBiplgi5GaxT1NAQLVhQP7Bidj3q+e3LqSWHFR3mcDON1HatygPniQ
e1Y0bNdeUlk3V0sNG9LQcCNIsd475UrwOJOGTvbaLOP4zaXUrNX9x9cIbhOsD9NA
nF8rwDQGucTRHEC8TonG/rGwuOcnFR704ttHU6z0+P/+3lA7/xpl3KL7bK9L/3dS
g3ZZ6LTN8Z8=
=kfVk
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Mar 17 14:02:00 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 14:02:00 +0100
Subject: [Python-Dev] Solaris family and 64 bits compiling
In-Reply-To: <4CEBB15B.1010800@jcea.es>
References: <4CEAB7C9.7020504@jcea.es>	<AANLkTimjMiWLPTAUs4ASg=4wdt-VTKqymy1cdjbHbhp=@mail.gmail.com>	<4CEAC3F0.4040806@jcea.es>	<4CEAC798.5050707@v.loewis.de>	<4CEAE129.2060505@jcea.es>	<4CEAE934.9000106@v.loewis.de>	<4CEAFF9F.5070503@jcea.es>	<4CEB0567.8040500@v.loewis.de>	<4CEB11C6.1010504@jcea.es>	<4CEB6558.3000600@v.loewis.de>
	<4CEBB15B.1010800@jcea.es>
Message-ID: <4D820648.3060104@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/11/10 13:19, Jesus Cea wrote:
> Would be acceptable to change something like:
> 
> """
> add_library_path("/usr/local/lib")
> """
> 
> to something similar to:
> 
> """
> if (platform.uname()=="SunOS") and (platform.architecture()[0]=="64bits") :
>   add_library_path("/usr/local/lib/64")
> else :
>   add_library_path("/usr/local/lib")
> """
> 
> python-dev would consider that change OK?.

Resurrecting an old thread.

I think that, under SunOS and 64 bits, python should install the lib
directory under "/usr/local/lib/64", following the convention in the
platform.

In fact, under OpenIndiana 147, I see this:

"""
- -bash-4.0$ type python
python is /usr/bin/python
- -bash-4.0$ ldd /usr/bin/python
        libpython2.6.so.1.0 =>   /usr/lib/libpython2.6.so.1.0
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libm.so.2 =>     /lib/libm.so.2
- -bash-4.0$ file /usr/bin/python
/usr/bin/python:        ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped, no debugging information available
- -bash-4.0$ ls -lA /usr/lib/|grep python
lrwxrwxrwx  1 root root       19 Oct  1 10:55 libpython2.6.so ->
libpython2.6.so.1.0
- -rwxr-xr-x  1 root bin   1788896 Oct  1 10:55 libpython2.6.so.1.0
lrwxrwxrwx  1 root root       22 Oct  1 10:55 libpython2.6_db.so ->
libpython2.6_db.so.1.0
- -rwxr-xr-x  1 root bin     10372 Oct  1 10:55 libpython2.6_db.so.1.0
drwxr-xr-x 25 root bin       432 Oct  1 10:55 python2.6
- -bash-4.0$ ls -lA /usr/lib/64/|grep python
lrwxrwxrwx 1 root root       19 Oct  1 10:55 libpython2.6.so ->
libpython2.6.so.1.0
- -rwxr-xr-x 1 root bin   2217504 Oct  1 10:55 libpython2.6.so.1.0
lrwxrwxrwx 1 root root       22 Oct  1 10:55 libpython2.6_db.so ->
libpython2.6_db.so.1.0
- -rwxr-xr-x 1 root bin     13336 Oct  1 10:55 libpython2.6_db.so.1.0
- -bash-4.0$ file /usr/lib/64/libpython2.6.so.1.0
/usr/lib/64/libpython2.6.so.1.0:        ELF 64-bit LSB dynamic lib AMD64
Version 1 [SSE2 SSE CMOV], dynamically linked, not stripped, no
debugging information available
"""

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYIGSJlgi5GaxT1NAQIrGAP/fBcLKIdFN+O8jNArCs01m30pQC5rNAhp
hs1mTqlllpGkSQLDeQvcN/ctwFpR8a+mlC4yCFwYFB8CpB9TjilIKRn0RlerfOlw
U0OuhezPTGc75NY95a+x8iZG4FQYytMkv7ClPmyDjG/g68CTS/zArRoKGRA7trZk
+WbsLPK4lhg=
=ScvG
-----END PGP SIGNATURE-----

From brian.curtin at gmail.com  Thu Mar 17 14:10:15 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Thu, 17 Mar 2011 08:10:15 -0500
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D82018A.209@jcea.es>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<4D820026.9050308@jcea.es> <4D82018A.209@jcea.es>
Message-ID: <AANLkTikwbMvc9cY3EOs=QCfg8dLjJWnNY8Ka5PJ=PkSg@mail.gmail.com>

On Thu, Mar 17, 2011 at 07:41, Jesus Cea <jcea at jcea.es> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 17/03/11 13:35, Jesus Cea wrote:
> > Tonight I was thinking about doing a merge inside the branch, to solve
> > the "+1 branch". Something like transforming:
>
> Another thing I was thinking about tonight was... dropping the "+1 head"
> banning. Embrace it. Embrace the mercurial way completely.
>
> Each developer is responsible of merging HIS heads. If somebody
> "forgets", nothing wrong will happens. And no patch is left behind,
> because you can see unmerged patches with "hg heads", and bug their owners.


That just makes more work.

1. I, being new to hg, might not realize my error and just think I'm done. I
move on with life.
2. Someone has to notice the additional head then contact me.
3. Now I have to go back and figure out not only what I did wrong, but what
I have to do to correct it.

In the end, yes, it's my problem, but just because you can shoot yourself in
the foot doesn't mean we need to let people do it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110317/b7a17b20/attachment.html>

From rdmurray at bitdance.com  Thu Mar 17 14:24:26 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 17 Mar 2011 09:24:26 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <ilsnk6$v38$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
Message-ID: <20110317132426.2A4DC200407@kimball.webabinitio.net>

On Thu, 17 Mar 2011 11:26:13 +0100, Georg Brandl <g.brandl at gmx.net> wrote:
> Am 17.03.2011 06:14, schrieb R. David Murray:
> > The fun part comes if there are changesets.  At this point there
> > are two options: go through each of the branches doing an up/merge/ci,
> > and then pull/push.  Or, what I actually do:
> > 
> > hg log
> > hg strip <the changeset id of my first checkin>
> 
> Uh... wouldn't using the rebase extension make this much easier?

As far as I can tell, rebase and share don't mix, because rebase refers
to the branch of the working directory.  I need to rebase all branches
at once.  (That is, I've got a repo with changes on multiple branches,
and I want to rebase the entire repo...shelve all my changes since the
last pull from cpython, do the pull, and then reapply *all* my changes,
on all branches.)

I tried hg pull --rebase, and that was when I had to rebuild my share
setup, because I have no idea what it did, and it didn't look good.
I can't remember *what* didn't look good, though, so perhaps I should
try it again.

It would be great if rebase did work with share, that would make a
push race basically a non-issue for me.

--
R. David Murray                                      www.bitdance.com

From jcea at jcea.es  Thu Mar 17 14:28:51 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 14:28:51 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikwbMvc9cY3EOs=QCfg8dLjJWnNY8Ka5PJ=PkSg@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<4D820026.9050308@jcea.es>
	<4D82018A.209@jcea.es>
	<AANLkTikwbMvc9cY3EOs=QCfg8dLjJWnNY8Ka5PJ=PkSg@mail.gmail.com>
Message-ID: <4D820C93.6010200@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/03/11 14:10, Brian Curtin wrote:
> On Thu, Mar 17, 2011 at 07:41, Jesus Cea <jcea at jcea.es
> <mailto:jcea at jcea.es>> wrote:
[..]
>     Each developer is responsible of merging HIS heads. If somebody
>     "forgets", nothing wrong will happens. And no patch is left behind,
>     because you can see unmerged patches with "hg heads", and bug their
>     owners.
> 
> 
> That just makes more work.
> 
> 1. I, being new to hg, might not realize my error and just think I'm
> done. I move on with life.
> 2. Someone has to notice the additional head then contact me.
> 3. Now I have to go back and figure out not only what I did wrong, but
> what I have to do to correct it.

But thinking that you are done is already a problem now, and everybody
must deal with your unmerged head doing whatever trick to keep your head
apart and don't merge it automatically. That is burdensome and error prone.

I would guess that most people would merge your head themselves, just
for convenience. And that would not be your plan if, for instance, your
patch is being tested/half done/whatever.

Allowing multiple heads, your patch is still there, but nobody suffers
for it. If fact, if you don't care, your patch will sit out of the tip
line and will be not actually integrated in the "tip" code. So you must
merge it, but nobody has to pay any price just because you "forgot" :).

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYIMk5lgi5GaxT1NAQJPaAP/fJv2IKHQycxyfg4xkZaqQe/VbxrpfAeV
l4Q6nQKYXKCFyTGrlh0Hx6Kb8lkdR+H1KOGWQ7tZVDITLvnK4YBYXj6Be4Uoddn8
H/zsJYAHz1rGKmkq1erY5+ejZpQ2BhUnPqz20yomACG/hUCXH+KI7kf5yqZ27fTx
5c/all+SNNg=
=XNMs
-----END PGP SIGNATURE-----

From rdmurray at bitdance.com  Thu Mar 17 14:30:50 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 17 Mar 2011 09:30:50 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTiktF+E2VsbP-exEJRQDUYXw18zFfOM27mgvRAGL@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<AANLkTiktF+E2VsbP-exEJRQDUYXw18zFfOM27mgvRAGL@mail.gmail.com>
Message-ID: <20110317133050.AE51624CB5D@kimball.webabinitio.net>

On Wed, 16 Mar 2011 23:21:37 -0700, "Gregory P. Smith" <greg at krypto.org> wrote:
> why do you use hg diff and patch above rather than hg export and hg import?
> 
> (not implying one is better than the other, learning here...)

We're all learning, even the ones who have used Mercurial before (which
isn't me).

I have been avoiding hg import because my understanding is that it
defaults to commit, and I don't see that it has any advantage over patch
itself.  If export preserves the commit message (I haven't tried export,
didn't even know it existed), then that could indeed be a better way to
go for this particular scenario.  I'll have to check that out.

--
R. David Murray                                      www.bitdance.com

From solipsis at pitrou.net  Thu Mar 17 14:33:00 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 17 Mar 2011 14:33:00 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
Message-ID: <20110317143300.73e699b6@pitrou.net>

On Thu, 17 Mar 2011 09:24:26 -0400
"R. David Murray" <rdmurray at bitdance.com> wrote:
> 
> It would be great if rebase did work with share, that would make a
> push race basically a non-issue for me.

rebase as well as strip destroy some history, meaning some of your
shared clones may end up having their working copy based on a
non-existent changeset. I'm not sure why rebase would be worse that
strip in that regard, though.

Regards

Antoine.



From rdmurray at bitdance.com  Thu Mar 17 14:45:49 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 17 Mar 2011 09:45:49 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D820026.9050308@jcea.es>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<4D820026.9050308@jcea.es>
Message-ID: <20110317134549.5482920044D@kimball.webabinitio.net>

On Thu, 17 Mar 2011 13:35:50 +0100, Jesus Cea <jcea at jcea.es> wrote:
> On 17/03/11 06:14, R. David Murray wrote:
> > Clearly, this procedure is not for everyone
> 
> Clearly not :).
> 
> So you do a "hg strip" and start over again.
> 
> The problem with this is that your patch will be applied on top of the
> incoming changeset, and your merge will merge that patch too, if the
> original pusher haven't done it yet.

Not if the cpython repo is in a fully merged stated.  And if it
isn't, I will wait until it is.  (The update notifications on the
IRC channel help with monitoring this.)

> Tonight I was thinking about doing a merge inside the branch, to solve
> the "+1 branch". Something like transforming:
> 
> branch 3.2 -----My patch----incoming patch---
> branch 3.x ----------------------------------
> 
> to
> 
>                     +--------------------------+
>                     |                          |
>                     |                          v
> branch 3.2 -----My patch----incoming patch---merge---
>                     |
>                     V
> branch 3.x --------merge------------------------
> 
> So I merge my patch to the other branches, preserving history and
> keeping only a single head in the 3.2 branch, that the other developer
> must merge to 3.x.

I cannot at the moment wrap my head around this, and I really have no
desire to do so.  I will keep things as simple as I can for myself,
even if that means I do a little more work (redoing my merge dance on a
push race) or have to wait until the repo is sane again.  (Or, perhaps,
make the repo sane, if the committer who left it in a weird state doesn't
seem to be fixing it; and *then* apply my patch.)

If you leave an unmerged changeset in 3.2, I would consider that to be
leaving the repo in a weird state.  I want to see something like this
after I do a pull and before I do a push:

>hg branches
default                    68637:2b3fb2398f45
2.7                        68630:d8eaeee1c063
3.2                        68636:21fe6d393242 (inactive)
3.1                        68625:d9c3cfd36b58 (inactive)
2.6                        68377:d6626c9fc28d (inactive)
2.5                        68263:7790ad8332ba (inactive)

That is, only 2.7 and 3.2 are active.  This is what is recommended by
the devguide, to my understanding.

--
R. David Murray                                      www.bitdance.com

From reid.kleckner at gmail.com  Thu Mar 17 15:03:36 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Thu, 17 Mar 2011 10:03:36 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317143300.73e699b6@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
Message-ID: <AANLkTin-nLpkuNV5+8xMSVaTq5iJDqsuAJE-pLYAPLYB@mail.gmail.com>

On Thu, Mar 17, 2011 at 9:33 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 17 Mar 2011 09:24:26 -0400
> "R. David Murray" <rdmurray at bitdance.com> wrote:
>>
>> It would be great if rebase did work with share, that would make a
>> push race basically a non-issue for me.
>
> rebase as well as strip destroy some history, meaning some of your
> shared clones may end up having their working copy based on a
> non-existent changeset. I'm not sure why rebase would be worse that
> strip in that regard, though.

I don't think anyone has laid out why destroying history is considered
bad by some, so I thought I'd plug this post:
http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html

Essentially, lets say I have a handful of commits hacking on C code.
While I wrote them, someone changed a C API from under me and pushed
their change.  However, in the last change, I remove my dependence on
this API.  I pull, rebase, rebuild and test.  The tests pass in the
latest commit, so I push.  But now if someone tries to go back to
those intermediate commits (say, searching for the introduction of a
regression), they will find a broken build.

It boils down to when you alter history, at each altered commit you
have some source tree state for which you haven't built and run the
tests.

On the flipside, in the case of a single commit, it's easy to pull,
rebase, rerun tests, and then push.  Running the tests takes a while
so you open yourself to another push race, though.

98% of the time, if you don't actually have merge conflicts, applying
your change over someone else's without testing will work, so I feel
like rebasing a single commit without testing is no big deal.  On the
off chance that it breaks, the buildbots will find out.  Just don't
rebase a whole feature branch of commits, leave the final merge in.

Reid

From solipsis at pitrou.net  Thu Mar 17 15:19:22 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 17 Mar 2011 15:19:22 +0100
Subject: [Python-Dev] cpython: Exercise crashers to ensure they are
 still covering known	error cases
References: <E1Q00eg-0007EX-1m@dinsdale.python.org>
Message-ID: <20110317151922.5d708129@pitrou.net>

On Thu, 17 Mar 2011 01:01:30 +0100
nick.coghlan <python-checkins at python.org> wrote:
> http://hg.python.org/cpython/rev/e3fb176add41
> changeset:   68628:e3fb176add41
> user:        Nick Coghlan <ncoghlan at gmail.com>
> date:        Wed Mar 16 19:52:14 2011 -0400
> summary:
>   Exercise crashers to ensure they are still covering known error cases
> 
> files:
>   Lib/test/crashers/README
>   Lib/test/test_crashers.py

This has broken many buildbots.

Regards

Antoine.



From ncoghlan at gmail.com  Thu Mar 17 15:21:04 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 17 Mar 2011 10:21:04 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTin-nLpkuNV5+8xMSVaTq5iJDqsuAJE-pLYAPLYB@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<AANLkTin-nLpkuNV5+8xMSVaTq5iJDqsuAJE-pLYAPLYB@mail.gmail.com>
Message-ID: <AANLkTi=tRu3v1PyBXM=RmJdoJEwVJ_e46u0hk+7ptz=+@mail.gmail.com>

On Thu, Mar 17, 2011 at 10:03 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote:
> 98% of the time, if you don't actually have merge conflicts, applying
> your change over someone else's without testing will work, so I feel
> like rebasing a single commit without testing is no big deal. ?On the
> off chance that it breaks, the buildbots will find out. ?Just don't
> rebase a whole feature branch of commits, leave the final merge in.

This is one of the reasons we're advocating only collapsed patches in
the main repository, so those untested intermediate revisions don't
exist.

Then the commits will consist of either cohesive changes, or else
minor bookkeeping stuff like fixing NEWS, ACKS or the merge status.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Thu Mar 17 15:39:05 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 17 Mar 2011 10:39:05 -0400
Subject: [Python-Dev] cpython: Exercise crashers to ensure they are
 still covering known error cases
In-Reply-To: <20110317151922.5d708129@pitrou.net>
References: <E1Q00eg-0007EX-1m@dinsdale.python.org>
	<20110317151922.5d708129@pitrou.net>
Message-ID: <AANLkTimhgOCKj5ZbYNfB6DeP_ho+rOKCsnoGWuveceYC@mail.gmail.com>

On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> This has broken many buildbots.

I'm pretty sure I know which one is the problem child, so I just
pushed a fix which should get that one dying reliably on more
platforms.

I also tweaked the test to provide more info as to which crashers are
being tried in verbose mode.

More generally, should we tweak test.script_helper._assert_python to
print the failing arguments as part of the assertion message? (the API
flexibility pretty much rules out the caller passing in an explicit
assertion message)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From rdmurray at bitdance.com  Thu Mar 17 15:50:24 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 17 Mar 2011 10:50:24 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317143300.73e699b6@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
Message-ID: <20110317145024.A8878253264@kimball.webabinitio.net>

On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 17 Mar 2011 09:24:26 -0400
> "R. David Murray" <rdmurray at bitdance.com> wrote:
> > 
> > It would be great if rebase did work with share, that would make a
> > push race basically a non-issue for me.
> 
> rebase as well as strip destroy some history, meaning some of your
> shared clones may end up having their working copy based on a
> non-existent changeset. I'm not sure why rebase would be worse that
> strip in that regard, though.

So maybe the problem was that I tried hg pull --rebase, and that mucked
with the checkout.  If I do a straight hg rebase, will it rebase *all*
the commits in my local repo, regardless of branch?  I know how to fix
the parent of my working dirs, so that isn't an issue.  But do I need
to do an hg rebase for each branch?  The docs made it sound like I did,
but the multi-branch case isn't covered in the scenarios.

--
R. David Murray                                      www.bitdance.com

From ncoghlan at gmail.com  Thu Mar 17 15:51:37 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 17 Mar 2011 10:51:37 -0400
Subject: [Python-Dev] cpython: Exercise crashers to ensure they are
 still covering known error cases
In-Reply-To: <AANLkTimhgOCKj5ZbYNfB6DeP_ho+rOKCsnoGWuveceYC@mail.gmail.com>
References: <E1Q00eg-0007EX-1m@dinsdale.python.org>
	<20110317151922.5d708129@pitrou.net>
	<AANLkTimhgOCKj5ZbYNfB6DeP_ho+rOKCsnoGWuveceYC@mail.gmail.com>
Message-ID: <AANLkTim1rDq-fRxyqVX6phQWLR4H=uULQd4c1Dnh0+pM@mail.gmail.com>

On Thu, Mar 17, 2011 at 10:39 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> This has broken many buildbots.
>
> I'm pretty sure I know which one is the problem child, so I just
> pushed a fix which should get that one dying reliably on more
> platforms.

If my last push didn't fix it, I'm not ignoring the problem, I'm just
in transit for the next ~30 hours or so.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From rdmurray at bitdance.com  Thu Mar 17 15:55:41 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 17 Mar 2011 10:55:41 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTin-nLpkuNV5+8xMSVaTq5iJDqsuAJE-pLYAPLYB@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<AANLkTin-nLpkuNV5+8xMSVaTq5iJDqsuAJE-pLYAPLYB@mail.gmail.com>
Message-ID: <20110317145541.D2A9A253264@kimball.webabinitio.net>

On Thu, 17 Mar 2011 10:03:36 -0400, Reid Kleckner <reid.kleckner at gmail.com> wrote:
> I don't think anyone has laid out why destroying history is considered
> bad by some, so I thought I'd plug this post:
> http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html
> 
> Essentially, lets say I have a handful of commits hacking on C code.
> While I wrote them, someone changed a C API from under me and pushed
> their change.  However, in the last change, I remove my dependence on
> this API.  I pull, rebase, rebuild and test.  The tests pass in the
> latest commit, so I push.  But now if someone tries to go back to
> those intermediate commits (say, searching for the introduction of a
> regression), they will find a broken build.

Yeah, the workflow I'm discussing is about applying individual patches
from the tracker, so there's no history in the above sense to worry about.
When I start working on a feature branch I will be working in a separate
clone and will not rebase.  But I will probably produce a collapsed
patch when I'm ready to apply to mainline, so the concern with rewriting
history won't really apply even there.

--
R. David Murray                                      www.bitdance.com

From solipsis at pitrou.net  Thu Mar 17 16:00:50 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 17 Mar 2011 16:00:50 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317145024.A8878253264@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110317145024.A8878253264@kimball.webabinitio.net>
Message-ID: <20110317160050.509e7d86@pitrou.net>

On Thu, 17 Mar 2011 10:50:24 -0400
"R. David Murray" <rdmurray at bitdance.com> wrote:
> On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Thu, 17 Mar 2011 09:24:26 -0400
> > "R. David Murray" <rdmurray at bitdance.com> wrote:
> > > 
> > > It would be great if rebase did work with share, that would make a
> > > push race basically a non-issue for me.
> > 
> > rebase as well as strip destroy some history, meaning some of your
> > shared clones may end up having their working copy based on a
> > non-existent changeset. I'm not sure why rebase would be worse that
> > strip in that regard, though.
> 
> So maybe the problem was that I tried hg pull --rebase, and that mucked
> with the checkout.

Can't you just fix the checkout then, using "hg up" or even "hg up -C"?
(note: I'm not a rebase expert)

Regards

Antoine.

From guido at python.org  Thu Mar 17 16:04:05 2011
From: guido at python.org (Guido van Rossum)
Date: Thu, 17 Mar 2011 08:04:05 -0700
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
Message-ID: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>

I've thought some more about deprecations and subsequent deletions in
Python 3 (but not read the whole thread -- sorry, I've gotten sick
right after coming home from PyCon).

I think that as long as a significant number of people are still using
Python 2, it may be problematic if we start removing things (or making
other backwards-incompatible changes) from later Python 3 versions
that existed in early Python 3 versions, even if we've followed PEP 5
for the deprecation period. The problem is that --unrelated to this
issue, and for legitimate reasons that we can anticipate-- people will
likely ignore the entire Python 3 line until they're ready, which
means that they may skip the early Python 3 versions once they port to
Python 3.

For comparison, suppose you had some code that supported only Python
2.3. Now, even if you ignored Python 2.4, once you were ready for
porting to 2.5, you'd either notice the deprecations introduced in 2.4
for stuff removed in 2.5 following PEP 5, or you'd slap yourself on
the forehead for not paying attention for such a long time. But you
wouldn't complain that core development moves too fast: You know that
you are too slow.

But if you have a big app finally ported to Python 2.7 (feeling ready
Python 3) but are waiting for your last dependency to be ported to
Python 3, it's quite reasonable to ignore 3.0, 3.1, 3.2, 3.3... Until
you finally attempt to port to 3.4. And if something never got a
deprecation warning in 2.7, and was deprecated in 3.2 (say) and
removed in 3.4, you'd be in for a shock. And this is not necessarily
the kind of stuff that 2to3 does (since the feature existed in 3.0 and
3.1). In some cases 3to2 could even be wrong if we're not careful.

I don't want to be alarmist and I don't want to start another
moratorium, but I do think that we need to be aware of people coming
in "sideways" into Python 3 and missing the nice deprecations. So
let's be conservative with deprecations in the Python 3 line for now.

PS. An example of this came up offline: deprecation and eventual
removal of various frowned-upon unittest methods. But I anticipate
others.

-- 
--Guido van Rossum (python.org/~guido)

From rdmurray at bitdance.com  Thu Mar 17 16:11:35 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 17 Mar 2011 11:11:35 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317160050.509e7d86@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110317145024.A8878253264@kimball.webabinitio.net>
	<20110317160050.509e7d86@pitrou.net>
Message-ID: <20110317151135.CA240253171@kimball.webabinitio.net>

On Thu, 17 Mar 2011 16:00:50 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 17 Mar 2011 10:50:24 -0400
> "R. David Murray" <rdmurray at bitdance.com> wrote:
> > On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > > On Thu, 17 Mar 2011 09:24:26 -0400
> > > "R. David Murray" <rdmurray at bitdance.com> wrote:
> > > > 
> > > > It would be great if rebase did work with share, that would make a
> > > > push race basically a non-issue for me.
> > > 
> > > rebase as well as strip destroy some history, meaning some of your
> > > shared clones may end up having their working copy based on a
> > > non-existent changeset. I'm not sure why rebase would be worse that
> > > strip in that regard, though.
> > 
> > So maybe the problem was that I tried hg pull --rebase, and that mucked
> > with the checkout.
> 
> Can't you just fix the checkout then, using "hg up" or even "hg up -C"?
> (note: I'm not a rebase expert)

Perhaps, at the time I knew even less than I do now about mercurial.
hg up didn't work, but maybe hg up -C would have.  I'll try it again at
some point.

--
R. David Murray                                      www.bitdance.com

From martin at v.loewis.de  Thu Mar 17 17:37:17 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 17 Mar 2011 12:37:17 -0400
Subject: [Python-Dev] Generating patch files
In-Reply-To: <ilsrc2$kib$1@dough.gmane.org>
References: <4D80F836.8070701@v.loewis.de> <ilsrc2$kib$1@dough.gmane.org>
Message-ID: <4D8238BD.8050409@v.loewis.de>

Am 17.03.11 07:30, schrieb Baptiste Carvello:
> Le 16/03/2011 18:49, "Martin v. L?wis" a ?crit :
>
>> Having the revision of cpython to compare against is the
>> difficult part;
>
> how about: 'max( ancestors(default) and not outgoing() )' ?

That fails if there have been later merges with default.

Regards,
Martin

From martin at v.loewis.de  Thu Mar 17 17:40:18 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 17 Mar 2011 12:40:18 -0400
Subject: [Python-Dev] Generating patch files
In-Reply-To: <ilsrc2$kib$1@dough.gmane.org>
References: <4D80F836.8070701@v.loewis.de> <ilsrc2$kib$1@dough.gmane.org>
Message-ID: <4D823972.7080809@v.loewis.de>

Am 17.03.11 07:30, schrieb Baptiste Carvello:
> Le 16/03/2011 18:49, "Martin v. L?wis" a ?crit :
>
>> Having the revision of cpython to compare against is the
>> difficult part;
>
> how about: 'max( ancestors(default) and not outgoing() )' ?

I take back what I just said: it looks good.

Regards,
Martin

From benjamin at python.org  Thu Mar 17 18:45:02 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 17 Mar 2011 12:45:02 -0500
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <ilr3fu$14c$1@dough.gmane.org>
References: <ilr3fu$14c$1@dough.gmane.org>
Message-ID: <AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>

2011/3/16 Thomas Heller <theller at ctypes.org>:
> I would like my committer rights to be retracted.
>
> I have been contributing to Python here and there for 10 years now,
> and it was a pleasant experience.
>
> Unfortunately, since about a year I have lots more things to do, and
> I won't be able to contribute anymore (I have not even started to
> learn mercurial yet). ?Plus I'm still using 2.6 or even 2.5 with my own
> Python projects.

Thank you very much for you work. We'd always be happy to have you back.


-- 
Regards,
Benjamin

From jcea at jcea.es  Thu Mar 17 20:00:29 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 20:00:29 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317134549.5482920044D@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<4D820026.9050308@jcea.es>
	<20110317134549.5482920044D@kimball.webabinitio.net>
Message-ID: <4D825A4D.2080805@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/03/11 14:45, R. David Murray wrote:
> Not if the cpython repo is in a fully merged stated.  And if it
> isn't, I will wait until it is.  (The update notifications on the
> IRC channel help with monitoring this.)

That is repository serialization. The point of HG is to avoid that :-).
Moreover, you are supposing that the original committer will merge "soon".

> If you leave an unmerged changeset in 3.2, I would consider that to be
> leaving the repo in a weird state.

I do agree. But there is nothing enforcing it (push hooks), except
social pressure.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYJaTZlgi5GaxT1NAQJTmgP+IUCRioVAgSEjXtuufj3T6Vl1Q9XQCHej
4R+RTHeojTleWui3W013tS8cmQMa3Y8RSYh5G60kwhSZmdligRcDHWOzuTkemYol
QEv5DDx5dAK/n6XoRA4VWFkVWlw9ZQ8TiiQtvd8h5xiCSxFVTq9NB/LHCQTNzQrW
et/jGUvlkOI=
=oTMp
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Mar 17 20:08:50 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 17 Mar 2011 20:08:50 +0100
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
Message-ID: <4D825C42.9020606@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/03/11 16:04, Guido van Rossum wrote:
> I don't want to be alarmist and I don't want to start another
> moratorium, but I do think that we need to be aware of people coming
> in "sideways" into Python 3 and missing the nice deprecations. So
> let's be conservative with deprecations in the Python 3 line for now.

I can see the motivation for this.

I would suggest to keep deprecating things in 3.x, BUT keeping the
deprecated stuff around (maybe reimplementing them using the new stuff)
until we decide is safe to axe it, instead of the regular 3.x
deprecates, 3.(x+1) cleans up.

In this way we can keep the improvements, while not leaving people just
migrating from 2.7 behind.

The problem will be to decide when to do the cleanup...

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYJcQplgi5GaxT1NAQIeawQAgC3kpmS8RoYoeRn6BRFKTOSEKc6edafY
NVKDZ+NAZzTeYqJcr0symc+9A+5J92fJQq2n6tz1/K2yAzS/m1dudAXK7YIb1Ldc
EwX8JB2osvCgGM5PFefhGOLZ0VrrlWnHQTEviU5GilGNHzCcbEgNj/3BPnEyCNyv
QPmlcyeN+eQ=
=xidU
-----END PGP SIGNATURE-----

From eric at trueblade.com  Thu Mar 17 20:22:36 2011
From: eric at trueblade.com (Eric Smith)
Date: Thu, 17 Mar 2011 15:22:36 -0400
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <4D825C42.9020606@jcea.es>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
	<4D825C42.9020606@jcea.es>
Message-ID: <4D825F7C.4070402@trueblade.com>

On 03/17/2011 03:08 PM, Jesus Cea wrote:
> I would suggest to keep deprecating things in 3.x, BUT keeping the
> deprecated stuff around (maybe reimplementing them using the new stuff)
> until we decide is safe to axe it, instead of the regular 3.x
> deprecates, 3.(x+1) cleans up.

At some point, didn't we say PendingDeprecationWarning in version x, 
DeprecationWarning in x+1, and removal in x+2? That's what I've been 
doing, but it's not what PEP 5 says.

Removing in x+2 would lengthen the timeframe, although I agree with 
Guido that we should be extra careful for the next several years because 
of people moving directory from 2.7 to (say) 3.5.

Eric.

From raymond.hettinger at gmail.com  Thu Mar 17 21:07:58 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Thu, 17 Mar 2011 13:07:58 -0700
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <4D825F7C.4070402@trueblade.com>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
	<4D825C42.9020606@jcea.es> <4D825F7C.4070402@trueblade.com>
Message-ID: <E2FE017C-2095-4901-87E5-8987F990B503@gmail.com>


On Mar 17, 2011, at 12:22 PM, Eric Smith wrote:

> On 03/17/2011 03:08 PM, Jesus Cea wrote:
>> I would suggest to keep deprecating things in 3.x, BUT keeping the
>> deprecated stuff around (maybe reimplementing them using the new stuff)
>> until we decide is safe to axe it, instead of the regular 3.x
>> deprecates, 3.(x+1) cleans up.
> 
> At some point, didn't we say PendingDeprecationWarning in version x, DeprecationWarning in x+1, and removal in x+2? That's what I've been doing, but it's not what PEP 5 says.
> 
> Removing in x+2 would lengthen the timeframe, although I agree with Guido that we should be extra careful for the next several years because of people moving directory from 2.7 to (say) 3.5.

Agreeing with Guido is always a good move :-)

In addition, any new deprecations in Py3.x can be marked with py3k warnings in Py2.7 point releases.  That would give users the maximum chance to make updates before porting, even if they wait five years to migrate to Py3.x.


Raymond

From foom at fuhm.net  Thu Mar 17 21:14:44 2011
From: foom at fuhm.net (James Y Knight)
Date: Thu, 17 Mar 2011 16:14:44 -0400
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <E2FE017C-2095-4901-87E5-8987F990B503@gmail.com>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
	<4D825C42.9020606@jcea.es> <4D825F7C.4070402@trueblade.com>
	<E2FE017C-2095-4901-87E5-8987F990B503@gmail.com>
Message-ID: <A0B030F3-030D-4626-959D-C3E213FF4DDF@fuhm.net>

On Mar 17, 2011, at 4:07 PM, Raymond Hettinger wrote:
> Agreeing with Guido is always a good move :-)
> 
> In addition, any new deprecations in Py3.x can be marked with py3k warnings in Py2.7 point releases.  That would give users the maximum chance to make updates before porting, even if they wait five years to migrate to Py3.x.

And of course, updating 2to3, if possible, would also be appreciated.

James

From db3l.net at gmail.com  Thu Mar 17 22:46:17 2011
From: db3l.net at gmail.com (David Bolen)
Date: Thu, 17 Mar 2011 17:46:17 -0400
Subject: [Python-Dev] cpython: Exercise crashers to ensure they are
	still covering known error cases
References: <E1Q00eg-0007EX-1m@dinsdale.python.org>
	<20110317151922.5d708129@pitrou.net>
	<AANLkTimhgOCKj5ZbYNfB6DeP_ho+rOKCsnoGWuveceYC@mail.gmail.com>
Message-ID: <m2oc59v2s6.fsf@valheru.db3l.homeip.net>

Nick Coghlan <ncoghlan at gmail.com> writes:

> On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> This has broken many buildbots.
>
> I'm pretty sure I know which one is the problem child, so I just
> pushed a fix which should get that one dying reliably on more
> platforms.

On my Windows buildbots it appears as if this change started creating
new debug RTL pop-up windows that my AutoIt script wasn't expecting,
so it probably affected the build step in some subsequent builds too
since the dialogs kept the python_d process live.

I've reset those dialogs and updated my script to automatically
acknowledge these dialogs too going forward, but failures prior to this
point may not be true failures but just fallout from the prior issue.

-- David


From tjreedy at udel.edu  Fri Mar 18 00:23:30 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 Mar 2011 19:23:30 -0400
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
Message-ID: <ilu55g$rei$1@dough.gmane.org>

On 3/17/2011 11:04 AM, Guido van Rossum wrote:
> I've thought some more about deprecations and subsequent deletions in
> Python 3 (but not read the whole thread -- sorry, I've gotten sick
> right after coming home from PyCon).
>
> I think that as long as a significant number of people are still using
> Python 2, it may be problematic if we start removing things (or making
> other backwards-incompatible changes) from later Python 3 versions
> that existed in early Python 3 versions, even if we've followed PEP 5
> for the deprecation period. The problem is that --unrelated to this
> issue, and for legitimate reasons that we can anticipate-- people will
> likely ignore the entire Python 3 line until they're ready, which
> means that they may skip the early Python 3 versions once they port to
> Python 3.
...

> But if you have a big app finally ported to Python 2.7 (feeling ready
> Python 3) but are waiting for your last dependency to be ported to
> Python 3, it's quite reasonable to ignore 3.0, 3.1, 3.2, 3.3... Until
> you finally attempt to port to 3.4. And if something never got a
> deprecation warning in 2.7, and was deprecated in 3.2 (say) and
> removed in 3.4, you'd be in for a shock.

Agreed. As Raymond said, such things *should* get a warning in the next 
release of 2.7, and there will be 'next' 2.7 releases for several years 
to received such updates. As I understand it, the Pyxxx to PyCapsule 
CAPI warning was put in 2.7. If 'py3k' warnings need to be specific, I 
presume that should be possible. People should retest their stuff with 
each micro (bugfix) release anyway.

One counterpoint: everyone should ignore 3.0. And in my opinion, anyone 
who has ignored 3.1 can continue to ignore it. Which is to say, there is 
not so much 3.1 stuff frozen in place but what most everyone using 3.1 
cannot upgrade to 3.2. So jumping from 2.7 to 3.2 should not be much 
harder than to 3.1.

It might be a little harder to say this about 3.2 when 3.3 comes out.

> And this is not necessarily
> the kind of stuff that 2to3 does (since the feature existed in 3.0 and
> 3.1). In some cases 3to2 could even be wrong if we're not careful.

This came up in a tracker issue and I meant to bring it up here before 
this. Since there is no single 'Python 3', 2to3 really needs to be 
2to3.x. So I think the 2to3 that come with 3.x should be specific to 
3.x. Or 2to3 should target the latest 3.x. For instance, 2to3 could make 
the unittest name substitutions now regardless of target version since 
the now preferred names were in 3.0 already.

At the Python level, most of the recent deprecations have either been 
the delayed unittest cleanup or obscure library methods, many of which 
were undocumented and/or meant to be private. One exception is the 
change of .fromstring to .frombytes for a bytes method in one of the 
modules, a change that should have been in 3.0 but was overlooked.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Fri Mar 18 00:28:17 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 Mar 2011 19:28:17 -0400
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>
References: <ilr3fu$14c$1@dough.gmane.org>
	<AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>
Message-ID: <ilu5ee$sk0$1@dough.gmane.org>

On 3/17/2011 1:45 PM, Benjamin Peterson wrote:
> 2011/3/16 Thomas Heller<theller at ctypes.org>:
>> I would like my committer rights to be retracted.
>>
>> I have been contributing to Python here and there for 10 years now,
>> and it was a pleasant experience.
>>
>> Unfortunately, since about a year I have lots more things to do, and
>> I won't be able to contribute anymore (I have not even started to
>> learn mercurial yet).  Plus I'm still using 2.6 or even 2.5 with my own
>> Python projects.
>
> Thank you very much for you work. We'd always be happy to have you back.

In the meanwhile, it would be nice to have another ctypes maintainer, as 
there are several open issues. There is certainly a opening for a new 
person with C experience.

-- 
Terry Jan Reedy


From solipsis at pitrou.net  Fri Mar 18 00:35:03 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 18 Mar 2011 00:35:03 +0100
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
	<ilu55g$rei$1@dough.gmane.org>
Message-ID: <20110318003503.519b7983@pitrou.net>

On Thu, 17 Mar 2011 19:23:30 -0400
Terry Reedy <tjreedy at udel.edu> wrote:
> People should retest their stuff with 
> each micro (bugfix) release anyway.

I'm not sure they should. The point of having micro releases is that
they don't bring any visible change in behaviour - apart from fixing
bugs, that is.

Regards

Antoine.



From jsbueno at python.org.br  Fri Mar 18 00:46:48 2011
From: jsbueno at python.org.br (Joao S. O. Bueno)
Date: Thu, 17 Mar 2011 20:46:48 -0300
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <20110318003503.519b7983@pitrou.net>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
	<ilu55g$rei$1@dough.gmane.org> <20110318003503.519b7983@pitrou.net>
Message-ID: <AANLkTin55-U86vvMLmjZ2SuGrK08gEvacQNikQxygi5S@mail.gmail.com>

On Thu, Mar 17, 2011 at 8:35 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 17 Mar 2011 19:23:30 -0400
> Terry Reedy <tjreedy at udel.edu> wrote:
>> People should retest their stuff with
>> each micro (bugfix) release anyway.
>
> I'm not sure they should. The point of having micro releases is that
> they don't bring any visible change in behaviour - apart from fixing
> bugs, that is.

But IMHO, it would be that, or urging people to use 2to3 from a separate source.
It does not make sense to keep 2to3 frozen while its target moves
forward. Even if
it is decided that things should not be removed, 2to3 should warn of new
deprecations as Python moves into 3.3, 3.4, and beyond.

    js
  -><-
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
>

From larry at hastings.org  Fri Mar 18 01:01:16 2011
From: larry at hastings.org (Larry Hastings)
Date: Thu, 17 Mar 2011 20:01:16 -0400
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <ilu55g$rei$1@dough.gmane.org>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
	<ilu55g$rei$1@dough.gmane.org>
Message-ID: <4D82A0CC.30206@hastings.org>


On 03/17/2011 07:23 PM, Terry Reedy wrote:
> As I understand it, the Pyxxx to PyCapsule CAPI warning was put in 2.7.

In 2.7, the CObject constructor PyCObject_FromVoidPtr() threw a 
PendingDeprecationWarning exception.  Like other warnings, these aren't 
active by default.  This still caused two problems:

    * If you enabled warnings, PyCObject_FromVoidPtr() would return
      NULL.  There is definitely code out there that assumes
      PyCObject_FromVoidPtr() always succeeds and doesn't bother
      checking the pointer it gets back.  That's a bad assumption, the
      code is therefore buggy--but exposing these heretofore unnoticed
      bugs caused problems.
    * If you enabled warnings-as-errors, a PendingDeprecationWarning is
      therefore an error.  In some environments there's a requirement
      that Python must build from scratch and pass its unit test suite
      without errors, with warnings-as-errors turned on.  Python 2.7
      shipped with one module still using PyCObject_FromVoidPtr(),
      bsddb, as it's externally maintained.  (I wanted to change it to
      use PyCapsule for 2.7 but was told to leave it alone.)  bsddb's
      test threw the warning, the warning was an error, now people had a
      problem.

In 2.7.1 PyCObject_FromVoidPtr() now calls PyErr_WarnPy3k().  This means 
it's been promoted to throwing DeprecationWarning!  But that's also 
guarded with Py_Py3kWarningFlag so it's not active unless you ask for 
that too (as with "-3" on the command-line, etc).


/larry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110317/6a4fed82/attachment.html>

From ethan at stoneleaf.us  Fri Mar 18 01:21:55 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 17 Mar 2011 17:21:55 -0700
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <20110318003503.519b7983@pitrou.net>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>	<ilu55g$rei$1@dough.gmane.org>
	<20110318003503.519b7983@pitrou.net>
Message-ID: <4D82A5A3.9090301@stoneleaf.us>

Antoine Pitrou wrote:
> On Thu, 17 Mar 2011 19:23:30 -0400
> Terry Reedy <tjreedy at udel.edu> wrote:
>> People should retest their stuff with 
>> each micro (bugfix) release anyway.
> 
> I'm not sure they should. The point of having micro releases is that
> they don't bring any visible change in behaviour - apart from fixing
> bugs, that is.

Even bug fixes can have unintended consequences (in other words, new 
bugs).   Or perhaps there is work-around code in place that now causes 
problems because there is nothing to work around.

Even if neither of those two cases is true, why would you not want the 
warm, fuzzy feeling of contentment *knowing* that your code runs on the 
latest Python?

~Ethan~

From guido at python.org  Fri Mar 18 03:49:04 2011
From: guido at python.org (Guido van Rossum)
Date: Thu, 17 Mar 2011 19:49:04 -0700
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
	<AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
Message-ID: <AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>

On Wed, Mar 16, 2011 at 5:02 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Mar 15, 2011 at 11:34 PM, Guido van Rossum <guido at python.org> wrote:
>>
>> Can you be specific? What is different between those RFCs?
>
> I finally got around to trying to backport some of the additional
> urljoin tests from http://bugs.python.org/issue1500504 (specifically,
> the additional ones Mike Brown provided), but got tripped up by the
> behavioural changes between the earlier RFCs and RFC 3986 regarding
> the way ".." is handled.

Ah, got it.

> Even in test_urlparse, a bunch of the normative tests from RFC 3986
> are commented out because they fail (by design) when run through
> urllib.parse.urljoin. Some of the additional tests also fail because
> our urljoin implementation has a whitelist of schemas that support
> relative references, whereas 3986 expects relative references to work
> for unknown schemas as well.
>
> There's actually quite a few more terminology changes as well (as
> Senthil pointed out in his email), but it was specifically the failing
> test cases for urljoin semantics that bit me again yesterday.
>
> The problem is that it is quite a lot of work to get fully general URI
> parsing to work correctly, but the overlap with legacy URL parsing is
> large enough that many (most?) use cases in practice work just fine
> with the older RFC semantics.

So would having two different API functions, one legacy and one
conforming, be a problem? Ideally the conforming API's name would not
be something lame like urllib2 but something timeless. :-)

-- 
--Guido van Rossum (python.org/~guido)

From orsenthil at gmail.com  Fri Mar 18 04:19:36 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Fri, 18 Mar 2011 11:19:36 +0800
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
	<AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
	<AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
Message-ID: <20110318031936.GA25061@kevin>

Nick Coghlan wrote:
> > The problem is that it is quite a lot of work to get fully general URI
> > parsing to work correctly, but the overlap with legacy URL parsing is
> > large enough that many (most?) use cases in practice work just fine
> > with the older RFC semantics.

Yes. We can have API which strictly confirms to latest RFC by
definition, but the problem is there is code out there which 'expects'
the parsing behavior remain unchanged so that their existing code does
not break. And with parsing behavior unchanged means conforming to
older RFC parsing rules.

The solution seems to be extra function or an flag in the urlparse
method which will exhibit the more latest behavior.

Guido wrote:

> So would having two different API functions, one legacy and one
> conforming, be a problem? Ideally the conforming API's name would not
> be something lame like urllib2 but something timeless. :-)

:-) Should blame Jeremy for that name!. But urllib2 is long replaced
by urllib.parse, urllib.request and urllib.response. Considering how
you remember urllib2, I think it's name has stood the test of time.

But seriously, I think an additional function or additional flag in the
current functions/method in the parse module is sufficient than going
for another module.

-- 
Senthil

From guido at python.org  Fri Mar 18 04:38:42 2011
From: guido at python.org (Guido van Rossum)
Date: Thu, 17 Mar 2011 20:38:42 -0700
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <20110318031936.GA25061@kevin>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
	<AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
	<AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
	<20110318031936.GA25061@kevin>
Message-ID: <AANLkTikKmqY9ju4zmKR=fGHwqQUtBnGm1oCOGjyLCx5R@mail.gmail.com>

On Thu, Mar 17, 2011 at 8:19 PM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> Nick Coghlan wrote:
>> > The problem is that it is quite a lot of work to get fully general URI
>> > parsing to work correctly, but the overlap with legacy URL parsing is
>> > large enough that many (most?) use cases in practice work just fine
>> > with the older RFC semantics.
>
> Yes. We can have API which strictly confirms to latest RFC by
> definition, but the problem is there is code out there which 'expects'
> the parsing behavior remain unchanged so that their existing code does
> not break. And with parsing behavior unchanged means conforming to
> older RFC parsing rules.
>
> The solution seems to be extra function or an flag in the urlparse
> method which will exhibit the more latest behavior.
>
> Guido wrote:
>
>> So would having two different API functions, one legacy and one
>> conforming, be a problem? Ideally the conforming API's name would not
>> be something lame like urllib2 but something timeless. :-)
>
> :-) Should blame Jeremy for that name!. But urllib2 is long replaced
> by urllib.parse, urllib.request and urllib.response. Considering how
> you remember urllib2, I think it's name has stood the test of time.

It stood out like a sore thumb. :-)

> But seriously, I think an additional function or additional flag in the
> current functions/method in the parse module is sufficient than going
> for another module.

I vote for a new function, not a flag. (Others can explain my rule of
thumb against flag arguments whose values are nearly always
constants.)

-- 
--Guido van Rossum (python.org/~guido)

From steve at pearwood.info  Fri Mar 18 07:06:50 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Fri, 18 Mar 2011 17:06:50 +1100
Subject: [Python-Dev] Conflict between time docs and timeit
Message-ID: <4D82F67A.3070600@pearwood.info>

I see that the documentation for the time module has this to say about 
time.clock:

     On Unix, return the current processor time as a floating
     point number expressed in seconds. The precision, and in fact
     the very definition of the meaning of ?processor time?,
     depends on that of the C function of the same name, but in
     any case, this is the function to use for benchmarking Python
     or timing algorithms.


In contrast, timeit defaults to using time.time() under all operating 
systems other than Windows, and says:

     ...on Windows, clock() has microsecond granularity but
     time()'s granularity is 1/60th of a second; on Unix,
     clock() has 1/100th of a second granularity and time()
     is much more precise.


Should timeit be changed, or the docs, or have I missed something?


-- 
Steven

From rosslagerwall at gmail.com  Fri Mar 18 07:15:20 2011
From: rosslagerwall at gmail.com (Ross Lagerwall)
Date: Fri, 18 Mar 2011 08:15:20 +0200
Subject: [Python-Dev] Documentation not being updated
In-Reply-To: <AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
	<AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
	<AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
Message-ID: <1300428920.1608.15.camel@hobo>

A change that I made (a49bda5ff3d5) to the documentation 3 days ago does
not appear to have propagated to

http://docs.python.org/dev/library/multiprocessing.html

Building the docs locally shows the change. Am I doing something wrong?

Cheers
Ross


From g.brandl at gmx.net  Fri Mar 18 09:15:45 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 18 Mar 2011 09:15:45 +0100
Subject: [Python-Dev] Documentation not being updated
In-Reply-To: <1300428920.1608.15.camel@hobo>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
	<AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
	<AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
	<1300428920.1608.15.camel@hobo>
Message-ID: <ilv4bg$upe$1@dough.gmane.org>

On 18.03.2011 07:15, Ross Lagerwall wrote:
> A change that I made (a49bda5ff3d5) to the documentation 3 days ago does
> not appear to have propagated to
> 
> http://docs.python.org/dev/library/multiprocessing.html
> 
> Building the docs locally shows the change. Am I doing something wrong?

Nope, that was me.  Should be fixed now.

Georg


From martin at v.loewis.de  Fri Mar 18 03:31:36 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 17 Mar 2011 22:31:36 -0400
Subject: [Python-Dev] Generating patch files
In-Reply-To: <AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>
References: <4D80F836.8070701@v.loewis.de>
	<AANLkTimt8UsZkbqKgKs2QjOQVhXZNtYbLDQiNpuCwWai@mail.gmail.com>
Message-ID: <4D82C408.5070300@v.loewis.de>

> I get "unknown revision" (listing the full expression text) when using
> Mercurial 1.6.3 (default version in Ubuntu 10.10).

Based on Baptiste's approach, I propose the script below to compute a 
patch. Please report whether it works for you.

Regards,
Martin

#!/bin/sh
base=`hg log --template {rev} -r'max(ancestors(default)-outgoing())'`
hg diff -r$base


From solipsis at pitrou.net  Fri Mar 18 12:07:04 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 18 Mar 2011 12:07:04 +0100
Subject: [Python-Dev] Conflict between time docs and timeit
References: <4D82F67A.3070600@pearwood.info>
Message-ID: <20110318120704.7613dd07@pitrou.net>

On Fri, 18 Mar 2011 17:06:50 +1100
Steven D'Aprano <steve at pearwood.info> wrote:
> 
> In contrast, timeit defaults to using time.time() under all operating 
> systems other than Windows, and says:
> 
>      ...on Windows, clock() has microsecond granularity but
>      time()'s granularity is 1/60th of a second; on Unix,
>      clock() has 1/100th of a second granularity and time()
>      is much more precise.
> 
> 
> Should timeit be changed, or the docs, or have I missed something?

Well, time.clock() is less precise (in terms of timing granularity),
but more accurate if the system if not otherwise idle - since it will
report CPU time for the current process instead of total wall clock
time, removing the direct contribution of other processes.

That said, benchmarks on a loaded system are inaccurate anyway, because
of other factors (such as cost of context switching, TLB and cache
misses, concurrent memory access from several processes).

I think a rule-of-thumb can be made:
- for short-running benchmarks (a couple of seconds at most), use
  time.time() which will give increased precision
- for longer-running benchmarks, use time.clock() (or the system's
  "time" command) which will avoid counting the runtime of other
  processes

timeit is in the former case.

(this is all about Unix, by the way)

Regards

Antoine.



From regebro at gmail.com  Fri Mar 18 12:34:07 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 18 Mar 2011 12:34:07 +0100
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <ilu55g$rei$1@dough.gmane.org>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
	<ilu55g$rei$1@dough.gmane.org>
Message-ID: <AANLkTimN0jUWOnLA8Ain8d4jJ_8=NdbBuk1KNXu6q9_2@mail.gmail.com>

On Fri, Mar 18, 2011 at 00:23, Terry Reedy <tjreedy at udel.edu> wrote:
> People should retest their stuff with each micro
> (bugfix) release anyway.

That would be creating an insane burden on library developers.
Besides, I've so far not have things break between micro releases, it
must be very unusual.

That said, when running Python 2.7 with -3 in preparation for a port,
you should of course use the latest version, that has the most
warnings.

//Lennart

From jnoller at gmail.com  Fri Mar 18 14:59:19 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 18 Mar 2011 09:59:19 -0400
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <ilu5ee$sk0$1@dough.gmane.org>
References: <ilr3fu$14c$1@dough.gmane.org>
	<AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>
	<ilu5ee$sk0$1@dough.gmane.org>
Message-ID: <AANLkTi=0xBN5pLMoKG7oZbrmF4j4WmExqTDcOq3Bbnu9@mail.gmail.com>

On Thu, Mar 17, 2011 at 7:28 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 3/17/2011 1:45 PM, Benjamin Peterson wrote:
>>
>> 2011/3/16 Thomas Heller<theller at ctypes.org>:
>>>
>>> I would like my committer rights to be retracted.
>>>
>>> I have been contributing to Python here and there for 10 years now,
>>> and it was a pleasant experience.
>>>
>>> Unfortunately, since about a year I have lots more things to do, and
>>> I won't be able to contribute anymore (I have not even started to
>>> learn mercurial yet). ?Plus I'm still using 2.6 or even 2.5 with my own
>>> Python projects.
>>
>> Thank you very much for you work. We'd always be happy to have you back.
>
> In the meanwhile, it would be nice to have another ctypes maintainer, as
> there are several open issues. There is certainly a opening for a new person
> with C experience.
>

I'll ask doug hellmann if this is something we can do a blog post
about on the PSF blog. Having another ctypes expert is pretty critical
(everyone I know is using it)

From doug.hellmann at gmail.com  Fri Mar 18 15:17:43 2011
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Fri, 18 Mar 2011 10:17:43 -0400
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <AANLkTi=0xBN5pLMoKG7oZbrmF4j4WmExqTDcOq3Bbnu9@mail.gmail.com>
References: <ilr3fu$14c$1@dough.gmane.org>
	<AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>
	<ilu5ee$sk0$1@dough.gmane.org>
	<AANLkTi=0xBN5pLMoKG7oZbrmF4j4WmExqTDcOq3Bbnu9@mail.gmail.com>
Message-ID: <06649710-64BF-4881-93BE-D52D14F04BB3@gmail.com>


On Mar 18, 2011, at 9:59 AM, Jesse Noller wrote:

> On Thu, Mar 17, 2011 at 7:28 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 3/17/2011 1:45 PM, Benjamin Peterson wrote:
>>> 
>>> 2011/3/16 Thomas Heller<theller at ctypes.org>:
>>>> 
>>>> I would like my committer rights to be retracted.
>>>> 
>>>> I have been contributing to Python here and there for 10 years now,
>>>> and it was a pleasant experience.
>>>> 
>>>> Unfortunately, since about a year I have lots more things to do, and
>>>> I won't be able to contribute anymore (I have not even started to
>>>> learn mercurial yet).  Plus I'm still using 2.6 or even 2.5 with my own
>>>> Python projects.
>>> 
>>> Thank you very much for you work. We'd always be happy to have you back.
>> 
>> In the meanwhile, it would be nice to have another ctypes maintainer, as
>> there are several open issues. There is certainly a opening for a new person
>> with C experience.
>> 
> 
> I'll ask doug hellmann if this is something we can do a blog post
> about on the PSF blog. Having another ctypes expert is pretty critical
> (everyone I know is using it)

This does seem like a good use of the blog. The team is working on setting up the dev blog, and I expect to have something up soon. This can be our second post there (the first being an introduction).

Is there a "job description" for a ctypes maintainer? Where should we send people for more details about this request? We would link to the dev guide and this mailing list, but is there something more specific?

Doug


From alexander.belopolsky at gmail.com  Fri Mar 18 15:18:06 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 18 Mar 2011 10:18:06 -0400
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <ilu5ee$sk0$1@dough.gmane.org>
References: <ilr3fu$14c$1@dough.gmane.org>
	<AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>
	<ilu5ee$sk0$1@dough.gmane.org>
Message-ID: <AANLkTinqDn8ftGLF7mGqiFNRtOA9jysnpm=RdvvjdoSV@mail.gmail.com>

On Thu, Mar 17, 2011 at 7:28 PM, Terry Reedy <tjreedy at udel.edu> wrote:
..
> In the meanwhile, it would be nice to have another ctypes maintainer, as
> there are several open issues. There is certainly a opening for a new person
> with C experience.

I am not ready to volunteer as maintainer, but if ctypes is not listed
as my area of interest, it should be.  Unfortunately, since
Misc/maintainers.rst is gone, I am not sure how to edit maintainers
list.   I wonder if someone could replace Misc/maintainers.rst with a
short document with the proper link and describing how to edit the
list at the new location.

From solipsis at pitrou.net  Fri Mar 18 15:34:48 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 18 Mar 2011 15:34:48 +0100
Subject: [Python-Dev] Please retract my committer rights
References: <ilr3fu$14c$1@dough.gmane.org>
	<AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>
	<ilu5ee$sk0$1@dough.gmane.org>
	<AANLkTinqDn8ftGLF7mGqiFNRtOA9jysnpm=RdvvjdoSV@mail.gmail.com>
Message-ID: <20110318153448.3d39f1fd@pitrou.net>

On Fri, 18 Mar 2011 10:18:06 -0400
Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> On Thu, Mar 17, 2011 at 7:28 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> ..
> > In the meanwhile, it would be nice to have another ctypes maintainer, as
> > there are several open issues. There is certainly a opening for a new person
> > with C experience.
> 
> I am not ready to volunteer as maintainer, but if ctypes is not listed
> as my area of interest, it should be.  Unfortunately, since
> Misc/maintainers.rst is gone, I am not sure how to edit maintainers
> list.

Just modify experts.rst in http://hg.python.org/devguide/.

Regards

Antoine.



From orsenthil at gmail.com  Fri Mar 18 15:48:14 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Fri, 18 Mar 2011 22:48:14 +0800
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <06649710-64BF-4881-93BE-D52D14F04BB3@gmail.com>
References: <ilr3fu$14c$1@dough.gmane.org>
	<AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>
	<ilu5ee$sk0$1@dough.gmane.org>
	<AANLkTi=0xBN5pLMoKG7oZbrmF4j4WmExqTDcOq3Bbnu9@mail.gmail.com>
	<06649710-64BF-4881-93BE-D52D14F04BB3@gmail.com>
Message-ID: <20110318144814.GA2341@kevin>

Doug Hellmann wrote:

> On Mar 18, 2011, at 9:59 AM, Jesse Noller wrote:
> 
> > Terry Reedy wrote:
> >> there are several open issues. There is certainly a opening for a new person
> >> with C experience.
> > 
> > about on the PSF blog. Having another ctypes expert is pretty
> > critical (everyone I know is using it)
> 
> Is there a "job description" for a ctypes maintainer? Where should

I am the only one who is finding the following phrases amusing?!

- "opening for a new person"
- "another ctypes expert is pretty critical"
- "job description"
- "send people to.."

-- 
Senthil

From rdmurray at bitdance.com  Fri Mar 18 16:40:37 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 18 Mar 2011 11:40:37 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D825A4D.2080805@jcea.es>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<4D820026.9050308@jcea.es>
	<20110317134549.5482920044D@kimball.webabinitio.net>
	<4D825A4D.2080805@jcea.es>
Message-ID: <20110318154037.F223A2353F4@kimball.webabinitio.net>

On Thu, 17 Mar 2011 20:00:29 +0100, Jesus Cea <jcea at jcea.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 17/03/11 14:45, R. David Murray wrote:
> > Not if the cpython repo is in a fully merged stated.  And if it
> > isn't, I will wait until it is.  (The update notifications on the
> > IRC channel help with monitoring this.)
> 
> That is repository serialization. The point of HG is to avoid that :-).

I don't think your second sentence is true.  *Allowing* non-serialized
repositories, yes; but I don't think our desire to have a relatively
serialized main repository is somehow anti-mercurial :)

We may change our mind at some point, of course.

--
R. David Murray                                      www.bitdance.com

From ysj.ray at gmail.com  Fri Mar 18 15:32:15 2011
From: ysj.ray at gmail.com (Ray Allen)
Date: Fri, 18 Mar 2011 22:32:15 +0800
Subject: [Python-Dev] PEP 395: Module Aliasing
In-Reply-To: <4D7E6F3D.306@voidspace.org.uk>
References: <AANLkTi=6U1U5RTokAC1Ra0EF5_7hR_doPDJqfcdxAEUe@mail.gmail.com>
	<20110304155959.2231.1503113061.divmod.xquotient.144@localhost.localdomain>
	<AANLkTinyA_tOo6qg4-0dhyiCLUzh0s8UqHf4RZTMHH_9@mail.gmail.com>
	<20110304120743.22042ded@neurotica.wooz.org>
	<4D7122D1.30505@voidspace.org.uk>
	<20110309213119.9F22D3A4116@sparrow.telecommunity.com>
	<4D7E6F3D.306@voidspace.org.uk>
Message-ID: <AANLkTi=pVd1R89YTnNn5hX_1NXBzwiZbasG8YRT=wbqN@mail.gmail.com>

    Just now I was trapped by the "Importing the main module twice" problem
for a while, and then I searched on web and go into here. It seems pretty
good to fix this problem, since it is really difficult to find out this
problem. Anyway, a module should not be initialized twice which results in
that each of the objects defined in this module has TWO instances
in separate modules. Accidentally people will mix up them together.

-- 
Ray Allen
Best wishes!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110318/cfc9eabd/attachment.html>

From status at bugs.python.org  Fri Mar 18 18:07:17 2011
From: status at bugs.python.org (Python tracker)
Date: Fri, 18 Mar 2011 18:07:17 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20110318170717.BF2F31CC5D@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2011-03-11 - 2011-03-18)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    2723 (+14)
  closed 20655 (+115)
  total  23378 (+129)

Open issues with patches: 1164 


Issues opened (60)
==================

#11452: test_trace not symlink install clean
http://bugs.python.org/issue11452  reopened by sdaoden

#11468: Improve unittest basic example in the doc
http://bugs.python.org/issue11468  opened by ezio.melotti

#11469: Fix resource warning in test_trailers
http://bugs.python.org/issue11469  opened by brian.curtin.test

#11470: Flag inappropriate uses of callable class attributes
http://bugs.python.org/issue11470  opened by twouters

#11471: If without else generates redundant jump
http://bugs.python.org/issue11471  opened by eltoder

#11472: upload command fails to read auth information from .pypirc
http://bugs.python.org/issue11472  opened by jaraco

#11473: upload command no longer accepts repository by section name
http://bugs.python.org/issue11473  opened by jaraco

#11474: url2pathname() handling of '/C|/' on Windows
http://bugs.python.org/issue11474  opened by calvin

#11477: Bug in code dispatching based on internal slots
http://bugs.python.org/issue11477  opened by terry.reedy

#11479: Add discussion of trailing slash in raw string to tutorial
http://bugs.python.org/issue11479  opened by r.david.murray

#11480: Cannot copy a class with a metaclass other than type
http://bugs.python.org/issue11480  opened by durban

#11481: The copy module already uses copyreg
http://bugs.python.org/issue11481  opened by durban

#11485: Default SDK value on MacOSX needs changing
http://bugs.python.org/issue11485  opened by ronaldoussoren

#11486: Add option to not install into /Applications
http://bugs.python.org/issue11486  opened by ronaldoussoren

#11487: build_installer.py should avoid relying on a young Python
http://bugs.python.org/issue11487  opened by pitrou

#11489: json.dumps not parsable by json.loads (on Linux only)
http://bugs.python.org/issue11489  opened by Brian.Merrell

#11491: dbm.open(..., flag="n") raises dbm.error if file exists and is
http://bugs.python.org/issue11491  opened by denversc

#11492: email.header.Header doesn't fold headers
http://bugs.python.org/issue11492  opened by kitterma

#11493: Add python.exe-gdb.py to .hgignore
http://bugs.python.org/issue11493  opened by santa4nt

#11494: Confusing error message from warnings.warn
http://bugs.python.org/issue11494  opened by Gerrit.Holl

#11504: test_subprocess failure
http://bugs.python.org/issue11504  opened by pitrou

#11505: string.py increased test coverage
http://bugs.python.org/issue11505  opened by Alicia.Arlen

#11506: b'' += gives SystemError instead of SyntaxError
http://bugs.python.org/issue11506  opened by ncoghlan

#11508: Virtual Interfaces cause uuid._find_mac to raise a ValueError 
http://bugs.python.org/issue11508  opened by kfrazier

#11511: Proposal for exposing proxy bypass settings in ProxyHandler
http://bugs.python.org/issue11511  opened by rswilson

#11512: adding test suite for cgitb
http://bugs.python.org/issue11512  opened by robquad

#11513: chained exception/incorrect exception from tarfile.open on a n
http://bugs.python.org/issue11513  opened by ev

#11549: Rewrite peephole to work on AST
http://bugs.python.org/issue11549  opened by eltoder

#11551: test_dummy_thread.py test coverage improvement
http://bugs.python.org/issue11551  opened by denversc

#11552: Confusing error message when hook module cannot be loaded
http://bugs.python.org/issue11552  opened by cournape

#11553: Docs for: import, packages, site.py, .pth files
http://bugs.python.org/issue11553  opened by gwideman

#11557: Increase coverage in logging module
http://bugs.python.org/issue11557  opened by nessita

#11558: Raise a more helpful exception in email.message.Message.attach
http://bugs.python.org/issue11558  opened by michael.henry

#11561: "coverage" of Python regrtest cannot see initial import of lib
http://bugs.python.org/issue11561  opened by brandon-rhodes

#11563: test_urllibnet is triggering a ResourceWarning
http://bugs.python.org/issue11563  opened by brett.cannon

#11564: pickle not 64-bit ready
http://bugs.python.org/issue11564  opened by nyevik

#11566: hypot define in pyconfig.h clashes with g++'s cmath
http://bugs.python.org/issue11566  opened by schmir

#11568: docstring of select.epoll.register() is wrong
http://bugs.python.org/issue11568  opened by thekorn

#11571: Turtle window pops under the terminal on OSX
http://bugs.python.org/issue11571  opened by belopolsky

#11572: bring Lib/copy.py to 100% coverage
http://bugs.python.org/issue11572  opened by brandon-rhodes

#11573: Improve Unicode Documentation with Known Caveats
http://bugs.python.org/issue11573  opened by aronacher

#11574: Unicode Fallback Encoding on Python 3.3
http://bugs.python.org/issue11574  opened by aronacher

#11575: addresses.txt file leaks into search engines
http://bugs.python.org/issue11575  opened by skip.montanaro

#11576: timedelta subtraction glitch on big timedelta values
http://bugs.python.org/issue11576  opened by enrico

#11579: python 2.5 does not build from hg - looks for subversion keywo
http://bugs.python.org/issue11579  opened by orsenthil

#11580: Add width and precision formatters to PyBytes_FromFormatV()
http://bugs.python.org/issue11580  opened by ysj.ray

#11582: Boilerplate code replaced in Python/ceval.c
http://bugs.python.org/issue11582  opened by knicker.kicker

#11583: os.path.isdir() is slow on windows
http://bugs.python.org/issue11583  opened by eli.bendersky

#11584: email.decode_header fails if msg.__getitem__ returns  Header o
http://bugs.python.org/issue11584  opened by sdaoden

#11585: Documentation 1.8 shows Python 2 example
http://bugs.python.org/issue11585  opened by cdarke

#11586: Python/pythonrun.c: get_codec_name() typo
http://bugs.python.org/issue11586  opened by ysj.ray

#11587: METH_KEYWORDS alone gives "METH_OLDARGS is no longer supported
http://bugs.python.org/issue11587  opened by cdarke

#11588: Add "necessarily inclusive" groups to argparse
http://bugs.python.org/issue11588  opened by John.Didion

#11589: Additional tests for email module
http://bugs.python.org/issue11589  opened by michael.henry

#11590: email quoprimime.py patch for header_encode of empty string, d
http://bugs.python.org/issue11590  opened by michael.henry

#11591: "python -S" should be robust against e.g. "from site import ad
http://bugs.python.org/issue11591  opened by carljm

#11593: Add encoding parameter to logging.basicConfig
http://bugs.python.org/issue11593  opened by Samuel.Michaels

#11594: 2to3 tool does not preserve line-endings
http://bugs.python.org/issue11594  opened by bialix

#11595: Miscellaneous bugs in cfg_to_args() utility function
http://bugs.python.org/issue11595  opened by erik.bray

#11596: import error in test_fileinput.py when bz2 not installed (wind
http://bugs.python.org/issue11596  opened by DaMutz



Most recent 15 issues with no replies (15)
==========================================

#11596: import error in test_fileinput.py when bz2 not installed (wind
http://bugs.python.org/issue11596

#11595: Miscellaneous bugs in cfg_to_args() utility function
http://bugs.python.org/issue11595

#11594: 2to3 tool does not preserve line-endings
http://bugs.python.org/issue11594

#11590: email quoprimime.py patch for header_encode of empty string, d
http://bugs.python.org/issue11590

#11589: Additional tests for email module
http://bugs.python.org/issue11589

#11588: Add "necessarily inclusive" groups to argparse
http://bugs.python.org/issue11588

#11586: Python/pythonrun.c: get_codec_name() typo
http://bugs.python.org/issue11586

#11580: Add width and precision formatters to PyBytes_FromFormatV()
http://bugs.python.org/issue11580

#11566: hypot define in pyconfig.h clashes with g++'s cmath
http://bugs.python.org/issue11566

#11558: Raise a more helpful exception in email.message.Message.attach
http://bugs.python.org/issue11558

#11553: Docs for: import, packages, site.py, .pth files
http://bugs.python.org/issue11553

#11552: Confusing error message when hook module cannot be loaded
http://bugs.python.org/issue11552

#11551: test_dummy_thread.py test coverage improvement
http://bugs.python.org/issue11551

#11512: adding test suite for cgitb
http://bugs.python.org/issue11512

#11511: Proposal for exposing proxy bypass settings in ProxyHandler
http://bugs.python.org/issue11511



Most recent 15 issues waiting for review (15)
=============================================

#11596: import error in test_fileinput.py when bz2 not installed (wind
http://bugs.python.org/issue11596

#11595: Miscellaneous bugs in cfg_to_args() utility function
http://bugs.python.org/issue11595

#11593: Add encoding parameter to logging.basicConfig
http://bugs.python.org/issue11593

#11591: "python -S" should be robust against e.g. "from site import ad
http://bugs.python.org/issue11591

#11590: email quoprimime.py patch for header_encode of empty string, d
http://bugs.python.org/issue11590

#11589: Additional tests for email module
http://bugs.python.org/issue11589

#11582: Boilerplate code replaced in Python/ceval.c
http://bugs.python.org/issue11582

#11580: Add width and precision formatters to PyBytes_FromFormatV()
http://bugs.python.org/issue11580

#11579: python 2.5 does not build from hg - looks for subversion keywo
http://bugs.python.org/issue11579

#11572: bring Lib/copy.py to 100% coverage
http://bugs.python.org/issue11572

#11568: docstring of select.epoll.register() is wrong
http://bugs.python.org/issue11568

#11563: test_urllibnet is triggering a ResourceWarning
http://bugs.python.org/issue11563

#11561: "coverage" of Python regrtest cannot see initial import of lib
http://bugs.python.org/issue11561

#11557: Increase coverage in logging module
http://bugs.python.org/issue11557

#11551: test_dummy_thread.py test coverage improvement
http://bugs.python.org/issue11551



Top 10 most discussed issues (10)
=================================

#11477: Bug in code dispatching based on internal slots
http://bugs.python.org/issue11477  18 msgs

#11572: bring Lib/copy.py to 100% coverage
http://bugs.python.org/issue11572  12 msgs

#11320: Can't call Py_SetPath() on pointer returned by Py_GetPath()
http://bugs.python.org/issue11320  11 msgs

#11487: build_installer.py should avoid relying on a young Python
http://bugs.python.org/issue11487  11 msgs

#11549: Rewrite peephole to work on AST
http://bugs.python.org/issue11549  11 msgs

#5863: bz2.BZ2File should accept other file-like objects. (issue42740
http://bugs.python.org/issue5863   9 msgs

#11088: IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input / raw
http://bugs.python.org/issue11088   9 msgs

#10775: assertRaises as a context manager should accept a 'msg' keywor
http://bugs.python.org/issue10775   8 msgs

#11055: OS X IDLE 3.2 Save As menu accelerator opens two Save windows
http://bugs.python.org/issue11055   7 msgs

#11467: urlparse.urlsplit() regression for paths consisting of digits
http://bugs.python.org/issue11467   7 msgs



Issues closed (112)
===================

#1099: Mac compile fails with pydebug and framework enabled
http://bugs.python.org/issue1099  closed by ronaldoussoren

#5421: Irritating error message by socket's sendto method
http://bugs.python.org/issue5421  closed by pitrou

#5673: Add timeout option to subprocess.Popen
http://bugs.python.org/issue5673  closed by rnk

#5870: subprocess.DEVNULL
http://bugs.python.org/issue5870  closed by rosslagerwall

#6873: posix_lchown: possible overflow of uid, gid
http://bugs.python.org/issue6873  closed by gregory.p.smith

#7013: Httplib read routine is not tolerant to not well-formed chunke
http://bugs.python.org/issue7013  closed by flox

#8516: Speed difference between Python 2.5 and 2.6 during filling bsd
http://bugs.python.org/issue8516  closed by jcea

#9047: Python 2.7rc2 includes -isysroot twice on each gcc command lin
http://bugs.python.org/issue9047  closed by ronaldoussoren

#9298: binary email attachment issue with base64 encoding
http://bugs.python.org/issue9298  closed by r.david.murray

#9362: Make exit/quit hint more novice friendly
http://bugs.python.org/issue9362  closed by brian.curtin

#9384: Tkinter windows pop under the terminal in OSX
http://bugs.python.org/issue9384  closed by ronaldoussoren

#10237: failure in Barrier tests
http://bugs.python.org/issue10237  closed by krisvale

#10242: unittest's assertItemsEqual() method makes too many assumption
http://bugs.python.org/issue10242  closed by ezio.melotti

#10288: Remove deprecated C "character" handling macros ISUPPER() etc
http://bugs.python.org/issue10288  closed by dmalcolm

#10812: Add some posix functions
http://bugs.python.org/issue10812  closed by rosslagerwall

#10885: multiprocessing docs
http://bugs.python.org/issue10885  closed by rosslagerwall

#10979: setUpClass exception causes explosion with "-b"
http://bugs.python.org/issue10979  closed by python-dev

#11090: Doc errors for unittest in Python 3.1
http://bugs.python.org/issue11090  closed by ezio.melotti

#11131: decimal.py: plus/minus with ROUND_FLOOR
http://bugs.python.org/issue11131  closed by mark.dickinson

#11133: inspect.getattr_static code execution
http://bugs.python.org/issue11133  closed by python-dev

#11148: Crash and error message from Python VM
http://bugs.python.org/issue11148  closed by ronaldoussoren

#11179: ccbench doesn't work on 3.1/2.7
http://bugs.python.org/issue11179  closed by pitrou

#11216: email.message.Message set_charset does not encode properly?
http://bugs.python.org/issue11216  closed by r.david.murray

#11243: email/message.py str conversion
http://bugs.python.org/issue11243  closed by r.david.murray

#11257: asyncore stores unnecessary object references
http://bugs.python.org/issue11257  closed by giampaolo.rodola

#11283: incorrect pattern in the re module docs for conditional regex
http://bugs.python.org/issue11283  closed by orsenthil

#11289: smtplib context manager
http://bugs.python.org/issue11289  closed by barry

#11312: Confusing sentence in file.readline() doc
http://bugs.python.org/issue11312  closed by benjamin.peterson

#11329: PyEval_InitThreads() not safe before Py_Initialize()
http://bugs.python.org/issue11329  closed by pitrou

#11350: __setitem__()'s problem of dbm.dumb object pointed out by comm
http://bugs.python.org/issue11350  closed by r.david.murray

#11401: email.header error during .flatten()
http://bugs.python.org/issue11401  closed by r.david.murray

#11403: Add some generated files in PC/ to .hgignore.
http://bugs.python.org/issue11403  closed by pitrou

#11407: unittest.TestCase.run should return result
http://bugs.python.org/issue11407  closed by python-dev

#11426: CSV examples can't close their files
http://bugs.python.org/issue11426  closed by eli.bendersky

#11432: webbrowser.open on unix fails.
http://bugs.python.org/issue11432  closed by gregory.p.smith

#11442: list_directory() in SimpleHTTPServer.py should add charset=...
http://bugs.python.org/issue11442  closed by orsenthil

#11446: Incorrect PEP link in Language Reference section 7.7
http://bugs.python.org/issue11446  closed by ezio.melotti

#11462: Peephole creates duplicate and unused constants
http://bugs.python.org/issue11462  closed by rhettinger

#11464: Call Mac API Crash via ctypes
http://bugs.python.org/issue11464  closed by ronaldoussoren

#11475: trunc in documentation of numbers.Real should math.trunc
http://bugs.python.org/issue11475  closed by benjamin.peterson

#11476: StreamHandler code broken by change of parameter name
http://bugs.python.org/issue11476  closed by vinay.sajip

#11478: Docs list nonexistant PyObject_CopyToObject function
http://bugs.python.org/issue11478  closed by pitrou

#11482: Float Plus Error
http://bugs.python.org/issue11482  closed by mark.dickinson

#11483: python fails to follow symlinks on windows
http://bugs.python.org/issue11483  closed by brian.curtin

#11484: `with_traceback` in 2.7 docs but not implemented
http://bugs.python.org/issue11484  closed by ezio.melotti

#11488: Add writelines test coverage in tempfile
http://bugs.python.org/issue11488  closed by r.david.murray

#11490: subprocess test_leaking_fds_on_error fails if last directory i
http://bugs.python.org/issue11490  closed by r.david.murray

#11495: Remove OSF support completelly
http://bugs.python.org/issue11495  closed by jcea

#11496: test_readline fails when readline was installed after running 
http://bugs.python.org/issue11496  closed by r.david.murray

#11497: Devguide: re-run configure in Unix setup step after installing
http://bugs.python.org/issue11497  closed by brett.cannon

#11498: test_zipfile.test_unicode_filenames should be skipped of no zl
http://bugs.python.org/issue11498  closed by python-dev

#11499: 2to3: reassignment to bool is left in the file
http://bugs.python.org/issue11499  closed by benjamin.peterson

#11500: Fixes failing urllib2 proxy tests on OSX
http://bugs.python.org/issue11500  closed by ronaldoussoren

#11501: distutils.archive_util should handle absence of zlib module
http://bugs.python.org/issue11501  closed by pitrou

#11502: assignment of winreg module to another name causes NameError
http://bugs.python.org/issue11502  closed by jaraco

#11503: Expand test coverage in posixpath
http://bugs.python.org/issue11503  closed by python-dev

#11507: Misspelled exercises
http://bugs.python.org/issue11507  closed by ezio.melotti

#11509: fileinput module unit test coverage improvements
http://bugs.python.org/issue11509  closed by brian.curtin

#11510: Peephole breaks set unpacking
http://bugs.python.org/issue11510  closed by rhettinger

#11514: Misspelled access
http://bugs.python.org/issue11514  closed by ezio.melotti

#11515: Misspelled actually
http://bugs.python.org/issue11515  closed by ezio.melotti

#11516: Misspelled additionally
http://bugs.python.org/issue11516  closed by ezio.melotti

#11517: Misspelled aforementioned
http://bugs.python.org/issue11517  closed by ezio.melotti

#11518: Misspelled algorithm 2
http://bugs.python.org/issue11518  closed by ezio.melotti

#11519: Misspelled algorithm
http://bugs.python.org/issue11519  closed by ezio.melotti

#11520: Misspelled alignment 2
http://bugs.python.org/issue11520  closed by ezio.melotti

#11521: Misspelled alignment3
http://bugs.python.org/issue11521  closed by ezio.melotti

#11522: Misspelled alignment 4
http://bugs.python.org/issue11522  closed by ezio.melotti

#11523: Misspelled alignment 5
http://bugs.python.org/issue11523  closed by ezio.melotti

#11524: Misspelled alignment 6
http://bugs.python.org/issue11524  closed by ezio.melotti

#11525: Misspelled alignment
http://bugs.python.org/issue11525  closed by ezio.melotti

#11526: Misspelled along
http://bugs.python.org/issue11526  closed by ezio.melotti

#11527: Misspelled ambiguous
http://bugs.python.org/issue11527  closed by ezio.melotti

#11528: Misspelled anonymously
http://bugs.python.org/issue11528  closed by ezio.melotti

#11529: Misspelled application 2
http://bugs.python.org/issue11529  closed by ezio.melotti

#11530: Misspelled application
http://bugs.python.org/issue11530  closed by ezio.melotti

#11531: Misspelled applications
http://bugs.python.org/issue11531  closed by ezio.melotti

#11532: Misspelled arbitrary 2
http://bugs.python.org/issue11532  closed by ezio.melotti

#11533: Misspelled arbitrary
http://bugs.python.org/issue11533  closed by ezio.melotti

#11534: Misspelled architecture, control
http://bugs.python.org/issue11534  closed by ezio.melotti

#11535: Misspelled architecture
http://bugs.python.org/issue11535  closed by ezio.melotti

#11536: Misspelled arguments 2
http://bugs.python.org/issue11536  closed by ezio.melotti

#11537: Misspelled arguments
http://bugs.python.org/issue11537  closed by ezio.melotti

#11538: Misspelled assign
http://bugs.python.org/issue11538  closed by ezio.melotti

#11539: Misspelled associated
http://bugs.python.org/issue11539  closed by ezio.melotti

#11540: Misspelled assume
http://bugs.python.org/issue11540  closed by ezio.melotti

#11541: Misspelled attribute
http://bugs.python.org/issue11541  closed by ezio.melotti

#11542: Misspelled augmented
http://bugs.python.org/issue11542  closed by ezio.melotti

#11543: Misspelled available, instances
http://bugs.python.org/issue11543  closed by ezio.melotti

#11544: Misspelled avoid
http://bugs.python.org/issue11544  closed by ezio.melotti

#11545: Misspelled backtracking
http://bugs.python.org/issue11545  closed by ezio.melotti

#11546: Misspelled between
http://bugs.python.org/issue11546  closed by ezio.melotti

#11547: Misspelled builtin
http://bugs.python.org/issue11547  closed by ezio.melotti

#11548: Passing format= to unpack_archive fails
http://bugs.python.org/issue11548  closed by python-dev

#11550: Fix ResourceWarning in test_pulldom
http://bugs.python.org/issue11550  closed by brett.cannon

#11554: Port email module's test_email_codecs.py to Python 3
http://bugs.python.org/issue11554  closed by r.david.murray

#11555: email.Message.as_string no longer mangles "From " (doc fix)
http://bugs.python.org/issue11555  closed by r.david.murray

#11556: email.Message.get_payload can handle bytes payloads (minor doc
http://bugs.python.org/issue11556  closed by r.david.murray

#11559: Increase test coverage in dis module
http://bugs.python.org/issue11559  closed by python-dev

#11560: Expand test coverage in shutil
http://bugs.python.org/issue11560  closed by python-dev

#11562: += on list inside a tuple raises TypeError but succeeds anyway
http://bugs.python.org/issue11562  closed by ncoghlan

#11565: Another (the last) group of misspellings
http://bugs.python.org/issue11565  closed by ezio.melotti

#11567: http.server error message format
http://bugs.python.org/issue11567  closed by orsenthil

#11569: multiprocessing/darwin: sysctl(8) mislocation
http://bugs.python.org/issue11569  closed by ronaldoussoren

#11570: Lib/test/test_distutils.py tries to mix 32 and 64 bits object 
http://bugs.python.org/issue11570  closed by python-dev

#11577: testcase for exception binhex.Error
http://bugs.python.org/issue11577  closed by python-dev

#11578: Increase test coverage for timeit.py
http://bugs.python.org/issue11578  closed by r.david.murray

#11581: buildbot error when pushing to 2.5 branch?
http://bugs.python.org/issue11581  closed by r.david.murray

#11592: Compilation warnings in os module
http://bugs.python.org/issue11592  closed by rosslagerwall

#1681333: email.header unicode fix
http://bugs.python.org/issue1681333  closed by r.david.murray

#1162477: Parsing failures in parsedate_tz
http://bugs.python.org/issue1162477  closed by r.david.murray

#1038909: pydoc method documentation lookup enhancement
http://bugs.python.org/issue1038909  closed by brian.curtin

From jcea at jcea.es  Fri Mar 18 19:20:18 2011
From: jcea at jcea.es (Jesus Cea)
Date: Fri, 18 Mar 2011 19:20:18 +0100
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <4D82A0CC.30206@hastings.org>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>	<ilu55g$rei$1@dough.gmane.org>
	<4D82A0CC.30206@hastings.org>
Message-ID: <4D83A262.5070503@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18/03/11 01:01, Larry Hastings wrote:
> In 2.7.1 PyCObject_FromVoidPtr() now calls PyErr_WarnPy3k().  This means
> it's been promoted to throwing DeprecationWarning!  But that's also
> guarded with Py_Py3kWarningFlag so it's not active unless you ask for
> that too (as with "-3" on the command-line, etc).

I kind of remember doing this change myself. Since no 2.8 is planned, it
seemed sensible to mark PyCObject as a py3k warning.

PS: I am the maintainer of (externally developed lib) bsddb, but the
2.7.0 behaviour actually broke some other extensions out there (when
used with warnings active). Details in the tracker, somewhere. I am
offline now, can't use the browser.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYOiYplgi5GaxT1NAQLtRgQAjdB1yvFmqJLGqqzEaCK+ll5jx277b751
RGshITBFUkd+OLVErP9nEKUMsHvr/nl7BIjhZotKH31g6Hl0KiuGPHHkPNKYGs4y
5XsHaZ2a9/qkgt1wa12gLsHmxsrIICGKPzcPUQs6GVJGBuppGtDkc18iODOCd6eC
kkDcc/sFHUI=
=mXiX
-----END PGP SIGNATURE-----

From tjreedy at udel.edu  Fri Mar 18 23:55:21 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 18 Mar 2011 18:55:21 -0400
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <20110318144814.GA2341@kevin>
References: <ilr3fu$14c$1@dough.gmane.org>	<AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>	<ilu5ee$sk0$1@dough.gmane.org>	<AANLkTi=0xBN5pLMoKG7oZbrmF4j4WmExqTDcOq3Bbnu9@mail.gmail.com>	<06649710-64BF-4881-93BE-D52D14F04BB3@gmail.com>
	<20110318144814.GA2341@kevin>
Message-ID: <im0nso$frm$1@dough.gmane.org>

On 3/18/2011 10:48 AM, Senthil Kumaran wrote:
> Doug Hellmann wrote:
>
>> On Mar 18, 2011, at 9:59 AM, Jesse Noller wrote:
>>
>>> Terry Reedy wrote:
>>>> there are several open issues. There is certainly a opening for a new person
>>>> with C experience.
>>>
>>> about on the PSF blog. Having another ctypes expert is pretty
>>> critical (everyone I know is using it)
>>
>> Is there a "job description" for a ctypes maintainer? Where should
>
> I am the only one who is finding the following phrases amusing?!
>
> - "opening for a new person"
> - "another ctypes expert is pretty critical"
> - "job description"
> - "send people to.."

Sorry, you humor is too subtle for me ;-). I find 42 unattended open 
ctypes issues a bit sad. IDLE is a bit worse, I think, but I plan on 
helping to make a dent on *that* in the next year.

-- 
Terry Jan Reedy


From python at mrabarnett.plus.com  Sat Mar 19 00:04:58 2011
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 18 Mar 2011 23:04:58 +0000
Subject: [Python-Dev] Adding function checks to regex
Message-ID: <4D83E519.1060008@mrabarnett.plus.com>

Some of those who are relative new to regexes sometimes ask how to write 
a regex which checks that a number is in a range or is a valid date. 
Although this may be possible, it certainly isn't easy.

 From what I've read, Perl has a way of including code in a regex, but I 
don't think that's a good idea

However, it occurs to me that there may be a case for being able to call 
a supplied function to perform such checking.

Borrowing some syntax from Perl, it could look like this:

     def range_check(m):
         return 1 <= int(m.group()) <= 10

     numbers = regex.findall(r"\b\d+\b(*CALL)", text, call=range_check)

The regex module would match as normal until the "(*CALL)", at which 
point it would call the function. If the function returns True, the 
matching continues (and succeeds); if the function returns False, the 
matching backtracks (and fails).

The function would be passed a match object.

An extension, again borrowing the syntax from Perl, could include a tag 
like this:

     numbers = regex.findall(r"\b\d+\b(*CALL:RANGE)", text, 
call=range_check)

The tag would be passed to the function so that it could support 
multiple checks.

Alternatively, a tag could always be passed; if no tag is provided then 
None would be passed instead.

There's also the additional possibility of providing a dict of functions 
instead and using the tag to select the function which should be called.

I'd be interested in your opinions.

From tjreedy at udel.edu  Sat Mar 19 00:15:19 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 18 Mar 2011 19:15:19 -0400
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <06649710-64BF-4881-93BE-D52D14F04BB3@gmail.com>
References: <ilr3fu$14c$1@dough.gmane.org>	<AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>	<ilu5ee$sk0$1@dough.gmane.org>	<AANLkTi=0xBN5pLMoKG7oZbrmF4j4WmExqTDcOq3Bbnu9@mail.gmail.com>
	<06649710-64BF-4881-93BE-D52D14F04BB3@gmail.com>
Message-ID: <im0p25$lp1$1@dough.gmane.org>

On 3/18/2011 10:17 AM, Doug Hellmann wrote:

> Is there a "job description" for a ctypes maintainer?

I would say a knowledge of C and C implementations, a tolerance of OS 
idiosyncrasies, and an interest bridging C to Python and in particular 
the way ctpes does it. (I intentionally omitted general Python knowledge.)

 > Where should we send people for more details about this request?

The tracker:
http://bugs.python.org/issue?@template=search&status=1
select Components: ctypes, enter, and take a look at some of the 42 (at 
the moment) issues. Or, also select Keyword: patch (17 issues now) to 
look at and possibly review some of the existing patches.

For more help, post here.

-- 
Terry Jan Reedy


From ncoghlan at gmail.com  Sat Mar 19 01:32:04 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Mar 2011 10:32:04 +1000
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTikKmqY9ju4zmKR=fGHwqQUtBnGm1oCOGjyLCx5R@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
	<AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
	<AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
	<20110318031936.GA25061@kevin>
	<AANLkTikKmqY9ju4zmKR=fGHwqQUtBnGm1oCOGjyLCx5R@mail.gmail.com>
Message-ID: <AANLkTi=F-ojn7hpJfVFUVhAC8XKDKAhX-pxXox5ANHi7@mail.gmail.com>

On Fri, Mar 18, 2011 at 1:38 PM, Guido van Rossum <guido at python.org> wrote:
>> But seriously, I think an additional function or additional flag in the
>> current functions/method in the parse module is sufficient than going
>> for another module.
>
> I vote for a new function, not a flag. (Others can explain my rule of
> thumb against flag arguments whose values are nearly always
> constants.)

When I was last tinkering with this (i.e. when I wrote that proof of
concept module for a fully RFC 3986 compliant parser), I actually
replaced the "urljoin" name with "resolve_uriref".

So a minimal change to provide at least RFC 3986 joining semantics
would be to add a "resolve_uriref" that provides the RFC 3986 join
semantics, while "urljoin" would continue to follow the older RFCs.

There are additional niceties in RFC 3986 that it would be good to
provide, but that's when you start to get to the scale of a completely
new URI parsing module.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From larry at hastings.org  Sat Mar 19 01:32:24 2011
From: larry at hastings.org (Larry Hastings)
Date: Fri, 18 Mar 2011 17:32:24 -0700
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <4D83A262.5070503@jcea.es>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>	<ilu55g$rei$1@dough.gmane.org>	<4D82A0CC.30206@hastings.org>
	<4D83A262.5070503@jcea.es>
Message-ID: <4D83F998.405@hastings.org>


On 03/18/2011 11:20 AM, Jesus Cea wrote:
> I kind of remember doing this change myself. Since no 2.8 is planned, it
> seemed sensible to mark PyCObject as a py3k warning.

It's all fine by me, and yeah I think you did the change.  I'm sure it 
wasn't me.

> PS: I am the maintainer of (externally developed lib) bsddb, but the
> 2.7.0 behaviour actually broke some other extensions out there (when
> used with warnings active). Details in the tracker, somewhere. I am
> offline now, can't use the browser.

My point in bringing up bsddb was that it was the only remaining use of 
CObject that shipped with Python 2.7.  Yes, certainly there were 
externally-maintained extensions that went to pieces when 
PyCObject_FromVoidPtr() started returning NULL.  But internally, 2.7 
switched entirely to capsules, except for bsddb.

Cheers,


/larry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110318/221c16fd/attachment.html>

From guido at python.org  Sat Mar 19 01:38:33 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 18 Mar 2011 17:38:33 -0700
Subject: [Python-Dev] Adding function checks to regex
In-Reply-To: <4D83E519.1060008@mrabarnett.plus.com>
References: <4D83E519.1060008@mrabarnett.plus.com>
Message-ID: <AANLkTimEO-nqh7TS+KZZntH9zm+T+4AgAHycnUOEM9ak@mail.gmail.com>

Probably best discussed on python-ideas...

On Fri, Mar 18, 2011 at 4:04 PM, MRAB <python at mrabarnett.plus.com> wrote:
> Some of those who are relative new to regexes sometimes ask how to write a
> regex which checks that a number is in a range or is a valid date. Although
> this may be possible, it certainly isn't easy.
>
> From what I've read, Perl has a way of including code in a regex, but I
> don't think that's a good idea
>
> However, it occurs to me that there may be a case for being able to call a
> supplied function to perform such checking.
>
> Borrowing some syntax from Perl, it could look like this:
>
> ? ?def range_check(m):
> ? ? ? ?return 1 <= int(m.group()) <= 10
>
> ? ?numbers = regex.findall(r"\b\d+\b(*CALL)", text, call=range_check)
>
> The regex module would match as normal until the "(*CALL)", at which point
> it would call the function. If the function returns True, the matching
> continues (and succeeds); if the function returns False, the matching
> backtracks (and fails).
>
> The function would be passed a match object.
>
> An extension, again borrowing the syntax from Perl, could include a tag like
> this:
>
> ? ?numbers = regex.findall(r"\b\d+\b(*CALL:RANGE)", text, call=range_check)
>
> The tag would be passed to the function so that it could support multiple
> checks.
>
> Alternatively, a tag could always be passed; if no tag is provided then None
> would be passed instead.
>
> There's also the additional possibility of providing a dict of functions
> instead and using the tag to select the function which should be called.
>
> I'd be interested in your opinions.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)

From guido at python.org  Sat Mar 19 01:41:46 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 18 Mar 2011 17:41:46 -0700
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTi=F-ojn7hpJfVFUVhAC8XKDKAhX-pxXox5ANHi7@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
	<AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
	<AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
	<20110318031936.GA25061@kevin>
	<AANLkTikKmqY9ju4zmKR=fGHwqQUtBnGm1oCOGjyLCx5R@mail.gmail.com>
	<AANLkTi=F-ojn7hpJfVFUVhAC8XKDKAhX-pxXox5ANHi7@mail.gmail.com>
Message-ID: <AANLkTikusCuYsBj51gW4rpoGf4R-mpa67T5iVPRVN+79@mail.gmail.com>

On Fri, Mar 18, 2011 at 5:32 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Mar 18, 2011 at 1:38 PM, Guido van Rossum <guido at python.org> wrote:
>>> But seriously, I think an additional function or additional flag in the
>>> current functions/method in the parse module is sufficient than going
>>> for another module.
>>
>> I vote for a new function, not a flag. (Others can explain my rule of
>> thumb against flag arguments whose values are nearly always
>> constants.)
>
> When I was last tinkering with this (i.e. when I wrote that proof of
> concept module for a fully RFC 3986 compliant parser), I actually
> replaced the "urljoin" name with "resolve_uriref".
>
> So a minimal change to provide at least RFC 3986 joining semantics
> would be to add a "resolve_uriref" that provides the RFC 3986 join
> semantics, while "urljoin" would continue to follow the older RFCs.

It's a bit long though -- users tend to flock to the shorter name.

> There are additional niceties in RFC 3986 that it would be good to
> provide, but that's when you start to get to the scale of a completely
> new URI parsing module.

Really. Do they still call them URIs? :-)

-- 
--Guido van Rossum (python.org/~guido)

From glyph at twistedmatrix.com  Sat Mar 19 01:57:42 2011
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Fri, 18 Mar 2011 20:57:42 -0400
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <AANLkTikusCuYsBj51gW4rpoGf4R-mpa67T5iVPRVN+79@mail.gmail.com>
References: <AANLkTinCVoOd1u7fjsDBOJyNgjjonK_2EJdxrJY8Fz2_@mail.gmail.com>
	<AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
	<AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
	<AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
	<20110318031936.GA25061@kevin>
	<AANLkTikKmqY9ju4zmKR=fGHwqQUtBnGm1oCOGjyLCx5R@mail.gmail.com>
	<AANLkTi=F-ojn7hpJfVFUVhAC8XKDKAhX-pxXox5ANHi7@mail.gmail.com>
	<AANLkTikusCuYsBj51gW4rpoGf4R-mpa67T5iVPRVN+79@mail.gmail.com>
Message-ID: <DF4CFCB2-8AC0-4469-B807-0C71461EE0E6@twistedmatrix.com>


On Mar 18, 2011, at 8:41 PM, Guido van Rossum wrote:

> Really. Do they still call them URIs? :-)

Well, by RFC 398*7* they're calling them IRIs instead.  'irilib', perhaps? ;-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110318/ed0d0faa/attachment.html>

From orsenthil at gmail.com  Sat Mar 19 02:16:51 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Sat, 19 Mar 2011 09:16:51 +0800
Subject: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
In-Reply-To: <DF4CFCB2-8AC0-4469-B807-0C71461EE0E6@twistedmatrix.com>
References: <AANLkTimVCQzYg_BLmzDh+ZjvC_WJx=yGkKjie4yHJbok@mail.gmail.com>
	<AANLkTi=AKUq_jLXN0NEnbexw8Hu=MxWge9NRNe1q8Y2a@mail.gmail.com>
	<AANLkTi=bgyCqgSKW-nERjZ2=L3-wr8gdJ9jDPivi7f+-@mail.gmail.com>
	<AANLkTinmM_uD1jc=VdJaHJKfX13gDrsBMDhOF0sy2OE0@mail.gmail.com>
	<AANLkTimg2X8s6m3dg3oY=sBkNp=AZHEW-a4zYQXyz2Dz@mail.gmail.com>
	<20110318031936.GA25061@kevin>
	<AANLkTikKmqY9ju4zmKR=fGHwqQUtBnGm1oCOGjyLCx5R@mail.gmail.com>
	<AANLkTi=F-ojn7hpJfVFUVhAC8XKDKAhX-pxXox5ANHi7@mail.gmail.com>
	<AANLkTikusCuYsBj51gW4rpoGf4R-mpa67T5iVPRVN+79@mail.gmail.com>
	<DF4CFCB2-8AC0-4469-B807-0C71461EE0E6@twistedmatrix.com>
Message-ID: <20110319011651.GC2596@kevin>

On Fri, Mar 18, 2011 at 08:57:42PM -0400, Glyph Lefkowitz wrote:

> Well, by RFC 398*7* they're calling them IRIs instead.  'irilib', perhaps? ;-)

Yes, and it involves huge lot of unicode character handling /parsing
rules in Resource Indentifiers. 'irilib' sounds like a good plan.

-- 
Senthil

From ncoghlan at gmail.com  Sat Mar 19 03:14:43 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Mar 2011 12:14:43 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D825A4D.2080805@jcea.es>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<4D820026.9050308@jcea.es>
	<20110317134549.5482920044D@kimball.webabinitio.net>
	<4D825A4D.2080805@jcea.es>
Message-ID: <AANLkTikYEhFMWCvo5khXJipGKgMO485MAX6BBoUT05g_@mail.gmail.com>

On Fri, Mar 18, 2011 at 5:00 AM, Jesus Cea <jcea at jcea.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 17/03/11 14:45, R. David Murray wrote:
>> Not if the cpython repo is in a fully merged stated. ?And if it
>> isn't, I will wait until it is. ?(The update notifications on the
>> IRC channel help with monitoring this.)
>
> That is repository serialization. The point of HG is to avoid that :-).

The easier merging in Hg means that it *is* easy to work offline, or
even against separate clones. Trying to keep a clean history in the
main repository so committer responsibilities are tracked correctly is
still a reasonable goal.

> Moreover, you are supposing that the original committer will merge "soon".

What may actually be better for buildbot experimentation purposes is
to allow us to request running a build-and-test cycle from branches in
*any* of the repositories hosted on hg.python.org, rather than having
to push experimental changes to the main line of development.

(i.e. start moving towards more of a style of development where code
doesn't land in the main repository until it has been vetted by the
buildbots *first*).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From greg.ewing at canterbury.ac.nz  Sat Mar 19 03:28:52 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 19 Mar 2011 15:28:52 +1300
Subject: [Python-Dev] Module version variable
In-Reply-To: <ilrgoc$efd$1@dough.gmane.org>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
Message-ID: <4D8414E4.7060001@canterbury.ac.nz>

Tres Seaver wrote:

> I'm not even sure why you would want __version__ in 99% of modules:  in
> the ordinary cases, a module's version should be either the Python
> version (for a module shipped in the stdlib), or the release of the
> distribution which shipped it.

It's useful to be able to find out the version of a module
you're using at run time so you can cope with API changes.

I had a case just recently where the behaviour of something
in pywin32 changed between one release and the next. I looked
for an attribute called 'version' or something similar to
test, but couldn't find anything.

+1 on having a standard place to look for version info.

-- 
Greg

From guido at python.org  Sat Mar 19 03:40:43 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 18 Mar 2011 19:40:43 -0700
Subject: [Python-Dev] Module version variable
In-Reply-To: <4D8414E4.7060001@canterbury.ac.nz>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
Message-ID: <AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>

On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Tres Seaver wrote:
>
>> I'm not even sure why you would want __version__ in 99% of modules: ?in
>> the ordinary cases, a module's version should be either the Python
>> version (for a module shipped in the stdlib), or the release of the
>> distribution which shipped it.
>
> It's useful to be able to find out the version of a module
> you're using at run time so you can cope with API changes.
>
> I had a case just recently where the behaviour of something
> in pywin32 changed between one release and the next. I looked
> for an attribute called 'version' or something similar to
> test, but couldn't find anything.
>
> +1 on having a standard place to look for version info.

I believe __version__ *is* the standard (like __author__). IIRC it was
proposed by Ping. I think this convention is so old that there isn't a
PEP for it. So yes, we might as well write it down. But it's really
nothing new.

-- 
--Guido van Rossum (python.org/~guido)

From ncoghlan at gmail.com  Sat Mar 19 03:42:54 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Mar 2011 12:42:54 +1000
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
Message-ID: <AANLkTinPNhwaBdzOEX4cetn+xQVE-d01YBXm=qj5x0z_@mail.gmail.com>

On Fri, Mar 18, 2011 at 1:04 AM, Guido van Rossum <guido at python.org> wrote:
> I don't want to be alarmist and I don't want to start another
> moratorium, but I do think that we need to be aware of people coming
> in "sideways" into Python 3 and missing the nice deprecations. So
> let's be conservative with deprecations in the Python 3 line for now.

Adding new deprecations is probably OK, but we should definitely be
very cautious about following through with *removal* of deprecated
items.

I was pondering the specific case of PyCapsule on the way home, and it
actually took quite a series of events for it to blow up in Lennart's
face the way it did at the sprints:

1. We really should have made a PEP about it at the time, but that
didn't occur to anyone involved in the decision (I have vague
recollections of contributing to those discussions, so I suspect a
piece of the blame for that ends up in my own lap).

2. I believe PyCObject jumped directly from a
PendingDeprecationWarning in 3.1 to removal in 3.2. That would have
been less likely if we'd written a PEP to clearly spell out the
deprecation timeline.

3. For whatever reason, nobody objected to the removal during post hoc
python-checkins review. (While that manual filter catches a lot of
mistakes, things can definitely slip through).

4. Anyone testing C extensions against the 3.2 alpha and beta releases
must have either not used the PyCObject API in the first place, or
else had already ported their code to use the PyCapsule API as
necessary.

5. The parallel evolution of the 2.x and 3.x line meant that the first
version of 2.x with the relevant warning was released only ~7 months
or so before the version of 3.2 where the API was removed

Backfilling with an after-the-fact PEP (as Larry now plans to do) will
help make sure this particular change is less likely to come as a
nasty surprise to anyone else, and will provide concrete porting
advice for those that need to maintain compatibility with older Python
versions that only offer the PyCObject API.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar 19 03:45:51 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Mar 2011 12:45:51 +1000
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <20110318144814.GA2341@kevin>
References: <ilr3fu$14c$1@dough.gmane.org>
	<AANLkTin7sZbijf1Cv5U2aPXP-LNVJ7SyuLc14zwA-xe7@mail.gmail.com>
	<ilu5ee$sk0$1@dough.gmane.org>
	<AANLkTi=0xBN5pLMoKG7oZbrmF4j4WmExqTDcOq3Bbnu9@mail.gmail.com>
	<06649710-64BF-4881-93BE-D52D14F04BB3@gmail.com>
	<20110318144814.GA2341@kevin>
Message-ID: <AANLkTi=QMD+4dFr=Koh9-mcUiL3HAt4rgzsQES8rRV0+@mail.gmail.com>

On Sat, Mar 19, 2011 at 12:48 AM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> I am the only one who is finding the following phrases amusing?!
>
> - "opening for a new person"
> - "another ctypes expert is pretty critical"
> - "job description"
> - "send people to.."

Come join python-dev - we have plenty of jobs that need filling, but
we won't offer to pay you for any of them! :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar 19 03:47:57 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Mar 2011 12:47:57 +1000
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <5EB58235-7989-465B-AF66-98EDC2D3C4D6@gmail.com>
References: <ilr3fu$14c$1@dough.gmane.org>
	<5EB58235-7989-465B-AF66-98EDC2D3C4D6@gmail.com>
Message-ID: <AANLkTi=1h9C9Yw5JbKr7wnOO=oyg8hHaNRivCm_Pr3zY@mail.gmail.com>

On Thu, Mar 17, 2011 at 5:44 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
> You will be missed.
> Thanks for all your efforts.

Indeed!

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From merwok at netwok.org  Sat Mar 19 04:01:16 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 19 Mar 2011 04:01:16 +0100
Subject: [Python-Dev] Please retract my committer rights
In-Reply-To: <AANLkTi=1h9C9Yw5JbKr7wnOO=oyg8hHaNRivCm_Pr3zY@mail.gmail.com>
References: <ilr3fu$14c$1@dough.gmane.org>	<5EB58235-7989-465B-AF66-98EDC2D3C4D6@gmail.com>
	<AANLkTi=1h9C9Yw5JbKr7wnOO=oyg8hHaNRivCm_Pr3zY@mail.gmail.com>
Message-ID: <4D841C7C.6060603@netwok.org>

Hello

Will it be okay to make you nosy on a bug report to ask for an expert
opinion when the current developers need it?  If yes, I?ll mark your
name as ?retired? in the experts file, if not I?ll remove it.

Thanks for your contributions, and have fun in your next adventures!

[Alexander]
> Unfortunately, since
> Misc/maintainers.rst is gone, I am not sure how to edit maintainers
> list.   I wonder if someone could replace Misc/maintainers.rst with a
> short document with the proper link and describing how to edit the
> list at the new location.

I?ve added a notice in 2.7 and 3.1, but the file is just gone in 3.2+.
Is adding a note to Misc/README about the removals worth it?

Regards

From a.badger at gmail.com  Sat Mar 19 04:12:19 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 18 Mar 2011 20:12:19 -0700
Subject: [Python-Dev] Module version variable
In-Reply-To: <AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
Message-ID: <20110319031219.GC19053@unaka.lan>

On Fri, Mar 18, 2011 at 07:40:43PM -0700, Guido van Rossum wrote:
> On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> > Tres Seaver wrote:
> >
> >> I'm not even sure why you would want __version__ in 99% of modules: ?in
> >> the ordinary cases, a module's version should be either the Python
> >> version (for a module shipped in the stdlib), or the release of the
> >> distribution which shipped it.
> >
> > It's useful to be able to find out the version of a module
> > you're using at run time so you can cope with API changes.
> >
> > I had a case just recently where the behaviour of something
> > in pywin32 changed between one release and the next. I looked
> > for an attribute called 'version' or something similar to
> > test, but couldn't find anything.
> >
> > +1 on having a standard place to look for version info.
> 
> I believe __version__ *is* the standard (like __author__). IIRC it was
> proposed by Ping. I think this convention is so old that there isn't a
> PEP for it. So yes, we might as well write it down. But it's really
> nothing new.
> 
There is a section in PEP8 about __version__ but it serves a slightly
different purpose there:

"""
Version Bookkeeping

    If you have to have Subversion, CVS, or RCS crud in your source file, do
    it as follows.

        __version__ = "$Revision: 88433 $"
        # $Source$

    These lines should be included after the module's docstring, before any
    other code, separated by a blank line above and below.
"""

Personally, I've never found a need to access the repository revision
programatically from my pyhon applications but I have needed to access the
API version so it would make sense to me to change the meaning of
__version__.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110318/37501ac5/attachment.pgp>

From jcea at jcea.es  Sat Mar 19 04:22:00 2011
From: jcea at jcea.es (Jesus Cea)
Date: Sat, 19 Mar 2011 04:22:00 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikYEhFMWCvo5khXJipGKgMO485MAX6BBoUT05g_@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<4D820026.9050308@jcea.es>	<20110317134549.5482920044D@kimball.webabinitio.net>	<4D825A4D.2080805@jcea.es>
	<AANLkTikYEhFMWCvo5khXJipGKgMO485MAX6BBoUT05g_@mail.gmail.com>
Message-ID: <4D842158.30608@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/03/11 03:14, Nick Coghlan wrote:
> What may actually be better for buildbot experimentation purposes is
> to allow us to request running a build-and-test cycle from branches in
> *any* of the repositories hosted on hg.python.org, rather than having
> to push experimental changes to the main line of development.
> 
> (i.e. start moving towards more of a style of development where code
> doesn't land in the main repository until it has been vetted by the
> buildbots *first*).

This is a good suggestion. I kind of remember that when working in SVN
you could request a particular build from a particular branch. If that
was true, we should consider something similar with mercurial. I am
offline and can't check, thought.

In fact I am thinking about being able to push a "patch" to the
buildbots and, if the patch applies cleanly to the branch tip, actually
apply it, build & test.

That would be amazing, security aside :).

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYQhWJlgi5GaxT1NAQJ23AP/dn2lqXgxeoYgsAZklkDR2hLqHJzYs8PT
Y38sGpeUdDmJQ/k+vISUtlNsshLRDc7o88cL95wy1j10QNPSL43ehfz3+W6anAvB
6ELpvTePT/0rJzTcWQVgXSwAu50am4z9rcV7r2Q7EluLCKg3azXcARoCMFSZ/8Wp
vMgbAGe3pwk=
=5LvY
-----END PGP SIGNATURE-----

From merwok at netwok.org  Sat Mar 19 04:29:12 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 19 Mar 2011 04:29:12 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <4D7C0676.5020901@python.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<4D7B9A82.6070309@netwok.org>	<AANLkTimmCL9FrFpakkQNJH5mo6F9_s5y7Uz5-WPLYDmH@mail.gmail.com>	<4D7BBEAC.7060803@python.org>
	<4D7BF008.4020307@g.nevcal.com> <4D7C0676.5020901@python.org>
Message-ID: <4D842308.9010303@netwok.org>

> The short summary is that the Parrot VM is a very good semantic fit for 
> Python (AFAICT, a better fit than it is for Perl 6, though I haven't 
> done the feature-by-feature comparison).

Thanks for the write-up.  The point quoted above is especially useful,
since I vaguely remembered reading that Parrot was not suited to
Python?s semantics but now stand corrected.

Regards

From ncoghlan at gmail.com  Sat Mar 19 04:30:58 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Mar 2011 13:30:58 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D842158.30608@jcea.es>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<4D820026.9050308@jcea.es>
	<20110317134549.5482920044D@kimball.webabinitio.net>
	<4D825A4D.2080805@jcea.es>
	<AANLkTikYEhFMWCvo5khXJipGKgMO485MAX6BBoUT05g_@mail.gmail.com>
	<4D842158.30608@jcea.es>
Message-ID: <AANLkTikgJUTyD4h3B3s5SE0-mVioyTuam=DxSxMP-NPn@mail.gmail.com>

On Sat, Mar 19, 2011 at 1:22 PM, Jesus Cea <jcea at jcea.es> wrote:
> This is a good suggestion. I kind of remember that when working in SVN
> you could request a particular build from a particular branch. If that
> was true, we should consider something similar with mercurial. I am
> offline and can't check, thought.
>
> In fact I am thinking about being able to push a "patch" to the
> buildbots and, if the patch applies cleanly to the branch tip, actually
> apply it, build & test.
>
> That would be amazing, security aside :).

Given how easy Antoine (I think) made it for us to create server side
clones on hg.python.org, making a new clone, pushing a change to it
over ssh, then triggering a build, would be almost as nice, but with
the security of requiring registered public SSH keys on the server.

I did just poke around on the buildbot pages, but couldn't find
anything resembling the old "buiild a branch" form.

MvL/Antoine/Georg, any ideas?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Sat Mar 19 04:42:47 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Mar 2011 04:42:47 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikgJUTyD4h3B3s5SE0-mVioyTuam=DxSxMP-NPn@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<4D820026.9050308@jcea.es>	<20110317134549.5482920044D@kimball.webabinitio.net>	<4D825A4D.2080805@jcea.es>	<AANLkTikYEhFMWCvo5khXJipGKgMO485MAX6BBoUT05g_@mail.gmail.com>	<4D842158.30608@jcea.es>
	<AANLkTikgJUTyD4h3B3s5SE0-mVioyTuam=DxSxMP-NPn@mail.gmail.com>
Message-ID: <4D842637.6040406@v.loewis.de>

> I did just poke around on the buildbot pages, but couldn't find
> anything resembling the old "buiild a branch" form.
> 
> MvL/Antoine/Georg, any ideas?

Kelsey Hightower is already working on it. There is the buildbot 'try'
feature, but there may be other options as well.

Regards,
Martin

From brian.curtin at gmail.com  Sat Mar 19 04:52:06 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Fri, 18 Mar 2011 23:52:06 -0400
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
Message-ID: <AANLkTinGvj=nFjqS9nOcComZ6rC9YkHBLYWWmJidViJO@mail.gmail.com>

On Sat, Mar 12, 2011 at 06:43, Nick Coghlan <ncoghlan at gmail.com> wrote:

> I posted my rough notes and additional write-ups for Wednesday's VM
> summit and Thursday's language summit:
>
> http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
>
> http://www.boredomandlaziness.org/2011/03/python-vm-summit-somewhat-coherent.html
>
> http://www.boredomandlaziness.org/2011/03/python-language-summit-rough-notes.html
>
> http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html
>
> I believe Brian Curtin will also be posting a write-up for Thursday,
> but I don't know if that is online anywhere yet.


I still owe a write-up from my 5 pages of notes, but being too busy to write
it during PyCon might have a benefit: it's ammunition for the newly created
dev blog that Doug got setup today.

Just wanted to put that out there. I didn't forget!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110318/d41f5407/attachment.html>

From guido at python.org  Sat Mar 19 04:50:09 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 18 Mar 2011 20:50:09 -0700
Subject: [Python-Dev] Module version variable
In-Reply-To: <20110319031219.GC19053@unaka.lan>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
	<20110319031219.GC19053@unaka.lan>
Message-ID: <AANLkTin24CORfNhrX3pVWhWFKwp1ttUxJo6oqHhPqdX8@mail.gmail.com>

On Fri, Mar 18, 2011 at 8:12 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> On Fri, Mar 18, 2011 at 07:40:43PM -0700, Guido van Rossum wrote:
>> On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> > Tres Seaver wrote:
>> >
>> >> I'm not even sure why you would want __version__ in 99% of modules: ?in
>> >> the ordinary cases, a module's version should be either the Python
>> >> version (for a module shipped in the stdlib), or the release of the
>> >> distribution which shipped it.
>> >
>> > It's useful to be able to find out the version of a module
>> > you're using at run time so you can cope with API changes.
>> >
>> > I had a case just recently where the behaviour of something
>> > in pywin32 changed between one release and the next. I looked
>> > for an attribute called 'version' or something similar to
>> > test, but couldn't find anything.
>> >
>> > +1 on having a standard place to look for version info.
>>
>> I believe __version__ *is* the standard (like __author__). IIRC it was
>> proposed by Ping. I think this convention is so old that there isn't a
>> PEP for it. So yes, we might as well write it down. But it's really
>> nothing new.
>>
> There is a section in PEP8 about __version__ but it serves a slightly
> different purpose there:
>
> """
> Version Bookkeeping
>
> ? ?If you have to have Subversion, CVS, or RCS crud in your source file, do
> ? ?it as follows.
>
> ? ? ? ?__version__ = "$Revision: 88433 $"
> ? ? ? ?# $Source$
>
> ? ?These lines should be included after the module's docstring, before any
> ? ?other code, separated by a blank line above and below.
> """

Ah, hm. Yes, that's way outdated. I don't think anyone believe in
marking each file with its revision any more.

I do distinctly recall __version__ being standardized for other
purposes too, but I have no idea how to find that reference... It
probably was well before 2000.

> Personally, I've never found a need to access the repository revision
> programatically from my pyhon applications but I have needed to access the
> API version so it would make sense to me to change the meaning of
> __version__.

Agreed. I don't think that was the only allowed use of __version__ --
just the only mentioned use. (Note the conditional "If you have to
have Subversion, ..." at the start of that paragraph in PEP 8.)

-- 
--Guido van Rossum (python.org/~guido)

From ncoghlan at gmail.com  Sat Mar 19 06:35:18 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Mar 2011 15:35:18 +1000
Subject: [Python-Dev] [Python-checkins] Daily reference leaks
	(979ae5972604): sum=30
In-Reply-To: <E1Q0R2g-0007qk-8V@ap.vmr.nerim.net>
References: <E1Q0R2g-0007qk-8V@ap.vmr.nerim.net>
Message-ID: <AANLkTimAFudKaFzMN0n_HDoBsVYXFTbOHTWSOaGe=Wjk@mail.gmail.com>

The timing of these new refleaks being triggered by test_os and by
test_posix is suspicious, making me think that #10812 is the likely
culprit.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From mhammond at skippinet.com.au  Sat Mar 19 07:02:08 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 19 Mar 2011 17:02:08 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
	launcher for Windows
Message-ID: <4D8446E0.7030401@skippinet.com.au>

Hi all,
   During the huge thread about PEP 394, a suggestion was made that a 
"launcher" for Python on Windows could be implemented which would allow 
for some of the guidelines in that PEP to apply to the Windows version 
of Python.

I've attached the first draft of a PEP for such a launcher and put the 
first draft of the "reference implementation" (implemented in Python 3) 
at http://starship.python.net/crew/mhammond/downloads/python_launcher.py

The reference implementation is fairly complete WRT the features 
described in the PEP.  However, I'm sure there will be comments on both 
the PEP itself and the implementation, so I'm putting them up for 
discussion now rather than spending more time polishing things which may 
end up changing.  I'll start work on a C implementation once there is 
broad agreement on the functionality in the reference implementation.

All comments welcome, including, but not limited to:

* Is this really PEP material, or will turning the PEP into a regular 
spec be suitable?

* If it is a PEP, is it "Standards Track" or "Informational"?

* Does the functionality described strike the right balance between 
simplicity and usefulness?

* Does the strategy have general support from Martin, who as the person 
making Python distributions would need to be involved in at least some 
aspects of it (specifically, having the installer MSI install the 
launcher and update the file associations to reference it).

Thanks,

Mark
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: launcher-pep.txt
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110319/6b99a0e6/attachment.txt>

From regebro at gmail.com  Sat Mar 19 12:14:21 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 19 Mar 2011 12:14:21 +0100
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <AANLkTinPNhwaBdzOEX4cetn+xQVE-d01YBXm=qj5x0z_@mail.gmail.com>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
	<AANLkTinPNhwaBdzOEX4cetn+xQVE-d01YBXm=qj5x0z_@mail.gmail.com>
Message-ID: <AANLkTinYN2qPNna9vUZ4ToCRH6GUVVp_SD2p8hcm1=_E@mail.gmail.com>

On Sat, Mar 19, 2011 at 03:42, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 5. The parallel evolution of the 2.x and 3.x line meant that the first
> version of 2.x with the relevant warning was released only ~7 months
> or so before the version of 3.2 where the API was removed

An additional issue that makes it particularly problematic for me is
that this is a part of moving a whole framework, the Zope Component
Architecture And Friends (aka the Bicycle toolkit) that contains a lot
of hard to port projects like zope.testing and zc.buildout. This means
that it's so far take three years of porting (starting with efforts to
port Setuptools in 2008) and isn't done yet. It's extremely
frustrating that in the middle of this porting effort the target
changes, so things I *thought* was done and ported, are now suddenly
not done anymore. It becomes a sisyphean task to port to Python 3, and
I don't fancy myself ending up in such a boring part of hell. :-) If I
had instead ignored Python 3 completely until this year, then I this
wouldn't have been a problem. As a result it feels like early porters
like me just got our fingers whacked.

But it all comes down to what Guido mentioned in his fie-side chat (at
least how I understood him): The pace of change for Python needs to
slow down a bit, at least until the migration to Python 3 both for
Python implementations and general use has been completed.

//Lennart

From stephen at xemacs.org  Sat Mar 19 12:46:47 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 19 Mar 2011 20:46:47 +0900
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D842158.30608@jcea.es>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<4D820026.9050308@jcea.es>
	<20110317134549.5482920044D@kimball.webabinitio.net>
	<4D825A4D.2080805@jcea.es>
	<AANLkTikYEhFMWCvo5khXJipGKgMO485MAX6BBoUT05g_@mail.gmail.com>
	<4D842158.30608@jcea.es>
Message-ID: <AANLkTims-e0pjB01Lau0ofvp8N_NpTY8KqcPKqzPJZKz@mail.gmail.com>

On Sat, Mar 19, 2011 at 12:22 PM, Jesus Cea <jcea at jcea.es> wrote:
> On 19/03/11 03:14, Nick Coghlan wrote:

>> (i.e. start moving towards more of a style of development where code
>> doesn't land in the main repository until it has been vetted by the
>> buildbots *first*).

Unfortunately, this is *not* good enough.  Basically what you are
talking about is equivalent to automatic rebasing (although without
history loss).  The rebased code *must* be retested in the new context
anyway.  (Linus famously flamed DaveM over this issue on lkml.  Sorry,
I don't have the URL.)

To the extent the buildbots are not overloaded, this strategy will
indeed save developer time, as most changes are more or less
independent of each other (that's why automated merging works at all
well), and most of the time something that passes in a branch will
also pass after merging.  So it's probably easier, and certainly less
wearing on other developers, if you detect breakage in the branch
rather than waiting for it to happen in the trunk.  However, such
early detection is not guaranteed because not all semantic conflicts
are syntactic conflicts.  Ie, the merge may succeed but the code
break.

> In fact I am thinking about being able to push a "patch" to the
> buildbots and, if the patch applies cleanly to the branch tip, actually
> apply it, build & test.

This is what Bazaar does with its PQM service ("patch queue manager").
 I don't see why that wouldn't be usable with Mercurial, although if
it uses Bazaar internal APIs (a lot of Bazaar-related projects do) it
might be mildly tedious to port).

From solipsis at pitrou.net  Sat Mar 19 13:51:43 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 19 Mar 2011 13:51:43 +0100
Subject: [Python-Dev] Module version variable
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
	<20110319031219.GC19053@unaka.lan>
Message-ID: <20110319135143.199b0868@pitrou.net>

On Fri, 18 Mar 2011 20:12:19 -0700
Toshio Kuratomi <a.badger at gmail.com> wrote:
> There is a section in PEP8 about __version__ but it serves a slightly
> different purpose there:
> 
> """
> Version Bookkeeping
> 
>     If you have to have Subversion, CVS, or RCS crud in your source file, do
>     it as follows.
> 
>         __version__ = "$Revision: 88433 $"
>         # $Source$

This should be updated (or rather, removed) now that we use Mercurial...

Regards

Antoine.



From solipsis at pitrou.net  Sat Mar 19 13:57:02 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 19 Mar 2011 13:57:02 +0100
Subject: [Python-Dev] cpython (3.2): Issue 7391: Remove questionable and
 outdated HOWTO	document with permission
References: <E1Q0ksM-0002Ip-9U@dinsdale.python.org>
Message-ID: <20110319135702.30df216b@pitrou.net>

On Sat, 19 Mar 2011 02:22:42 +0100
raymond.hettinger <python-checkins at python.org> wrote:
> http://hg.python.org/cpython/rev/80ff78425419
> changeset:   68671:80ff78425419
> branch:      3.2
> parent:      68665:f832ca852329
> user:        Raymond Hettinger <python at rcn.com>
> date:        Fri Mar 18 18:22:28 2011 -0700
> summary:
>   Issue 7391: Remove questionable and outdated HOWTO document with permission from its author.

How is this questionable?
I found it quite useful when trying to warn beginners about anti-idioms.
Is there another resource which replaces it?

Regards

Antoine.



From merwok at netwok.org  Sat Mar 19 13:57:46 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 19 Mar 2011 13:57:46 +0100
Subject: [Python-Dev] Module version variable
In-Reply-To: <AANLkTin24CORfNhrX3pVWhWFKwp1ttUxJo6oqHhPqdX8@mail.gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>	<4D80F460.6010307@voidspace.org.uk>	<20110316183322.A34F424A614@kimball.webabinitio.net>	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>	<4D81367B.9010808@trueblade.com>
	<ilrgoc$efd$1@dough.gmane.org>	<4D8414E4.7060001@canterbury.ac.nz>	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>	<20110319031219.GC19053@unaka.lan>
	<AANLkTin24CORfNhrX3pVWhWFKwp1ttUxJo6oqHhPqdX8@mail.gmail.com>
Message-ID: <4D84A84A.5060008@netwok.org>

> I do distinctly recall __version__ being standardized for other
> purposes too, but I have no idea how to find that reference... It
> probably was well before 2000.

Maybe you were thinking about Pydoc, which will display __version__ in a
dedicated section of the doc.

Regards

From skip at pobox.com  Sat Mar 19 15:25:07 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 19 Mar 2011 09:25:07 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
Message-ID: <19844.48323.176151.931392@montanaro.dyndns.org>


I have a trivial little documentation patch for csv.rst.  I committed it
locally, then I pulled and merged:

    cpython% hg pull
    pulling from ssh://hg at hg.python.org/cpython
    searching for changes
    adding changesets
    adding manifests
    adding file changes
    added 94 changesets with 422 changes to 154 files (+1 heads)
    (run 'hg heads' to see heads, 'hg merge' to merge)
    cpython% hg merge
    132 files updated, 0 files merged, 0 files removed, 0 files unresolved
    (branch merge, don't forget to commit)

hg heads showed my changeset:

    changeset:   68585:c63d7374b89a
    user:        Skip Montanaro <skip at pobox.com>
    date:        Sat Mar 19 09:09:30 2011 -0500
    summary:     Mention RFC 4180.  Based on input by Tony Wallace in issue 11456.

I committed.  Now:

    changeset:   68680:64eeb4cd4b56
    tag:         tip
    parent:      68585:c63d7374b89a
    parent:      68679:dfceb98767c0
    user:        Skip Montanaro <skip at pobox.com>
    date:        Sat Mar 19 09:15:28 2011 -0500
    summary:     commit merge

The dev guide says something about collapsing changesets.  Is that
collapsing commits within a changeset or collapsing multiple changesets
(whatever that might be)?  Do I need this for a trivial change?  Can I just
push at this point?  Once pushed, how does it get merged into the main
codebase?

Skip

From martin at v.loewis.de  Sat Mar 19 16:23:12 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Mar 2011 16:23:12 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <19844.48323.176151.931392@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
Message-ID: <4D84CA60.6010001@v.loewis.de>

> hg heads showed my changeset:
> 
>     changeset:   68585:c63d7374b89a
>     user:        Skip Montanaro <skip at pobox.com>
>     date:        Sat Mar 19 09:09:30 2011 -0500
>     summary:     Mention RFC 4180.  Based on input by Tony Wallace in issue 11456.
> 
> I committed.  Now:
> 
>     changeset:   68680:64eeb4cd4b56
>     tag:         tip
>     parent:      68585:c63d7374b89a
>     parent:      68679:dfceb98767c0
>     user:        Skip Montanaro <skip at pobox.com>
>     date:        Sat Mar 19 09:15:28 2011 -0500
>     summary:     commit merge
> 
> The dev guide says something about collapsing changesets.  Is that
> collapsing commits within a changeset or collapsing multiple changesets
> (whatever that might be)?

It's only the latter. If you had a number of commits done just to
implement the feature, some with commit messages such as "fix typo",
"revert bogus change", "more cleanup", etc., people don't want to see
this in Python's history, so you would have to come up with a single
patch for the entire feature and commit that separately.

> Do I need this for a trivial change?

No. The essential change is in a single changeset (c63d7374b89a), which
is how it should be.

> Can I just push at this point?

Yes. If somebody pushed something else meanwhile, you'll have to merge
again.

> Once pushed, how does it get merged into the main codebase?

Pushing the change will exactly do that. Your merge (64eeb4cd4b56)
has your change (c63d7374b89a) as it's parent, so 64eeb4cd4b56 now
contains both the current state of cpython plus your change.

If somebody else now makes other changes that succeeded your merge,
you will need to merge them again, so that, at the time of your
push, your most recent merge is newer than cpython's default head.

Regards,
Martin

From rdmurray at bitdance.com  Sat Mar 19 16:30:55 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Mar 2011 11:30:55 -0400
Subject: [Python-Dev] cpython (3.2): Issue 7391: Remove questionable and
	outdated HOWTO document with permission
In-Reply-To: <20110319135702.30df216b@pitrou.net>
References: <E1Q0ksM-0002Ip-9U@dinsdale.python.org>
	<20110319135702.30df216b@pitrou.net>
Message-ID: <20110319153055.88AAA13F988@kimball.webabinitio.net>

On Sat, 19 Mar 2011 13:57:02 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 19 Mar 2011 02:22:42 +0100
> raymond.hettinger <python-checkins at python.org> wrote:
> > http://hg.python.org/cpython/rev/80ff78425419
> > changeset:   68671:80ff78425419
> > branch:      3.2
> > parent:      68665:f832ca852329
> > user:        Raymond Hettinger <python at rcn.com>
> > date:        Fri Mar 18 18:22:28 2011 -0700
> > summary:
> >   Issue 7391: Remove questionable and outdated HOWTO document with permission from its author.
> 
> How is this questionable?
> I found it quite useful when trying to warn beginners about anti-idioms.
> Is there another resource which replaces it?

Indeed.  I spent some time a few months back updating a couple sections
of that howto.  Perhaps the better thing to do would be to update it
instead of deleting it (although I admit I haven't read through the
whole thing....an issue was submitted for a particular section and I
updated that section and the other one talking about the same topic
(sorry I don't remember which one off the top of my head)).

--
R. David Murray           http://www.bitdance.com

From rdmurray at bitdance.com  Sat Mar 19 16:49:51 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Mar 2011 11:49:51 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <19844.48323.176151.931392@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
Message-ID: <20110319154951.C5A1713F988@kimball.webabinitio.net>

On Sat, 19 Mar 2011 09:25:07 -0500, skip at pobox.com wrote:
> 
> I have a trivial little documentation patch for csv.rst.  I committed it
> locally, then I pulled and merged:

Note that if you want doc changes to appear in all the current doc sets
(2.7, 3.2, dev), then you should start with patching 3.2 and merge it
into default, and also patch 2.7, just like any other bug-fix commit.
Making doc changes to all current doc sets is our normal practice (unless,
of course, they are about new features).  You can also optionally start
your patching with 3.1, since the 3.1 docs will be re-generated one last
time for its upcoming last bugfix release.  It's easy enough (now that we
no longer have to deal with svnmerge) that I've been doing that, myself.

--
R. David Murray           http://www.bitdance.com

From v+python at g.nevcal.com  Sat Mar 19 09:44:42 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Sat, 19 Mar 2011 01:44:42 -0700
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D8446E0.7030401@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au>
Message-ID: <4D846CFA.2030808@g.nevcal.com>

Not all of the ideas below are complementary to each other, some are 
either or, to allow different thoughts to be inspired or different 
directions to be taken.

Thanks for starting a PEP.

On 3/18/2011 11:02 PM, Mark Hammond wrote:

>      The launcher should be as simple as possible (but no simpler.)

The launcher could be simpler if it isn't used for launching interactive 
interpreters as well as script references via Windows associations (more 
about that after the next quote).

The launcher could be simpler if it just read through the file of its 
first parameter until it finds a line starting with #@ (process as a 
Windows version of Unix #!) or starting without a # (error case).  This 
avoids the need parse such lines.  So in reality, you are not trying to 
make launcher as simple as possible, but rather attempting to make some 
perceived usage case simple, and make the launcher more complex (and 
harder to define, document, and implement) rather than suggesting that 
since Unix and Windows are different, that maybe they should have 
different lines in the script to help launch them.  Remember, the 
typical Windows user is not likely to place a #! line in their scripts 
in the first place, so teaching them what a Unix #! line is, and how the 
parameter after it should be something that Windows doesn't even use, 
and the launcher has to work hard to interpret, is not as simple as 
possible.

The launcher could be simpler if the Python installer placed versioned 
Python executables on the PATH.  Unfortunately, historically it hasn't.  
If it did, would, or the launcher installer would place them there for 
pre-existing versions of Python, then the launcher could work by 
launching the appropriate version of Python, expecting Windows to find 
it on the PATH.  The PEP doesn't address the level of internal 
complexity of the launcher necessary to find where Python has been 
installed, neither for CPython, nor for the alternate implementations to 
be supported.

The launcher could be simpler if a directory  \usr\bin were created 
under Windows Program Files, placed on the PATH, and %ProgramFiles% 
prepended to the Unix #! line, with the Python/Jython/Cython installers 
placing appropriately versioned executables in that directory.  Could 
even start a trend for programs ported from Unix.  One could even place 
an "env" program there, for more simplicity.

>      * When used to launch an interactive Python interpreter, the launcher
>        will support the first command-line argument optionally be a
>        version specifier in the form "-n[.n]" (where n is a single
>        integer) to nominate a specific version be used.  For example,
>        while "py.exe" may locate and launch the latest Python 2.x
>        implementation installed, a command-line such as "py.exe -3" could
>        specify the latest Python 3.x implementation be launched, while
>        "py.exe -2.6" could specify Python 2.6 be located and launched.
>        If a Python 2.x implementation is desired to be launched with the
>        -3 flag, the command-line would need to be similar to "py.exe -2
>        -3" (or the specific version of Python could obviously be
>        launched manually without use of this launcher.)

I think that a python launcher that is "on the PATH" that could be used 
to launch an interactive Python, should be different than one that is 
used to launch XXXX.py[w] scripts.  The above paragraph raises the 
issues below, which I think are confusing enough to justify this, IMO.  
Certainly, if the same python launcher is used for both cases, a lot 
more clarity around parameter handling must be provided.

1) python should be invoked interactively by typing "python" or 
"pythonX[.Y]" at the CMD prompt, not "py".  This can be done without a 
launcher, if appropriate versioned pythons are placed on the PATH.  The 
launcher is really and only needed for handling XXXX.py[w] scripts, 
which, in the Windows way of thinking, can only be associated with one 
specific, system-wide configured version of Python (presently, the 
latest one wins).  The script itself is not examined to modify such an 
association.  The Unix !# line provides such modification on Unix.

2) If the launcher provides command line options for the "benefit" of 
launching interactive Python interpreters, those command line options 
can have data puns with script names, or can conflict with actual Python 
options.  I believe Python 2 already has a -3 option, for example.  And 
Windows users are not trained that "-" introduces an option syntax, but 
rather "/".  Most _programmer_ users would probably be aware of "-" as 
an option syntax, but Python is used as a language for non-programmers 
in some circles, and few Windows non-programmers understand "/" much 
less "-" and not even command lines very well.  So not using a launcher 
for launching interactive Python sidesteps all that: Python itself is 
introduced and taught, and no need to teach about (or even have) 
launcher options that could possibly conflict and confuse, in addition 
to Python options that may conflict with script names already.  (I have 
seen lots of Windows users use leading punctuation characters on 
filenames to affect sort order and grouping of files in My Documents, 
not knowing they can create subdirectories/subfolders, or not wanting to 
bother with them, since all their applications default to opening things 
from My Documents.)

3) Unix !# lines can have embedded options after the program name on the 
line.  Such options would be another source of potential conflict with 
launcher options, if the launcher has options for use with launching 
interactive interpreters.

Item 3 is also an issue for the PEP even apart from its use as an 
interactive Python launcher; since options may exist on the Unix #! 
line, a discussion of how and if they are handled by the launcher should 
be included in the PEP.

>      * Environment varialbes will be used to override the semantics for
>        determining exactly what version of Python will be used.  For
>        example, while a shebang line of "/usr/bin/python2" will
>        automatically locate a Python 2.x implementation, an environment
>        variable can override exactly which Python 2.x implementation will
>        be chosen.  Similarly for "/usr/bin/python" etc.

Clarify if environment variables can be used to override semantics for 
shebang lines of the form "/usr/bin/python2.x".

>      The launcher should be capable of supporting implementations other
>      than CPython, such as jython and IronPython.  In particular, if there
>      are common symbolic links used on Unix to specify such an
>      implementation (such as "/usr/bin/jpython", the launcher should
>      support such references on Windows. However, the launcher on Windows
>      need not create its own conventions for use on Windows - ie, if
>      "/usr/bin/jython" is not commonly found on Unix and therefore does
>      not commonly exist in shebang lines, the Windows launcher need not
>      support it. The ability to specify the fully-qualified path to the
>      executable could be used just as it would need to be done on Unix.

I am under the impression that IronPython is a Windows-only 
implementation, but even if it becomes available on Unix via Mono it is 
certainly possible to have Windows-specific implementations.  Apparently 
the above prevents the launcher from launching a Windows-specific 
implementation not commonly available on Unix.

>      A shebang line will be parsed according to the rules in [1].  Once
>      parsed, the command will be examined to see if it is a "virtual
>      command".  A virtual command starts with either of the 2 strings
>      '/usr/bin/python' or '/usr/bin/env python'.

If alternate implementations are to be supported, additional virtual 
commands will be required, not just these two.  Each one adds complexity 
to the launcher.

>      Non-virtual shebang lines should be discouraged as they make the
>      script specific to a specific Windows installation. However, they
>      are supported for maximum flexibility.

This is a false statement.  Non-virtual shebang lines do not make a  
script specific to a specific Windows installation, only specific to the 
(often quite large) subset of Windows installations with particular 
characteristics that are reflected in the non-virtual shebang line.  I 
think the major issue here is whether the Python is installed in drive 
C: or some other drive letter; a secondary issue would be if reference 
is made to a 32-bit Python on a 64-bit Windows, which wouldn't port back 
to a 32-bit Windows not having the "Program Files (x86)" path.

Within a corporate environment, the system drive, and the Python 
installation drive, are likely to be consistent.

Outside a corporate environment, most Windows system drives, and most 
Python installation drives are both C: and references to "C:\Program 
Files" are highly portable.

A Windows #@ could support syntax such as   "#@ 
%ProgramFiles%\python3.2\python.exe" where the %-enclosed syntax would 
be looked up in the environment (that is a predefined variable on 
current versions of windows, not sure how far back in history it goes).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110319/a3ac3803/attachment-0001.html>

From digitalxero at gmail.com  Sat Mar 19 18:15:59 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Mar 2011 13:15:59 -0400
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D846CFA.2030808@g.nevcal.com>
References: <4D8446E0.7030401@skippinet.com.au> <4D846CFA.2030808@g.nevcal.com>
Message-ID: <AANLkTim+u_yPi09qTfY5TmztHqKX6qsT_rMzVxDKKHz=@mail.gmail.com>

On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> The launcher could be simpler if the Python installer placed versioned
> Python executables on the PATH.? Unfortunately, historically it hasn't.? If
> it did, would, or the launcher installer would place them there for
> pre-existing versions of Python, then the launcher could work by launching
> the appropriate version of Python, expecting Windows to find it on the
> PATH.? The PEP doesn't address the level of internal complexity of the
> launcher necessary to find where Python has been installed, neither for
> CPython, nor for the alternate implementations to be supported.

The complexity isnt all that much since python has installed Registry
keys in known locations for a long time, it could/would just use these
to locate the proper python version

>
> The launcher could be simpler if a directory? \usr\bin were created under
> Windows Program Files, placed on the PATH, and %ProgramFiles% prepended to
> the Unix #! line, with the Python/Jython/Cython installers placing
> appropriately versioned executables in that directory.? Could even start a
> trend for programs ported from Unix.? One could even place an "env" program
> there, for more simplicity.

This is not about trying to get windows to behave more like *nix in
general it is about allowing python to have interoperability between
windows and unix with well known shebang lines

> I think that a python launcher that is "on the PATH" that could be used to
> launch an interactive Python, should be different than one that is used to
> launch XXXX.py[w] scripts.? The above paragraph raises the issues below,
> which I think are confusing enough to justify this, IMO.? Certainly, if the
> same python launcher is used for both cases, a lot more clarity around
> parameter handling must be provided.

The pep specifically stated that there would be py.exe and pyw.exe

>
> 1) python should be invoked interactively by typing "python" or
> "pythonX[.Y]" at the CMD prompt, not "py".? This can be done without a
> launcher, if appropriate versioned pythons are placed on the PATH.? The
> launcher is really and only needed for handling XXXX.py[w] scripts, which,
> in the Windows way of thinking, can only be associated with one specific,
> system-wide configured version of Python (presently, the latest one wins).
> The script itself is not examined to modify such an association.? The Unix
> !# line provides such modification on Unix.

Adding each version of python to the PATH is not going to happen on
windows the devs have always been resistant to this (A little annoying
yes, but it is what it is)

>
> 2) If the launcher provides command line options for the "benefit" of
> launching interactive Python interpreters, those command line options can
> have data puns with script names, or can conflict with actual Python
> options.? I believe Python 2 already has a -3 option, for example.? And
> Windows users are not trained that "-" introduces an option syntax, but
> rather "/".? Most _programmer_ users would probably be aware of "-" as an
> option syntax, but Python is used as a language for non-programmers in some
> circles, and few Windows non-programmers understand "/" much less "-" and
> not even command lines very well.? So not using a launcher for launching
> interactive Python sidesteps all that: Python itself is introduced and
> taught, and no need to teach about (or even have) launcher options that
> could possibly conflict and confuse, in addition to Python options that may
> conflict with script names already.? (I have seen lots of Windows users use
> leading punctuation characters on filenames to affect sort order and
> grouping of files in My Documents, not knowing they can create
> subdirectories/subfolders, or not wanting to bother with them, since all
> their applications default to opening things from My Documents.)

The command line options I disagree with as well. If the user wants to
test a script that has a shebang of python2 with python3 then they
should explicitly launch it that way just like you would have to do on
*nix

>
> 3) Unix !# lines can have embedded options after the program name on the
> line.? Such options would be another source of potential conflict with
> launcher options, if the launcher has options for use with launching
> interactive interpreters.
>
> Item 3 is also an issue for the PEP even apart from its use as an
> interactive Python launcher; since options may exist on the Unix #! line, a
> discussion of how and if they are handled by the launcher should be included
> in the PEP.

They should be passed exactly as they are on the shebang line

>
>     * Environment varialbes will be used to override the semantics for
>       determining exactly what version of Python will be used.  For
>       example, while a shebang line of "/usr/bin/python2" will
>       automatically locate a Python 2.x implementation, an environment
>       variable can override exactly which Python 2.x implementation will
>       be chosen.  Similarly for "/usr/bin/python" etc.
>
> Clarify if environment variables can be used to override semantics for
> shebang lines of the form "/usr/bin/python2.x".

No I think there should be at max 2 environment variables and they
should be explicitly set by the user not added by default
PYTHON_2
    If set would override the latest version of python2 that is
launched via a shebang line ending in python or python2 but not
python2.x
PYTHON_3
    if set would override the latest version of python3 that is
launched via a shebang line ending in python3 but not python3.x


>
>     The launcher should be capable of supporting implementations other
>     than CPython, such as jython and IronPython.  In particular, if there
>     are common symbolic links used on Unix to specify such an
>     implementation (such as "/usr/bin/jpython", the launcher should
>     support such references on Windows. However, the launcher on Windows
>     need not create its own conventions for use on Windows - ie, if
>     "/usr/bin/jython" is not commonly found on Unix and therefore does
>     not commonly exist in shebang lines, the Windows launcher need not
>     support it. The ability to specify the fully-qualified path to the
>     executable could be used just as it would need to be done on Unix.
>
> I am under the impression that IronPython is a Windows-only implementation,
> but even if it becomes available on Unix via Mono it is certainly possible
> to have Windows-specific implementations.? Apparently the above prevents the
> launcher from launching a Windows-specific implementation not commonly
> available on Unix.

Thats not true it specifically states that the launcher supports fully
qualified path to launch the app so you could do
#! c:\ironpython\ipy.exe

>
>     A shebang line will be parsed according to the rules in [1].  Once
>     parsed, the command will be examined to see if it is a "virtual
>     command".  A virtual command starts with either of the 2 strings
>     '/usr/bin/python' or '/usr/bin/env python'.
>
> If alternate implementations are to be supported, additional virtual
> commands will be required, not just these two.? Each one adds complexity to
> the launcher.

These are the two most common shebang lines on *nix for python. If
there are additional ones that are used in enough distros by default
it would be trivial to add the correct prefixes.

>
> Outside a corporate environment, most Windows system drives, and most Python
> installation drives are both C: and references to "C:\Program Files" are
> highly portable.

This is not true. The default windows installers install to
C:\PythonX.Y and 90% of windows users dont change it.


>
> A Windows #@ could support syntax such as?? "#@
> %ProgramFiles%\python3.2\python.exe" where the %-enclosed syntax would be
> looked up in the environment (that is a predefined variable on current
> versions of windows, not sure how far back in history it goes).

No. This is not about adding special functionality on windows it is
about making portable python scripts that just work on most *nix
distros also work and be portable on windows



Thank you Mark for writing up this pep. It is almost identical to the
one I was working up but covers more details and actually provides an
implementation example. Other then the command line args I agree with
everything covered.

From g.brandl at gmx.net  Sat Mar 19 19:05:59 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 19 Mar 2011 19:05:59 +0100
Subject: [Python-Dev] cpython (3.2): Issue 7391: Remove questionable and
 outdated HOWTO document with permission
In-Reply-To: <20110319153055.88AAA13F988@kimball.webabinitio.net>
References: <E1Q0ksM-0002Ip-9U@dinsdale.python.org>
	<20110319135702.30df216b@pitrou.net>
	<20110319153055.88AAA13F988@kimball.webabinitio.net>
Message-ID: <im2r9u$ioa$2@dough.gmane.org>

On 19.03.2011 16:30, R. David Murray wrote:
> On Sat, 19 Mar 2011 13:57:02 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Sat, 19 Mar 2011 02:22:42 +0100
>> raymond.hettinger <python-checkins at python.org> wrote:
>> > http://hg.python.org/cpython/rev/80ff78425419
>> > changeset:   68671:80ff78425419
>> > branch:      3.2
>> > parent:      68665:f832ca852329
>> > user:        Raymond Hettinger <python at rcn.com>
>> > date:        Fri Mar 18 18:22:28 2011 -0700
>> > summary:
>> >   Issue 7391: Remove questionable and outdated HOWTO document with permission from its author.
>> 
>> How is this questionable?
>> I found it quite useful when trying to warn beginners about anti-idioms.
>> Is there another resource which replaces it?
> 
> Indeed.  I spent some time a few months back updating a couple sections
> of that howto.  Perhaps the better thing to do would be to update it
> instead of deleting it (although I admit I haven't read through the
> whole thing....an issue was submitted for a particular section and I
> updated that section and the other one talking about the same topic
> (sorry I don't remember which one off the top of my head)).

+1.  (Also I don't understand why we'd need permission from an author to
*remove* content.)

Georg



From solipsis at pitrou.net  Sat Mar 19 19:21:28 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 19 Mar 2011 19:21:28 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
References: <19844.48323.176151.931392@montanaro.dyndns.org>
Message-ID: <20110319192128.522235fb@pitrou.net>

On Sat, 19 Mar 2011 09:25:07 -0500
skip at pobox.com wrote:
> 
> I have a trivial little documentation patch for csv.rst.  I committed it
> locally, then I pulled and merged:
> 
>     cpython% hg pull
>     pulling from ssh://hg at hg.python.org/cpython
>     searching for changes
>     adding changesets
>     adding manifests
>     adding file changes
>     added 94 changesets with 422 changes to 154 files (+1 heads)

94 changesets? If you want to avoid risking conflicts, you should "hg
pull" and "hg up" (or "hg pull -u") before you start working on
something (just like you "svn up"'ed before working on something).

> The dev guide says something about collapsing changesets.  Is that
> collapsing commits within a changeset or collapsing multiple changesets
> (whatever that might be)?  Do I need this for a trivial change?  Can I just
> push at this point?  Once pushed, how does it get merged into the main
> codebase?

Sincerely, I would really recommend that you read a Mercurial tutorial.
We could answer all your questions one by one but that wouldn't help you
much if you don't understand the concepts.

Regards

Antoine.



From db3l.net at gmail.com  Sat Mar 19 19:45:10 2011
From: db3l.net at gmail.com (David Bolen)
Date: Sat, 19 Mar 2011 14:45:10 -0400
Subject: [Python-Dev] buildbot VM exhausted in test_crashers
Message-ID: <m2hbazueyx.fsf@valheru.db3l.homeip.net>

I've run out of virtual memory on my Ubuntu buildbot today (and I
think the FreeBSD buildbots a few days ago).  Those have physically
OOMd/restarted the VM.  The Windows buildbots have been giving me
VM warnings, but appear to have gotten through it.

I believe it's the test_crashers test, which when I observed the
Ubuntu buildbot when trying to bring it back online suddenly spikes to
over 500MB allocated to the Python process (which is the limit of
physical memory on that box), then causes an overall OOM and crash.

The problem is that the failing build is automatically retried when I
try to reconnect the buildbot, so it just get rights into trouble
again.  The comment in that build's changeset looks like it might be
getting rolled back?

Assuming that's the case, is there a way to flush any pending builds
for my slaves before I bring them back online?

Thanks.

-- David

PS: Neither FreeBSD nor my Ubuntu slave are actually up though the master
thinks they are.  The pinging option worked once for the Ubuntu slave but
at the moment I can't seem to get the master to think that any of them
are really disconnected.


From martin at v.loewis.de  Sat Mar 19 19:49:28 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Mar 2011 19:49:28 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D8446E0.7030401@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au>
Message-ID: <4D84FAB8.3040301@v.loewis.de>

> * Is this really PEP material, or will turning the PEP into a regular
> spec be suitable?

It's PEP material if it is contentious, which I believe it is.

I, for example, will find issues with it if the implementation uses
CreateProcess at some point - the launcher should IMO run Python
directly, rather than creating a new process. This, in turn, will
probably mean that you cannot actually implement the PEP in Python.

Others may find issues if the PEP proposes to change the standard
association for .py (and also issues if it doesn't).

> * If it is a PEP, is it "Standards Track" or "Informational"?

If you are proposing to change the CPython code base (which I think you
should), it's standards track. If you are talking about a tool provided
by you on PyPI, you actually don't need to discuss it with anybody.

> * Does the functionality described strike the right balance between
> simplicity and usefulness?

It leaves a number of issues still open, so it's hard to tell yet.
For example, the 32-bit vs. 64-bit issue should be resolved (which I
think comes down to having 4 binaries). Plus, it should talk about
installation of multiple copies of the same Python version, e.g.
from ActivePython, EPD, etc.

> * Does the strategy have general support from Martin, who as the person
> making Python distributions would need to be involved in at least some
> aspects of it (specifically, having the installer MSI install the
> launcher and update the file associations to reference it).

Notice that the PEP doesn't talk about file associations yet (but it
should).

I'm fine with the strategy, but I feel that the devil's in the detail.

Regards,
Martin

From skip at pobox.com  Sat Mar 19 19:53:11 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 19 Mar 2011 13:53:11 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <20110319154951.C5A1713F988@kimball.webabinitio.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319154951.C5A1713F988@kimball.webabinitio.net>
Message-ID: <19844.64407.891398.896342@montanaro.dyndns.org>


    >> I have a trivial little documentation patch for csv.rst.  I committed
    >> it locally, then I pulled and merged:

    RDM> Note that if you want doc changes to appear in all the current doc
    RDM> sets (2.7, 3.2, dev), then you should start with patching 3.2 and
    RDM> merge it into default, and also patch 2.7, just like any other
    RDM> bug-fix commit.

Sorry, I found updating cpython hard enough.  I almost gave up on just that
one simple change.

Anyway, I thought I was supposed to pull from head to 3.2 and 2.7.  What is
"dev"?

Skip

From solipsis at pitrou.net  Sat Mar 19 19:58:30 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 19 Mar 2011 19:58:30 +0100
Subject: [Python-Dev] buildbot VM exhausted in test_crashers
References: <m2hbazueyx.fsf@valheru.db3l.homeip.net>
Message-ID: <20110319195830.70ccc4f3@pitrou.net>

On Sat, 19 Mar 2011 14:45:10 -0400
David Bolen <db3l.net at gmail.com> wrote:
> 
> The problem is that the failing build is automatically retried when I
> try to reconnect the buildbot, so it just get rights into trouble
> again.  The comment in that build's changeset looks like it might be
> getting rolled back?
> 
> Assuming that's the case, is there a way to flush any pending builds
> for my slaves before I bring them back online?

I've enabled the button to cancel pending builds in the Web UI. You
should be able to bring back the Ubuntu slave online. You can do the
same (cancel pending builds) for other slaves if needed.

Regards

Antoine.



From raymond.hettinger at gmail.com  Sat Mar 19 19:59:27 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 19 Mar 2011 11:59:27 -0700
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <20110319192128.522235fb@pitrou.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
Message-ID: <26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>


On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:

> On Sat, 19 Mar 2011 09:25:07 -0500
> skip at pobox.com wrote:
> 
>> The dev guide says something about collapsing changesets.  Is that
>> collapsing commits within a changeset or collapsing multiple changesets
>> (whatever that might be)?  Do I need this for a trivial change?  Can I just
>> push at this point?  Once pushed, how does it get merged into the main
>> codebase?
> 
> Sincerely, I would really recommend that you read a Mercurial tutorial.
> We could answer all your questions one by one but that wouldn't help you
> much if you don't understand the concepts.

Skip is not alone on this one.  I've been using Mercurial for a couple of months now, have read multiple tutorials and whatnot, but am still not clear on how to follow the devguide's suggested cross-branch workflow.

The dance of pulling, merging, reverting, collapsing, resolving, null merging, and rebasing cross-linked branches is somewhat more involved and complex than covered in any of the tutorials I've seen.

I think if we're going to require a complex workflow, then we're going to have to expect a lot of questions.  And those questions shouldn't be brushed-off with "go read the tutorial, we have no time for you" or words to that effect.


RAymond

From skip at pobox.com  Sat Mar 19 20:05:12 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 19 Mar 2011 14:05:12 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <20110319192128.522235fb@pitrou.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
Message-ID: <19844.65128.436929.526859@montanaro.dyndns.org>

>>>>> "Antoine" == Antoine Pitrou <solipsis at pitrou.net> writes:

    Antoine> On Sat, 19 Mar 2011 09:25:07 -0500
    Antoine> skip at pobox.com wrote:
    >> 
    >> I have a trivial little documentation patch for csv.rst.  I committed it
    >> locally, then I pulled and merged:
    >> 
    >> cpython% hg pull
    >> pulling from ssh://hg at hg.python.org/cpython
    >> searching for changes
    >> adding changesets
    >> adding manifests
    >> adding file changes
    >> added 94 changesets with 422 changes to 154 files (+1 heads)

    Antoine> 94 changesets? If you want to avoid risking conflicts, you should "hg
    Antoine> pull" and "hg up" (or "hg pull -u") before you start working on
    Antoine> something (just like you "svn up"'ed before working on something).

Sorry, this workflow is still new and hugely confusing to me.  To make a
simple edit to csv.rst I needed to do a couple pulls and merges, local
commits, resolve the same conflict multiple times, get rebuffed when I first
pushed because there was a tab in the file, and ask a question here.  If
this is the typical route necessary to make even the simplest changes which
would have been a single commit with svn, my already meager rate of
contributions is likely to wither away to nothing.

    >> The dev guide says something about collapsing changesets.  Is that
    >> collapsing commits within a changeset or collapsing multiple
    >> changesets (whatever that might be)?  Do I need this for a trivial
    >> change?  Can I just push at this point?  Once pushed, how does it get
    >> merged into the main codebase?

    Antoine> Sincerely, I would really recommend that you read a Mercurial
    Antoine> tutorial.  We could answer all your questions one by one but
    Antoine> that wouldn't help you much if you don't understand the
    Antoine> concepts.

Thanks for the snide response.  If I had time to read an entire book just to
learn how to do something I was doing in CVS and Subversion with no trouble,
I would have done so by now.  I want to understand how to use the workflow
set up for this project.  If you aren't willing to help me get past my
initial difficulties, please don't bother responding.

-- 
Skip Montanaro - skip at pobox.com - http://www.smontanaro.net/

From dsdale24 at gmail.com  Sat Mar 19 20:06:54 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Sat, 19 Mar 2011 15:06:54 -0400
Subject: [Python-Dev] improvement to declaring abstract properties
Message-ID: <AANLkTino7Gt7XuLHT0Rt273-G5p8nLN3a913MQd_NZLe@mail.gmail.com>

I suggested at python-ideas a way that the declaration of abstract
properties could be improved to support the decorator syntax:
http://mail.python.org/pipermail/python-ideas/2011-March/009411.html .
A relatively small change to the property builtin would allow
properties to identify themselves as abstract when they are passed
abstract methods (the same way that function objects identify
themselves as abstract when decorated with @abstractmethod). As a
result, @abstractproperty would no longer be needed.

 I submitted a patch at http://bugs.python.org/issue11610. It includes
the changes to the property builtin, documentation, and unit tests.
Unfortunately, I have not been able to python-3.3 from a mercurial
checkout on either Ubuntu 11.04 or OS X 10.6.6 (for reasons unrelated
to the patch), and so I have not been able to test the patch.

Darren

From db3l.net at gmail.com  Sat Mar 19 20:41:51 2011
From: db3l.net at gmail.com (David Bolen)
Date: Sat, 19 Mar 2011 15:41:51 -0400
Subject: [Python-Dev] buildbot VM exhausted in test_crashers
References: <m2hbazueyx.fsf@valheru.db3l.homeip.net>
	<20110319195830.70ccc4f3@pitrou.net>
Message-ID: <m2d3lmvqww.fsf@valheru.db3l.homeip.net>

Antoine Pitrou <solipsis at pitrou.net> writes:

> I've enabled the button to cancel pending builds in the Web UI. You
> should be able to bring back the Ubuntu slave online. You can do the
> same (cancel pending builds) for other slaves if needed.

Thanks.  Is that a single button somewhere or do I need to cancel the
pending builds individually when there are several waiting?

In any event it looks like the retries of the failing 3.x build
stopped on their own.

I suspect, however, that as soon as something else commits to the 3.x
branch and causes a new test, that test_crashers (presumably from
changeset 9c6dcb5d8f01) will likely just take the slaves down again.

Perhaps the test is just too hard to execute reliably on the entire
build farm?

-- David


From solipsis at pitrou.net  Sat Mar 19 20:52:11 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 19 Mar 2011 20:52:11 +0100
Subject: [Python-Dev] buildbot VM exhausted in test_crashers
References: <m2hbazueyx.fsf@valheru.db3l.homeip.net>
	<20110319195830.70ccc4f3@pitrou.net>
	<m2d3lmvqww.fsf@valheru.db3l.homeip.net>
Message-ID: <20110319205211.2dc72637@pitrou.net>

On Sat, 19 Mar 2011 15:41:51 -0400
David Bolen <db3l.net at gmail.com> wrote:
> 
> Thanks.  Is that a single button somewhere or do I need to cancel the
> pending builds individually when there are several waiting?

There seems to be a single button.

> In any event it looks like the retries of the failing 3.x build
> stopped on their own.

Yes, I pressed the button myself :)

> I suspect, however, that as soon as something else commits to the 3.x
> branch and causes a new test, that test_crashers (presumably from
> changeset 9c6dcb5d8f01) will likely just take the slaves down again.

The test is already disabled. I don't know if Nick will remove it
entirely, but it shouldn't cause any harm in the meantime.

Regards

Antoine.



From martin at v.loewis.de  Sat Mar 19 20:55:34 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Mar 2011 20:55:34 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
Message-ID: <4D850A36.3090602@v.loewis.de>

> I think if we're going to require a complex workflow, then we're
> going to have to expect a lot of questions.  And those questions
> shouldn't be brushed-off with "go read the tutorial, we have no time
> for you" or words to that effect.

And indeed, I think this (asking questions) is just about the only
sensible way to approach this - requests to RTFM are probably less
useful than people expect. The only way to learn this stuff is by
doing it, not by reading about it.

I think I warned that this would happen - that the tools require
a large amount of relearning, and that it will take time for
committers to adjust.

So I'd encourage everybody to keep asking questions, and request that
they are answered in a polite manner, even if the one answering thinks
that the same question is already answered in some documentation.

The only alternative is that some people just give up contributing
to Python.

I just hope that we can stick with Mercurial for more than five years,
before the next hot thing comes along.

Regards,
Martin

From ncoghlan at gmail.com  Sat Mar 19 23:42:34 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Mar 2011 08:42:34 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTims-e0pjB01Lau0ofvp8N_NpTY8KqcPKqzPJZKz@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<4D820026.9050308@jcea.es>
	<20110317134549.5482920044D@kimball.webabinitio.net>
	<4D825A4D.2080805@jcea.es>
	<AANLkTikYEhFMWCvo5khXJipGKgMO485MAX6BBoUT05g_@mail.gmail.com>
	<4D842158.30608@jcea.es>
	<AANLkTims-e0pjB01Lau0ofvp8N_NpTY8KqcPKqzPJZKz@mail.gmail.com>
Message-ID: <AANLkTi=8J0mdXd3W3OrtY7gyuHy3PPgyVJJWOaOBT3oJ@mail.gmail.com>

On Sat, Mar 19, 2011 at 9:46 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> To the extent the buildbots are not overloaded, this strategy will
> indeed save developer time, as most changes are more or less
> independent of each other (that's why automated merging works at all
> well), and most of the time something that passes in a branch will
> also pass after merging. ?So it's probably easier, and certainly less
> wearing on other developers, if you detect breakage in the branch
> rather than waiting for it to happen in the trunk. ?However, such
> early detection is not guaranteed because not all semantic conflicts
> are syntactic conflicts. ?Ie, the merge may succeed but the code
> break.

Committers would still be obliged to run the tests *locally* before
pushing, so it's only cross-platform issues that would potentially
slip through the cracks. That may still turn the buildbots red, of
course, but the combination should keep them green more reliably.

(e.g. in retrospect, I never would have committed test_crashers in its
original state if I had easily been able to run it across the buildbot
fleet from my sandbox)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar 19 23:51:39 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Mar 2011 08:51:39 +1000
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D84FAB8.3040301@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
Message-ID: <AANLkTi=TgY-XWVaqUVEzJP76hvgU0XTN1AHTQbTu5YAg@mail.gmail.com>

On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I, for example, will find issues with it if the implementation uses
> CreateProcess at some point - the launcher should IMO run Python
> directly, rather than creating a new process. This, in turn, will
> probably mean that you cannot actually implement the PEP in Python.

runpy performs basically that dance to implement
_run_module_as_main(), so it's definitely possible. You just need to
be careful with it, since whatever module you invoke is going to
inherit the __main__ namespace. The implementation in runpy doesn't
suffer that problem, since the interpreter imports it directly, rather
than requiring it to bootstrap itself (/tangent: I think I may have
just noticed a nasty corner case for PEP 395 to deal with...)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar 19 23:57:15 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Mar 2011 08:57:15 +1000
Subject: [Python-Dev] buildbot VM exhausted in test_crashers
In-Reply-To: <20110319205211.2dc72637@pitrou.net>
References: <m2hbazueyx.fsf@valheru.db3l.homeip.net>
	<20110319195830.70ccc4f3@pitrou.net>
	<m2d3lmvqww.fsf@valheru.db3l.homeip.net>
	<20110319205211.2dc72637@pitrou.net>
Message-ID: <AANLkTikpgQmmLhHsB9mKAwB=6XuhwRMiodt26HQ_j=uc@mail.gmail.com>

On Sun, Mar 20, 2011 at 5:52 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> I suspect, however, that as soon as something else commits to the 3.x
>> branch and causes a new test, that test_crashers (presumably from
>> changeset 9c6dcb5d8f01) will likely just take the slaves down again.
>
> The test is already disabled. I don't know if Nick will remove it
> entirely, but it shouldn't cause any harm in the meantime.

Thanks for turning it off (I went to do that myself this morning only
to find you had already killed it).

I don't want to give up completely on the idea just yet, but I'll
experiment in the sandbox before I turn it back on.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Sun Mar 20 00:04:51 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 20 Mar 2011 00:04:51 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <AANLkTi=TgY-XWVaqUVEzJP76hvgU0XTN1AHTQbTu5YAg@mail.gmail.com>
References: <4D8446E0.7030401@skippinet.com.au>	<4D84FAB8.3040301@v.loewis.de>
	<AANLkTi=TgY-XWVaqUVEzJP76hvgU0XTN1AHTQbTu5YAg@mail.gmail.com>
Message-ID: <4D853693.20102@v.loewis.de>

Am 19.03.2011 23:51, schrieb Nick Coghlan:
> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I, for example, will find issues with it if the implementation uses
>> CreateProcess at some point - the launcher should IMO run Python
>> directly, rather than creating a new process. This, in turn, will
>> probably mean that you cannot actually implement the PEP in Python.
> 
> runpy performs basically that dance to implement
> _run_module_as_main(), so it's definitely possible.

Does it also support loading a different interpreter version than the
one it is running?

Regards,
Martin

From ncoghlan at gmail.com  Sun Mar 20 00:21:32 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Mar 2011 09:21:32 +1000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <19844.65128.436929.526859@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<19844.65128.436929.526859@montanaro.dyndns.org>
Message-ID: <AANLkTiktVXSRMLW0Z8iFVZ3LkAEDV8vui_A4f-OciXcU@mail.gmail.com>

On Sun, Mar 20, 2011 at 5:05 AM,  <skip at pobox.com> wrote:
> Sorry, this workflow is still new and hugely confusing to me. ?To make a
> simple edit to csv.rst I needed to do a couple pulls and merges, local
> commits, resolve the same conflict multiple times, get rebuffed when I first
> pushed because there was a tab in the file, and ask a question here. ?If
> this is the typical route necessary to make even the simplest changes which
> would have been a single commit with svn, my already meager rate of
> contributions is likely to wither away to nothing.

Note that some of that isn't unique to the Mercurial transition
(specifically, the server side hook that complained about the
whitespace change existed in SVN as well).

One key difference that we could historically ignore with SVN is that
it would happily accept changes from an out-of-date working copy, so
long as the committed changes didn't alter any files that had also
been updated on the head. In practice, this *did* mean a lot of
commits did get rejected, since Misc/NEWS would often conflict.
Mercurial's changeset based view of the world means it wants to know
how the changesets relate to each other even when they affect
different files, unlike SVN which would happily do an implicit merge
(creating a state in the central repo that no developer has ever
tested locally).

So the full flow for a trunk commit in SVN was:

svn update
# change stuff
svn commit -m "Whatever"
# get rejected by server side hooks (e.g. changed files, bad whitespace)
make patchcheck # fix whitespace issues
svn update # get updated files
# Resolve any conflicts, rerun relevant tests
svn commit -m "Whatever"

Mercurial isn't really all that different, but it's distributed nature
means it want to keep track of even minor things like the local
whitespace fixes and the merger of your changes with the other changes
that were pushed since you started work. So the example above becomes
something like:

hg pull -u
#change stuff
hg commit -m "Whatever"
hg push
# get rejected by server side hooks (e.g. changed files, bad whitespace)
make patchcheck
hg commit -m "Fix whitespace"
hg pull -u
hg merge
# Resolve any conflicts, rerun relevant tests
hg commit -m "Merge with remote"
hg push

It definitely produces some additional noise on python-checkins, since
things that would normally have been resolved privately by the
developer before SVN accepted the commit are now being published to
the mailing list. To help with that, I've personally split my
python-checkins label into two: one which contains everything from the
list, and another which filters out any messages with "merge" in the
subject line.

You may also find "hg outgoing" useful, since that will tell you all
the changesets that a call to "hg push" will publish, rather than just
the latest changeset as shown by "hg heads".

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sun Mar 20 00:23:21 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Mar 2011 09:23:21 +1000
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D853693.20102@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<AANLkTi=TgY-XWVaqUVEzJP76hvgU0XTN1AHTQbTu5YAg@mail.gmail.com>
	<4D853693.20102@v.loewis.de>
Message-ID: <AANLkTik+=dbKWreHQVkLdPfKqog6jd4ZgCxDJ7rvUH5b@mail.gmail.com>

On Sun, Mar 20, 2011 at 9:04 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 19.03.2011 23:51, schrieb Nick Coghlan:
>> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> I, for example, will find issues with it if the implementation uses
>>> CreateProcess at some point - the launcher should IMO run Python
>>> directly, rather than creating a new process. This, in turn, will
>>> probably mean that you cannot actually implement the PEP in Python.
>>
>> runpy performs basically that dance to implement
>> _run_module_as_main(), so it's definitely possible.
>
> Does it also support loading a different interpreter version than the
> one it is running?

Ouch, no. I guess you're right, any Python based solution will need to
create a child process.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From guido at python.org  Sun Mar 20 00:32:53 2011
From: guido at python.org (Guido van Rossum)
Date: Sat, 19 Mar 2011 16:32:53 -0700
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <4D850A36.3090602@v.loewis.de>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D850A36.3090602@v.loewis.de>
Message-ID: <AANLkTinR0nc_JghttG_o8Fhn=Q+8coKkMhugNn5PX8jr@mail.gmail.com>

On Sat, Mar 19, 2011 at 12:55 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> So I'd encourage everybody to keep asking questions, and request that
> they are answered in a polite manner, even if the one answering thinks
> that the same question is already answered in some documentation.

Thanks. I have some basic questions.

> The only alternative is that some people just give up contributing
> to Python.

I was about to do just that. :-) Now I've decided to take the plunge instead.

I made a test change to the 2.5 README and merged it into 2.6 and 2.7.
Then I pushed. It *seems* to have worked, but I also got some
traceback:

hg push
pushing to ssh://hg at hg.python.org/cpython
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 6 changes to 1 files
remote: change(s) NOT sent, something went wrong:
remote: [Failure instance: Traceback from remote host -- Traceback
(most recent call last):
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/banana.py",
line 153, in gotItem
remote:     self.callExpressionReceived(item)
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/banana.py",
line 116, in callExpressionReceived
remote:     self.expressionReceived(obj)
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/pb.py",
line 514, in expressionReceived
remote:     method(*sexp[1:])
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/pb.py",
line 826, in proto_message
remote:     self._recvMessage(self.localObjectForID, requestID,
objectID, message, answerRequired, netArgs, netKw)
remote: --- <exception caught here> ---
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/pb.py",
line 840, in _recvMessage
remote:     netResult = object.remoteMessageReceived(self, message,
netArgs, netKw)
remote:   File "/usr/lib/python2.6/dist-packages/twisted/spread/pb.py",
line 225, in perspectiveMessageReceived
remote:     state = method(*args, **kw)
remote:   File "/data/buildbot/master/master.cfg", line 87, in
perspective_addChange
remote:     changedict['category'] = branch_to_category[changedict['branch']]
remote: exceptions.KeyError: '2.5'
remote: ]
remote: notified python-checkins at python.org of incoming changeset 3074c77b7121
remote: notified python-checkins at python.org of incoming changeset cf5e4bdb24a1
remote: notified python-checkins at python.org of incoming changeset 89007356798b
remote: notified python-checkins at python.org of incoming changeset cc959f114739
remote: notified python-checkins at python.org of incoming changeset 69650b81f4b9
remote: notified python-checkins at python.org of incoming changeset 5ae4f3bbaebe

I also have trouble building the 2.5 branch on OS X Snow Leopard
(10.6) with Xcode 3.2 -- this is gcc 4.2.1. I think I'll just give up
on that part though, it's probably just too old, and 2.7 builds just
fine.

> I just hope that we can stick with Mercurial for more than five years,
> before the next hot thing comes along.

+1. Just as I hope for the Python 3-4 transition, I hope that whatever
comes along next has a better transition strategy. That would make it
really hot.

-- 
--Guido van Rossum (python.org/~guido)

From solipsis at pitrou.net  Sun Mar 20 00:39:49 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 20 Mar 2011 00:39:49 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <AANLkTinR0nc_JghttG_o8Fhn=Q+8coKkMhugNn5PX8jr@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D850A36.3090602@v.loewis.de>
	<AANLkTinR0nc_JghttG_o8Fhn=Q+8coKkMhugNn5PX8jr@mail.gmail.com>
Message-ID: <20110320003949.3ce64d01@pitrou.net>

On Sat, 19 Mar 2011 16:32:53 -0700
Guido van Rossum <guido at python.org> wrote:
> remote:   File "/data/buildbot/master/master.cfg", line 87, in
> perspective_addChange
> remote:     changedict['category'] = branch_to_category[changedict['branch']]
> remote: exceptions.KeyError: '2.5'
> remote: ]

That's because the buildbot notification hook tries to launch new builds
on branch 2.5 but it is unknown to the buildmaster.

Regards

Antoine.

From ncoghlan at gmail.com  Sun Mar 20 00:41:28 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Mar 2011 09:41:28 +1000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <AANLkTinR0nc_JghttG_o8Fhn=Q+8coKkMhugNn5PX8jr@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D850A36.3090602@v.loewis.de>
	<AANLkTinR0nc_JghttG_o8Fhn=Q+8coKkMhugNn5PX8jr@mail.gmail.com>
Message-ID: <AANLkTik2VnnUAvjzvaLUSrv20qEGAHEdGA7Y6EMrtAZ_@mail.gmail.com>

On Sun, Mar 20, 2011 at 9:32 AM, Guido van Rossum <guido at python.org> wrote:
> +1. Just as I hope for the Python 3-4 transition, I hope that whatever
> comes along next has a better transition strategy. That would make it
> really hot.

Given that the hardest part of any transition is updating developers'
brains, that would be some pretty damn neat neurohacking right there
:)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From db3l.net at gmail.com  Sun Mar 20 00:44:12 2011
From: db3l.net at gmail.com (David Bolen)
Date: Sat, 19 Mar 2011 19:44:12 -0400
Subject: [Python-Dev] buildbot VM exhausted in test_crashers
References: <m2hbazueyx.fsf@valheru.db3l.homeip.net>
	<20110319195830.70ccc4f3@pitrou.net>
	<m2d3lmvqww.fsf@valheru.db3l.homeip.net>
	<20110319205211.2dc72637@pitrou.net>
	<AANLkTikpgQmmLhHsB9mKAwB=6XuhwRMiodt26HQ_j=uc@mail.gmail.com>
Message-ID: <m2y64au14j.fsf@valheru.db3l.homeip.net>

Nick Coghlan <ncoghlan at gmail.com> writes:

> I don't want to give up completely on the idea just yet, but I'll
> experiment in the sandbox before I turn it back on.

If you get to that point again, I'd also be willing to pick a time to
manually check out the right branch or whatever and try it manually
on one of two of my slaves while I'm watching.

Typically I don't pay too much attention to various failures created
by testing, but this particular case breaks in a way that the slaves don't
recover, so is probably better to put a toe in the water slowly while
watching :-)

-- David


From dreamingforward at gmail.com  Sun Mar 20 00:47:17 2011
From: dreamingforward at gmail.com (Mark Janssen)
Date: Sat, 19 Mar 2011 17:47:17 -0600
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
Message-ID: <AANLkTino--j+uBCadzTeOjo71C6MKfRGWMQ7wPPYY0iY@mail.gmail.com>

On Sat, Mar 19, 2011 at 12:59 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:
>> On Sat, 19 Mar 2011 09:25:07 -0500
>> skip at pobox.com wrote:
>>
>>> The dev guide says something about collapsing changesets. ?Is that
>>> collapsing commits within a changeset or collapsing multiple changesets
>>> (whatever that might be)? ?Do I need this for a trivial change? ?Can I just
>>> push at this point? ?Once pushed, how does it get merged into the main
>>> codebase?
>>
>> Sincerely, I would really recommend that you read a Mercurial tutorial.
>> We could answer all your questions one by one but that wouldn't help you
>> much if you don't understand the concepts.
>
> Skip is not alone on this one. ?I've been using Mercurial for a couple of months now, have read multiple tutorials and whatnot, but am still not clear on how to follow the devguide's suggested cross-branch workflow.
>
> The dance of pulling, merging, reverting, collapsing, resolving, null merging, and rebasing cross-linked branches is somewhat more involved and complex than covered in any of the tutorials I've seen.

I think this will always be the case until someone develops a
wiki-type code revision system along with a voting model.  The most
reliable and highest ranking code would be a nucleus whereupon all
other revisions from other collaborators would revolve.  Links between
the revisions and the core would have "acceptance" requirements. All
would be organized around this circular nucleus rather than attempt
linearity (which not only requires a benevolent dictator, but that
everyone agree so that forks do not create factions -- or worse,
abandonment).   That being said, it would be a radical adjustment to
development style as there would no longer be a "canonical" or MAIN
authority.

But whatever, wanna help me built it?

Marcos,
pangaia.sf.net

From ncoghlan at gmail.com  Sun Mar 20 00:56:52 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Mar 2011 09:56:52 +1000
Subject: [Python-Dev] buildbot VM exhausted in test_crashers
In-Reply-To: <m2y64au14j.fsf@valheru.db3l.homeip.net>
References: <m2hbazueyx.fsf@valheru.db3l.homeip.net>
	<20110319195830.70ccc4f3@pitrou.net>
	<m2d3lmvqww.fsf@valheru.db3l.homeip.net>
	<20110319205211.2dc72637@pitrou.net>
	<AANLkTikpgQmmLhHsB9mKAwB=6XuhwRMiodt26HQ_j=uc@mail.gmail.com>
	<m2y64au14j.fsf@valheru.db3l.homeip.net>
Message-ID: <AANLkTimSYgGM2RWFpJSr-gbYwGo-fkAG2FHnkX8GRv3v@mail.gmail.com>

On Sun, Mar 20, 2011 at 9:44 AM, David Bolen <db3l.net at gmail.com> wrote:
> Nick Coghlan <ncoghlan at gmail.com> writes:
>
>> I don't want to give up completely on the idea just yet, but I'll
>> experiment in the sandbox before I turn it back on.
>
> If you get to that point again, I'd also be willing to pick a time to
> manually check out the right branch or whatever and try it manually
> on one of two of my slaves while I'm watching.
>
> Typically I don't pay too much attention to various failures created
> by testing, but this particular case breaks in a way that the slaves don't
> recover, so is probably better to put a toe in the water slowly while
> watching :-)

That would be great. The first thing I'll be trying (once I get back
to it) is simply skipping the crasher I think is the main cause of the
instability (the compiler recursion one). I already deliberately dodge
the two crashers that are known to cause infinite loops, skipping one
more wouldn't be a terrible outcome.

I need to bug Barry about his PPC buildbot as well. It seemed to be
surviving even after I had cranked the expression size in the compiler
recursion crasher to absolutely ridiculous levels, so I'm wondering if
there may be something different about the way PPC handles the stack.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From paul at boddie.org.uk  Sun Mar 20 01:52:28 2011
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 20 Mar 2011 01:52:28 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
Message-ID: <201103200152.28455.paul@boddie.org.uk>

Skip wrote:
> Antoine wrote:
> > 94 changesets? If you want to avoid risking conflicts, you should "hg
> > pull" and "hg up" (or "hg pull -u") before you start working on
> > something (just like you "svn up"'ed before working on something).
>
> Sorry, this workflow is still new and hugely confusing to me.  To make a
> simple edit to csv.rst I needed to do a couple pulls and merges, local
> commits, resolve the same conflict multiple times, get rebuffed when I
> first pushed because there was a tab in the file, and ask a question here. 
> If this is the typical route necessary to make even the simplest changes
> which would have been a single commit with svn, my already meager rate of
> contributions is likely to wither away to nothing.

This is reminiscent of a message on the Mercurial mailing list recently, to 
which I responded with a question about people experiencing problems with 
Mercurial because they are used to file- or directory-specific operations in 
other systems, eliciting this reply:

"hg failed saying there were uncommitted changes (his source code
changes in another part of the tree). He didn't want to commit those
changes yet, they weren't finished. So he was stuck. To his mind, hg
was being stupid because it was getting in his way, "unnecessarily"
linking changes in the two sets of files together. The concept of a
revision being a state of the whole repo was alien. For most people
that concept came in with svn."

http://www.selenic.com/pipermail/mercurial/2011-March/037373.html

I've spent some time trying to tidy up and improve a document on the Mercurial 
Wiki about CVS-like working practices with Mercurial, and this might explain 
the differences in operation between CVS/Subversion and Mercurial, although 
it doesn't yet distinguish between the "narrow" file-specific commits you get 
in systems like CVS and Subversion, and the whole-project commits you get in 
systems like Mercurial:

http://mercurial.selenic.com/wiki/CvsLikePractice

(By the time you look at that page, I might have added something, though.)

I'm certainly no expert with Mercurial, and I've only been using it as a 
personal tool since the MoinMoin guys introduced me to it back at EuroPython 
2006, so even now the "right way" or "best practice" when it comes to 
propagating fixes between branches/clones is something I'm still figuring 
out, but having lurked on the recent python-dev threads and having read 
various queries on the Mercurial list over the past year or so, I get the 
impression that reaching for things like rebase and mq as the first choice to 
solve various workflow problems would get some blunt criticism on the 
Mercurial list.

That said, I can't readily find any good guides to managing a multi-branch 
project, but there seem to be some interesting techniques documented for some 
of the situations people are likely to encounter. For example:

http://mercurial.selenic.com/wiki/DaggyFixes describes pulling fixes 
selectively which I'll probably have to try on some personal project at some 
point

http://hginit.com/05.html describes the presumably common way of propagating 
fixes from stable branches to development branches

Certainly, the Python devguide is a nice piece of documentation, but I feel 
that there's an opportunity here to address some documentation issues that 
would also help others using and adopting Mercurial. For example, 
submitting "clean" changes to a project (that "collapse" thing) is a topic 
for a document that could usefully be written, containing some nice diagrams 
that explain the mechanism to newcomers, and it would surely benefit more 
than just the CPython development effort.

Paul

From martin at v.loewis.de  Sun Mar 20 01:52:37 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 20 Mar 2011 01:52:37 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <AANLkTinR0nc_JghttG_o8Fhn=Q+8coKkMhugNn5PX8jr@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D850A36.3090602@v.loewis.de>
	<AANLkTinR0nc_JghttG_o8Fhn=Q+8coKkMhugNn5PX8jr@mail.gmail.com>
Message-ID: <4D854FD5.8000802@v.loewis.de>

> I made a test change to the 2.5 README and merged it into 2.6 and 2.7.
> Then I pushed. It *seems* to have worked, but I also got some
> traceback:

Oops. I wouldn't have expected that tracebacks propagate that far back.
This was your hg client talking to the remote hg client executing a
post-push hook talking to buildbot raising an exception (for there no
being builder category for 2.5).

Your changesets were accepted, anyway.

> I also have trouble building the 2.5 branch on OS X Snow Leopard
> (10.6) with Xcode 3.2 -- this is gcc 4.2.1. I think I'll just give up
> on that part though, it's probably just too old, and 2.7 builds just
> fine.

Yes, this is a known limitation. Please don't make any changes to the
2.5 branch unless they are security fixes (changing the copyright
is fine, but I'd rather avoid even documentation changes). If you
want to build the 2.5 branch, check it out from subversion.

Regards,
Martin

From victor.stinner at haypocalc.com  Sun Mar 20 02:00:39 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Sun, 20 Mar 2011 02:00:39 +0100
Subject: [Python-Dev] Have we lost changeset info in the buildbots
In-Reply-To: <m2sjupv6jg.fsf@valheru.db3l.homeip.net>
References: <4D7E496F.8050302@jcea.es> <20110314180756.45711629@pitrou.net>
	<m2sjupv6jg.fsf@valheru.db3l.homeip.net>
Message-ID: <1300582839.20491.1.camel@marge>

Le lundi 14 mars 2011 ? 15:36 -0400, David Bolen a ?crit :
> Antoine Pitrou <solipsis at pitrou.net> writes:
> 
> > I suggest you try http://code.google.com/p/bbreport/, which provides a
> > very nice command-line interface.
> 
> Speaking of bbreport, I sometimes use the published page on that site
> (http://code.google.com/p/bbreport/wiki/PythonBuildbotReport) to check
> over things, but looking at it today, it seems to most recently have been
> generated back in January.  Or is the generated date line wrong?

I ran a cron task to regenerate this page each hour, but I didn't get
any feedback and I stopped to use it, so I just removed the cron task.

Do you want that I restart this cron task?

I don't remember if bbreport can directly generate an HTML page or not.
If not, we should patch it :-)

Victor


From martin at v.loewis.de  Sun Mar 20 02:26:08 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 20 Mar 2011 02:26:08 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <20110320003949.3ce64d01@pitrou.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D850A36.3090602@v.loewis.de>	<AANLkTinR0nc_JghttG_o8Fhn=Q+8coKkMhugNn5PX8jr@mail.gmail.com>
	<20110320003949.3ce64d01@pitrou.net>
Message-ID: <4D8557B0.4010407@v.loewis.de>

Am 20.03.2011 00:39, schrieb Antoine Pitrou:
> On Sat, 19 Mar 2011 16:32:53 -0700
> Guido van Rossum <guido at python.org> wrote:
>> remote:   File "/data/buildbot/master/master.cfg", line 87, in
>> perspective_addChange
>> remote:     changedict['category'] = branch_to_category[changedict['branch']]
>> remote: exceptions.KeyError: '2.5'
>> remote: ]
> 
> That's because the buildbot notification hook tries to launch new builds
> on branch 2.5 but it is unknown to the buildmaster.

Not exactly. It tries to categorize the changes, so that they would
should up on a waterfall filtered by category. Since we have no
waterfall for 2.5, I didn't add any categorization for it. This should
now be fixed.

Regards,
Martin

From nad at acm.org  Sun Mar 20 02:59:43 2011
From: nad at acm.org (Ned Deily)
Date: Sat, 19 Mar 2011 18:59:43 -0700
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<19844.65128.436929.526859@montanaro.dyndns.org>
	<AANLkTiktVXSRMLW0Z8iFVZ3LkAEDV8vui_A4f-OciXcU@mail.gmail.com>
Message-ID: <nad-21FD11.18594319032011@news.gmane.org>

In article 
<AANLkTiktVXSRMLW0Z8iFVZ3LkAEDV8vui_A4f-OciXcU at mail.gmail.com>,
 Nick Coghlan <ncoghlan at gmail.com> wrote:
> Mercurial isn't really all that different, but it's distributed nature
> means it want to keep track of even minor things like the local
> whitespace fixes and the merger of your changes with the other changes
> that were pushed since you started work. So the example above becomes
> something like:
> 
> hg pull -u
> #change stuff
> hg commit -m "Whatever"
> hg push
> # get rejected by server side hooks (e.g. changed files, bad whitespace)
> make patchcheck
> hg commit -m "Fix whitespace"
> hg pull -u
> hg merge
> # Resolve any conflicts, rerun relevant tests
> hg commit -m "Merge with remote"
> hg push

As a side note, if you are prone to accidentally adding extra whitespace 
(like I am), you can add the whitespace check hook into your local copy 
of Mercurial so that you will be warned about whitespace problems 
immediately when you commit things to your local repos rather than later 
when you try to push them up to the python.org repo.  You will need to 
add checkwhitsepace.py and reindent.py from the official hooks repo into 
the site-packages directory of the Python instance where your copy of hg 
is installed and then configure the hook in an hgrc configuration file. 

On a Unix-y system, here is one way to do it (no warranty on the 
installation instructions!):

# try to avoid permission problems
umask 022
hg clone http://hg.python.org/hooks
cd hooks
# make a dummy setup.py file for distutils
cat >setup.py <<EOF1
from distutils.core import setup
setup(name='pydevhooks',
      version='0.1',
      py_modules=['checkwhitespace', 'reindent'],
      )
EOF1
# kludge to find the Python instance which your hg uses
HGPYTHON=$(head -1 $(which hg) | sed s'/#!//')
echo $HGPYTHON
# install the hooks 
sudo  $HGPYTHON setup.py install
#  configure the hooks in your global .hgrc file -> affects all hg repos
HGRC=~/.hgrc
#  ... or configure in specific repos
#HGRC=/path/to/your_repo/.hg/hgrc
cat >>$HGRC <<EOF2

[hooks]
pretxncommit.whitespace = python:checkwhitespace.check_whitespace_single
EOF2

-- 
 Ned Deily,
 nad at acm.org


From mhammond at skippinet.com.au  Sun Mar 20 03:38:44 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 20 Mar 2011 13:38:44 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D846CFA.2030808@g.nevcal.com>
References: <4D8446E0.7030401@skippinet.com.au> <4D846CFA.2030808@g.nevcal.com>
Message-ID: <4D8568B4.3070102@skippinet.com.au>

Thanks for the feedback!

On 19/03/2011 7:44 PM, Glenn Linderman wrote:
> Not all of the ideas below are complementary to each other, some are
> either or, to allow different thoughts to be inspired or different
> directions to be taken.
>
> Thanks for starting a PEP.
>
> On 3/18/2011 11:02 PM, Mark Hammond wrote:
>
>>      The launcher should be as simple as possible (but no simpler.)
>
> The launcher could be simpler if it isn't used for launching interactive
> interpreters as well as script references via Windows associations (more
> about that after the next quote).
>
> The launcher could be simpler if it just read through the file of its
> first parameter until it finds a line starting with #@ (process as a
> Windows version of Unix #!) or starting without a # (error case). This
> avoids the need parse such lines.

I don't agree with that at all.  The rules for the shebang parsing are 
very simple - see the man-page I reference in the pep - the file must 
start with the characters '#!' and the entire command must be < 127 
chars.  The only real "parsing" needed is to check if the specified 
command starts with one of 2 fixed strings.  I believe this is simpler 
than parsing multiple lines of the file.

 > Remember, the typical
> Windows user is not likely to place a #! line in their scripts in the
> first place, so teaching them what a Unix #! line is, and how the
> parameter after it should be something that Windows doesn't even use,
> and the launcher has to work hard to interpret, is not as simple as
> possible.

I disagree with various aspects of that - the "typical Windows user" is 
not going to add a shebang or variation of to their Python source files, 
period.  IMO, the kind of user who would is already somewhat likely to 
know of the shebang convention, so it would not be foreign.  Those 
remaining who are not familiar with it can simply be pointed at existing 
docs etc for the shebang line and their new knowledge now works on more 
than Windows (and more than Python on non-Windows platforms)

> The launcher could be simpler if the Python installer placed versioned
> Python executables on the PATH. Unfortunately, historically it hasn't.
> If it did, would, or the launcher installer would place them there for
> pre-existing versions of Python, then the launcher could work by
> launching the appropriate version of Python, expecting Windows to find
> it on the PATH. The PEP doesn't address the level of internal complexity
> of the launcher necessary to find where Python has been installed,
> neither for CPython, nor for the alternate implementations to be supported.

The PEP intentionally doesn't, but the implementation does - it already 
does exactly that for CPython.  Other implementation may need a 
different strategy, but we can cross that bridge when we come to it.

> The launcher could be simpler if a directory \usr\bin were created under
> Windows Program Files, placed on the PATH, and %ProgramFiles% prepended
> to the Unix #! line, with the Python/Jython/Cython installers placing
> appropriately versioned executables in that directory. Could even start
> a trend for programs ported from Unix. One could even place an "env"
> program there, for more simplicity.

Again, I disagree - I think in practice the code would be more complex, 
and having Python assert it "owns" such directories and executables is a 
can of worms we should avoid.

>
>>      * When used to launch an interactive Python interpreter, the launcher
>>        will support the first command-line argument optionally be a
>>        version specifier in the form "-n[.n]" (where n is a single
>>        integer) to nominate a specific version be used.  For example,
>>        while "py.exe" may locate and launch the latest Python 2.x
>>        implementation installed, a command-line such as "py.exe -3" could
>>        specify the latest Python 3.x implementation be launched, while
>>        "py.exe -2.6" could specify Python 2.6 be located and launched.
>>        If a Python 2.x implementation is desired to be launched with the
>>        -3 flag, the command-line would need to be similar to "py.exe -2
>>        -3" (or the specific version of Python could obviously be
>>        launched manually without use of this launcher.)
>
> I think that a python launcher that is "on the PATH" that could be used
> to launch an interactive Python, should be different than one that is
> used to launch XXXX.py[w] scripts.

I believe that if you know the Python you want is already on the PATH, 
you should just use 'python.exe' instead of 'py.exe'.  I don't see any 
reason to use this launcher for interactive Python sessions where this 
is the case.

> 1) python should be invoked interactively by typing "python" or
> "pythonX[.Y]" at the CMD prompt, not "py". This can be done without a
> launcher, if appropriate versioned pythons are placed on the PATH. The
> launcher is really and only needed for handling XXXX.py[w] scripts,
> which, in the Windows way of thinking, can only be associated with one
> specific, system-wide configured version of Python (presently, the
> latest one wins). The script itself is not examined to modify such an
> association. The Unix !# line provides such modification on Unix.

OK, I think we found something we can agree on :)  If the python.exe you 
want is on your path, just ignore this launcher for anything other than 
file associations.

> 2) If the launcher provides command line options for the "benefit" of
> launching interactive Python interpreters, those command line options
> can have data puns with script names, or can conflict with actual Python
> options. I believe Python 2 already has a -3 option, for example. And
> Windows users are not trained that "-" introduces an option syntax, but
> rather "/". Most _programmer_ users would probably be aware of "-" as an
> option syntax, but Python is used as a language for non-programmers in
> some circles, and few Windows non-programmers understand "/" much less
> "-" and not even command lines very well. So not using a launcher for
> launching interactive Python sidesteps all that: Python itself is
> introduced and taught, and no need to teach about (or even have)
> launcher options that could possibly conflict and confuse, in addition
> to Python options that may conflict with script names already. (I have
> seen lots of Windows users use leading punctuation characters on
> filenames to affect sort order and grouping of files in My Documents,
> not knowing they can create subdirectories/subfolders, or not wanting to
> bother with them, since all their applications default to opening things
> from My Documents.)

I'm not 100% sure of the points you are trying to make above, but the 
gist of it seems to be the same as (1) - use python.exe directly if you 
prefer - in which case I agree.  Obviously if people choose to use the 
new launcher interactively they are doing so because they see some 
benefit and would be willing to understand how it works.  So I don't see 
any problems here as I'm not advocating it would replace "python.exe" in 
interactive scenarios except where the user actively chooses to.

> 3) Unix !# lines can have embedded options after the program name on the
> line. Such options would be another source of potential conflict with
> launcher options, if the launcher has options for use with launching
> interactive interpreters.
>
> Item 3 is also an issue for the PEP even apart from its use as an
> interactive Python launcher; since options may exist on the Unix #!
> line, a discussion of how and if they are handled by the launcher should
> be included in the PEP.

I believe a reference to the execve man-page and the note in the PEP 
that we will support the description there, including limitations, is 
enough - but I'm happy to change this if people agree it is 
underspecified or confusing.

>
>>      * Environment varialbes will be used to override the semantics for
>>        determining exactly what version of Python will be used.  For
>>        example, while a shebang line of "/usr/bin/python2" will
>>        automatically locate a Python 2.x implementation, an environment
>>        variable can override exactly which Python 2.x implementation will
>>        be chosen.  Similarly for "/usr/bin/python" etc.
>
> Clarify if environment variables can be used to override semantics for
> shebang lines of the form "/usr/bin/python2.x".

On re-reading the PEP, I notice I deleted something which is important 
on the mistaken belief the execve man page would make it clear.  Only 
the first command-line argument will be checked for a shebang line.  If 
the first argument is an option (ie, starts with a '-'), nothing is 
examined for a shebang line.  This is what the reference implementation 
does and I'll be sure to update the PEP to reflect this.

The PEP does state the optional -N.N argument must be the first 
argument.  Therefore, the presence of the -N.N argument will avoid any 
shebang processing at all so can't impact the version selected via the 
shebang line.  This makes sense to me as someone explicitly executing 
"py.exe -3 foo.py" is explicitly overriding the version they want to run 
the script with.

> If alternate implementations are to be supported, additional virtual
> commands will be required, not just these two. Each one adds complexity
> to the launcher.

This is true - each implementation would need custom code to sniff out 
the requested implementation version.  I don't think this is a burden 
though and can be worked around by using fully-qualified executable 
names in the shebang line.

>>      Non-virtual shebang lines should be discouraged as they make the
>>      script specific to a specific Windows installation. However, they
>>      are supported for maximum flexibility.
>
> This is a false statement.

I believe it is a true statement - needing words like "likely" and 
"most" to dispute it just demonstrates that IMO.  Note that I don't 
dispute your statements, but instead believe that "most" simply isn't 
good enough - I want "always".

Unfortunately, it is clear we disagree on some fundamental points and I 
can't see a way to change my PEP that would keep both you and I happy. 
Therefore, the only reasonable resolution would be for you to draft a 
competing PEP and reference implementation which python-dev can 
informally vote on.

Cheers,

Mark

From mhammond at skippinet.com.au  Sun Mar 20 03:41:41 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 20 Mar 2011 13:41:41 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <AANLkTim+u_yPi09qTfY5TmztHqKX6qsT_rMzVxDKKHz=@mail.gmail.com>
References: <4D8446E0.7030401@skippinet.com.au> <4D846CFA.2030808@g.nevcal.com>
	<AANLkTim+u_yPi09qTfY5TmztHqKX6qsT_rMzVxDKKHz=@mail.gmail.com>
Message-ID: <4D856965.10805@skippinet.com.au>

On 20/03/2011 4:15 AM, Dj Gilcrease wrote:
> On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman<v+python at g.nevcal.com>  wrote:

>> 2) If the launcher provides command line options for the "benefit" of
>> launching interactive Python interpreters, those command line options can
>> have data puns with script names, or can conflict with actual Python
>> options.  I believe Python 2 already has a -3 option, for example.

FWIW, the point about Python 2 supporting a -3 arg is explicitly 
mentioned in the PEP.

>> Windows users are not trained that "-" introduces an option syntax, but
>> rather "/".  Most _programmer_ users would probably be aware of "-" as an
>> option syntax, but Python is used as a language for non-programmers in some
>> circles, and few Windows non-programmers understand "/" much less "-" and
>> not even command lines very well.  So not using a launcher for launching
>> interactive Python sidesteps all that: Python itself is introduced and
>> taught, and no need to teach about (or even have) launcher options that
>> could possibly conflict and confuse, in addition to Python options that may
>> conflict with script names already.  (I have seen lots of Windows users use
>> leading punctuation characters on filenames to affect sort order and
>> grouping of files in My Documents, not knowing they can create
>> subdirectories/subfolders, or not wanting to bother with them, since all
>> their applications default to opening things from My Documents.)
>
> The command line options I disagree with as well. If the user wants to
> test a script that has a shebang of python2 with python3 then they
> should explicitly launch it that way just like you would have to do on
> *nix

See my reply to Glenn on this - the optional -N.N argument must be the 
first arg, as must the file with the shebang - so if you specify -N.N, 
no shebang processing is done at all.

I expect that in general, the key advantage of shebang parsing will be 
when the script is launched via file association - eg, entering the 
command "foo.py" directly at the command-prompt or double-clicking from 
explorer.  Windows itself will lookup the association and execute 
"py.exe foo.py" - there is no opportunity for the user to arrange for 
arguments to be inserted in that command (only at the tail).

If a user explicitly specifies the command "py.exe -3 foo.py", I 
personally think it is fine the shebang line is ignored as the user has 
expressed a clear intention that a specific version of Python be used.

> No I think there should be at max 2 environment variables and they
> should be explicitly set by the user not added by default
> PYTHON_2
>      If set would override the latest version of python2 that is
> launched via a shebang line ending in python or python2 but not
> python2.x
> PYTHON_3
>      if set would override the latest version of python3 that is
> launched via a shebang line ending in python3 but not python3.x

The reference implementation currently supports 3 environment variables 
- while they have different names, 2 of them work as you describe above. 
  The third is used to nominate how a simple 'python' with no version 
qualifiers should be treated - I wanted the ability for the simple 
'python' to execute a python 3.x version if desired by the user.

> Thank you Mark for writing up this pep. It is almost identical to the
> one I was working up but covers more details and actually provides an
> implementation example. Other then the command line args I agree with
> everything covered.

Thanks for the feedback!

Cheers,

Mark

From mhammond at skippinet.com.au  Sun Mar 20 04:00:27 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 20 Mar 2011 14:00:27 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D84FAB8.3040301@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
Message-ID: <4D856DCB.5000600@skippinet.com.au>

On 20/03/2011 5:49 AM, "Martin v. L?wis" wrote:
>> * Is this really PEP material, or will turning the PEP into a regular
>> spec be suitable?
>
> It's PEP material if it is contentious, which I believe it is.

Of course it is - this is python-dev <wink>.

> I, for example, will find issues with it if the implementation uses
> CreateProcess at some point - the launcher should IMO run Python
> directly, rather than creating a new process. This, in turn, will
> probably mean that you cannot actually implement the PEP in Python.

Out of curiosity, what is your objection to having the child process?  I 
guess it must be the system resources needed for the parent process 
while it waits for the child to terminate so the exit code can be 
reflected correctly "up stream"?

I would have 3 main problems with dynamically loading Python into the 
launcher process:

* It may be difficult or impossible to do for implementations other than 
CPython.

* There are subtle differences when Python is loaded by an executable in 
the "install" directory versus by an executable that is not. 
Specifically, I'm thinking about the differences in how the default 
sys.path is populated.

* The registry doesn't currently tell us exactly where pythonxx.dll can 
be located, but does tell is where python.exe is.  Thus things would get 
a little more complex as we go snooping for the location of the DLL.

Note that these are almost certainly surmountable, but I wonder if the 
benefits outweigh the costs.

>> * If it is a PEP, is it "Standards Track" or "Informational"?
>
> If you are proposing to change the CPython code base (which I think you
> should), it's standards track. If you are talking about a tool provided
> by you on PyPI, you actually don't need to discuss it with anybody.

Thanks - "Standards Track" it is then :)  FWIW, I have no interest in 
making this a stand-alone project or distribution.  If there is 
agreement that this shouldn't be part of Python itself (which may well 
be a reasonable decision to make), I'll let the idea die.

>
>> * Does the functionality described strike the right balance between
>> simplicity and usefulness?
>
> It leaves a number of issues still open, so it's hard to tell yet.
> For example, the 32-bit vs. 64-bit issue should be resolved (which I
> think comes down to having 4 binaries).

This is an interesting one and one which I don't have a firm opinion 
about - but the soft opinion I have is something along the lines of "the 
functionality should not be dictated by the bittedness of the launcher 
itself".  IOW, if we decide that a 64bit implementation of Python should 
be chosen over a 32bit implementation of the exact same version, this 
should be done by both the 32bit and 64bit launchers.

Of course, I welcome more thoughts on this and could be easily swayed.

> Plus, it should talk about
> installation of multiple copies of the same Python version, e.g.
> from ActivePython, EPD, etc.

Good point - this is something I haven't considered at all.  Any 
thoughts on this from anyone?

> Notice that the PEP doesn't talk about file associations yet (but it
> should).

Actually, it does say '...the "console" version of the launcher should 
be associated with .py files and the "windows" version associated with 
.pyw files.'

What extra level of detail do you feel is necessary?

> I'm fine with the strategy, but I feel that the devil's in the detail.

Indeed!  But general approval for the strategy is an encouraging first 
step :)

Thanks!

Mark

From ben+python at benfinney.id.au  Sun Mar 20 04:01:25 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 20 Mar 2011 14:01:25 +1100
Subject: [Python-Dev] Avoiding whitespace conflicts (was: I am now lost -
	committed, pulled, merged, what is "collapse"?)
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<19844.65128.436929.526859@montanaro.dyndns.org>
	<AANLkTiktVXSRMLW0Z8iFVZ3LkAEDV8vui_A4f-OciXcU@mail.gmail.com>
	<nad-21FD11.18594319032011@news.gmane.org>
Message-ID: <87lj0a5wca.fsf_-_@benfinney.id.au>

Ned Deily <nad at acm.org> writes:

> As a side note, if you are prone to accidentally adding extra
> whitespace (like I am), you can add the whitespace check hook into
> your local copy of Mercurial so that you will be warned about
> whitespace problems immediately when you commit things to your local
> repos rather than later when you try to push them up to the python.org
> repo.

Even earlier that the attempt to commit, one can configure the text
editor to show whitespace in order to be aware of it at the point where
it's easiest to change:

    Emacs:

        M-x whitespace-mode RET

    Vim:

        :set list listchars=trail:?,tab:??

Or, instead of all whitespace, highlight trailing whitespace as an
error:

    Emacs:

        M-: (setq show-trailing-whitespace t) RET

    Vim:

        :set list listchars=trail:?,tab:??
        :highlight SpecialKey ctermfg=Yellow ctermbg=Red

Of course, any Python programmer hoping to comply with PEP 8 is best
advised to never insert a U+0009 HORIZONTAL TAB character:

    Emacs:

        M-: (setq indent-tabs-mode nil) RET

    Vim:

        :set expandtabs

One can even tell the editor to remove all the trailing whitespace:

    Emacs:

        M-x delete-trailing-whitespace RET

    Vim:

        :%s:\s\+$::

More:

    <URL:http://www.emacswiki.org/emacs/WhiteSpace>
    <URL:http://stackoverflow.com/questions/3165503/emacs-global-configuration-of-tabs>

    <URL:http://vim.wikia.com/wiki/Highlight_unwanted_spaces>
    <URL:http://vim.wikia.com/wiki/Remove_unwanted_spaces>
    <URL:http://stackoverflow.com/questions/69998/tabs-and-spaces-in-vim>

This allows a belt-and-braces approach: the repository will reject
attempts to commit with whitespace mistakes, but one's text editor can
be an ally in never getting to that point.

-- 
 \       ?For fast acting relief, try slowing down.? ?Jane Wagner, via |
  `\                                                       Lily Tomlin |
_o__)                                                                  |
Ben Finney


From eltoder at gmail.com  Sun Mar 20 04:10:31 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Sat, 19 Mar 2011 23:10:31 -0400
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D856DCB.5000600@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au>
Message-ID: <AANLkTikO5K5-iN_84DOu5u8xFEij_Ca1bwJcwHOTUu59@mail.gmail.com>

> Out of curiosity, what is your objection to having the child process?

One of the problems is that parent process will not be able to kill
launched script. Simply doing TerminateProcess will kill the launcher,
leaving interpreter running. This can be partially fixed with job
objects, though.

Eugene

From rdmurray at bitdance.com  Sun Mar 20 04:23:14 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Mar 2011 23:23:14 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <19844.64407.891398.896342@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319154951.C5A1713F988@kimball.webabinitio.net>
	<19844.64407.891398.896342@montanaro.dyndns.org>
Message-ID: <20110320032314.D8414C9669@kimball.webabinitio.net>

On Sat, 19 Mar 2011 13:53:11 -0500, skip at pobox.com wrote:
> 
>     >> I have a trivial little documentation patch for csv.rst.  I committed
>     >> it locally, then I pulled and merged:
> 
>     RDM> Note that if you want doc changes to appear in all the current doc
>     RDM> sets (2.7, 3.2, dev), then you should start with patching 3.2 and
>     RDM> merge it into default, and also patch 2.7, just like any other
>     RDM> bug-fix commit.
> 
> Sorry, I found updating cpython hard enough.  I almost gave up on just that
> one simple change.
> 
> Anyway, I thought I was supposed to pull from head to 3.2 and 2.7.  What is
> "dev"?

That's "doc speak", I guess.  http://docs.python.org/dev/library, for
example, points to the library reference for the docs on the default
branch.

--
R. David Murray           http://www.bitdance.com

From rdmurray at bitdance.com  Sun Mar 20 05:06:01 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 20 Mar 2011 00:06:01 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317143300.73e699b6@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
Message-ID: <20110320040601.573A4D5EAB@kimball.webabinitio.net>

On Thu, 17 Mar 2011 14:33:00 +0100,  wrote:
> On Thu, 17 Mar 2011 09:24:26 -0400
> "R. David Murray" <rdmurray at bitdance.com> wrote:
> > 
> > It would be great if rebase did work with share, that would make a
> > push race basically a non-issue for me.
> 
> rebase as well as strip destroy some history, meaning some of your
> shared clones may end up having their working copy based on a
> non-existent changeset. I'm not sure why rebase would be worse that
> strip in that regard, though.

Well, it turns out that this completely doesn't work, though at first
it appeared to (and so I pushed).

I had a push race, so I did hg pull; hg rebase.  Then I looked at the
log, and I could (apparently) see my change sets on the top of the
stack.  So I pushed.  Victor then asked why one of my commits deleted
Tools/demo/README, and then the next commit restored it.

What I was attempting to push was a doc change in 3.1 that I had then
merged to 3.2 and default.  What I saw when looking closer at the log
(after Victor pointed it out) was that my merge commits had lost their
parents.

I thought that at worst a rebase would screw up my local history, but
apparently I managed to push some sort of damaged history.  The doc
change only got applied to default, since that's the branch I
happened to be in when I did the rebase.

Needless to say, I'm avoiding rebase henceforth.

I don't think this had anything to do with share, by the way, but rather
the fact that I had merge commits before I did the rebase, and that
rebase apparently operates on branches, not the repository has a whole.
It would have been nice if rebase had refused to run given that
there were merges, since it clearly doesn't work in that case.

I'll backport the doc change tomorrow :(

--
R. David Murray           http://www.bitdance.com

From scott+python-dev at scottdial.com  Sun Mar 20 06:46:17 2011
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Sun, 20 Mar 2011 01:46:17 -0400
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <AANLkTik+=dbKWreHQVkLdPfKqog6jd4ZgCxDJ7rvUH5b@mail.gmail.com>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D84FAB8.3040301@v.loewis.de>	<AANLkTi=TgY-XWVaqUVEzJP76hvgU0XTN1AHTQbTu5YAg@mail.gmail.com>	<4D853693.20102@v.loewis.de>
	<AANLkTik+=dbKWreHQVkLdPfKqog6jd4ZgCxDJ7rvUH5b@mail.gmail.com>
Message-ID: <4D8594A9.5060602@scottdial.com>

On 3/19/2011 7:23 PM, Nick Coghlan wrote:
> On Sun, Mar 20, 2011 at 9:04 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Am 19.03.2011 23:51, schrieb Nick Coghlan:
>>> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>>> I, for example, will find issues with it if the implementation uses
>>>> CreateProcess at some point - the launcher should IMO run Python
>>>> directly, rather than creating a new process. This, in turn, will
>>>> probably mean that you cannot actually implement the PEP in Python.
>>>
>>> runpy performs basically that dance to implement
>>> _run_module_as_main(), so it's definitely possible.
>>
>> Does it also support loading a different interpreter version than the
>> one it is running?
> 
> Ouch, no. I guess you're right, any Python based solution will need to
> create a child process.

Why would that be true? Shouldn't this launcher just be a basic wrapper
that cobbles together the arguments for an eventual os.exec*() call?
What is there to do other than to exec the correct interpreter with (a
subset of?) the command-line arguments?

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From ncoghlan at gmail.com  Sun Mar 20 07:40:04 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Mar 2011 16:40:04 +1000
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D8594A9.5060602@scottdial.com>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<AANLkTi=TgY-XWVaqUVEzJP76hvgU0XTN1AHTQbTu5YAg@mail.gmail.com>
	<4D853693.20102@v.loewis.de>
	<AANLkTik+=dbKWreHQVkLdPfKqog6jd4ZgCxDJ7rvUH5b@mail.gmail.com>
	<4D8594A9.5060602@scottdial.com>
Message-ID: <AANLkTinXsB_DW73YuK6jkj2-Vf43+ZEBb4QDcY=AM_O4@mail.gmail.com>

On Sun, Mar 20, 2011 at 3:46 PM, Scott Dial
<scott+python-dev at scottdial.com> wrote:
> Why would that be true? Shouldn't this launcher just be a basic wrapper
> that cobbles together the arguments for an eventual os.exec*() call?
> What is there to do other than to exec the correct interpreter with (a
> subset of?) the command-line arguments?

Those all create a new process on Windows (there is much about Windows
process management which is annoying to anyone used to playing with a
Unix style process model).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From v+python at g.nevcal.com  Sun Mar 20 08:22:36 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Sun, 20 Mar 2011 00:22:36 -0700
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D8568B4.3070102@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au> <4D846CFA.2030808@g.nevcal.com>
	<4D8568B4.3070102@skippinet.com.au>
Message-ID: <4D85AB3C.6050802@g.nevcal.com>

On 3/19/2011 7:38 PM, Mark Hammond wrote:
> Thanks for the feedback!

And thanks for more complete explanations.

Sadly I was offline when writing my first response, and couldn't view 
the man page for execve you referred to.  Having just read it, I think 
it would be total gibberish to a Windows user who has only learned 
Python 2.x programming, and is now faced with migrating to 3.x, and 
wants to use this launcher to help make that a gradual process, instead 
of the full, instant migration required by the installation of Python 
3.x wiping out the associations from Python 2.x leaving his system with 
2.x unusable (from a na?ve point of view).  I have not found any support 
either from the installer or the documentation (but maybe I missed some 
things) that tell how to make Python 2.x and 3.x coexist happily on 
Windows, short of simply reinstalling the one you want to use.

A Windows user who has only learned Python 2.x programming would not 
necessarily have ever heard of execve, would not realize execve(2) means 
it is from the 2nd chapter of the Unix man pages, meaning an API call, 
would not know C programming, would not know what #include <unistd.h> 
means, would not understand syntax like "const" or "[]".  The 
description is a bit friendlier, if they get that far, but they may 
still be quite confused by wondering how to create and provide argv and 
envp in the right forms, wondering what SIGCHLD, PID, set-user-ID bit, 
SIG_IGN, SIG_DFL, SIGTRAP, set-group-ID, effective id, a.out, binary 
executable, shared library stubs, ld.so(8), ELF executable, PT_INTERP, 
and /lib/ld-unix.so.1 (and .2) are.

In short, anyone that is a Unix C programmer can easily understand this 
stuff, but anyone that is a Windows Python-only programmer will feel 
like understanding the launcher by reading that man page is similar in 
effort to getting their masters degree, and that if it is that hard to 
slowly migrate their 300 Python scripts to use Python 3.x while still 
using Python 2.x for those that are not converted, that they might as 
well just stick with Python 2.x.

Yes, the argument could be made that parts of Python also require some 
Unix knowledge and basic C knowledge to use effectively... but there are 
many Python programs that can be written without using the parts that 
require that knowledge.

That said, I don't think it would be an onerous task to extract a 
reasonable description of #! usage from the execve man page, and 
eliminate the Unix masters degree requirement.  In fact, only the 
following two paragraph fragments seem to be relevant to #! lines:

> ... a script starting with a line of the form "*#! /interpreter/* 
> [arg]".  ... the interpreter must be a valid pathname for an 
> executable which is not itself a script, which will be invoked as 
> *interpreter* [arg] /filename/.
>
> A maximum line length of 127 characters is allowed for the first line 
> in a #! executable shell script.
>

More below in context...

> On 19/03/2011 7:44 PM, Glenn Linderman wrote:
>> Not all of the ideas below are complementary to each other, some are
>> either or, to allow different thoughts to be inspired or different
>> directions to be taken.
>>
>> Thanks for starting a PEP.
>>
>> On 3/18/2011 11:02 PM, Mark Hammond wrote:
>>
>>>      The launcher should be as simple as possible (but no simpler.)
>>
>> The launcher could be simpler if it isn't used for launching interactive
>> interpreters as well as script references via Windows associations (more
>> about that after the next quote).
>>
>> The launcher could be simpler if it just read through the file of its
>> first parameter until it finds a line starting with #@ (process as a
>> Windows version of Unix #!) or starting without a # (error case). This
>> avoids the need parse such lines.
>
> I don't agree with that at all.  The rules for the shebang parsing are 
> very simple - see the man-page I reference in the pep - the file must 
> start with the characters '#!' and the entire command must be < 127 
> chars.  The only real "parsing" needed is to check if the specified 
> command starts with one of 2 fixed strings.  I believe this is simpler 
> than parsing multiple lines of the file.

Ah, but Mark!  You are confusing (and maybe I do in some of my comments 
too) the complexity of the launcher versus the complexity of describing 
the launcher.  It is really the complexity of describing the launcher 
(and remember, Unix doesn't need a launcher, it has #!, so you need to 
describe it to Windows users for Windows users) that matters most.  I 
find I often rewrite portions of my programs when I write the 
documentation to make them easier to describe.  And some say the docs 
should be written first, but then I find that I have to rewrite the docs 
to make the code possible :)  Whatever the order, the goal should be to 
make the program as useful as possible to a variety of users, with as 
little complexity as possible in the documentation.

So I still claim that it is easier to tell a Windows user that the 
launcher looks at comment lines starting from line 1 until it finds a 
line starting with #@ or finds a non-comment line, and executes it like 
the first paragraph I extracted from execve above, than to explain about 
how Unix works, why Unix uses / instead of \, why there is a special 
case for /usr/bin/python and /usr/bin/env python, and why there is a 127 
character limit (which need not be the case for a Windows specific 
line).  After describing that, the only reference to Unix that is 
necessary is to say that Unix implements a similar feature[footnote to 
execve man page] in the operating system with a line starting with #! 
which must be the very first line and limited to 127 characters, and 
that this Windows launcher is more flexible to accommodate using both 
techniques for cross-platform scripts.

>
> > Remember, the typical
>> Windows user is not likely to place a #! line in their scripts in the
>> first place, so teaching them what a Unix #! line is, and how the
>> parameter after it should be something that Windows doesn't even use,
>> and the launcher has to work hard to interpret, is not as simple as
>> possible.
>
> I disagree with various aspects of that - the "typical Windows user" 
> is not going to add a shebang or variation of to their Python source 
> files, period. 

IMO, when faced with migrating from 2.x to 3.x incrementally, the 
"typical Windows user" will look to the Python provided launcher 
solution to help (presuming that there is such a thing).  If it doesn't 
require a Unix masters degree, they'll give it whirl.  Something like

Install the launcher feature from Python 3.3 (or available separately 
somewhere), and add
#@C:\Python3.3\python.exe before the first non-comment line in the new 
Python 3 scripts.

In fact, this description just inspired me to suggest that the launcher 
should launch a Python 2 if it cannot find a #@ (or #! if I can't 
convince you of #@) line... that way old scripts stick with Python 2 
until they are converted.

> IMO, the kind of user who would is already somewhat likely to know of 
> the shebang convention, so it would not be foreign.  Those remaining 
> who are not familiar with it can simply be pointed at existing docs 
> etc for the shebang line and their new knowledge now works on more 
> than Windows (and more than Python on non-Windows platforms)

I agree that the users that already understand #! would gladly add it to 
their Windows Python scripts and understand it.  And I agree that those 
are probably the only users that would understand the execve Unix 
masters degree well enough to figure out a launcher that is described by 
pointed to that man page.  But I think a simple description of a 
launcher that uses Windows terminology (Unix users don't need a 
launcher) would be acceptable to a much larger subset of Windows users, 
that have learned a bit of Python scripting.  And those are the ones 
that need it.  The ones that understand #! have also figured out Windows 
assoc and ftype baloney, and have figured out how to switch back and 
forth from one version of Python (or anything else).  Or have given up 
using  XXXX.py and simply always invoke scripts with 
C:\PythonX.y\python.exe XXXX.py in frustration at the lack of a Python 
aid in this area.

>
>> The launcher could be simpler if the Python installer placed versioned
>> Python executables on the PATH. Unfortunately, historically it hasn't.
>> If it did, would, or the launcher installer would place them there for
>> pre-existing versions of Python, then the launcher could work by
>> launching the appropriate version of Python, expecting Windows to find
>> it on the PATH. The PEP doesn't address the level of internal complexity
>> of the launcher necessary to find where Python has been installed,
>> neither for CPython, nor for the alternate implementations to be 
>> supported.
>
> The PEP intentionally doesn't, but the implementation does - it 
> already does exactly that for CPython.  Other implementation may need 
> a different strategy, but we can cross that bridge when we come to it.

The PEP could therefore be clearer by discussing the CPython 
implementation strategy, even if it points out that other 
implementations may need a different strategy.  Putting PythonX.Y on the 
PATH eliminates the need for the launchers (py.exe and pyw.exe) to be on 
the path.  They are then only needed in the Windows associations, as I 
suggested somewhere.


>
>> The launcher could be simpler if a directory \usr\bin were created under
>> Windows Program Files, placed on the PATH, and %ProgramFiles% prepended
>> to the Unix #! line, with the Python/Jython/Cython installers placing
>> appropriately versioned executables in that directory. Could even start
>> a trend for programs ported from Unix. One could even place an "env"
>> program there, for more simplicity.
>
> Again, I disagree - I think in practice the code would be more 
> complex, and having Python assert it "owns" such directories and 
> executables is a can of worms we should avoid.

This was a random thought I had, which went a "more Unix" direction, 
instead of the "less Unix" direction of #@.  I didn't particularly like 
this one either, but it seemed to be a possible alternative, so I didn't 
want it to go unmentioned, in case thousands of other Python users 
thought it would be a great idea if only they had thought of it... :)


>>>      * When used to launch an interactive Python interpreter, the 
>>> launcher
>>>        will support the first command-line argument optionally be a
>>>        version specifier in the form "-n[.n]" (where n is a single
>>>        integer) to nominate a specific version be used.  For example,
>>>        while "py.exe" may locate and launch the latest Python 2.x
>>>        implementation installed, a command-line such as "py.exe -3" 
>>> could
>>>        specify the latest Python 3.x implementation be launched, while
>>>        "py.exe -2.6" could specify Python 2.6 be located and launched.
>>>        If a Python 2.x implementation is desired to be launched with 
>>> the
>>>        -3 flag, the command-line would need to be similar to "py.exe -2
>>>        -3" (or the specific version of Python could obviously be
>>>        launched manually without use of this launcher.)
>>
>> I think that a python launcher that is "on the PATH" that could be used
>> to launch an interactive Python, should be different than one that is
>> used to launch XXXX.py[w] scripts.
>
> I believe that if you know the Python you want is already on the PATH, 
> you should just use 'python.exe' instead of 'py.exe'.  I don't see any 
> reason to use this launcher for interactive Python sessions where this 
> is the case.
>
>> 1) python should be invoked interactively by typing "python" or
>> "pythonX[.Y]" at the CMD prompt, not "py". This can be done without a
>> launcher, if appropriate versioned pythons are placed on the PATH. The
>> launcher is really and only needed for handling XXXX.py[w] scripts,
>> which, in the Windows way of thinking, can only be associated with one
>> specific, system-wide configured version of Python (presently, the
>> latest one wins). The script itself is not examined to modify such an
>> association. The Unix !# line provides such modification on Unix.
>
> OK, I think we found something we can agree on :)  If the python.exe 
> you want is on your path, just ignore this launcher for anything other 
> than file associations.

So I think we are agreeing here, mostly.  And you mentioned having the 
CPython implementation PythonX.Y get on the PATH somehow.  So just keep 
the python launcher off the PATH, remove its then unnecessary option 
syntax, and we agree totally :)

>> 2) If the launcher provides command line options for the "benefit" of
>> launching interactive Python interpreters, those command line options
>> can have data puns with script names, or can conflict with actual Python
>> options. I believe Python 2 already has a -3 option, for example. And
>> Windows users are not trained that "-" introduces an option syntax, but
>> rather "/". Most _programmer_ users would probably be aware of "-" as an
>> option syntax, but Python is used as a language for non-programmers in
>> some circles, and few Windows non-programmers understand "/" much less
>> "-" and not even command lines very well. So not using a launcher for
>> launching interactive Python sidesteps all that: Python itself is
>> introduced and taught, and no need to teach about (or even have)
>> launcher options that could possibly conflict and confuse, in addition
>> to Python options that may conflict with script names already. (I have
>> seen lots of Windows users use leading punctuation characters on
>> filenames to affect sort order and grouping of files in My Documents,
>> not knowing they can create subdirectories/subfolders, or not wanting to
>> bother with them, since all their applications default to opening things
>> from My Documents.)
>
> I'm not 100% sure of the points you are trying to make above, but the 
> gist of it seems to be the same as (1) - use python.exe directly if 
> you prefer - in which case I agree.  Obviously if people choose to use 
> the new launcher interactively they are doing so because they see some 
> benefit and would be willing to understand how it works.  So I don't 
> see any problems here as I'm not advocating it would replace 
> "python.exe" in interactive scenarios except where the user actively 
> chooses to.

Does anyone see any benefit to using a launcher, if PythonX.Y is on the 
PATH?  I don't.  I see putting PythonX.Y as an extremely useful feature 
available for Unix Python that is totally missing from Windows Python, 
to its large detriment.  But that is not a feature the launcher should 
have to supply, but since Python hasn't been, a launcher installer may 
need to, to compensate.


>
>> 3) Unix !# lines can have embedded options after the program name on the
>> line. Such options would be another source of potential conflict with
>> launcher options, if the launcher has options for use with launching
>> interactive interpreters.
>>
>> Item 3 is also an issue for the PEP even apart from its use as an
>> interactive Python launcher; since options may exist on the Unix #!
>> line, a discussion of how and if they are handled by the launcher should
>> be included in the PEP.
>
> I believe a reference to the execve man-page and the note in the PEP 
> that we will support the description there, including limitations, is 
> enough - but I'm happy to change this if people agree it is 
> underspecified or confusing.

Per the beginning of this email, I think you need to stay far away from 
referencing the execve man page in a description of a Windows launcher, 
except perhaps as a footnote.

Until there is a benefit seen to using a launcher from the command line, 
I think it should (1) not be on the PATH (2) have no option syntax, 
which gets things back to a simple description.

>
>>
>>>      * Environment varialbes will be used to override the semantics for
>>>        determining exactly what version of Python will be used.  For
>>>        example, while a shebang line of "/usr/bin/python2" will
>>>        automatically locate a Python 2.x implementation, an environment
>>>        variable can override exactly which Python 2.x implementation 
>>> will
>>>        be chosen.  Similarly for "/usr/bin/python" etc.
>>
>> Clarify if environment variables can be used to override semantics for
>> shebang lines of the form "/usr/bin/python2.x".
>
> On re-reading the PEP, I notice I deleted something which is important 
> on the mistaken belief the execve man page would make it clear.  Only 
> the first command-line argument will be checked for a shebang line.  
> If the first argument is an option (ie, starts with a '-'), nothing is 
> examined for a shebang line.  This is what the reference 
> implementation does and I'll be sure to update the PEP to reflect this.
>
> The PEP does state the optional -N.N argument must be the first 
> argument.  Therefore, the presence of the -N.N argument will avoid any 
> shebang processing at all so can't impact the version selected via the 
> shebang line.  This makes sense to me as someone explicitly executing 
> "py.exe -3 foo.py" is explicitly overriding the version they want to 
> run the script with.

Not using the launcher from the command line, and it not having any 
available options, would sidestep this issue nicely.

Here you didn't respond to the question about overriding semantics of 
/usr/bin/pythonX.Y, but your reply to Dj did.  Please clarify it in the 
PEP, however.  Thanks.

>> If alternate implementations are to be supported, additional virtual
>> commands will be required, not just these two. Each one adds complexity
>> to the launcher.
>
> This is true - each implementation would need custom code to sniff out 
> the requested implementation version.  I don't think this is a burden 
> though and can be worked around by using fully-qualified executable 
> names in the shebang line.

No, the workaround of using fully-qualified executable names in the 
shebang line makes the script now dysfunctional on Unix.   So it would 
not be possible to use CPython on Unix, and IronPython on Windows, nor 
jpython on Unix and CPython on Windows, nor any other 
cross-implementation scripts, should different implementations be used 
on different platforms in a particular environment.  This is one of the 
reasons I like a separate #@ line for a Windows launcher.  It permits 
the flexibility of specifying both the implementation and the version 
separately for the different platforms, which would be complex to 
achieve if both platforms look at  the same #! line.

>
>>>      Non-virtual shebang lines should be discouraged as they make the
>>>      script specific to a specific Windows installation. However, they
>>>      are supported for maximum flexibility.
>>
>> This is a false statement.
>
> I believe it is a true statement - needing words like "likely" and 
> "most" to dispute it just demonstrates that IMO.  Note that I don't 
> dispute your statements, but instead believe that "most" simply isn't 
> good enough - I want "always".

I don't think you'll get "always", because of environments that use 
different implementations on different platforms.  To get always, you 
need the flexibility to specify implementation and version for each 
platform separately... two lines.  I recall an environment I once worked 
in where yacc was used on Unix, and bison on Windows, for example... as 
a counter-argument for anyone that wants to jump in a say that such a 
split implementation environment would surely never exist.  And 
differing C implementations between Unix/Windows also, in another 
environment. I wasn't using Python in those days, but I recall having 
different versions of Perl available between Unix/Windows.  Etc.

It may be true that it is better to rely on the Windows path, 
specifying  #@pythonX.Y  instead of  #@C:\PythonX.Y\python.exe if 
Python, or the launcher installer, can arrange to get all the pythonX.Y 
on the PATH.

> Unfortunately, it is clear we disagree on some fundamental points and 
> I can't see a way to change my PEP that would keep both you and I 
> happy. Therefore, the only reasonable resolution would be for you to 
> draft a competing PEP and reference implementation which python-dev 
> can informally vote on.

Let's enumerate... and maybe if we keep talking we'll increase the 
agreement list and decrease the disagreement list.

New ideas in this message:
1) If launcher doesn't find a #!/#@ line, it should run python2 to 
support scripts without such lines.

Agreements:
1) Python needs PythonX.Y to be on the PATH
2) Need a launcher to handle Windows associations that otherwise only 
allow one version for one extension
3) Need a separate launcher for .py and .pyw
4) Support for as many environments as possible, and as many 
installations as possible for each environment.

Disagreements:
1) #! only, with "virtual" paths   versus   #! for Unix, #@ for Windows 
to support different implementations and versions on the different 
platforms.
2) Use launcher from command line  versus   use PythonX.Y from the 
command line for interactive Python interpreters, don't put launcher on 
the PATH, its interactive option just adds complexity, not benefit. (Not 
sure if we disagree all that much here, my position is very close to +/- 
0 on this one -- just wondering if there is any benefit to the added 
complexity of documenting it for command line use)
3) Reference execve man page and expect Windows users to understand it  
versus   document one paragraph for how a similar feature works on Windows
4) The launcher should be as simple as possible (but no simpler)  
versus  The launcher should be as useful as possible to a variety of 
users, with as little complexity as possible in the documentation.

What else?  Can I borrow and tweak your reference implementation?  I'm 
seriously awash in multiple projects, most of which want to use 
cross-platform Python, so I see this topic as extremely important for my 
future projects, but haven't written C in so long I'd hate to try to 
commit to more than a reference implementation in Python.

> Cheers,
>
> Mark

Hopefully you are still cheery :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110320/8426ec53/attachment-0001.html>

From mhammond at skippinet.com.au  Sun Mar 20 09:00:00 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 20 Mar 2011 19:00:00 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D85AB3C.6050802@g.nevcal.com>
References: <4D8446E0.7030401@skippinet.com.au> <4D846CFA.2030808@g.nevcal.com>
	<4D8568B4.3070102@skippinet.com.au> <4D85AB3C.6050802@g.nevcal.com>
Message-ID: <4D85B400.3000602@skippinet.com.au>

On 20/03/2011 6:22 PM, Glenn Linderman wrote:
> On 3/19/2011 7:38 PM, Mark Hammond wrote:
...
> A Windows user who has only learned Python 2.x programming would not
> necessarily have ever heard of execve, would not realize execve(2) means
> it is from the 2nd chapter of the Unix man pages, meaning an API call,
> would not know C programming, would not know what #include <unistd.h>
> means, would not understand syntax like "const" or "[]". The description
> is a bit friendlier, if they get that far, but they may still be quite
> confused by wondering how to create and provide argv and envp in the
> right forms, wondering what SIGCHLD, PID, set-user-ID bit, SIG_IGN,
> SIG_DFL, SIGTRAP, set-group-ID, effective id, a.out, binary executable,
> shared library stubs, ld.so(8), ELF executable, PT_INTERP, and
> /lib/ld-unix.so.1 (and .2) are.

Sorry, I didn't mean to imply we would refer people to the execve man 
page, but simply that the man page defines the behaviour from the POV of 
the PEP.

> Ah, but Mark! You are confusing (and maybe I do in some of my comments
> too) the complexity of the launcher versus the complexity of describing
> the launcher.

I believe it will be simple to describe it -as you mention, the execve 
man page needs only a couple of sentences - I believe with just a few 
more it can be documented with the same clarity and quality as the rest 
of the Python docs for Windows users.

> The PEP could therefore be clearer by discussing the CPython
> implementation strategy, even if it points out that other
> implementations may need a different strategy.

I believe it states fairly clearly that the reference implementation 
defines much of this, and the reference implementation I referred to 
does indeed implement (and therefore define) it.  The PEP does make 
mention of other implementations.

> So I think we are agreeing here, mostly. And you mentioned having the
> CPython implementation PythonX.Y get on the PATH somehow. So just keep
> the python launcher off the PATH, remove its then unnecessary option
> syntax, and we agree totally :)

Not quite - my point is that *if* a CPython implementation is on the 
path (which many users arrange), then there is no advantage to using the 
launcher for that specific Python.  I personally don't have any CPython 
implementation on my path (actually, that isn't totally true - cygwin's 
Python is for my command-prompts), and therefore would find the 
behaviour described in the launcher incredibly useful.  This scratches 
my itch and unless the option does harm for people who choose not to use 
it, I see no problem with supporting it.

> Does anyone see any benefit to using a launcher, if PythonX.Y is on the
> PATH? I don't.

Fair enough.  But users who do not have a PythonX.Y on the PATH (even if 
they have another X.Y on it) will.

> Per the beginning of this email, I think you need to stay far away from
> referencing the execve man page in a description of a Windows launcher,
> except perhaps as a footnote.

The PEP is not intended to be user documentation, but if it is to be 
used in that way I'd be happy to document it directly in the PEP.

> Not using the launcher from the command line, and it not having any
> available options, would sidestep this issue nicely.

I don't see what issue needs to be side-stepped.  IMO the feature can be 
clearly described (even if my initial PEP didn't do so) and easily 
avoided if not desired.

> No, the workaround of using fully-qualified executable names in the
> shebang line makes the script now dysfunctional on Unix.

No - as the PEP says, if it can be expected to work on Unix, it should 
be expected to work on Windows.  Otherwise, the script is inherently 
dysfunctional on Unix, so the fully-qualified path is perfectly reasonable.

> I don't think you'll get "always", because of environments that use
> different implementations on different platforms. To get always, you
> need the flexibility to specify implementation and version for each
> platform separately... two lines.

Sorry, but I just don't go for this at all.  Please don't continue to 
advocate for that in a PEP I am sponsoring - just propose your own.

> Let's enumerate... and maybe if we keep talking we'll increase the
> agreement list and decrease the disagreement list.
>
> New ideas in this message:
> 1) If launcher doesn't find a #!/#@ line, it should run python2 to
> support scripts without such lines.

Sorry if the PEP didn't make it clear, but that is how the reference 
implementation works.  You might like to try it.

> Agreements:
> 1) Python needs PythonX.Y to be on the PATH

Nope.

> 2) Need a launcher to handle Windows associations that otherwise only
> allow one version for one extension
> 3) Need a separate launcher for .py and .pyw

Yep.

> 4) Support for as many environments as possible, and as many
> installations as possible for each environment.

Nope - "supports standard Python installations on all Windows 
installations".  Note the "all".

> What else? Can I borrow and tweak your reference implementation?

Please do!

Cheers,

Mark

From cesare.di.mauro at gmail.com  Sun Mar 20 09:40:03 2011
From: cesare.di.mauro at gmail.com (Cesare Di Mauro)
Date: Sun, 20 Mar 2011 09:40:03 +0100
Subject: [Python-Dev] PyLongObject "safe" changes?
Message-ID: <AANLkTinF16AjqbYPDR3jXRDRXCtDZrjqneYtLch0FgtW@mail.gmail.com>

Hi

I have little knowledge of some Python (3.2) internals on objects' internal
structure handling.

Suppose that I have any PyLongObject object (even internal / shared ones)
and that
- I need to change some or all of its internal values (size, sign, digits)
in a "critical section";
- the critical section is C code only;
- no CPython APIs will be called (all work is on local vars and object's
internal values);
- the object internal structure is completely restored before exiting from
the critical section.

Is it thread / interpreter safe or something dirty can happen?

Cesare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110320/1645e270/attachment.html>

From tjreedy at udel.edu  Sun Mar 20 10:36:19 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 20 Mar 2011 05:36:19 -0400
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D85AB3C.6050802@g.nevcal.com>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D846CFA.2030808@g.nevcal.com>	<4D8568B4.3070102@skippinet.com.au>
	<4D85AB3C.6050802@g.nevcal.com>
Message-ID: <im4hqe$5lf$1@dough.gmane.org>

On 3/20/2011 3:22 AM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
[snip]

As both a writer and reader, I would like to just add, for instance,

#! python3

(or 3.3 or whatever) and have the launcher do the 'right thing'.
It seems to me that that really should be enough info for *nix,
but given that it is not, a program to add the required extra noise  for 
a particular distribution to the first line of every module in a package 
should not be too difficult.

The above would be easy for anyone to write and understand.

-- 
Terry Jan Reedy


From martin at v.loewis.de  Sun Mar 20 10:37:14 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 20 Mar 2011 10:37:14 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D856DCB.5000600@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au>
Message-ID: <4D85CACA.1070400@v.loewis.de>

> Out of curiosity, what is your objection to having the child process?  I
> guess it must be the system resources needed for the parent process
> while it waits for the child to terminate so the exit code can be
> reflected correctly "up stream"?

I see three problems with creating child processes:
- WaitForSingleObject and GetExitProcessCode must work correctly. I
  think this is possible to achieve
- applications using the debug API, PSAPI, etc. will be confused if
  the action all happens in a child process. I can accept that they
  have to adjust, though.
- TerminateProcess must work correctly, and I see no way to achieve
  that (i.e. terminating the parent process won't terminate the child)

> I would have 3 main problems with dynamically loading Python into the
> launcher process:
> 
> * It may be difficult or impossible to do for implementations other than
> CPython.

That wouldn't bother me.

> * There are subtle differences when Python is loaded by an executable in
> the "install" directory versus by an executable that is not.
> Specifically, I'm thinking about the differences in how the default
> sys.path is populated.

This would need to be fixed. I.e. the launcher would have to arrange it
so it gives the illusion of having been started from the executable.

> * The registry doesn't currently tell us exactly where pythonxx.dll can
> be located, but does tell is where python.exe is.  Thus things would get
> a little more complex as we go snooping for the location of the DLL.

The launcher can know how all released Python versions behaved, so it
can adjust.

> Actually, it does say '...the "console" version of the launcher should
> be associated with .py files and the "windows" version associated with
> .pyw files.'

Ah, ok, I missed that.

Regards,
Martin

From martin at v.loewis.de  Sun Mar 20 10:39:48 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 20 Mar 2011 10:39:48 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D8594A9.5060602@scottdial.com>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D84FAB8.3040301@v.loewis.de>	<AANLkTi=TgY-XWVaqUVEzJP76hvgU0XTN1AHTQbTu5YAg@mail.gmail.com>	<4D853693.20102@v.loewis.de>
	<AANLkTik+=dbKWreHQVkLdPfKqog6jd4ZgCxDJ7rvUH5b@mail.gmail.com>
	<4D8594A9.5060602@scottdial.com>
Message-ID: <4D85CB64.7030801@v.loewis.de>

>>> Does it also support loading a different interpreter version than the
>>> one it is running?
>>
>> Ouch, no. I guess you're right, any Python based solution will need to
>> create a child process.
> 
> Why would that be true? Shouldn't this launcher just be a basic wrapper
> that cobbles together the arguments for an eventual os.exec*() call?

Windows doesn't support exec*(3).

Regards,
Martin

From martin at v.loewis.de  Sun Mar 20 10:57:28 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 20 Mar 2011 10:57:28 +0100
Subject: [Python-Dev] PyLongObject "safe" changes?
In-Reply-To: <AANLkTinF16AjqbYPDR3jXRDRXCtDZrjqneYtLch0FgtW@mail.gmail.com>
References: <AANLkTinF16AjqbYPDR3jXRDRXCtDZrjqneYtLch0FgtW@mail.gmail.com>
Message-ID: <4D85CF88.7060805@v.loewis.de>

> Is it thread / interpreter safe or something dirty can happen?

It is safe, thanks to the global interpreter lock (a.k.a. GIL).

Regards,
Martin

From skippy.hammond at gmail.com  Sun Mar 20 10:58:15 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Sun, 20 Mar 2011 20:58:15 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <im4hqe$5lf$1@dough.gmane.org>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D846CFA.2030808@g.nevcal.com>	<4D8568B4.3070102@skippinet.com.au>
	<4D85AB3C.6050802@g.nevcal.com> <im4hqe$5lf$1@dough.gmane.org>
Message-ID: <4D85CFB7.3050801@gmail.com>

On 20/03/2011 8:36 PM, Terry Reedy wrote:
> On 3/20/2011 3:22 AM, Glenn Linderman wrote:
> On 3/19/2011 7:38 PM, Mark Hammond wrote:
> [snip]
>
> As both a writer and reader, I would like to just add, for instance,
>
> #! python3
>
> (or 3.3 or whatever) and have the launcher do the 'right thing'.

If there was general agreement, I'd be happy for the PEP to support that 
variation.

Cheers,

Mark

From mhammond at skippinet.com.au  Sun Mar 20 11:25:59 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 20 Mar 2011 21:25:59 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D85CACA.1070400@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
Message-ID: <4D85D637.3040403@skippinet.com.au>

On 20/03/2011 8:37 PM, "Martin v. L?wis" wrote:
...
> ... problems with creating child processes:
> - applications using the debug API, PSAPI, etc. will be confused if
>    the action all happens in a child process. I can accept that they
>    have to adjust, though.

Some of these uses probably shouldn't use the launcher directly - eg, 
ISAPI apps and COM objects which have a separate registration step could 
register a specific python.exe - the installation script itself could by 
launched by the launcher, but that script could continue to use 
sys.executable to record the specific python.exe.

A side effect of this though is that if a newer version of python is 
installed such that "py.exe register.py" now used the later version, the 
existing registration would still use the older version until 
re-registered.  I think that is reasonable though.

> - TerminateProcess must work correctly, and I see no way to achieve
>    that (i.e. terminating the parent process won't terminate the child)

I understand this concern (and meant to say this in reply to Eugene's 
mail), but wonder if it isn't similar to the above - that if some 
program wants to launch python and note the id of the child process so 
it can terminate the child later, then python.exe could continue to be 
used.  OTOH, if you are terminating the process by using Process Manager 
or something else to find a 'python.exe', that will continue to work and 
the parent py.exe will automatically silently terminate.

> That wouldn't bother me.
>
>> * There are subtle differences when Python is loaded by an executable in
>> the "install" directory versus by an executable that is not.
>> Specifically, I'm thinking about the differences in how the default
>> sys.path is populated.
>
> This would need to be fixed. I.e. the launcher would have to arrange it
> so it gives the illusion of having been started from the executable.

It isn't immediately obvious how that could be done though - although I 
admit I haven't looked into it.

But in general, I'd be happy for py.exe to avoid CreateProcess for 
CPython if that could be reasonably done and was the consensus...

Thanks,

Mark

From solipsis at pitrou.net  Sun Mar 20 12:17:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 20 Mar 2011 12:17:25 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110320040601.573A4D5EAB@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
Message-ID: <1300619845.3481.0.camel@localhost.localdomain>

Le dimanche 20 mars 2011 ? 00:06 -0400, R. David Murray a ?crit :
> On Thu, 17 Mar 2011 14:33:00 +0100,  wrote:
> > On Thu, 17 Mar 2011 09:24:26 -0400
> > "R. David Murray" <rdmurray at bitdance.com> wrote:
> > > 
> > > It would be great if rebase did work with share, that would make a
> > > push race basically a non-issue for me.
> > 
> > rebase as well as strip destroy some history, meaning some of your
> > shared clones may end up having their working copy based on a
> > non-existent changeset. I'm not sure why rebase would be worse that
> > strip in that regard, though.
> 
> Well, it turns out that this completely doesn't work, though at first
> it appeared to (and so I pushed).
> 
> I had a push race, so I did hg pull; hg rebase.

Have you tried hg pull --rebase instead?
If you "hg rebase" by hand, I think you have to tell it the right set of
revisions to rebase.

Regards

Antoine.



From ben+python at benfinney.id.au  Sun Mar 20 12:19:10 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 20 Mar 2011 22:19:10 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
	launcher for Windows
References: <4D8446E0.7030401@skippinet.com.au>
	<4D846CFA.2030808@g.nevcal.com> <4D8568B4.3070102@skippinet.com.au>
	<4D85AB3C.6050802@g.nevcal.com> <im4hqe$5lf$1@dough.gmane.org>
Message-ID: <87hbay59ap.fsf@benfinney.id.au>

Terry Reedy <tjreedy at udel.edu> writes:

> As both a writer and reader, I would like to just add, for instance,
>
> #! python3
>
> (or 3.3 or whatever) and have the launcher do the 'right thing'. It
> seems to me that that really should be enough info for *nix,

For clarity: the reason it's not enough information is because the
kernel doesn't go hunting for the interpreter. The shebang line needs to
specify the full filesystem path of the interpreter program.

-- 
 \     ?The Vatican is not a state.? a state must have territory. This |
  `\         is a palace with gardens, about as big as an average golf |
_o__)                         course.? ?Geoffrey Robertson, 2010-09-18 |
Ben Finney


From stefan_ml at behnel.de  Sun Mar 20 12:19:12 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Mar 2011 12:19:12 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
Message-ID: <im4nrg$ph$1@dough.gmane.org>

Nick Coghlan, 12.03.2011 12:43:
> I posted my rough notes and additional write-ups for Wednesday's VM
> summit and Thursday's language summit:
>
> http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
> http://www.boredomandlaziness.org/2011/03/python-vm-summit-somewhat-coherent.html
> http://www.boredomandlaziness.org/2011/03/python-language-summit-rough-notes.html
> http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html

It appears that there has been little mention of Cython at the summit, 
despite of the speed of CPython being a major topic, according to the 
notes. I can see several areas where Cython could help in speeding up core 
CPython, one of the most obvious being compilation of standard library 
modules, and JIT-like compilation of Python modules at import time.

Nick mentioned that there was a discussion of making C-only modules 
available as alternative Python implementations. I'd like to suggest the 
opposite as well: make pure Python stdlib modules optionally compilable to 
fast C code using Cython. The obvious advantages are a) speed and b) a 
single code base for both Python and C modules.

Stefan


From jnoller at gmail.com  Sun Mar 20 12:32:34 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Sun, 20 Mar 2011 07:32:34 -0400
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im4nrg$ph$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
Message-ID: <AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>

On Sun, Mar 20, 2011 at 7:19 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Nick Coghlan, 12.03.2011 12:43:
>>
>> I posted my rough notes and additional write-ups for Wednesday's VM
>> summit and Thursday's language summit:
>>
>>
>> http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
>>
>> http://www.boredomandlaziness.org/2011/03/python-vm-summit-somewhat-coherent.html
>>
>> http://www.boredomandlaziness.org/2011/03/python-language-summit-rough-notes.html
>>
>> http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html
>
> It appears that there has been little mention of Cython at the summit,
> despite of the speed of CPython being a major topic, according to the notes.
> I can see several areas where Cython could help in speeding up core CPython,
> one of the most obvious being compilation of standard library modules, and
> JIT-like compilation of Python modules at import time.
>
> Nick mentioned that there was a discussion of making C-only modules
> available as alternative Python implementations. I'd like to suggest the
> opposite as well: make pure Python stdlib modules optionally compilable to
> fast C code using Cython. The obvious advantages are a) speed and b) a
> single code base for both Python and C modules.
>
> Stefan

The reason why there was no mention is probably because no one
intimately familiar with Cython was there, and if they were - it was
not brought up. If Cython supports PyPy - and Jython, and IronPython,
your proposal makes sense. The reason for "pure" python implementation
is so that other implementations can share the exact same standard
library we have today. I don't see adding a cython version as helping
that.

From solipsis at pitrou.net  Sun Mar 20 12:40:49 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 20 Mar 2011 12:40:49 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
Message-ID: <20110320124049.70610337@pitrou.net>

On Sun, 20 Mar 2011 07:32:34 -0400
Jesse Noller <jnoller at gmail.com> wrote:
> 
> The reason why there was no mention is probably because no one
> intimately familiar with Cython was there, and if they were - it was
> not brought up. If Cython supports PyPy - and Jython, and IronPython,
> your proposal makes sense. The reason for "pure" python implementation
> is so that other implementations can share the exact same standard
> library we have today.

Well, realistically, they don't. Some functionality just isn't
satisfied with a slow Python implementation. The io module is a primary
example of that.
(but I don't think a Cython version of io would be fast enough, either)

Regards

Antoine.



From stefan_ml at behnel.de  Sun Mar 20 12:56:22 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Mar 2011 12:56:22 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
Message-ID: <im4q17$aje$1@dough.gmane.org>

Jesse Noller, 20.03.2011 12:32:
> On Sun, Mar 20, 2011 at 7:19 AM, Stefan Behnel wrote:
>> It appears that there has been little mention of Cython at the summit,
>> despite of the speed of CPython being a major topic, according to the notes.
>> I can see several areas where Cython could help in speeding up core CPython,
>> one of the most obvious being compilation of standard library modules, and
>> JIT-like compilation of Python modules at import time.
>>
>> Nick mentioned that there was a discussion of making C-only modules
>> available as alternative Python implementations. I'd like to suggest the
>> opposite as well: make pure Python stdlib modules optionally compilable to
>> fast C code using Cython. The obvious advantages are a) speed and b) a
>> single code base for both Python and C modules.
>
> The reason why there was no mention is probably because no one
> intimately familiar with Cython was there, and if they were - it was
> not brought up. If Cython supports PyPy - and Jython, and IronPython,
> your proposal makes sense. The reason for "pure" python implementation
> is so that other implementations can share the exact same standard
> library we have today. I don't see adding a cython version as helping
> that.

Cython is meant to compile Python code. A "cython version" would just be a 
pure Python module, usable with all other implementations, but with type 
annotations that make it compile to more optimal C code. Type annotations 
can be provided in an external file (.pxd), using decorators and/or using 
Python 3 annotation syntax. There's also a port of Cython to IronPython 
being written. Additionally, other implementations (such as PyPy) could 
start using the available type declarations in order to improve their 
optimisation capabilities as well.

CPython, specifically, can also continue to use a multi-step implementation 
as it's currently being done, i.e. split the implementation into a pure 
Python module with optional compilation, a Cython-specific partial 
reimplementation in optimised only-mostly-Python code, and potentially a C 
module for the external code that must really be implemented in pure C for 
whatever reason. That would already lower the entry level for non-C-affine 
contributors by moving more code into plain Python and (mostly Python) 
Cython code, instead of requiring proficiency in both C and CPython's C-API 
in order to work on the code at all.

Stefan


From stefan_ml at behnel.de  Sun Mar 20 13:35:46 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Mar 2011 13:35:46 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <20110320124049.70610337@pitrou.net>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<20110320124049.70610337@pitrou.net>
Message-ID: <im4sb2$lg1$1@dough.gmane.org>

Antoine Pitrou, 20.03.2011 12:40:
> On Sun, 20 Mar 2011 07:32:34 -0400 Jesse Noller wrote:
>>
>> The reason why there was no mention is probably because no one
>> intimately familiar with Cython was there, and if they were - it was
>> not brought up. If Cython supports PyPy - and Jython, and IronPython,
>> your proposal makes sense. The reason for "pure" python implementation
>> is so that other implementations can share the exact same standard
>> library we have today.
>
> Well, realistically, they don't. Some functionality just isn't
> satisfied with a slow Python implementation. The io module is a primary
> example of that.

Agreed.


> (but I don't think a Cython version of io would be fast enough, either)

I assume you mean a compiled version of the pure Python implementation? No, 
that likely won't be faster and would certainly be much slower than the 
current C implementation. There's not much Cython can optimise in Python 
code that mostly does Python-level I/O operations.

However, I'd argue that if the C implementation of the "io" module had been 
written in Cython code instead of C, it would have ended up being about as 
fast (or maybe slightly faster due to the reduced calling overhead in 
Cython), but substantially shorter, more readable and accessible for Python 
users and consequently easier to maintain. Likely also easier to write in 
the first place, as most of the code had already been written for the pure 
Python version, which makes it a "copy&optimise" rather than a "read&rewrite".

Maybe that would make a good topic for the GSoC: rewrite some of the C 
modules in CPython in Cython, either in pure Python with Cython type 
annotations, or in Cython code, depending on the type of module and its 
speed requirements. Rewriting C code in Cython usually goes quite quickly, 
so the outcome would likely be several modules for one GSoC participant.

IMHO, taking modules that currently only have a C implementation due to 
performance constraints and rewriting them in Cython is a much more 
worthwhile thing to do than adding an alternative pure Python 
implementation that other Python runtimes wouldn't use anyway. And at least 
IronPython could soon benefit directly from a Cython implementation as well.

Stefan


From jnoller at gmail.com  Sun Mar 20 13:48:12 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Sun, 20 Mar 2011 08:48:12 -0400
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <20110320124049.70610337@pitrou.net>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<20110320124049.70610337@pitrou.net>
Message-ID: <AANLkTinWKNKMbgD_HyW5GYM5AoK+JVq43PbfwEFpwm4E@mail.gmail.com>

On Sun, Mar 20, 2011 at 7:40 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 20 Mar 2011 07:32:34 -0400
> Jesse Noller <jnoller at gmail.com> wrote:
>>
>> The reason why there was no mention is probably because no one
>> intimately familiar with Cython was there, and if they were - it was
>> not brought up. If Cython supports PyPy - and Jython, and IronPython,
>> your proposal makes sense. The reason for "pure" python implementation
>> is so that other implementations can share the exact same standard
>> library we have today.
>
> Well, realistically, they don't. Some functionality just isn't
> satisfied with a slow Python implementation. The io module is a primary
> example of that.
> (but I don't think a Cython version of io would be fast enough, either)
>
> Regards
>
> Antoine.

The intention (and pep that is in progress) is to break out the
standard library so that it *is* shared, and used by all of the
implementations. We should not go out of our way to make this
difficult, and provide pure python implementation whenever we can.
This was universally agreed to at the summit at least, and I believe
Brett Cannon is going to work on a pep that solidifies it.

The other implementations (PyPy, in particular) have run into serious
issues with the optimized C versions of modules being placed into the
core, and the Python fallbacks being torn out.

jesse

From jnoller at gmail.com  Sun Mar 20 13:51:04 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Sun, 20 Mar 2011 08:51:04 -0400
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im4sb2$lg1$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<20110320124049.70610337@pitrou.net> <im4sb2$lg1$1@dough.gmane.org>
Message-ID: <AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>

...snip

> IMHO, taking modules that currently only have a C implementation due to
> performance constraints and rewriting them in Cython is a much more
> worthwhile thing to do than adding an alternative pure Python implementation
> that other Python runtimes wouldn't use anyway. And at least IronPython
> could soon benefit directly from a Cython implementation as well.
>
> Stefan

The other python implementation expressed serious interest, and are
willing to help support a shared standard library, and shared modules.
So saying they "won't use them anyway" may apply to things such as the
io module, but is far from the truth for the entire standard library.

You're also asking that we depend on Cython within core, which while
it has it's benefits, I think warrants a PEP and a working
implementation to show the potential speedups you're talking about
before we can agree to include it/depend on it.

jesse

From digitalxero at gmail.com  Sun Mar 20 13:56:22 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sun, 20 Mar 2011 08:56:22 -0400
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D85CACA.1070400@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
Message-ID: <AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>

On Sun, Mar 20, 2011 at 5:37 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I see three problems with creating child processes:
> - WaitForSingleObject and GetExitProcessCode must work correctly. I
> ?think this is possible to achieve
> - applications using the debug API, PSAPI, etc. will be confused if
> ?the action all happens in a child process. I can accept that they
> ?have to adjust, though.
> - TerminateProcess must work correctly, and I see no way to achieve
> ?that (i.e. terminating the parent process won't terminate the child)

Before Mark wrote up this pep I had started experimenting with how to
make the launcher and I was able to get it to launch python while
exiting py.exe and as far as I could tell it behaved just as if I had
launched the app directly by double clicking it.

http://pastebin.com/vxcrC8Tn

I tested it with long running scripts and a full application (openrpg)
that has many external dependencies and in both cases py.exe exited
and the script/app ran as expected leaving the python console open
until the script/app exited on it's own. I did not test adding
debugger breakpoint in the code though to see how it behaved though.

From jcea at jcea.es  Sun Mar 20 14:02:24 2011
From: jcea at jcea.es (Jesus Cea)
Date: Sun, 20 Mar 2011 14:02:24 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
Message-ID: <4D85FAE0.40107@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/03/11 19:59, Raymond Hettinger wrote:
> I think if we're going to require a complex workflow, then we're
> going to have to expect a lot of questions.  And those questions
> shouldn't be brushed-off with "go read the tutorial, we have no time
> for you" or words to that effect.

I think we are doing some antipatterns with our current approach,
battling the tools instead of "joining them".

Would be nice to document a complete case workflow, from patch thinking
to the final push, dealing with all the little details, collapsing
outgoing commits, "+1 head", merging real conflicts, linealizing
history, moving the patch thru branches, etc.

But the fact is that some of us are still experimenting.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYX64Jlgi5GaxT1NAQLaXwQAhtZyuIZ1wYXx7yS41+bzIpZHEMbj3uCN
iA/OzE1cAY55/opNHqIu1OAONKD/Y4kAm6cU/Qs2prRL2OsMwml1zPsG2Aono2iN
SIqAN1YS7fagOEcDeKmPo6LbHTBpq9wuv53LBiW7xM1/ut2e5ou9DMfpf5bK6xP6
bbR4ESTGzyU=
=NNNV
-----END PGP SIGNATURE-----

From stefan_ml at behnel.de  Sun Mar 20 14:39:20 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Mar 2011 14:39:20 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>
	<im4sb2$lg1$1@dough.gmane.org>
	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>
Message-ID: <im5028$7h7$1@dough.gmane.org>

Jesse Noller, 20.03.2011 13:51:
> ...snip
>
>> IMHO, taking modules that currently only have a C implementation due to
>> performance constraints and rewriting them in Cython is a much more
>> worthwhile thing to do than adding an alternative pure Python implementation
>> that other Python runtimes wouldn't use anyway. And at least IronPython
>> could soon benefit directly from a Cython implementation as well.
>>
>> Stefan
>
> The other python implementation expressed serious interest, and are
> willing to help support a shared standard library, and shared modules.
> So saying they "won't use them anyway" may apply to things such as the
> io module, but is far from the truth for the entire standard library.

I guess someone would have to look through the stdlib and make a list of 
suitable candidates for Cython compilation and/or Python/Cython/C 
reimplementations at this point.


> You're also asking that we depend on Cython within core

It's a substantial dependency, sure. The question is: what's more work, 
having to install a specific version of Cython in order to work on CPython, 
or having to get fluent in C + C-API first?

I like the way the Jython people put it, slightly adapted into "We write C 
so you don't have to".


> which while
> it has it's benefits, I think warrants a PEP and a working
> implementation to show the potential speedups you're talking about
> before we can agree to include it/depend on it.

We will have a Cython core developers workshop next weekend. Maybe we can 
find a bit of time there to run the then-merged-together-bleeding-edge 
Cython over the standard library and see what that gives.

It's not easy to find good benchmarks, though. Most of what the 
PyPy/Unladen developers settled on so far isn't very interesting for the 
way Cython works. It's usually a bit of work to make the code substantially 
faster by providing enough type annotations to let the compiler drop 
critical Python code into C. We did that for a couple of benchmarks, but 
lost interest as there wasn't much to win - all we could show was that, by 
changing the code enough to make it violate the usual constraints of a fair 
benchmark comparison, you could make it run as fast as C code without 
writing C code. Not much news to us and nothing that would integrate in any 
acceptable way into speed.pypy.org.

If anyone knows about a good benchmark for a currently pure Python standard 
library module, preferably a smaller, self-contained one that's somewhat 
computationally intensive, I'd be happy to hear about it.

Stefan


From jnoller at gmail.com  Sun Mar 20 14:53:43 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Sun, 20 Mar 2011 09:53:43 -0400
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im5028$7h7$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<20110320124049.70610337@pitrou.net> <im4sb2$lg1$1@dough.gmane.org>
	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>
	<im5028$7h7$1@dough.gmane.org>
Message-ID: <AANLkTimDP8r-rHGzsFO7LBeUyMsDKLnXib_JgL=8tPWQ@mail.gmail.com>

On Sun, Mar 20, 2011 at 9:39 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Jesse Noller, 20.03.2011 13:51:
>>
>> ...snip
>>
>>> IMHO, taking modules that currently only have a C implementation due to
>>> performance constraints and rewriting them in Cython is a much more
>>> worthwhile thing to do than adding an alternative pure Python
>>> implementation
>>> that other Python runtimes wouldn't use anyway. And at least IronPython
>>> could soon benefit directly from a Cython implementation as well.
>>>
>>> Stefan
>>
>> The other python implementation expressed serious interest, and are
>> willing to help support a shared standard library, and shared modules.
>> So saying they "won't use them anyway" may apply to things such as the
>> io module, but is far from the truth for the entire standard library.
>
> I guess someone would have to look through the stdlib and make a list of
> suitable candidates for Cython compilation and/or Python/Cython/C
> reimplementations at this point.
>
>
>> You're also asking that we depend on Cython within core
>
> It's a substantial dependency, sure. The question is: what's more work,
> having to install a specific version of Cython in order to work on CPython,
> or having to get fluent in C + C-API first?
>
> I like the way the Jython people put it, slightly adapted into "We write C
> so you don't have to".
>
>
>> which while
>> it has it's benefits, I think warrants a PEP and a working
>> implementation to show the potential speedups you're talking about
>> before we can agree to include it/depend on it.
>
> We will have a Cython core developers workshop next weekend. Maybe we can
> find a bit of time there to run the then-merged-together-bleeding-edge
> Cython over the standard library and see what that gives.
>
> It's not easy to find good benchmarks, though. Most of what the PyPy/Unladen
> developers settled on so far isn't very interesting for the way Cython
> works. It's usually a bit of work to make the code substantially faster by
> providing enough type annotations to let the compiler drop critical Python
> code into C. We did that for a couple of benchmarks, but lost interest as
> there wasn't much to win - all we could show was that, by changing the code
> enough to make it violate the usual constraints of a fair benchmark
> comparison, you could make it run as fast as C code without writing C code.
> Not much news to us and nothing that would integrate in any acceptable way
> into speed.pypy.org.
>
> If anyone knows about a good benchmark for a currently pure Python standard
> library module, preferably a smaller, self-contained one that's somewhat
> computationally intensive, I'd be happy to hear about it.
>
> Stefan

The nice thing is about those benchmarks - from PyPy and Unladen
Swallow's work - is that they do reflect real world applications, and
tend away from pure numerical micro benchmarks (how fast you can do
fibonacci is almost worthless). So if we want to add more to that
suite of benchmarks, great - but those will be some of the benchmarks
against which speed improvements would be measured against.

There's also a plan (coming out of the vm summit/language summit) to
turn speed.pypy.org into a shared "performance.python.org" resource,
and showcase the speed of CPython, Jython, IronPython and PyPy side by
side, using common benchmarks. I am currently working on acquiring the
needed resources from the PSF side to get us to the point where the
real work can begin.

If you can show that Cython lowers the barrier to writing fast(er)
Python extensions, without dropping into pure C, and we don't cripple
the ability for the other implementation to share the code, then by
all means, I personally recommend a PEP.

jesse

From solipsis at pitrou.net  Sun Mar 20 15:51:31 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 20 Mar 2011 15:51:31 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<20110320124049.70610337@pitrou.net> <im4sb2$lg1$1@dough.gmane.org>
	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>
	<im5028$7h7$1@dough.gmane.org>
Message-ID: <20110320155131.23b126c8@pitrou.net>

On Sun, 20 Mar 2011 14:39:20 +0100
Stefan Behnel <stefan_ml at behnel.de> wrote:
> 
> If anyone knows about a good benchmark for a currently pure Python standard 
> library module, preferably a smaller, self-contained one that's somewhat 
> computationally intensive, I'd be happy to hear about it.

You can take a look at difflib, sre_compile, weak containers
(WeakrefSet, WeakValueDict, WeakKeyDict).

Regards

Antoine.



From p.f.moore at gmail.com  Sun Mar 20 15:55:18 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 20 Mar 2011 14:55:18 +0000
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D85CFB7.3050801@gmail.com>
References: <4D8446E0.7030401@skippinet.com.au> <4D846CFA.2030808@g.nevcal.com>
	<4D8568B4.3070102@skippinet.com.au> <4D85AB3C.6050802@g.nevcal.com>
	<im4hqe$5lf$1@dough.gmane.org> <4D85CFB7.3050801@gmail.com>
Message-ID: <AANLkTikkJXG8fbj6Uis15RcCygr+tX+sHX0vQXv_-cY_@mail.gmail.com>

On 20 March 2011 09:58, Mark Hammond <skippy.hammond at gmail.com> wrote:
> On 20/03/2011 8:36 PM, Terry Reedy wrote:
>>
>> On 3/20/2011 3:22 AM, Glenn Linderman wrote:
>> On 3/19/2011 7:38 PM, Mark Hammond wrote:
>> [snip]
>>
>> As both a writer and reader, I would like to just add, for instance,
>>
>> #! python3
>>
>> (or 3.3 or whatever) and have the launcher do the 'right thing'.
>
> If there was general agreement, I'd be happy for the PEP to support that
> variation.

I would probably use this. I'd also be happy with Unix-style
#!/usr/bin/python3. I would not use a Windows-only line at all.

Anyone advocating including full paths in a Windows-specific line
(can't remember who it was, sorry - Glen?) should remember that unlike
Unix, there is NO standard location for the Python interpreter on
Windows. The installer's default is only that - a default. (And TBH,
in my view, not that good a default, merely the best of a series of
bad options...) My Python installs are usually in \Apps\Pythonxy on
some drive - which one depends on how my drives are laid out and how
much free space I have. So an absolute path wouldn't even be portable
across all of my own PCs! Personally, I'd rather not have such a line
at all (and find another approach) than use an absolute path...

Paul.

From rdmurray at bitdance.com  Sun Mar 20 16:51:09 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 20 Mar 2011 11:51:09 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <1300619845.3481.0.camel@localhost.localdomain>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<1300619845.3481.0.camel@localhost.localdomain>
Message-ID: <20110320155110.11F23F4A10@kimball.webabinitio.net>

On Sun, 20 Mar 2011 12:17:25 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le dimanche 20 mars 2011 ?? 00:06 -0400, R. David Murray a ??crit :
> > On Thu, 17 Mar 2011 14:33:00 +0100,  wrote:
> > > On Thu, 17 Mar 2011 09:24:26 -0400
> > > "R. David Murray" <rdmurray at bitdance.com> wrote:
> > > >
> > > > It would be great if rebase did work with share, that would make a
> > > > push race basically a non-issue for me.
> > >
> > > rebase as well as strip destroy some history, meaning some of your
> > > shared clones may end up having their working copy based on a
> > > non-existent changeset. I'm not sure why rebase would be worse that
> > > strip in that regard, though.
> >
> > Well, it turns out that this completely doesn't work, though at first
> > it appeared to (and so I pushed).
> >
> > I had a push race, so I did hg pull; hg rebase.
> 
> Have you tried hg pull --rebase instead?
> If you "hg rebase" by hand, I think you have to tell it the right set of
> revisions to rebase.

That wouldn't help me, since my goal is to rebase merges between
branches.  I think Mercurial just doesn't support that.

I think I'm going to have to give in and do "merge heads" when
someone else has pushed since my last pull.

--
R. David Murray           http://www.bitdance.com

From rdmurray at bitdance.com  Sun Mar 20 16:52:35 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 20 Mar 2011 11:52:35 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110320040601.573A4D5EAB@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
Message-ID: <20110320155235.30B81F4A1B@kimball.webabinitio.net>

On Sun, 20 Mar 2011 00:06:01 -0400, "R. David Murray" <rdmurray at bitdance.com> wrote:
> It would have been nice if rebase had refused to run given that
> there were merges, since it clearly doesn't work in that case.

To clarify, that should have read "given that there were merges
*between branches*".  Cleaning merges on the same branch is
the goal of rebase, after all :)

--
R. David Murray           http://www.bitdance.com

From solipsis at pitrou.net  Sun Mar 20 16:53:59 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 20 Mar 2011 16:53:59 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110320155235.30B81F4A1B@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
Message-ID: <1300636439.3481.10.camel@localhost.localdomain>

Le dimanche 20 mars 2011 ? 11:52 -0400, R. David Murray a ?crit :
> On Sun, 20 Mar 2011 00:06:01 -0400, "R. David Murray" <rdmurray at bitdance.com> wrote:
> > It would have been nice if rebase had refused to run given that
> > there were merges, since it clearly doesn't work in that case.
> 
> To clarify, that should have read "given that there were merges
> *between branches*".  Cleaning merges on the same branch is
> the goal of rebase, after all :)

I think that would be the kind of issue working bringing on the
Mercurial mailing-list.

Regards

Antoine.



From guido at python.org  Sun Mar 20 17:17:19 2011
From: guido at python.org (Guido van Rossum)
Date: Sun, 20 Mar 2011 09:17:19 -0700
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im5028$7h7$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<20110320124049.70610337@pitrou.net> <im4sb2$lg1$1@dough.gmane.org>
	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>
	<im5028$7h7$1@dough.gmane.org>
Message-ID: <AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>

Hi Stefan,

I'm glad to see Cython picking up steam and trying to compete with
CPython, PyPy, and possibly others. It's true that few in the core
development group know much about Cython -- essentially my own
understanding is still that it's like Pyrex, which was a
mostly-Python-compatible syntax for writing C extensions, but
certainly not able to compile all existing Python code successfully,
due to small syntactic incompatibilities (e.g. new reserved words). I
also thought that Cython was mostly popular is scientific computing
circles. But I may well be wrong on all counts. Please enlighten me.

I'd like to hear more about Cython's compatibility -- e.g. does it
compile Django? If so, is it any faster? What versions of Python does
it currently support? How does it do on the benchmark suite used by
PyPy (originated with Unladen Swallow)? IMO it's up to Cython to prove
its worth.

-- 
--Guido van Rossum (python.org/~guido)

From guido at python.org  Sun Mar 20 17:21:06 2011
From: guido at python.org (Guido van Rossum)
Date: Sun, 20 Mar 2011 09:21:06 -0700
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <1300636439.3481.10.camel@localhost.localdomain>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
Message-ID: <AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>

What is "rebase"? Why does everyone want it and hate it at the same time?


-- 
--Guido van Rossum (python.org/~guido)

From rdmurray at bitdance.com  Sun Mar 20 17:33:32 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 20 Mar 2011 12:33:32 -0400
Subject: [Python-Dev] [Python-checkins] Would someone please help me
	merge these changes to other branches?
In-Reply-To: <19846.6346.55906.872873@montanaro.dyndns.org>
References: <19846.6346.55906.872873@montanaro.dyndns.org>
Message-ID: <20110320163332.E68D9F4A1B@kimball.webabinitio.net>

On Sun, 20 Mar 2011 10:10:02 -0500, skip at pobox.com wrote:
> > I pushed two changes to cpython yesterday and today.  I don't know how to
> > merge them to the 2.7 and 3.2 branches, and don't want to even try for
> > fear of screwing something up.  If what I read in python-dev yesterday is
> > correct, I did things incorrectly by starting with cpython instead of 2.7
> > or 3.2.
> 
> Actually, the newline= change only needs to go to 3.2.  The RFC 4180 change
> can also go to 2.7.

I'd already started on this fix, so I incorporated your changes (except
for the RFC 4180 one) and made them on 3.1, 3.2, and harmonized default.
So this should all be good now, except for the RFC change.  I guess I'll
see about doing that one later.

--
R. David Murray           http://www.bitdance.com

From g.brandl at gmx.net  Sun Mar 20 17:39:50 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 20 Mar 2011 16:39:50 +0000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
Message-ID: <im5akg$ptc$1@dough.gmane.org>

On 20.03.2011 16:21, Guido van Rossum wrote:
> What is "rebase"? Why does everyone want it and hate it at the same time?

Basically, rebase is a way to avoid having pointless merge commits on the
same branch.

Let's say you have the following history in your local repository:

... --- X --- A --- B

where X is the last commit that is in the remote repository, and
A and B are commits you made locally.  Now you pull from the remote,
and see that others have pushed more history in the meantime.  The
graph now looks this:

          A --- B
         /
... --- X --- C --- D --- E

To get your history pushed, you need to make a merge commit:

          A --- B ------------.
         /                     \
... --- X --- C --- D --- E --- M

Then you can push A, B and M to the remote.

Now, "hg pull --rebase" prevents that by "re-basing" the A-B history
line onto the latest remote head.  After rebasing, the history looks
like this:

... --- X --- C --- D --- E --- A' --- B'

without the need to merge before the push.

Obviously, if the merge above gave conflicts, the rebasing process
will also give conflicts.  In both cases you need to solve them
before continuing.

The reason why rebasing is not universally applied is that the
rebased changesets are different from the original ones (therefore
I wrote A' and B') -- even if the diff is the same, the parents
are not, and therefore the changeset id (hash) changes.  This is
called "changing history", and frowned upon by purists.  In reality
it works fine if you know the limits: rebasing really only should be
applied if the changesets are not already known somewhere else,
only in the local repo you're working with.

Georg


From g.brandl at gmx.net  Sun Mar 20 17:45:22 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 20 Mar 2011 16:45:22 +0000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <im5akg$ptc$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
Message-ID: <im5auk$ptb$1@dough.gmane.org>

On 20.03.2011 16:39, Georg Brandl wrote:

> The reason why rebasing is not universally applied is that the
> rebased changesets are different from the original ones (therefore
> I wrote A' and B') -- even if the diff is the same, the parents
> are not, and therefore the changeset id (hash) changes.  This is
> called "changing history", and frowned upon by purists.  In reality
> it works fine if you know the limits: rebasing really only should be
> applied if the changesets are not already known somewhere else,
> only in the local repo you're working with.

Ah, and it apparently also doesn't work in more complex situations
where you already merged your changes to another branch.  This is where
David got stuck, I guess.

Georg


From rdmurray at bitdance.com  Sun Mar 20 17:45:34 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 20 Mar 2011 12:45:34 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <im5akg$ptc$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
Message-ID: <20110320164534.583D7F4A1B@kimball.webabinitio.net>

On Sun, 20 Mar 2011 16:39:50 -0000, Georg Brandl <g.brandl at gmx.net> wrote:
> The reason why rebasing is not universally applied is that the
> rebased changesets are different from the original ones (therefore
> I wrote A' and B') -- even if the diff is the same, the parents
> are not, and therefore the changeset id (hash) changes.  This is
> called "changing history", and frowned upon by purists.  In reality
> it works fine if you know the limits: rebasing really only should be
> applied if the changesets are not already known somewhere else,
> only in the local repo you're working with.

And, as I discovered, only if they are on a single branch.  Which is
something *none* of the documentation I've read has mentioned.  Perhaps
that's because named branches are relatively new?

--
R. David Murray           http://www.bitdance.com

From thomas at python.org  Sun Mar 20 17:50:23 2011
From: thomas at python.org (Thomas Wouters)
Date: Sun, 20 Mar 2011 17:50:23 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <im5akg$ptc$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
Message-ID: <AANLkTin_GJzi3PBar1VO=aUq1RoJbRuJm9tLDizQgn5X@mail.gmail.com>

On Sun, Mar 20, 2011 at 17:39, Georg Brandl <g.brandl at gmx.net> wrote:

> The reason why rebasing is not universally applied is that the
> rebased changesets are different from the original ones (therefore
> I wrote A' and B') -- even if the diff is the same, the parents
> are not, and therefore the changeset id (hash) changes.  This is
> called "changing history", and frowned upon by purists.  In reality
> it works fine if you know the limits:


It's frowned upon by more than just purists, and it works "in reality" as
fine as handing out your creditcard and personal information over the
internet; you can't always tell the result is bad, and it can be very
painful finding out.

Jaywalking-and-unprotected-sex-metaphors-available-on-demand'ly y'rs,
-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110320/a6bed8cc/attachment.html>

From g.brandl at gmx.net  Sun Mar 20 17:59:19 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 20 Mar 2011 16:59:19 +0000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTin_GJzi3PBar1VO=aUq1RoJbRuJm9tLDizQgn5X@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTin_GJzi3PBar1VO=aUq1RoJbRuJm9tLDizQgn5X@mail.gmail.com>
Message-ID: <im5bop$vem$1@dough.gmane.org>

On 20.03.2011 16:50, Thomas Wouters wrote:
> 
> 
> On Sun, Mar 20, 2011 at 17:39, Georg Brandl <g.brandl at gmx.net
> <mailto:g.brandl at gmx.net>> wrote:
> 
>     The reason why rebasing is not universally applied is that the
>     rebased changesets are different from the original ones (therefore
>     I wrote A' and B') -- even if the diff is the same, the parents
>     are not, and therefore the changeset id (hash) changes.  This is
>     called "changing history", and frowned upon by purists.  In reality
>     it works fine if you know the limits:
> 
> 
> It's frowned upon by more than just purists, and it works "in reality" as fine
> as handing out your creditcard and personal information over the internet; you
> can't always tell the result is bad, and it can be very painful finding out.

Well, YMMV.  But instead of spreading FUD you might want to state *why*.

Georg


From tjreedy at udel.edu  Sun Mar 20 18:09:41 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 20 Mar 2011 13:09:41 -0400
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <20110320155131.23b126c8@pitrou.net>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>
	<im4sb2$lg1$1@dough.gmane.org>	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>	<im5028$7h7$1@dough.gmane.org>
	<20110320155131.23b126c8@pitrou.net>
Message-ID: <im5cci$2rn$1@dough.gmane.org>

On 3/20/2011 10:51 AM, Antoine Pitrou wrote:
> On Sun, 20 Mar 2011 14:39:20 +0100
> Stefan Behnel<stefan_ml at behnel.de>  wrote:
>>
>> If anyone knows about a good benchmark for a currently pure Python standard
>> library module, preferably a smaller, self-contained one that's somewhat
>> computationally intensive, I'd be happy to hear about it.
>
> You can take a look at difflib,

I think this is a good example. difflib.SequenceMatcher is linear to 
quadratic (says Tim) in the number of items and can take seconds or 
longer in real-life-sized use cases. It is all indexing, comparison, 
looping, and logic, so I think it would be an interesting test case. 
There is no C version now, so a sped-up version could be immediately 
useful to some people.

> sre_compile, weak containers
> (WeakrefSet, WeakValueDict, WeakKeyDict).

-- 
Terry Jan Reedy


From thomas at python.org  Sun Mar 20 18:32:54 2011
From: thomas at python.org (Thomas Wouters)
Date: Sun, 20 Mar 2011 18:32:54 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <im5bop$vem$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTin_GJzi3PBar1VO=aUq1RoJbRuJm9tLDizQgn5X@mail.gmail.com>
	<im5bop$vem$1@dough.gmane.org>
Message-ID: <AANLkTimLUFqkPsBBKR4vwr7vxxgRwv3iDZr5iJTyzo4E@mail.gmail.com>

On Sun, Mar 20, 2011 at 17:59, Georg Brandl <g.brandl at gmx.net> wrote:

> On 20.03.2011 16:50, Thomas Wouters wrote:
> >
> >
> > On Sun, Mar 20, 2011 at 17:39, Georg Brandl <g.brandl at gmx.net
> > <mailto:g.brandl at gmx.net>> wrote:
> >
> >     The reason why rebasing is not universally applied is that the
> >     rebased changesets are different from the original ones (therefore
> >     I wrote A' and B') -- even if the diff is the same, the parents
> >     are not, and therefore the changeset id (hash) changes.  This is
> >     called "changing history", and frowned upon by purists.  In reality
> >     it works fine if you know the limits:
> >
> >
> > It's frowned upon by more than just purists, and it works "in reality" as
> fine
> > as handing out your creditcard and personal information over the
> internet; you
> > can't always tell the result is bad, and it can be very painful finding
> out.
>
> Well, YMMV.  But instead of spreading FUD you might want to state *why*.


I could also ask you what makes you think changing history is frowned upon
by *just purists*, or why on earth anyone would think it's a good idea
regardless of how practical or theoretical they are.

As for my dislike, your reason (changing history) and Davids apparent
problem seem obvious enough. Aren't they? If you don't rebase correctly,
stuff goes wrong. Doing it correctly is harder than people seem to think.
You can see what's going on with 'hg outgoing -p', but I, as an observer,
have no way of knowing whether you used that and were aware of what exactly
you were pushing.

Merges can also contain useful information about how *future* merges of the
same changes should be handled. This doesn't matter much to changes with
short turnaround (or changes that are continuously reverted and re-applied)
but can make things a lot simpler if you have lots of diverging work in
multiple branches -- and all the getting used to Mercurial aside, I'm sure
that is what we're actually doing it for.

Even when done correctly, in situations where merges are automatic and do
not involve the changed code in any way, I don't like rebasing a single
changeset because it makes it less apparent when the actual work was
started. It's not any worse than diffing and re-applying a changeset, but
for example if your change modified a particular call pattern appearing in
multiples places, and another place started using the same pattern somewhere
in your merges that you made go away, did you intentionally forget to fix
the pattern or was it an accident? This isn't a problem that is *caused* by
rebasing, but it certainly isn't helped by it. Rebasing multiple changesets
is worse, because the intermediate changesets are a real lie rather than
some fudging of history; your repository was never in that state, that
changeset never looked that way and it was never built or tested that way.
No matter that it *usually* doesn't matter, or even *almost never* matters,
it *can* matter.

Merging and merge changesets are a fact of DVCSes, and while I (as a grumpy
luddite misanthrope) greatly prefer the automatic (and mostly silent) merge
as BitKeeper does it, in the long run the actual merging and the merge
changesets are unavoidable and something to get used to, not dodged around
(at least not at this cost.)
-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110320/f0f1d81e/attachment.html>

From stefan_ml at behnel.de  Sun Mar 20 18:46:33 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Mar 2011 18:46:33 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <20110320155131.23b126c8@pitrou.net>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>
	<im4sb2$lg1$1@dough.gmane.org>	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>	<im5028$7h7$1@dough.gmane.org>
	<20110320155131.23b126c8@pitrou.net>
Message-ID: <im5ehp$dvs$1@dough.gmane.org>

Antoine Pitrou, 20.03.2011 15:51:
> On Sun, 20 Mar 2011 14:39:20 +0100, Stefan Behnel wrote:
>>
>> If anyone knows about a good benchmark for a currently pure Python standard
>> library module, preferably a smaller, self-contained one that's somewhat
>> computationally intensive, I'd be happy to hear about it.
>
> You can take a look at difflib, sre_compile, weak containers
> (WeakrefSet, WeakValueDict, WeakKeyDict).

Ok, I skipped through the difflib module and it looked like a reasonable 
candidate. So I gave its Py3.2 version a run and except for triggering one 
class scoping bug in Cython, it compiled nicely with our latest generators 
branch. Working around that bug was easy (renaming the affected variables) 
and allowed me to run a diff on a short text file (68 lines, Cython's own 
README.txt). For simplicity, and to actually get a diff, I compared the 
duplicated original lines to their sorted list. Here are the timings:

Python 3.2 (locally compiled with suitable CFLAGS, Linux 64bit):

$ PYTHONPATH=py python3 -m timeit \
      -s 'from difflib import ndiff; \
          t1= 2 * open("../README.txt").readlines(); t2=sorted(t1);' \
      'list(ndiff(t1, t2))'
100 loops, best of 3: 3.36 msec per loop

Cython:

$ PYTHONPATH=so python3 -m timeit \
     -s 'from difflib import ndiff; \
         t1= 2 * open("../README.txt").readlines(); t2=sorted(t1);' \
     'list(ndiff(t1, t2))'
100 loops, best of 3: 2.08 msec per loop

That's more than a third faster, without any additional code optimisations 
or typing. It's not the first time I see Cython compiled plain Python code 
become about 30% faster, so I guess that's about the factor that 
computational code can expect before starting to add static types.

I did a bit of profiling and added a couple of type declarations to the 
top-2 methods, which grew the speed-up to about 50%, but there's quite some 
space left for improvements here, especially by overriding class 
definitions into extension types (which would speed up attribute access and 
method calls in Cython). Also, a couple of optimisationisms in the code 
prevent Cython from doing its own optimisions, e.g. there's critical code 
that takes off bound methods for "some_list.__contains__" or 
"some_dict.get". I didn't change those. They are faster in CPython, but 
Cython could otherwise translate them into the corresponding C-API calls 
directly.

I currently don't have psyco available to compare, but I think that would 
be interesting as well.

Stefan


From martin at v.loewis.de  Sun Mar 20 18:56:33 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 20 Mar 2011 18:56:33 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
	<AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>
Message-ID: <4D863FD1.9000204@v.loewis.de>

> Before Mark wrote up this pep I had started experimenting with how to
> make the launcher and I was able to get it to launch python while
> exiting py.exe and as far as I could tell it behaved just as if I had
> launched the app directly by double clicking it.

In this code, py.exe terminates way before the actual Python script
terminates, right?

So if somebody would launch a python script with py.exe, they would
think it was completed even though it would still be running.

Regards,
Martin

From skip at pobox.com  Sun Mar 20 19:05:37 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 20 Mar 2011 13:05:37 -0500
Subject: [Python-Dev] Avoiding whitespace conflicts (was: I am now lost
 - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <87lj0a5wca.fsf_-_@benfinney.id.au>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<19844.65128.436929.526859@montanaro.dyndns.org>
	<AANLkTiktVXSRMLW0Z8iFVZ3LkAEDV8vui_A4f-OciXcU@mail.gmail.com>
	<nad-21FD11.18594319032011@news.gmane.org>
	<87lj0a5wca.fsf_-_@benfinney.id.au>
Message-ID: <19846.16881.463607.688050@montanaro.dyndns.org>


    Ben> Ned Deily <nad at acm.org> writes:
    >> As a side note, if you are prone to accidentally adding extra
    >> whitespace (like I am), you can add the whitespace check hook into
    >> your local copy of Mercurial so that you will be warned about
    >> whitespace problems immediately when you commit things to your local
    >> repos rather than later when you try to push them up to the
    >> python.org repo.

    Ben> Even earlier that the attempt to commit, one can configure the text
    Ben> editor to show whitespace in order to be aware of it at the point
    Ben> where it's easiest to change:

    ...

I wasn't aware that TABs were verboten in .rst files.  If svn was configured
to reject TABs I simply never stumbled on it with my edits.  I did some
searching but found nothing in the dev guide to suggest there were any
restrictions on the whitespace in .rst files.  Now that I know, it's not
difficult to avoid.

Skip

From g.brandl at gmx.net  Sun Mar 20 19:14:20 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 20 Mar 2011 18:14:20 +0000
Subject: [Python-Dev] Avoiding whitespace conflicts
In-Reply-To: <19846.16881.463607.688050@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<19844.65128.436929.526859@montanaro.dyndns.org>
	<AANLkTiktVXSRMLW0Z8iFVZ3LkAEDV8vui_A4f-OciXcU@mail.gmail.com>
	<nad-21FD11.18594319032011@news.gmane.org>
	<87lj0a5wca.fsf_-_@benfinney.id.au>
	<19846.16881.463607.688050@montanaro.dyndns.org>
Message-ID: <im5g5d$l69$1@dough.gmane.org>

On 20.03.2011 18:05, skip at pobox.com wrote:
> 
>     Ben> Ned Deily <nad at acm.org> writes:
>     >> As a side note, if you are prone to accidentally adding extra
>     >> whitespace (like I am), you can add the whitespace check hook into
>     >> your local copy of Mercurial so that you will be warned about
>     >> whitespace problems immediately when you commit things to your local
>     >> repos rather than later when you try to push them up to the
>     >> python.org repo.
> 
>     Ben> Even earlier that the attempt to commit, one can configure the text
>     Ben> editor to show whitespace in order to be aware of it at the point
>     Ben> where it's easiest to change:
> 
>     ...
> 
> I wasn't aware that TABs were verboten in .rst files.  If svn was configured
> to reject TABs I simply never stumbled on it with my edits.  I did some
> searching but found nothing in the dev guide to suggest there were any
> restrictions on the whitespace in .rst files.  Now that I know, it's not
> difficult to avoid.

I probably thought it would be obvious, since reST relies on structural
indentation just like Python.  I've now added this in "Documenting Python".

cheers,
Georg



From fuzzyman at voidspace.org.uk  Sun Mar 20 19:38:35 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 20 Mar 2011 18:38:35 +0000
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D85CFB7.3050801@gmail.com>
References: <4D8446E0.7030401@skippinet.com.au>	<4D846CFA.2030808@g.nevcal.com>	<4D8568B4.3070102@skippinet.com.au>	<4D85AB3C.6050802@g.nevcal.com>
	<im4hqe$5lf$1@dough.gmane.org> <4D85CFB7.3050801@gmail.com>
Message-ID: <4D8649AB.4060405@voidspace.org.uk>

On 20/03/2011 09:58, Mark Hammond wrote:
> On 20/03/2011 8:36 PM, Terry Reedy wrote:
>> On 3/20/2011 3:22 AM, Glenn Linderman wrote:
>> On 3/19/2011 7:38 PM, Mark Hammond wrote:
>> [snip]
>>
>> As both a writer and reader, I would like to just add, for instance,
>>
>> #! python3
>>
>> (or 3.3 or whatever) and have the launcher do the 'right thing'.
>
> If there was general agreement, I'd be happy for the PEP to support 
> that variation.
>

Yes please. :-)

Michael

> Cheers,
>
> Mark
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From john at arbash-meinel.com  Sun Mar 20 19:39:16 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Sun, 20 Mar 2011 19:39:16 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110320040601.573A4D5EAB@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
Message-ID: <4D8649D4.708@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/20/2011 5:06 AM, R. David Murray wrote:
> On Thu, 17 Mar 2011 14:33:00 +0100,  wrote:
>> On Thu, 17 Mar 2011 09:24:26 -0400
>> "R. David Murray" <rdmurray at bitdance.com> wrote:
>>>
>>> It would be great if rebase did work with share, that would make a
>>> push race basically a non-issue for me.
>>
>> rebase as well as strip destroy some history, meaning some of your
>> shared clones may end up having their working copy based on a
>> non-existent changeset. I'm not sure why rebase would be worse that
>> strip in that regard, though.
> 
> Well, it turns out that this completely doesn't work, though at first
> it appeared to (and so I pushed).
> 
> I had a push race, so I did hg pull; hg rebase.  Then I looked at the
> log, and I could (apparently) see my change sets on the top of the
> stack.  So I pushed.  Victor then asked why one of my commits deleted
> Tools/demo/README, and then the next commit restored it.
> 
> What I was attempting to push was a doc change in 3.1 that I had then
> merged to 3.2 and default.  What I saw when looking closer at the log
> (after Victor pointed it out) was that my merge commits had lost their
> parents.
> 
> I thought that at worst a rebase would screw up my local history, but
> apparently I managed to push some sort of damaged history.  The doc
> change only got applied to default, since that's the branch I
> happened to be in when I did the rebase.
> 
> Needless to say, I'm avoiding rebase henceforth.

AIUI, rebase defaults to always omitting merge changesets. Under the
assumption that the branch you would merge is the one you are targeting
to rebase upon. So those merges are 'not interesting' once you are
rebased. Obviously this has failure cases (when the branch being merged
is not the one you are targeting.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2GSdMACgkQJdeBCYSNAAMf5wCgox24+LoJRKtzJHmCFTWcZnjI
MwIAniISqH9xDR/9g5EiXEsg5Wk66jeN
=39Oi
-----END PGP SIGNATURE-----

From tjreedy at udel.edu  Sun Mar 20 19:46:36 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 20 Mar 2011 14:46:36 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <19844.48323.176151.931392@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
Message-ID: <im5i29$o1$1@dough.gmane.org>

What you felt like doing after doing the rest;-?

I believe your question and its answers have helped me understand hg 
better for when I dive in. Thanks.

-- 
Terry Jan Reedy


From stephen at xemacs.org  Sun Mar 20 19:44:34 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 21 Mar 2011 03:44:34 +0900
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <4D85FAE0.40107@jcea.es>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es>
Message-ID: <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>

Jesus Cea writes:

 > I think we are doing some antipatterns with our current approach,
 > battling the tools instead of "joining them".

Yes.  That is deliberate; see PEP 0374.  I admit I personally didn't
foresee the issues Nick describes with the flow of patches from one
branch to another.  Also, the "collapse" stage was completely
unexpected to me (and wasn't stated as a requirement for PEP 0374),
although in hindsight it seems natural for Python.

The problem with "joining" the tools is that is a euphemism for "RTFM,
OK?"  People who are already working with hg and similar tools in
their daily lives can probably make that transition in Python's
workflow pretty easily, but they are not going to be very good at
providing scripts for the DVCS newbies because they don't have them;
they Just Do It.  The DVCS newbies, OTOH, were told that the workflow
would change as little as possible, and we (the PEP 0374 authors) did
our best to make that possible.  Unfortunately, it hasn't worked as
well as hoped.  I, for one, am sorry about that.

I'm coming to the conclusion that those who say that Mercurial
documentation should be found at the Mercurial project are wrong.  I
think there's a reasonably strong case (based on the explicit promise
of PEP 0374 that workflows would change as little as possible) for a
follow-on informational PEP providing verbal, and maybe automated,
scripts for the various operations needed in the Python workflow.

OTOH, people who are having problems with the workflow imposed by
Mercurial need to recognize that Subversion basically ripped a big
hole in the QA aspect of Python's workflow.  As Nick points out,
Subversion merges create new versions in the repository that *never
existed in any developer's workspace* and therefore was never tested
before committing.  This is somewhat mitigated by buildbot testing,
but that is mostly unit testing and inherently is not very good at
catching problems due to interactions across modules.  That is, it's
not that Subversion provided a simpler way of doing the work.  Rather,
it hid the fact that certain work was not being done at all.  hg
exposes this fact.


From rdmurray at bitdance.com  Sun Mar 20 20:40:23 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 20 Mar 2011 15:40:23 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20110320194023.DADE113F980@kimball.webabinitio.net>

On Mon, 21 Mar 2011 03:44:34 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> I'm coming to the conclusion that those who say that Mercurial
> documentation should be found at the Mercurial project are wrong.  I

+1.  I think the dev docs should explain anything needed to do the
basic Python workflow, even if that feels like repeating parts of the
Mercurial docs.  (If it is a large chunk, then a pointer to the exactly
relevant section of the Mercurial docs would be appropriate.)  On the
other hand, I'm not offering to do the work, so I'll happily accept
what has been produced so far (thanks, Antoine!).

> think there's a reasonably strong case (based on the explicit promise
> of PEP 0374 that workflows would change as little as possible) for a
> follow-on informational PEP providing verbal, and maybe automated,
> scripts for the various operations needed in the Python workflow.

Sounds good, but someone needs to write them.  You'll note that I've been
asking for this for a while, but as it turns out it wasn't really possible
to write them "correctly" until we started actually using the system.
I'm still not comfortable enough to write them myself, but after I've
used my chosen workflow for a while I'll do my best to write it up in
more detail than my earlier post as a blog post or something.

> OTOH, people who are having problems with the workflow imposed by
> Mercurial need to recognize that Subversion basically ripped a big
> hole in the QA aspect of Python's workflow.  As Nick points out,
> Subversion merges create new versions in the repository that *never
> existed in any developer's workspace* and therefore was never tested
> before committing.  This is somewhat mitigated by buildbot testing,
> but that is mostly unit testing and inherently is not very good at
> catching problems due to interactions across modules.  That is, it's
> not that Subversion provided a simpler way of doing the work.  Rather,
> it hid the fact that certain work was not being done at all.  hg
> exposes this fact.

Given that I generally did an svn up and a final regrtest run before
committing in SVN, the hole here for me was small (whatever changesets
came in after my up and before my commit).  Given that I do an hg pull/up
and a final regrtest run before starting my merge dance and am unlikely
to *re*run the regrtest after having to do an hg pull/merge heads,
exactly the same size hole is going to exist in my hg workflow.

--
R. David Murray           http://www.bitdance.com

From skip at pobox.com  Sun Mar 20 21:17:29 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 20 Mar 2011 15:17:29 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <19846.24793.573280.126001@montanaro.dyndns.org>


    Stephen> Subversion merges create new versions in the repository that
    Stephen> *never existed in any developer's workspace* and therefore was
    Stephen> never tested before committing.  This is somewhat mitigated by
    Stephen> buildbot testing, but that is mostly unit testing and
    Stephen> inherently is not very good at catching problems due to
    Stephen> interactions across modules.  That is, it's not that Subversion
    Stephen> provided a simpler way of doing the work.  Rather, it hid the
    Stephen> fact that certain work was not being done at all.  hg exposes
    Stephen> this fact.

Can you provide an example of this (real or hypothetical)?  It seems to me
that if all you have is unit tests it matters little, if at all, whether you
catch test failures before a checkin (in your local hg repo) or after (using
svn + a buildbot run).  The workflow of the version control system isn't
going to magically expose semantic interactions across modules.  It seems to
me that at best the new workflow means there is a better chance of catching
textual conflicts before checkin than before.

Skip

From skip at pobox.com  Sun Mar 20 21:23:21 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 20 Mar 2011 15:23:21 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <im5i29$o1$1@dough.gmane.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<im5i29$o1$1@dough.gmane.org>
Message-ID: <19846.25145.485684.114191@montanaro.dyndns.org>


    Terry> What you felt like doing after doing the rest;-?

I still f*cked everything up.  R. David Murray came to my rescue.  Even he
muffed it and had to backtrack I think, at least based on one of the
comments I saw on one of the involved tracker issues.

Skip

From stefan_ml at behnel.de  Sun Mar 20 21:59:13 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Mar 2011 21:59:13 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>
	<im4sb2$lg1$1@dough.gmane.org>	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>	<im5028$7h7$1@dough.gmane.org>
	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>
Message-ID: <im5pr1$7da$1@dough.gmane.org>

[warning, long post ahead]

Guido van Rossum, 20.03.2011 17:17:
> Hi Stefan,

Hi!

> I'm glad to see Cython picking up steam and trying to compete with
> CPython, PyPy, and possibly others.

We do, although our main focus is much more on targeted manual optimisation 
rather than whole applications. For example, we currently only boot-strap 
seven out of some 60 modules of Cython itself into C code, as those are the 
most critical parts (mostly related to parsing and syntax tree traversal) 
and the rest simply takes too long to run through the C compiler for too 
little overall benefit. Compiling only the top-4 pure Python modules of the 
Cython compiler, optimised with externally provided type annotations, lets 
the overall compiler run about twice as fast.


> It's true that few in the core
> development group know much about Cython -- essentially my own
> understanding is still that it's like Pyrex, which was a
> mostly-Python-compatible syntax for writing C extensions, but
> certainly not able to compile all existing Python code successfully,
> due to small syntactic incompatibilities (e.g. new reserved words).

We decide the available syntax/keywords based on the file extension (.py vs 
.pyx), and you can compile (most) Python 3 code by putting a comment at the 
top of your source file that specifies the language level (or by passing 
"-3" on the command line).

A nice feature is that we support CPython 2.3 through 3.2 with the same 
generated C code file, so you can ship the quality assured generated C code 
and then put your trust into a C compiler to do the right thing for a given 
runtime on a given machine, without requiring normal users to have (the 
right version of) Cython installed on their side.

Cython always works at a per-module level, does a bit of function/closure 
local static type inference and optimistic optimisations and has a few 
intentional semantic differences compared to Python, such as mostly fixed 
builtins (unless re-assigned directly inside of a module, or deemed 
uninteresting, such as "open"). This allows the compiler to apply a huge 
set of optimisations to the syntax tree and the generated C code that 
substantially speed up the usage of builtin types as well as common idioms 
for looping and iteration.

We still can't compile "all existing Python code", though, as there are 
several known bugs regarding Python semantics. However, we recently managed 
to get pretty close to Python language feature completeness and hope to 
finish that up soon.

In short: if it works, it works, and it usually only gets better. ;-)


> I also thought that Cython was mostly popular is scientific computing
> circles. But I may well be wrong on all counts. Please enlighten me.

It does have a large and quickly growing user base in scientific computing. 
I would even say that Cython is growing into one of the main features that 
Python has in that field, right next to NumPy/SciPy, which are also 
starting to migrate parts of their code to Cython to improve its 
portability and maintainability. Cython is a great way to get numeric code 
up to speed without descending all the way down into a low-level language.

Cython is IMHO also the most advanced FFI that CPython has, much faster 
than any other wrapper tool and also more natural to use than ctypes. We 
natively support interaction with C and C++ code, and there's external 
support (fwrap) for Fortran as well, as that's extremely important in the 
high-performance computing area.

Finally, Cython is a programming language in its own right, that aims to 
close the not-so-small gap between Python and C/C++, both in terms of 
performance and usability. For example, we support many Python programming 
idioms on C data types, such as for-loop iteration over sliced pointers, 
and tightly adapt the code generated for a given language construct to the 
data types it operates on. While code can often be rewritten in a more 
C-ish way if performance truly demands it, we rather try to avoid that need 
by constantly improving and tailoring the generated code instead.

'nough sold? :-)

There are also Cython language semantics that we are still working on, such 
as support for some tricky C++ features. We generally try to follow Python 
semantics whenever possible, but need to accept in some cases that C/C++ 
have language semantics that we cannot hide from the user or that are 
actually helpful for users (yes, that really happens :). Advancing the 
language in these fields is pretty interesting business.


> I'd like to hear more about Cython's compatibility -- e.g. does it
> compile Django?

Never been that ambitious. As I said, Cython works at the module level, and 
you'd likely only compile some performance critical modules of an 
application anyway, in order to keep the overall code development more 
flexible.

A common approach is to profile an application, take the top-k modules and 
try to compile them in Cython. If they fail to compile, adapt the code as 
needed to get them compiling, then profile the application again to see 
what that gave you (Cython supports cProfile). Optimise the top-j 
functions/classes/methods by adding static type declarations to drop the 
code deeper into C, until it's fast enough. If you can't get it fast enough 
that way, change the code in well selected places to make it more C-ish. If 
that's not enough either, rewrite the critical part of it in C or maybe 
Fortran, then call that from Cython code. The last step obviously leaves 
Python code compatibility, but you can usually get away with a separate 
wrapper module and a conditional import, which is simple enough.

OTOH, you can also use "pyximport" to integrate Cython as a JIT-like 
compiler that tries to compile a Python module on import and if that works, 
use the compiled version instead of the plain Python version. I might try 
that with the Django benchmark once Cython's current feature branches are 
merged into mainline.


> How does it do on the benchmark suite used by
> PyPy (originated with Unladen Swallow)?

As I already mentioned, I only tried some of the simpler modules so far. 
It's usually quite a bit faster than CPython for what I tried, especially 
the numeric computation ones from Debian's shootout can be made to run a 
couple of hundred times faster (more or less as fast as C code), *if* you 
apply manual code modifications or at least externally provide static types 
and drop Python classes into optimised extension types (which can also be 
done externally). So it's usually the required manual work that stops us 
from getting better results (and it also smells like cheating if you change 
the benchmarked code).

Without manual interaction, speed-ups commonly only range from 10-30% 
compared to CPython, with the lower speed-ups often due to an extensive 
usage of Python classes and CPython specific optimisation tricks that 
Cython could do better if it understood their intention.


> IMO it's up to Cython to prove its worth.

It also depends on what you consider it worth *for*. CPython could start 
using Cython gradually in very fine steps, and I'd argue that the benefits 
for CPython are far beyond plain "run&win" performance improvements. I 
think the main selling point for Cython code in CPython is that it opens up 
an extremely wide field of code optimisations without requiring C code to 
be written and maintained.

Even for non-CPython runtimes, Cython code would likely be easier to port 
than C code, as it has a much better signal-to-noise ratio.

Stefan


From timothy.c.delaney at gmail.com  Sun Mar 20 22:16:12 2011
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Mon, 21 Mar 2011 08:16:12 +1100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTimLUFqkPsBBKR4vwr7vxxgRwv3iDZr5iJTyzo4E@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTin_GJzi3PBar1VO=aUq1RoJbRuJm9tLDizQgn5X@mail.gmail.com>
	<im5bop$vem$1@dough.gmane.org>
	<AANLkTimLUFqkPsBBKR4vwr7vxxgRwv3iDZr5iJTyzo4E@mail.gmail.com>
Message-ID: <AANLkTinFAuJBnhhkrz5NQKvOwvUi+UNeft06Mw2CznLc@mail.gmail.com>

On 21 March 2011 04:32, Thomas Wouters <thomas at python.org> wrote:

>
> Merging and merge changesets are a fact of DVCSes, and while I (as a grumpy
> luddite misanthrope) greatly prefer the automatic (and mostly silent) merge
> as BitKeeper does it, in the long run the actual merging and the merge
> changesets are unavoidable and something to get used to, not dodged around
> (at least not at this cost.)
>

Agreed 100%. I really don't understand the antipathy to branching and
merging. I understand the desire to distribute a collapsed changeset - it's
changing history, but as long as you're absolutely sure that it's never been
shared to another repository, *even another local one* then you're OK.

As far as I can see, people here are fighting against the tools, and as a
result making life much much harder for themselves. Patch, Export/Import,
Mercurial Queues - they're all recipes for ending up with an inconsistent
history across repos in the hands of inexperienced users (and as much as I
consider myself a decent user of Mercurial, I'm very much a neophyte when it
comes to MQ).

The way I set up Mercurial for my team was to have a single master
repository, which was then cloned as many times as desired by developers.
Clones were also made to do automated builds/tests in. Nothing was *ever*
done in the master's workspace (it was always empty).

All work was done in a named branch per task named for the task number. You
could collapse changesets so long as they had not been shared (though we
preferred to keep the entire history - made code reviews and pairing much
easier).

The advantages I saw of this:

1. It's a much simpler workflow. You pull and push between repositories,
update to the named branch you're working on, and commit. You only need to
merge *from* your task branch in most cases, except when merging a change
between feature branches (e.g. named branch -> 3.1 -> 3.2 -> 3.3).

The only complication is if you start your work in e.g. 3.2 but it needs to
be backported to 3.1. In that case, you can either do an export/import/dummy
merge forwards to get the change onto 3.1, or if the change has never been
shared you could *transplant* the named branch onto the 3.1 feature branch
(but that is a history change, using the transplant extension, so should
only be done if the named branch has never been shared outside that repo).
For this reason, you should always branch from the earliest possible
location - you can always merge forwards, but backwards is hard because of
the extra associated history). If the task is for a bugfix, always try to
branch from the point where the bug originated.

2. Work sits in named branches, and can be reviewed there. All you have to
say in the issue tracker is "branch X in repo URL". Work doesn't need to be
merged to the feature branches until it's been reviewed.

This does mean that a branch can be based on an outdated version of the
feature branch. A merge from the feature branch will fix that, but does make
reviewing harder. This is the main reason I've seen to want to rebase - but
in general I still think it's more trouble than it's worth. Live with the
merges - if you really want to, you can always create *another* named branch
to do the merge in e.g. for the first merge from feature branch to task 1234

hg update 1234
hg branch 1234_merged_with_3.2
hg merge 3.2
hg commit -m "Initial merge 1234_merged_with_3.2"

For the second and later merges:

hg update 1234_merged_with_3.2
hg merge 3.2
hg commit -m "Merged 3.2 to 1234_merged_with_3.2"
hg merge 1234
hg commit -m "Merged 1234 to 1234_merged_with_3.2"

Then you have a "clean" branch to review, and a branch that will merge
cleanly with the feature branch. This combined branch is the one that you
will then merge to the feature branch.

3. When a branch is finished, it can just be closed, then merged to the
feature branch(es). Note that you do want to merge the close changeset as
well - this prevents leaving extra heads around.

4. When a branch is abandoned, it can just be closed. It stays in the
history, so if someone wants to take it up again they've got the previous
work sitting there and can either resume, or use it to work out what went
wrong. Note that closing a branch does nothing except hide it from hg heads
and hg branches.

5. It's very easy to just pull or push a single branch (although I'm
personally in favour of all branches eventually ending up in the master
repository). Pulling a single branch from another developer's repo is a good
way to work on a branch together.

6. Working on someone else's code is much much easier. Say I have an
environment set up, with various ignored configuration files, etc. A good
example would be an Eclipse workspace. You really don't want to have to set
up a separate workspace for each task or feature you're working on (which
you would need to do if you're using separate clones for each task). If you
have each task on a named branch, you can just hg update 1234 and your
existing workspace is now ready to work on another task (you might want to
hg purge as well to get rid of generated artifacts such as .pyc files).

I've worked extensively with this workflow, and it was *really easy*. The
entire team was working happily in about a week, and we really found no
reason to change how we used Mercurial once we started doing this. Yes - you
end up with a much branchier workflow, but I found that to be an advantage,
rather than a disadvantage, because I could easily isolate the changes that
composed any particular task.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/2a07d6ec/attachment-0001.html>

From stephen at xemacs.org  Sun Mar 20 22:22:36 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 21 Mar 2011 06:22:36 +0900
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTimLUFqkPsBBKR4vwr7vxxgRwv3iDZr5iJTyzo4E@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTin_GJzi3PBar1VO=aUq1RoJbRuJm9tLDizQgn5X@mail.gmail.com>
	<im5bop$vem$1@dough.gmane.org>
	<AANLkTimLUFqkPsBBKR4vwr7vxxgRwv3iDZr5iJTyzo4E@mail.gmail.com>
Message-ID: <871v21trkz.fsf@uwakimon.sk.tsukuba.ac.jp>

Thomas Wouters writes:
 > On Sun, Mar 20, 2011 at 17:59, Georg Brandl <g.brandl at gmx.net> wrote:
 > > On 20.03.2011 16:50, Thomas Wouters wrote:
 > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl <g.brandl at gmx.net
 > > > <mailto:g.brandl at gmx.net>> wrote:
 > > >
 > > >     The reason why rebasing is not universally applied is that the
 > > >     rebased changesets are different from the original ones (therefore
 > > >     I wrote A' and B') -- even if the diff is the same, the parents
 > > >     are not, and therefore the changeset id (hash) changes.  This is
 > > >     called "changing history", and frowned upon by purists.  In reality
 > > >     it works fine if you know the limits: rebasing really only should be
 > > >     applied if the changesets are not already known somewhere else,
 > > >     only in the local repo you're working with.

This is not complete list.  The other important limit (pointed out by
Nick and Thomas) is that it creates changesets that have not yet been
tested, and therefore need to be tested or collapsed (if you want
bisect searches to work properly).

 > > > It's frowned upon by more than just purists, and it works "in
 > > > reality" as fine as handing out your creditcard and personal
 > > > information over the internet; you can't always tell the result
 > > > is bad, and it can be very painful finding out.

That's a problem with any merging, not just with rebasing, though.

 > I could also ask you what makes you think changing history is frowned upon
 > by *just purists*, or why on earth anyone would think it's a good idea
 > regardless of how practical or theoretical they are.

In practice, people who rebase often rebase the same branch to
mainline frequently.  If so, they detect most conflicts with mainline
as they occur, and this is often more useful context than knowing only
that "this branch was developed in a different context from the
current mainline tip", which is the "purist" reason most frequently
given for disliking rebasing.

That is, in practice people often resolve merge conflicts statically,
just by looking at the diff3 output.  If a developer is rebasing
frequently, on the other hand, they are probably also more aware of
the current context of the mainline, and why the conflicting changes
were made.  This dynamic context may improve the conflict resolutions.

 > As for my dislike, your reason (changing history) and Davids apparent
 > problem seem obvious enough. Aren't they? If you don't rebase correctly,
 > stuff goes wrong. Doing it correctly is harder than people seem to
 > think.

I don't think it is, at least not in theory: just run the test suite
on all rebased changesets.  As argued above, the case for frequent
rebasing is as least as strong as the case for merging a branch
developed entirely in its original context, and only dealing with
conflicts at the very end, quite out of context.

 > Merges can also contain useful information about how *future* merges of the
 > same changes should be handled.

That hg rebasing (and git rebasing, for that matter) doesn't preserve
this information is a design bug (ask any Darcs user :-).  It is
important in practice, of course.

 > Rebasing multiple changesets is worse, because the intermediate
 > changesets are a real lie rather than some fudging of history; your
 > repository was never in that state, that changeset never looked
 > that way and it was never built or tested that way.

Ah, but merging and rebasing are done locally.  The repository *is* in
that state now, and building and testing the relevant changesets can
be done automatically.  (This may be problematic in practice due to
the push race, of course.)  So it's just a matter of project policy to
require those tests before pushing.  People who are bugged by the push
race can do an ordinary merge, and provide less testing thereby.

 > Merging and merge changesets are a fact of DVCSes,

Actually, of any decentralized development.  DVCSes simply provide
tools to make you aware of merges, rather than hiding problems behind
"coalesced" patches that don't even know their parent version.

From ncoghlan at gmail.com  Sun Mar 20 22:19:47 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 Mar 2011 07:19:47 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <im5bop$vem$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTin_GJzi3PBar1VO=aUq1RoJbRuJm9tLDizQgn5X@mail.gmail.com>
	<im5bop$vem$1@dough.gmane.org>
Message-ID: <AANLkTi=WYBqCxfeaDw2ZBFCP8R3PPJAqE3jHO536seU6@mail.gmail.com>

On Mon, Mar 21, 2011 at 2:59 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> Well, YMMV. ?But instead of spreading FUD you might want to state *why*.

David isn't the only one this kind of thing blew up on during the
sprints (although in my case, it may have been "hg rollback" rather
than rebasing).

Essentially, if using the cascaded local repositories workflow (i.e.
local 3.1 -> local 3.2 -> local default -> hg.python.org/cpython), by
the time you go to do the push to remote, your local history already
includes a change on 3.1, a 3.1->3.2 merge and a 3.2->default merge.
The history changing commands appear to have trouble coping with that
correctly.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From mhammond at skippinet.com.au  Sun Mar 20 22:16:28 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 21 Mar 2011 08:16:28 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D85D637.3040403@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>
	<4D85CACA.1070400@v.loewis.de> <4D85D637.3040403@skippinet.com.au>
Message-ID: <4D866EAC.8050701@skippinet.com.au>

Following up myself here...
On 20/03/2011 9:25 PM, Mark Hammond wrote:
> On 20/03/2011 8:37 PM, "Martin v. L?wis" wrote:
> ...
> Some of these uses probably shouldn't use the launcher directly - eg,
> ISAPI apps and COM objects which have a separate registration step could
> register a specific python.exe - the installation script itself could by
> launched by the launcher, but that script could continue to use
> sys.executable to record the specific python.exe.

The above raises an interesting question - if the launcher executed 
Python in-process, what would sys.executable be?  I can imagine there 
are few scenarios where it would be desirable to have it refer to the 
launcher and a number of scenarios where it would be undesirable and 
possibly break existing scripts.

Consider when a script with a "../python3" shebang line is started via 
the launcher, but that script itself uses sys.executable to launch its 
own child.  If sys.executable was the launcher, that child would likely 
be started using a python 2.x interpreter...

Mark

From mhammond at skippinet.com.au  Sun Mar 20 22:22:29 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 21 Mar 2011 08:22:29 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
	<AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>
Message-ID: <4D867015.4050303@skippinet.com.au>

On 20/03/2011 11:56 PM, Dj Gilcrease wrote:
...
> Before Mark wrote up this pep I had started experimenting with how to
> make the launcher and I was able to get it to launch python while
> exiting py.exe and as far as I could tell it behaved just as if I had
> launched the app directly by double clicking it.

In addition to Martin's point, this approach would mean the exit code of 
the child process probably isn't available to whoever started the 
launcher.  For example, a batch file that tried to use something like 
"if errorlevel ..." to check the result of the Python process would 
probably not work as expected.

Cheers,

Mark

From g.brandl at gmx.net  Sun Mar 20 22:41:15 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 20 Mar 2011 22:41:15 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTimLUFqkPsBBKR4vwr7vxxgRwv3iDZr5iJTyzo4E@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTin_GJzi3PBar1VO=aUq1RoJbRuJm9tLDizQgn5X@mail.gmail.com>
	<im5bop$vem$1@dough.gmane.org>
	<AANLkTimLUFqkPsBBKR4vwr7vxxgRwv3iDZr5iJTyzo4E@mail.gmail.com>
Message-ID: <im5s9h$jjv$1@dough.gmane.org>

On 20.03.2011 18:32, Thomas Wouters wrote:
> 
> 
> On Sun, Mar 20, 2011 at 17:59, Georg Brandl <g.brandl at gmx.net
> <mailto:g.brandl at gmx.net>> wrote:
> 
>     On 20.03.2011 16:50, Thomas Wouters wrote:
>     >
>     >
>     > On Sun, Mar 20, 2011 at 17:39, Georg Brandl <g.brandl at gmx.net
>     <mailto:g.brandl at gmx.net>
>     > <mailto:g.brandl at gmx.net <mailto:g.brandl at gmx.net>>> wrote:
>     >
>     >     The reason why rebasing is not universally applied is that the
>     >     rebased changesets are different from the original ones (therefore
>     >     I wrote A' and B') -- even if the diff is the same, the parents
>     >     are not, and therefore the changeset id (hash) changes.  This is
>     >     called "changing history", and frowned upon by purists.  In reality
>     >     it works fine if you know the limits:
>     >
>     >
>     > It's frowned upon by more than just purists, and it works "in reality" as fine
>     > as handing out your creditcard and personal information over the internet; you
>     > can't always tell the result is bad, and it can be very painful finding out.
> 
>     Well, YMMV.  But instead of spreading FUD you might want to state *why*.
> 
> 
> I could also ask you what makes you think changing history is frowned upon by
> *just purists*, or why on earth anyone would think it's a good idea regardless
> of how practical or theoretical they are.

The "purists" (which may have been a slight hyperbole) came from the fact that
usually the only argument you're presented with is "but, but, you're changing
history!" -- and I usually reply "it's my private history, and it's none of your
concern if I change it".  I will still have to take the blame if my changesets
break the build, so or so.

> As for my dislike, your reason (changing history) and Davids apparent problem
> seem obvious enough. Aren't they?

Yes, it shows that you should know about the limits of rebase.  In particular,
it is not suited to the forward-merging branch workflow when these merges
already occurred.

> If you don't rebase correctly, stuff goes
> wrong. Doing it correctly is harder than people seem to think. You can see
> what's going on with 'hg outgoing -p', but I, as an observer, have no way of
> knowing whether you used that and were aware of what exactly you were pushing.

That isn't specific to rebased changesets though, but to all changesets.  (See
for example the recently committed changeset including merge conflict markers.)
And by pushing linear history, I'm even making it easier for others to review,
since merge commits are a real pain to review.

> Merges can also contain useful information about how *future* merges of the same
> changes should be handled. This doesn't matter much to changes with short
> turnaround (or changes that are continuously reverted and re-applied) but can
> make things a lot simpler if you have lots of diverging work in multiple
> branches -- and all the getting used to Mercurial aside, I'm sure that is what
> we're actually doing it for.

Yes, and for large parallel work it totally makes sense to use all the history
tracking that hg gives us.

> Even when done correctly, in situations where merges are automatic and do not
> involve the changed code in any way, I don't like rebasing a single changeset
> because it makes it less apparent when the actual work was started.

You need to remember that not all changesets are a) large or b) involve a lot of
code in different places.  Typical bugfix commits to Python touch one module,
its docs, and the NEWS file.  Others are even smaller.  It is utterly irrelevant
if I fixed a typo in the urllib docs when os.lseek was still leaking references,
or when it was already fixed.

> It's not any
> worse than diffing and re-applying a changeset, but for example if your change
> modified a particular call pattern appearing in multiples places, and another
> place started using the same pattern somewhere in your merges that you made go
> away, did you intentionally forget to fix the pattern or was it an accident?
> This isn't a problem that is *caused* by rebasing, but it certainly isn't helped
> by it.

Sure, you will be given a chance to fix all new call sites in the merge commit.
For this kind of change it makes much sense to merge.

> Rebasing multiple changesets is worse, because the intermediate
> changesets are a real lie rather than some fudging of history; your repository
> was never in that state, that changeset never looked that way and it was never
> built or tested that way. No matter that it *usually* doesn't matter, or even
> *almost never* matters, it *can* matter.

There we have the "purist" point again.

> Merging and merge changesets are a fact of DVCSes, and while I (as a grumpy
> luddite misanthrope) greatly prefer the automatic (and mostly silent) merge as
> BitKeeper does it, in the long run the actual merging and the merge changesets
> are unavoidable and something to get used to, not dodged around (at least not at
> this cost.)

I think we're not that far apart -- you as a grumpy luddite misanthrope just
like to stress the negative part a bit more :)

Georg


From digitalxero at gmail.com  Sun Mar 20 22:48:32 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sun, 20 Mar 2011 17:48:32 -0400
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D863FD1.9000204@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
	<AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>
	<4D863FD1.9000204@v.loewis.de>
Message-ID: <AANLkTinrQ0=QASTvuUF8sPaEsC7v94MGMmZ=SV-Ksgpe@mail.gmail.com>

On Sun, Mar 20, 2011 at 1:56 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> So if somebody would launch a python script with py.exe, they would
> think it was completed even though it would still be running.

Yes py.exe exits way before the python script, but the console stays
open, though now that I test it by running it via the command line and
not just launch it it directly I see what you mean the console returns
to usable then output starts being sent to it.

From anikom15 at gmail.com  Sun Mar 20 23:35:02 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Sun, 20 Mar 2011 15:35:02 -0700
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <im4hqe$5lf$1@dough.gmane.org>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D846CFA.2030808@g.nevcal.com>	<4D8568B4.3070102@skippinet.com.au>
	<4D85AB3C.6050802@g.nevcal.com>  <im4hqe$5lf$1@dough.gmane.org>
Message-ID: <1300660502.2535.3.camel@localhost.localdomain>

On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote:
> On 3/20/2011 3:22 AM, Glenn Linderman wrote:
> On 3/19/2011 7:38 PM, Mark Hammond wrote:
> [snip]
> 
> As both a writer and reader, I would like to just add, for instance,
> 
> #! python3
> 
> (or 3.3 or whatever) and have the launcher do the 'right thing'.
> It seems to me that that really should be enough info for *nix,
> but given that it is not, a program to add the required extra noise  for 
> a particular distribution to the first line of every module in a package 
> should not be too difficult.
> 
> The above would be easy for anyone to write and understand.
> 
That would break the whole point of platform-independence.  UNIX won't
understand that, and I don't think we're gonna be able to convince all
the kernel developers to implement this simplified shebang.


From martin at v.loewis.de  Mon Mar 21 00:32:01 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 00:32:01 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D866EAC.8050701@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>
	<4D85CACA.1070400@v.loewis.de> <4D85D637.3040403@skippinet.com.au>
	<4D866EAC.8050701@skippinet.com.au>
Message-ID: <4D868E71.7010306@v.loewis.de>

> The above raises an interesting question - if the launcher executed
> Python in-process, what would sys.executable be?  I can imagine there
> are few scenarios where it would be desirable to have it refer to the
> launcher and a number of scenarios where it would be undesirable and
> possibly break existing scripts.

Interesting question. What is it in COM and ISAPI applications?

Regards,
Martin

From rdmurray at bitdance.com  Mon Mar 21 00:39:25 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 20 Mar 2011 19:39:25 -0400
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
	launcher for Windows
In-Reply-To: <1300660502.2535.3.camel@localhost.localdomain>
References: <4D8446E0.7030401@skippinet.com.au> <4D846CFA.2030808@g.nevcal.com>
	<4D8568B4.3070102@skippinet.com.au>
	<4D85AB3C.6050802@g.nevcal.com> <im4hqe$5lf$1@dough.gmane.org>
	<1300660502.2535.3.camel@localhost.localdomain>
Message-ID: <20110320233925.E998D13F983@kimball.webabinitio.net>

On Sun, 20 Mar 2011 15:35:02 -0700, Westley =?ISO-8859-1?Q?Mart=EDnez?= <anikom15 at gmail.com> wrote:
> On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote:
> > On 3/20/2011 3:22 AM, Glenn Linderman wrote:
> > On 3/19/2011 7:38 PM, Mark Hammond wrote:
> > [snip]
> > 
> > As both a writer and reader, I would like to just add, for instance,
> > 
> > #! python3
> > 
> > (or 3.3 or whatever) and have the launcher do the 'right thing'.
> > It seems to me that that really should be enough info for *nix,
> > but given that it is not, a program to add the required extra noise  for 
> > a particular distribution to the first line of every module in a package 
> > should not be too difficult.
> > 
> > The above would be easy for anyone to write and understand.
> > 
> That would break the whole point of platform-independence.  UNIX won't
> understand that, and I don't think we're gonna be able to convince all
> the kernel developers to implement this simplified shebang.

+1.  If one of the points is to be compatible with PEP 394, then
the above seems like a bad idea.

However, I don't use windows, so I don't know if my vote should
count ;)

--
R. David Murray           http://www.bitdance.com

From greg.ewing at canterbury.ac.nz  Mon Mar 21 00:43:58 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 21 Mar 2011 12:43:58 +1300
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D866EAC.8050701@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
	<4D85D637.3040403@skippinet.com.au>
	<4D866EAC.8050701@skippinet.com.au>
Message-ID: <4D86913E.7010407@canterbury.ac.nz>

Mark Hammond wrote:

> The above raises an interesting question - if the launcher executed 
> Python in-process, what would sys.executable be?

I think it should be the actual Python executing at that
moment, not the launcher. This is the least change from
current behaviour and therefore least likely to break
existing code.

If some new code that's aware of the launcher wants to
use it, a new attribute such as sys.launcher could be
provided to make it easy to find. Or maybe a launch()
function that runs a specified script using launcher
semantics.

-- 
Greg

From mhammond at skippinet.com.au  Mon Mar 21 00:52:48 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 21 Mar 2011 10:52:48 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D868E71.7010306@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>
	<4D85CACA.1070400@v.loewis.de> <4D85D637.3040403@skippinet.com.au>
	<4D866EAC.8050701@skippinet.com.au> <4D868E71.7010306@v.loewis.de>
Message-ID: <4D869350.3060408@skippinet.com.au>

On 21/03/2011 10:32 AM, "Martin v. L?wis" wrote:
>> The above raises an interesting question - if the launcher executed
>> Python in-process, what would sys.executable be?  I can imagine there
>> are few scenarios where it would be desirable to have it refer to the
>> launcher and a number of scenarios where it would be undesirable and
>> possibly break existing scripts.
>
> Interesting question. What is it in COM and ISAPI applications?

ISAPI isn't a good example - that uses DLLs.  For COM objects hosted in 
a .exe it will be pythonw.exe.  For Windows services it will be 
pythonservice.exe (which is part of pywin32 and is located simply by 
assuming it is next to win32service.pyd)

Regardless, I don't think they are very likely to break - my concern is 
more for "normal" scripts which construct a child process cmdline/argv 
using sys.executable...

Mark

From martin at v.loewis.de  Mon Mar 21 01:08:55 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 01:08:55 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <1300660502.2535.3.camel@localhost.localdomain>
References: <4D8446E0.7030401@skippinet.com.au>	<4D846CFA.2030808@g.nevcal.com>	<4D8568B4.3070102@skippinet.com.au>	<4D85AB3C.6050802@g.nevcal.com>
	<im4hqe$5lf$1@dough.gmane.org>
	<1300660502.2535.3.camel@localhost.localdomain>
Message-ID: <4D869717.7030306@v.loewis.de>

>> #! python3
[...]
> That would break the whole point of platform-independence.

a) the PEP makes no point about platform-independence.
   it is a pure Windows thing, and has no stated objective
   to being platform-independent. So loss of platform-independence
   may not be deliberate, but is certainly acceptable.
b) platform-independence is not lost as the launcher would continue
   to support /usr/bin-based paths. So platform-independence would
   be an opt-in feature, at the choice of script authors.

Regards,
Martin

From martin at v.loewis.de  Mon Mar 21 01:10:41 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 01:10:41 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D869350.3060408@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au>	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>	<4D85CACA.1070400@v.loewis.de>
	<4D85D637.3040403@skippinet.com.au>	<4D866EAC.8050701@skippinet.com.au>
	<4D868E71.7010306@v.loewis.de> <4D869350.3060408@skippinet.com.au>
Message-ID: <4D869781.9070305@v.loewis.de>

Am 21.03.2011 00:52, schrieb Mark Hammond:
> On 21/03/2011 10:32 AM, "Martin v. L?wis" wrote:
>>> The above raises an interesting question - if the launcher executed
>>> Python in-process, what would sys.executable be?  I can imagine there
>>> are few scenarios where it would be desirable to have it refer to the
>>> launcher and a number of scenarios where it would be undesirable and
>>> possibly break existing scripts.
>>
>> Interesting question. What is it in COM and ISAPI applications?
> 
> ISAPI isn't a good example - that uses DLLs. 

Actually, this is precisely the example i was looking at.

> For COM objects hosted in
> a .exe it will be pythonw.exe.  For Windows services it will be
> pythonservice.exe (which is part of pywin32 and is located simply by
> assuming it is next to win32service.pyd)
> 
> Regardless, I don't think they are very likely to break - my concern is
> more for "normal" scripts which construct a child process cmdline/argv
> using sys.executable...

If we find out how other cases of just loading the DLL deal with
sys.executable, it may help us in guiding how it should be set in the
launcher.

Regards,
Martin

From timothy.c.delaney at gmail.com  Mon Mar 21 01:15:39 2011
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Mon, 21 Mar 2011 11:15:39 +1100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTinFAuJBnhhkrz5NQKvOwvUi+UNeft06Mw2CznLc@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTin_GJzi3PBar1VO=aUq1RoJbRuJm9tLDizQgn5X@mail.gmail.com>
	<im5bop$vem$1@dough.gmane.org>
	<AANLkTimLUFqkPsBBKR4vwr7vxxgRwv3iDZr5iJTyzo4E@mail.gmail.com>
	<AANLkTinFAuJBnhhkrz5NQKvOwvUi+UNeft06Mw2CznLc@mail.gmail.com>
Message-ID: <AANLkTin89PtkbfAX6npc5ZGVVPAf_7GK+vpRjNQR8exz@mail.gmail.com>

On 21 March 2011 08:16, Tim Delaney <timothy.c.delaney at gmail.com> wrote:

>
> For the second and later merges:
>
> hg update 1234_merged_with_3.2
> hg merge 3.2
> hg commit -m "Merged 3.2 to 1234_merged_with_3.2"
> hg merge 1234
> hg commit -m "Merged 1234 to 1234_merged_with_3.2"
>

Of course, you should probably do the "hg merge 1234" before "hg merge 3.2"
to avert the case that you actually "hg update 1234" here ...

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/a22ea0bd/attachment.html>

From martin at v.loewis.de  Mon Mar 21 01:15:40 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 01:15:40 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D86913E.7010407@canterbury.ac.nz>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>
	<4D85CACA.1070400@v.loewis.de>	<4D85D637.3040403@skippinet.com.au>	<4D866EAC.8050701@skippinet.com.au>
	<4D86913E.7010407@canterbury.ac.nz>
Message-ID: <4D8698AC.2070908@v.loewis.de>

Am 21.03.2011 00:43, schrieb Greg Ewing:
> Mark Hammond wrote:
> 
>> The above raises an interesting question - if the launcher executed
>> Python in-process, what would sys.executable be?
> 
> I think it should be the actual Python executing at that
> moment, not the launcher. This is the least change from
> current behaviour and therefore least likely to break
> existing code.

I remain -1 on any proposal that uses subprocesses. It absolutely must
be the launcher that is running Python. In fact, I'd call it
"python.exe".

Because of this issue, it may turn out infeasible to actually implement
the PEP. If Mark takes a stance in this issue, I'd request that the
opposite position is appropriately reflected (and rebutted) in the PEP.

Regards,
Martin

From greg.ewing at canterbury.ac.nz  Mon Mar 21 01:15:36 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 21 Mar 2011 13:15:36 +1300
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D867015.4050303@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
	<AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>
	<4D867015.4050303@skippinet.com.au>
Message-ID: <4D8698A8.9010506@canterbury.ac.nz>

Mark Hammond wrote:

> In addition to Martin's point, this approach would mean the exit code of 
> the child process probably isn't available to whoever started the 
> launcher.

Maybe I've missed something in this discussion, but is there
any reason the launcher can't just exec the relevant python?
Then the pid, exit status, etc. will all be as you would
expect if you'd invoked it directly.

-- 
Greg

From mhammond at skippinet.com.au  Mon Mar 21 01:29:34 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 21 Mar 2011 11:29:34 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D869781.9070305@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au>	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>	<4D85CACA.1070400@v.loewis.de>
	<4D85D637.3040403@skippinet.com.au>	<4D866EAC.8050701@skippinet.com.au>
	<4D868E71.7010306@v.loewis.de> <4D869350.3060408@skippinet.com.au>
	<4D869781.9070305@v.loewis.de>
Message-ID: <4D869BEE.5000500@skippinet.com.au>

On 21/03/2011 11:10 AM, "Martin v. L?wis" wrote:
> Am 21.03.2011 00:52, schrieb Mark Hammond:
>> On 21/03/2011 10:32 AM, "Martin v. L?wis" wrote:
>>>> The above raises an interesting question - if the launcher executed
>>>> Python in-process, what would sys.executable be?  I can imagine there
>>>> are few scenarios where it would be desirable to have it refer to the
>>>> launcher and a number of scenarios where it would be undesirable and
>>>> possibly break existing scripts.
>>>
>>> Interesting question. What is it in COM and ISAPI applications?
>>
>> ISAPI isn't a good example - that uses DLLs.
>
> Actually, this is precisely the example i was looking at.
>
>> For COM objects hosted in
>> a .exe it will be pythonw.exe.  For Windows services it will be
>> pythonservice.exe (which is part of pywin32 and is located simply by
>> assuming it is next to win32service.pyd)
>>
>> Regardless, I don't think they are very likely to break - my concern is
>> more for "normal" scripts which construct a child process cmdline/argv
>> using sys.executable...
>
> If we find out how other cases of just loading the DLL deal with
> sys.executable, it may help us in guiding how it should be set in the
> launcher.

I guess it is all about context; in an ISAPI application or in a COM 
object implemented in a DLL, sys.executable will be the name of the host 
process (which is determined in PC/getpathp.c by calling 
GetModuleFileName with a NULL handle).  People writing ISAPI apps or COM 
objects are likely to understand the implications of them existing in 
some process which isn't python[w].exe so will ignore sys.executable and 
use some other technique to locate a python[w].exe if they need it.

"Normal" scripts are less likely to do so - a code search at google for 
sys.executable shows it used in ways which would possibly break if 
sys.executable referred to a launcher and the launcher didn't use the 
"current" version of Python as the default.  Often these are in tests or 
setup.py, but we would need to avoid any such breakage.

[Which isn't to suggest we can't avoid such breakage with an "in-process 
launcher" - it just isn't immediately clear how we would do so]

Cheers,

Mark

From martin at v.loewis.de  Mon Mar 21 01:30:17 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 01:30:17 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D8698A8.9010506@canterbury.ac.nz>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>
	<4D85CACA.1070400@v.loewis.de>	<AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>	<4D867015.4050303@skippinet.com.au>
	<4D8698A8.9010506@canterbury.ac.nz>
Message-ID: <4D869C19.2070000@v.loewis.de>

>> In addition to Martin's point, this approach would mean the exit code
>> of the child process probably isn't available to whoever started the
>> launcher.
> 
> Maybe I've missed something in this discussion, but is there
> any reason the launcher can't just exec the relevant python?

Windows doesn't support exec.

Regards,
Martin

From tjreedy at udel.edu  Mon Mar 21 01:34:23 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 20 Mar 2011 20:34:23 -0400
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <1300660502.2535.3.camel@localhost.localdomain>
References: <4D8446E0.7030401@skippinet.com.au>	<4D846CFA.2030808@g.nevcal.com>	<4D8568B4.3070102@skippinet.com.au>	<4D85AB3C.6050802@g.nevcal.com>
	<im4hqe$5lf$1@dough.gmane.org>
	<1300660502.2535.3.camel@localhost.localdomain>
Message-ID: <im66ei$1cn$1@dough.gmane.org>

On 3/20/2011 6:35 PM, Westley Mart?nez wrote:
> On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote:

>> As both a writer and reader, I would like to just add, for instance,
>>
>> #! python3
>>
>> (or 3.3 or whatever) and have the launcher do the 'right thing'.
>> It seems to me that that really should be enough info for *nix,
>> but given that it is not, a program to add the required extra noise  for
>> a particular distribution to the first line of every module in a package
>> should not be too difficult.
>>
>> The above would be easy for anyone to write and understand.
>>
> That would break the whole point of platform-independence.  UNIX won't
> understand that, and I don't think we're gonna be able to convince all
> the kernel developers to implement this simplified shebang.

Given that the default for code developed on windows is NO #! line (and 
that may also be true for new programmers in *nix too, for all I know), 
I should think that the above would be an improvement. It does not 
require new Python programmers on Windows to know anything about *nix 
(pseudo?)paths, nor about the '/' versus '\' fuss. One should only need 
to know all that if one wishes to distribute to *nix *and* to have 
script files directly executable. (I presume 'python x.py' does not 
require a #! line on *nix either.)

For people who do want to do that, I already suggested that there be a 
program that scans through a directory tree, looking for files that 
start with '#! " and replacing that when found with '#!/usr/bin/env ' or 
whatever. That could be done once, before distribution. And it would not 
even require understanding of the substitution.

-- 
Terry Jan Reedy



From mhammond at skippinet.com.au  Mon Mar 21 02:09:13 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 21 Mar 2011 12:09:13 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D8698AC.2070908@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au>	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>	<4D85CACA.1070400@v.loewis.de>	<4D85D637.3040403@skippinet.com.au>	<4D866EAC.8050701@skippinet.com.au>	<4D86913E.7010407@canterbury.ac.nz>
	<4D8698AC.2070908@v.loewis.de>
Message-ID: <4D86A539.1050004@skippinet.com.au>

On 21/03/2011 11:15 AM, "Martin v. L?wis" wrote:
> Am 21.03.2011 00:43, schrieb Greg Ewing:
>> Mark Hammond wrote:
>>
>>> The above raises an interesting question - if the launcher executed
>>> Python in-process, what would sys.executable be?
>>
>> I think it should be the actual Python executing at that
>> moment, not the launcher. This is the least change from
>> current behaviour and therefore least likely to break
>> existing code.
>
> I remain -1 on any proposal that uses subprocesses. It absolutely must
> be the launcher that is running Python. In fact, I'd call it
> "python.exe".

For clarity, could you please tell us which scenarios you have in mind 
that cause you to take that position, and why those scenarios couldn't 
ignore the existence of the launcher and stick with doing exactly what 
they do now (which presumably is to use python.exe directly)?

Thanks,

Mark

From martin at v.loewis.de  Mon Mar 21 02:27:58 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 02:27:58 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D86A539.1050004@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au>	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>	<4D85CACA.1070400@v.loewis.de>	<4D85D637.3040403@skippinet.com.au>	<4D866EAC.8050701@skippinet.com.au>	<4D86913E.7010407@canterbury.ac.nz>
	<4D8698AC.2070908@v.loewis.de> <4D86A539.1050004@skippinet.com.au>
Message-ID: <4D86A99E.9060908@v.loewis.de>

>> I remain -1 on any proposal that uses subprocesses. It absolutely must
>> be the launcher that is running Python. In fact, I'd call it
>> "python.exe".
> 
> For clarity, could you please tell us which scenarios you have in mind
> that cause you to take that position, and why those scenarios couldn't
> ignore the existence of the launcher and stick with doing exactly what
> they do now (which presumably is to use python.exe directly)?

I'm primarily bothered about the failure to implement TerminateProcess
correctly. I don't actually know what use cases would be affected, other
then saying that anything launching py.exe could be affect, in
particular applications using ShellExecuteEx. I don't think it is
feasible to change them all to launch something different instead; some
may be out of our control. Potential candidates would be web servers.

Regards,
Martin

From mhammond at skippinet.com.au  Mon Mar 21 02:54:00 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 21 Mar 2011 12:54:00 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D86A99E.9060908@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au>	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>	<4D85CACA.1070400@v.loewis.de>	<4D85D637.3040403@skippinet.com.au>	<4D866EAC.8050701@skippinet.com.au>	<4D86913E.7010407@canterbury.ac.nz>
	<4D8698AC.2070908@v.loewis.de> <4D86A539.1050004@skippinet.com.au>
	<4D86A99E.9060908@v.loewis.de>
Message-ID: <4D86AFB8.4040006@skippinet.com.au>

On 21/03/2011 12:27 PM, "Martin v. L?wis" wrote:
>>> I remain -1 on any proposal that uses subprocesses. It absolutely must
>>> be the launcher that is running Python. In fact, I'd call it
>>> "python.exe".
>>
>> For clarity, could you please tell us which scenarios you have in mind
>> that cause you to take that position, and why those scenarios couldn't
>> ignore the existence of the launcher and stick with doing exactly what
>> they do now (which presumably is to use python.exe directly)?
>
> I'm primarily bothered about the failure to implement TerminateProcess
> correctly. I don't actually know what use cases would be affected, other
> then saying that anything launching py.exe could be affect, in
> particular applications using ShellExecuteEx. I don't think it is
> feasible to change them all to launch something different instead; some
> may be out of our control. Potential candidates would be web servers.

This fear seems overblown to me as I doubt any such programs exist.  A 
program could not use ShellExecuteEx on an arbitrary file extension and 
hope to obtain a handle it can use to kill the process - the docs make 
it clear no handle is returned in a number of common cases and implies 
that even if you get a handle back you should not kill it (as it 
explicitly states that a single process may be the target for any number 
of such calls.)  For the same reason, you can't even wait on it unless 
you know the implementation of the associated program.

So this scenario would need to be a program which used ShellExecuteEx 
only to launch Python programs and therefore felt it could rely on the 
ability to (a) always get a handle back and (b) use TerminateProcess to 
kill it.  ISTM the likelihood of such a program existing is so low that 
it should not kill the chances of this PEP being accepted if the 
sub-process model is the only reasonable way to implement the launcher.

ie, let's say we are forced to choose between the following 3 options:

* No launcher at all (the status-quo), causing demonstrable breakage in 
Windows file associations whenever Python 2.x and Python 3.x scripts 
exist on the same box.

* An in-process launcher which caused breakage in a number of reasonably 
common scenarios for Python programmers, and such breakage could easily 
be demonstrated.

* An out-of-process launcher which caused breakage for the hypothetical 
program mentioned above, of which no instance can be found and no 
breakage actually demonstrated.

I personally would conclude that the last option is the least worst 
scenario by a wide margin.

Cheers,

Mark

From martin at v.loewis.de  Mon Mar 21 03:04:38 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 03:04:38 +0100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D86AFB8.4040006@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au>	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>	<4D85CACA.1070400@v.loewis.de>	<4D85D637.3040403@skippinet.com.au>	<4D866EAC.8050701@skippinet.com.au>	<4D86913E.7010407@canterbury.ac.nz>
	<4D8698AC.2070908@v.loewis.de> <4D86A539.1050004@skippinet.com.au>
	<4D86A99E.9060908@v.loewis.de> <4D86AFB8.4040006@skippinet.com.au>
Message-ID: <4D86B236.5020808@v.loewis.de>

> I personally would conclude that the last option is the least worst
> scenario by a wide margin.

Ok, I let this rest. Can you please add a summary of this discussion to
the PEP? (also, can you please check in the PEP, and give it a number?)

Thanks,
Martin

From curt at hagenlocher.org  Mon Mar 21 03:15:41 2011
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Sun, 20 Mar 2011 19:15:41 -0700
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D86A99E.9060908@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
	<4D85D637.3040403@skippinet.com.au>
	<4D866EAC.8050701@skippinet.com.au>
	<4D86913E.7010407@canterbury.ac.nz> <4D8698AC.2070908@v.loewis.de>
	<4D86A539.1050004@skippinet.com.au> <4D86A99E.9060908@v.loewis.de>
Message-ID: <AANLkTi=rxOqtMe0FFsb4GmPJQK1nxM0mwTzoZ1xaXiDj@mail.gmail.com>

On Sun, Mar 20, 2011 at 6:27 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> I'm primarily bothered about the failure to implement TerminateProcess
> correctly. I don't actually know what use cases would be affected, other
> then saying that anything launching py.exe could be affect, in
> particular applications using ShellExecuteEx. I don't think it is
> feasible to change them all to launch something different instead; some
> may be out of our control. Potential candidates would be web servers.

This can be worked around, depending on the level of inelegance you're
willing to accept. A third watchdog process could wait on the launcher
being terminated, and use that to terminate the child Python.exe
process. Alternatively, the launcher could inject a sentinel thread
into the Python.exe process using CreateRemoteThread. Both approaches
would work for any target implementation or bitness of Python.

-Curt

From guido at python.org  Mon Mar 21 03:34:18 2011
From: guido at python.org (Guido van Rossum)
Date: Sun, 20 Mar 2011 19:34:18 -0700
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <20110320194023.DADE113F980@kimball.webabinitio.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110320194023.DADE113F980@kimball.webabinitio.net>
Message-ID: <AANLkTin7v8vvBRS-ZUSHqBmjeKy83_Q=tVSpfBNF+H+s@mail.gmail.com>

On Sun, Mar 20, 2011 at 12:40 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Mon, 21 Mar 2011 03:44:34 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>> I'm coming to the conclusion that those who say that Mercurial
>> documentation should be found at the Mercurial project are wrong. ?I
>
> +1. ?I think the dev docs should explain anything needed to do the
> basic Python workflow, even if that feels like repeating parts of the
> Mercurial docs. ?(If it is a large chunk, then a pointer to the exactly
> relevant section of the Mercurial docs would be appropriate.) ?On the
> other hand, I'm not offering to do the work, so I'll happily accept
> what has been produced so far (thanks, Antoine!).
>
>> think there's a reasonably strong case (based on the explicit promise
>> of PEP 0374 that workflows would change as little as possible) for a
>> follow-on informational PEP providing verbal, and maybe automated,
>> scripts for the various operations needed in the Python workflow.
>
> Sounds good, but someone needs to write them. ?You'll note that I've been
> asking for this for a while, but as it turns out it wasn't really possible
> to write them "correctly" until we started actually using the system.
> I'm still not comfortable enough to write them myself, but after I've
> used my chosen workflow for a while I'll do my best to write it up in
> more detail than my earlier post as a blog post or something.

I think it ought to be added to the dev guide instead of a PEP.
Otherwise I agree -- the workflows are somewhat unique to Python. I
personally sure haven't grokked them yet, not having done anything
that required merging yet. (TBH I never got the hang of our SVN merge
flow either.)

-- 
--Guido van Rossum (python.org/~guido)

From guido at python.org  Mon Mar 21 03:46:06 2011
From: guido at python.org (Guido van Rossum)
Date: Sun, 20 Mar 2011 19:46:06 -0700
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im5pr1$7da$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<20110320124049.70610337@pitrou.net> <im4sb2$lg1$1@dough.gmane.org>
	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>
	<im5028$7h7$1@dough.gmane.org>
	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>
	<im5pr1$7da$1@dough.gmane.org>
Message-ID: <AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>

On Sun, Mar 20, 2011 at 1:59 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> [warning, long post ahead]
[all snipped]

Thanks for the clarifications. I now have a much better understanding
of what Cython is. But I'm not sold. For one, your attitude about
strict language compatibility worries me when it comes to the stdlib.
Also, I don't know how big it is, but it seems putting the cart before
the horse to use it to optimize the stdlib. Cython feels much less
mature than CPython; but the latter should only have dependencies that
themselves change even slower than CPython. I also am unclear on how
exactly you're supporting the different semantics in Python 2 vs. 3
without recompiling.

OTOH I think you've got the perfect audience in the scientific Python
world. Have you tried replacing selected stdlib modules with their
Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g.
what about Enthought's Python distros?) Depending on how well that
goes I might warm up to Cython more!

-- 
--Guido van Rossum (python.org/~guido)

From merwok at netwok.org  Mon Mar 21 03:49:17 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 21 Mar 2011 03:49:17 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110317133050.AE51624CB5D@kimball.webabinitio.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<AANLkTiktF+E2VsbP-exEJRQDUYXw18zFfOM27mgvRAGL@mail.gmail.com>
	<20110317133050.AE51624CB5D@kimball.webabinitio.net>
Message-ID: <4D86BCAD.4070406@netwok.org>

> I have been avoiding hg import because my understanding is that it
> defaults to commit, and I don't see that it has any advantage over patch
> itself.
?hg import? understands the extended diff format, which patch does not.
 (That format has been described a number of times already, see
http://mercurial.selenic.com/wiki/GitExtendedDiffFormat.)

?hg import --no-commit? is basically a patch command that understands
the extended format.  (Pro tip: it can be abbreviated to ?hg import
--no-c?, as Mercurial accepts unambiguous abbreviations of commands and
options.)

?hg import? can also use metadata in changeset files, that is, diffs
with a special header containing the parent, date, author and commit
message, such as produced by ?hg export?.  (Having symmetric names
without compatibility would be nothing short of criminal, but I?ve found
Mercurial satisfyingly consistent in those matters.)

> I'll have to check that out.
Remember that ?hg help command? is always here, and that the Mercurial
wiki and search engines have a lot of complementary information.

Regards

From merwok at netwok.org  Mon Mar 21 03:55:37 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 21 Mar 2011 03:55:37 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <nad-21FD11.18594319032011@news.gmane.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<19844.65128.436929.526859@montanaro.dyndns.org>	<AANLkTiktVXSRMLW0Z8iFVZ3LkAEDV8vui_A4f-OciXcU@mail.gmail.com>
	<nad-21FD11.18594319032011@news.gmane.org>
Message-ID: <4D86BE29.8070900@netwok.org>

Le 20/03/2011 02:59, Ned Deily a ?crit :
> On a Unix-y system, here is one way to do it (no warranty on the 
> installation instructions!):

With all due respect, the instructions are overly complicated, and may
also run afoul of the system conventions (sudo will put files in
directories that should not be touched for example).

Here?s my take:

Get the code
  $ cd where/ever
  $ hg clone http://hg.python.org/hooks

Edit your user ~/.hgrc of the cpython clones .hg/hgrc to enable the hook
  [hooks]
  pretxncommit.whitespace =
python:/home/you/where/ever/hooks/checkwhitespace.py:check_whitespace_single

Regards

From martin at v.loewis.de  Mon Mar 21 04:09:35 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 04:09:35 +0100
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
Message-ID: <4D86C16F.8080403@v.loewis.de>

Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
one outputting int; the other one outputting Py_ssize_t.

The former should have been removed in 3.0, but this was forgotten.

Still, I would like people to move over to the new version, so
that extension modules will typically support 64-bit collections
well. Therefore, I'd like to propose that the int version is deprecated
in 3.3.

Given the recent discussion about backwards compatibility: what's
the best approach? What warning should be emitted, if any?
(the warning would only be generated if an s# or similar format
 was actually encountered - not just if merely PyArg_ParseTuple is
 called).

Regards,
Martin

From nad at acm.org  Mon Mar 21 05:07:51 2011
From: nad at acm.org (Ned Deily)
Date: Sun, 20 Mar 2011 21:07:51 -0700
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<19844.65128.436929.526859@montanaro.dyndns.org>
	<AANLkTiktVXSRMLW0Z8iFVZ3LkAEDV8vui_A4f-OciXcU@mail.gmail.com>
	<nad-21FD11.18594319032011@news.gmane.org>
	<4D86BE29.8070900@netwok.org>
Message-ID: <nad-81A710.21075020032011@news.gmane.org>

In article <4D86BE29.8070900 at netwok.org>,
 ?ric Araujo <merwok at netwok.org> wrote:
> Le 20/03/2011 02:59, Ned Deily a ?crit :
> > On a Unix-y system, here is one way to do it (no warranty on the 
> > installation instructions!): 
> With all due respect, the instructions are overly complicated, and may
> also run afoul of the system conventions (sudo will put files in
> directories that should not be touched for example).

That depends on your configuration but ...

> Here?s my take:
> 
> Get the code
>   $ cd where/ever
>   $ hg clone http://hg.python.org/hooks
> 
> Edit your user ~/.hgrc of the cpython clones .hg/hgrc to enable the hook
>   [hooks]
>   pretxncommit.whitespace =
> python:/home/you/where/ever/hooks/checkwhitespace.py:check_whitespace_single

that's *much* better, thanks!  The hg documentation does not make it 
clear that, in the absolute path case, PYTHONPATH does not need to be 
manipulated, which is what I was trying to avoid.

Perhaps you could add those instructions to the devguide?

-- 
 Ned Deily,
 nad at acm.org


From greg.ewing at canterbury.ac.nz  Mon Mar 21 05:50:21 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 21 Mar 2011 17:50:21 +1300
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D869C19.2070000@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
	<AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>
	<4D867015.4050303@skippinet.com.au> <4D8698A8.9010506@canterbury.ac.nz>
	<4D869C19.2070000@v.loewis.de>
Message-ID: <4D86D90D.2010509@canterbury.ac.nz>

Martin v. L?wis wrote:

> Windows doesn't support exec.

Hmmm. In that case, if the launcher works by loading a pythonXY.dll,
I'd say that sys.executable should point to whatever version of
python.exe corresponds to that dll.

Generally, things should be made to look as much as possible as
if that python.exe had been executed in the first place.

-- 
Greg

From stephen at xemacs.org  Mon Mar 21 06:07:46 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 21 Mar 2011 14:07:46 +0900
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <19846.24793.573280.126001@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
Message-ID: <87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>

skip at pobox.com writes:

 >     Stephen> interactions across modules.  That is, it's not that Subversion
 >     Stephen> provided a simpler way of doing the work.  Rather, it hid the
 >     Stephen> fact that certain work was not being done at all.  hg exposes
 >     Stephen> this fact.

 > Can you provide an example of this (real or hypothetical)?

What happened to you is a real example.  With svn it would go
through, and any problems would be caught later.  With hg, it doesn't.

This is basically the statistical idea of false positives vs. false
negatives.  svn tends to generate false negatives (tests don't fail
until after the merge), while hg tends to generate false positives
(merges fail because they aren't "fast-forwards").

 > It seems to me that if all you have is unit tests it matters
 > little, if at all, whether you catch test failures before a checkin
 > (in your local hg repo) or after (using svn + a buildbot run).

In the long run, that's right.  In the short run the choice is between
imposing a substantially higher burden of merging and testing on
individual developers in order to get a higher quality shared branches
versus imposing a detectably higher burden on the project as whole in
terms of red buildbots.  It clearly matters to the individual
developers, and core developers are likely to have different interests
here from the occasional committers.

The burden on the project could get *very* high; that's why the Linux
kernel went to Bitkeeper, then git, rather than Subversion.  It was
necessary to impose as much burden on the branches as possible before
merging to trunk.  But then, Python doesn't have anywhere near the
change rate that the kernel does (Lennart R's woes notwithstanding).

I'm not going to take a position on what's best for the Python
project; I've drunk the DVCS Kool-Aid and am very much in Jesus's
"let's work with the tools, not against them" camp.  But there's an
uncertain amoung of bias in that opinion, and I'm not a committer so
can't speak from experience with the Python workflow.

 > The workflow of the version control system isn't going to magically
 > expose semantic interactions across modules.  It seems to me that
 > at best the new workflow means there is a better chance of catching
 > textual conflicts before checkin than before.

No, at best the DVCS workflow forces the developer on a branch to
merge and test the revisions that will actually be added to the
repository, and perhaps notice system-level anomolies before pushing.
Whether that is significant in practice is as yet a matter of faith
for me.  But again that's a personal opinion, not yet a recommendation
for the project.

From mhammond at skippinet.com.au  Mon Mar 21 06:30:56 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 21 Mar 2011 16:30:56 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D86D90D.2010509@canterbury.ac.nz>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>
	<4D85CACA.1070400@v.loewis.de>	<AANLkTims5jPLT7DAWuSbbUVRs930nvcX-hgdjipsTBAN@mail.gmail.com>	<4D867015.4050303@skippinet.com.au>
	<4D8698A8.9010506@canterbury.ac.nz>	<4D869C19.2070000@v.loewis.de>
	<4D86D90D.2010509@canterbury.ac.nz>
Message-ID: <4D86E290.9090606@skippinet.com.au>

On 21/03/2011 3:50 PM, Greg Ewing wrote:
> Martin v. L?wis wrote:
>
>> Windows doesn't support exec.
>
> Hmmm. In that case, if the launcher works by loading a pythonXY.dll,
> I'd say that sys.executable should point to whatever version of
> python.exe corresponds to that dll.
>
> Generally, things should be made to look as much as possible as
> if that python.exe had been executed in the first place.

Yeah, that would have to be the plan - if there are ways it *doesn't* 
look like python.exe had been executed it is likely to cause problems.

Initially I thought we could just adjust sys.executable after it is set 
to the "inappropriate" default value, but that would be tricky - this is 
called by Python during Py_Main() - which also executes the specified 
script.  Thus, the launcher would either:

* Call Py_Initialize(), adjust sys.executable, then call Py_Main().  I'm 
not sure what side-effects this would have though - Py_Main does a 
number of things before calling Py_Initialize() and having it called 
before those things are done might have other side-effects.

* Re-implement Py_Main and adjust sys.executable immediately after it is 
set.  This would be a huge burden given the size of that routine and the 
number of different versions we want to support.

The first option is the only one I'd really consider reasonable and I'll 
probably experiment with it once we have enough agreement that the C 
implementation can proceed - but I'm not confident enough we can make it 
work correctly to base the entire success or failure of the PEP on that 
detail.

Any other ideas/thoughts about this?

Mark

From greg.ewing at canterbury.ac.nz  Mon Mar 21 06:42:37 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 21 Mar 2011 18:42:37 +1300
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<20110320124049.70610337@pitrou.net> <im4sb2$lg1$1@dough.gmane.org>
	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>
	<im5028$7h7$1@dough.gmane.org>
	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>
	<im5pr1$7da$1@dough.gmane.org>
	<AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>
Message-ID: <4D86E54D.4070604@canterbury.ac.nz>

Guido van Rossum wrote:
> Cython feels much less
> mature than CPython; but the latter should only have dependencies that
> themselves change even slower than CPython.

You might be slightly more amenable to Pyrex, then, which
changes at a much more conservative pace!

They appear superficially similar, but there is a difference
in underlying philosophy. Pyrex makes no claim to be a
Python compiler; rather, it's a tool for bridging between
the Python and C worlds. As such, strict adherence to
Python syntax and semantics, or supporting all Python
features, or performing heroic optimisations on pure
Python code, are not design goals.

So it wouldn't make sense to try to compile any of the
pure Python parts of the stdlib with Pyrex. However, it
could make sense to use it for some of the modules
currently written in C, or for future modules that
would otherwise be written in C, to make them easier to
write, read and maintain.

Think of it as a tool for writing modules in C without
having to worry about reference counts or exception
handling.

If you think you might seriously consider using Pyrex,
I could translate a module or two from the stdlib so
you can see how the code might look.

> I also am unclear on how
> exactly you're supporting the different semantics in Python 2 vs. 3
> without recompiling.

I gather that Cython generates code with a lot of #ifs
for doing things differently depending on the Python
version.

I haven't decided exactly how to handle Python 3 in
Pyrex yet, but I have some ideas. I'm not sure whether
it will generate dual-version C files or not. It
probably wouldn't matter much for stdlib usage, though,
because it only needs to generate C code good enough
for a particular release of Python.

-- 
Greg


From contactprashantat at gmail.com  Mon Mar 21 07:37:02 2011
From: contactprashantat at gmail.com (Prashant Kumar)
Date: Mon, 21 Mar 2011 12:07:02 +0530
Subject: [Python-Dev] [GSoC] Porting on RPM3
Message-ID: <AANLkTik0C8JdwCafpgeoq10_nm7J4yRBqR-LSSqniwOO@mail.gmail.com>

Hello,
    My name is  Prashant Kumar and I've worked on porting few python
libraries(distutils2, configobj) and I've been looking at the ideas
list for GSoC for a project related to porting.

    I came across [1]  and found it interesting. It mentions that some
of the work has already been done; I would like to look at the code
repository for the same, could someone provide me the link for the
same?


Regards,
pkumar

[1] http://wiki.python.org/moin/RPMOnPython3

From rdmurray at bitdance.com  Mon Mar 21 07:58:35 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 21 Mar 2011 02:58:35 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20110321065835.664EC16245C@kimball.webabinitio.net>

On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> No, at best the DVCS workflow forces the developer on a branch to
> merge and test the revisions that will actually be added to the
> repository, and perhaps notice system-level anomolies before pushing.

hg does not force the developer to test, it only forces the merge.

As far as I can see, the only difference between hg and svn in this
regard is that svn merging was easier, because, as you say, it was done
behind the scenes when one did a conflict-free commit.  If there were
conflicts, though, you had the same need to merge to tip as with hg,
and the same lack of enforcing of the running of tests.

--
R. David Murray           http://www.bitdance.com

From mhammond at skippinet.com.au  Mon Mar 21 08:16:01 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 21 Mar 2011 18:16:01 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D86B236.5020808@v.loewis.de>
References: <4D8446E0.7030401@skippinet.com.au>	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>	<4D85CACA.1070400@v.loewis.de>	<4D85D637.3040403@skippinet.com.au>	<4D866EAC.8050701@skippinet.com.au>	<4D86913E.7010407@canterbury.ac.nz>	<4D8698AC.2070908@v.loewis.de>
	<4D86A539.1050004@skippinet.com.au>	<4D86A99E.9060908@v.loewis.de>
	<4D86AFB8.4040006@skippinet.com.au> <4D86B236.5020808@v.loewis.de>
Message-ID: <4D86FB31.8020700@skippinet.com.au>

On 21/03/2011 1:04 PM, "Martin v. L?wis" wrote:
> Can you please add a summary of this discussion to
> the PEP? (also, can you please check in the PEP, and
 > give it a number?)

OK, I'll check it in once I get a PEP number allocated as per PEP1, 
updated to reflect some of the discussions in this thread.

Should I also check the reference implementation in?  Maybe next to the 
PEP text as "pep-NNNN-reference.py"?

Thanks,

Mark

From mail at timgolden.me.uk  Mon Mar 21 10:02:56 2011
From: mail at timgolden.me.uk (Tim Golden)
Date: Mon, 21 Mar 2011 09:02:56 +0000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D86BCAD.4070406@netwok.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<AANLkTiktF+E2VsbP-exEJRQDUYXw18zFfOM27mgvRAGL@mail.gmail.com>	<20110317133050.AE51624CB5D@kimball.webabinitio.net>
	<4D86BCAD.4070406@netwok.org>
Message-ID: <4D871440.2000200@timgolden.me.uk>

On 21/03/2011 02:49, ?ric Araujo wrote:
>> I have been avoiding hg import because my understanding is that it
>> defaults to commit, and I don't see that it has any advantage over patch
>> itself.
> ?hg import? understands the extended diff format, which patch does not.
>   (That format has been described a number of times already, see
> http://mercurial.selenic.com/wiki/GitExtendedDiffFormat.)
>
> ?hg import --no-commit? is basically a patch command that understands
> the extended format.  (Pro tip: it can be abbreviated to ?hg import
> --no-c?, as Mercurial accepts unambiguous abbreviations of commands and
> options.)

A further tip in case it helps anyone: hg import (and its mq
counterpart hg qimport) can patch directly from a URL. This
is handy when I want to try out someone's patch directly from
the issue page on bugs.python.org. [Maybe everyone else knew
this, but I found it out by accident!]

TJG

From stephen at xemacs.org  Mon Mar 21 10:33:00 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 21 Mar 2011 18:33:00 +0900
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <20110321065835.664EC16245C@kimball.webabinitio.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
Message-ID: <87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>

R. David Murray writes:
 > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
 > > No, at best the DVCS workflow forces the developer on a branch to
 > > merge and test the revisions that will actually be added to the
 > > repository, and perhaps notice system-level anomolies before pushing.
 > 
 > hg does not force the developer to test, it only forces the merge.

I didn't say any VCS forces the test; I said that the workflow can (in
the best case).  That's also inaccurate, of course.  I should have
said "require", not "force".

My understanding is that svn does not detect fast forwards, only lack
of conflicts, and therefore in case of concurrent development it is
possible that the repository contains a version that never existed in
any developer's workspace.  If that is not true, I apologize for the
misinformation.

If it is true, by definition developers cannot test or review what
hasn't existed in their workspace; that testing and review is
therefore imposed on the project as a whole, and perhaps not done
until more concurrent commits have been made.  On the other hand, in a
DVCS this can't happen under normal circumstances.

 > As far as I can see, the only difference between hg and svn in this
 > regard is that svn merging was easier, because, as you say, it was done
 > behind the scenes when one did a conflict-free commit.

That's true from the point of view of the individual developer; the
DVCS requires more effort of her.  That is not true from the point of
view of the whole project however.

It would be possible for the svn-based workflow to require that after
testing in one's workspace, one does an svn update, and if any changes
are made to files in the workspace, the whole build and test procedure
must be repeated.  I don't see that that has advantages over the hg
workflow, though -- it should cause an addition build-test cycle in
exactly the same revision sequences that the hg workflow does.


From martin at v.loewis.de  Mon Mar 21 10:44:01 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 10:44:01 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>
	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D871DE1.6020307@v.loewis.de>

> My understanding is that svn does not detect fast forwards, only lack
> of conflicts, and therefore in case of concurrent development it is
> possible that the repository contains a version that never existed in
> any developer's workspace.  

I can't understand how you draw this conclusion ("therefore").

If you do an svn up, it merges local changes with remote changes;
if that works without conflicts, it tells you what files it merged,
but lets you commit.

Still, in this case, the merge result did exist in the sandbox
of the developer performing the merge. Subversion never ever creates
versions in the repository that didn't before exist in some working
copy. The notion that it may have done a server-side merge or some
such is absurd.

> If it is true, by definition developers cannot test or review what
> hasn't existed in their workspace; that testing and review is
> therefore imposed on the project as a whole, and perhaps not done
> until more concurrent commits have been made.

You make it sound as if you have never used subversion.

Regards,
Martin

From martin at v.loewis.de  Mon Mar 21 10:45:02 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 21 Mar 2011 10:45:02 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D871440.2000200@timgolden.me.uk>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<AANLkTiktF+E2VsbP-exEJRQDUYXw18zFfOM27mgvRAGL@mail.gmail.com>	<20110317133050.AE51624CB5D@kimball.webabinitio.net>	<4D86BCAD.4070406@netwok.org>
	<4D871440.2000200@timgolden.me.uk>
Message-ID: <4D871E1E.2030306@v.loewis.de>

> A further tip in case it helps anyone: hg import (and its mq
> counterpart hg qimport) can patch directly from a URL. This
> is handy when I want to try out someone's patch directly from
> the issue page on bugs.python.org. [Maybe everyone else knew
> this, but I found it out by accident!]

Thanks - I didn't know, and it sounds useful.

Regards,
Martin

From martin at v.loewis.de  Mon Mar 21 10:50:32 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 10:50:32 +0100
Subject: [Python-Dev] [GSoC] Porting on RPM3
In-Reply-To: <AANLkTik0C8JdwCafpgeoq10_nm7J4yRBqR-LSSqniwOO@mail.gmail.com>
References: <AANLkTik0C8JdwCafpgeoq10_nm7J4yRBqR-LSSqniwOO@mail.gmail.com>
Message-ID: <4D871F68.4000608@v.loewis.de>

Am 21.03.2011 07:37, schrieb Prashant Kumar:
> Hello,
>     My name is  Prashant Kumar and I've worked on porting few python
> libraries(distutils2, configobj) and I've been looking at the ideas
> list for GSoC for a project related to porting.
> 
>     I came across [1]  and found it interesting. It mentions that some
> of the work has already been done; I would like to look at the code
> repository for the same, could someone provide me the link for the
> same?

Not so much the code but the person who did the porting. This was Dave
Malcolm (CC'ed); please get in touch with him. Please familiarize
yourself with the existing Python bindings (in the latest RPM 4 release
from rpm.org). You'll notice that this already has Python 3 support;
not sure whether that's the most recent code, though.

Regards,
Martin

From ncoghlan at gmail.com  Mon Mar 21 11:57:51 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 Mar 2011 20:57:51 +1000
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D86FB31.8020700@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
	<4D85D637.3040403@skippinet.com.au>
	<4D866EAC.8050701@skippinet.com.au>
	<4D86913E.7010407@canterbury.ac.nz> <4D8698AC.2070908@v.loewis.de>
	<4D86A539.1050004@skippinet.com.au> <4D86A99E.9060908@v.loewis.de>
	<4D86AFB8.4040006@skippinet.com.au> <4D86B236.5020808@v.loewis.de>
	<4D86FB31.8020700@skippinet.com.au>
Message-ID: <AANLkTi=2nDYhf7MuvUgojLcGgF=0m3h34gspRDToKYUz@mail.gmail.com>

On Mon, Mar 21, 2011 at 5:16 PM, Mark Hammond <mhammond at skippinet.com.au> wrote:
> On 21/03/2011 1:04 PM, "Martin v. L?wis" wrote:
>>
>> Can you please add a summary of this discussion to
>> the PEP? (also, can you please check in the PEP, and
>
>> give it a number?)
>
> OK, I'll check it in once I get a PEP number allocated as per PEP1, updated
> to reflect some of the discussions in this thread.

We should really update PEP 1 at some point to say that people with
commit rights are allowed to just grab the next number in the sequence
(the source repository effectively prevents conflicts if two people
happen to start PEPs at the same time). I've asked the PEP editors
about that in the past, and they were fine with the practice.

> Should I also check the reference implementation in? ?Maybe next to the PEP
> text as "pep-NNNN-reference.py"?

Generally the PEP directory is just for the PEPs themselves. Attaching
scripts to tracker items is a fairly common way of publishing
reference implementations, as is sticking them in an alternate repo
somewhere.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From stefan_ml at behnel.de  Mon Mar 21 11:58:50 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 21 Mar 2011 11:58:50 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>
	<im4sb2$lg1$1@dough.gmane.org>	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>	<im5028$7h7$1@dough.gmane.org>	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>	<im5pr1$7da$1@dough.gmane.org>
	<AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>
Message-ID: <im7b1a$14l$1@dough.gmane.org>

[long post ahead, again]

Guido van Rossum, 21.03.2011 03:46:
> Thanks for the clarifications. I now have a much better understanding
> of what Cython is. But I'm not sold. For one, your attitude about
> strict language compatibility worries me when it comes to the stdlib.

Not sure what you mean exactly. Given our large user base, we do worry a 
lot about things like backwards compatibility, for example.

If you are referring to compatibility with Python, I don't think anyone in 
the project really targets Cython as a a drop-in replacement for a Python 
runtime. We aim to compile Python code, yes, and there's a hand-wavy idea 
in the back of our head that we may want a plain Python compatibility mode 
at some point that will disable several important optimisations. But 
there's no real drive for that, simply because Cython users usually care a 
lot more about speed than about strict Python language compliance in 
dangerous areas like overridden builtins (such as 'range'). And Cython 
users know that they also have CPython available, which allows them to 
easily get 100% compatibility if they need it, be it through an import or 
by calling "exec".

That being said, we do consider any deviation from Python language 
semantics a bug, and try to fix at least those with a user impact. 
Compatibility has improved a lot since the early days.


> Also, I don't know how big it is

It's not small. The compiler is getting close to some 50,000 lines of 
python code.


> but it seems putting the cart before
> the horse to use it to optimize the stdlib. Cython feels much less
> mature than CPython;

It certainly is not completely stable, neither the language nor the 
compiler, but it has been used for production code ever since the project 
started (from Pyrex' original inheritance).

There are parts of the language that we still fledge out, but we try hard 
to keep the user impact low and to adhere to the "expected" Python 
semantics as closely as possible whenever we design new language features. 
Much of what we need to fix these days is actually due to different 
language semantics that originally appeared in Pyrex, or to differences 
between Python 2 and Python 3 that make it tricky for users to write 
portable code.


> but the latter should only have dependencies that
> themselves change even slower than CPython.

I understand that. C is certainly evolving a *lot* slower than Cython.

Personally, I wouldn't consider Cython a dependency even if CPython started 
using code written in Cython. It's more like a development tool, as users 
won't have to care if the generated C sources ship with the distribution. 
Only those who want to build from hg sources and distributors that patch 
impacted release sources will have to take care to install the 
corresponding Cython version. Shipping tested C sources is certainly the 
recommended way of using Cython.


> I also am unclear on how
> exactly you're supporting the different semantics in Python 2 vs. 3
> without recompiling.

We try to make it easy for users to write portable code by keeping the code 
semantics fixed as much as possible once it's compiled. However, there are 
things that we don't currently fix. For example, we only try to keep 
builtins compatible as far as we consider reasonable. If you write

    x = range(5)

in your Cython code, you will get a list in Py2 and an iterator in Py3. If 
you write "xrange(5)", however, you will get an xrange object in Py2 and a 
range object in Py3. Same for "unicode" etc. We also don't change the API 
of the bytes type (returning integers on indexing in Python 3), even though 
it represents a major portability hassle for our users and also prevents 
several optimisations (and language features) that Cython could otherwise 
provide.

String semantics are actually quite complex inside of the Cython compiler 
(as the cross-Python/C/C++ type system in general) and were subject to 
major design/usability discussions in the past. We basically have three 
Python string types: bytes (Py2/3 bytes), unicode (Py2 unicode, Py3 str) 
and str (Py2/3 str), as well as C types like char/char* or Py_UCS4. The 
'str' type is needed because parts of CPython, its stdlib and external 
libraries actually require bytes in Python 2 (and it's sort-of the "native" 
string type for ASCII text there), but require unicode text in Python 3. To 
write portable code, you can use unprefixed string constants in Cython 
code, which will become the respective 'str' type in each of the runtime 
environments. That's an impressively well appreciated feature for our 
users, and obviously modelled after 2to3.

However, since the API of 'str' isn't portable, you will only get a 
performance boost when you use the unicode (and, for portable operations, 
bytes) type, especially for looping, 'in' tests, etc. That will basically 
allow Cython to 'unbox' the strings into a C array, with the obvious 
optimisations like unboxed Unicode characters etc. As I said, quite a 
complex type system.

Cython is actually a pretty cool tool for text processing these days. For 
example, this

     for c in some_typed_unicode_string:
         if c == u'X': ...
         elif c in u' \t\r\n': ...
         elif c in u'AB12UV': ...
         else: ...

will turn into a C pointer loop around a C switch statement. And I heard of 
some fast bindings to C/C++ regex libs etc. that are getting written. 
Shipping those with a PyCapsule based C-API (Cython can generate and import 
those) and buffer interface support would provide a really speedy way to 
use them from other Cython modules, without sacrificing the Python language 
feeling.


> OTOH I think you've got the perfect audience in the scientific Python
> world.

Partly, but joined with the majority of FFI and "speeding up CPython code" 
users. The scientific Python world is (obviously) very focussed on numeric 
computation. Cython is much more versatile than that.


> Have you tried replacing selected stdlib modules with their
> Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g.
> what about Enthought's Python distros?) Depending on how well that
> goes I might warm up to Cython more!

Hmm, I hadn't heard about that before. I'll ask on our mailing list if 
anyone's aware of them. I doubt that the stdlib participates in the 
critical parts of scientific computation code. Maybe alternative CSV 
parsers or something like that, but I'd be surprised if they were 
compatible with what's in the stdlib.

Stefan


From orsenthil at gmail.com  Mon Mar 21 12:02:51 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Mon, 21 Mar 2011 19:02:51 +0800
Subject: [Python-Dev] cpython (3.2): Issue 7391: Remove questionable and
 outdated HOWTO document with permission
In-Reply-To: <im2r9u$ioa$2@dough.gmane.org>
References: <E1Q0ksM-0002Ip-9U@dinsdale.python.org>
	<20110319135702.30df216b@pitrou.net>
	<20110319153055.88AAA13F988@kimball.webabinitio.net>
	<im2r9u$ioa$2@dough.gmane.org>
Message-ID: <20110321110251.GA2496@kevin>

This push caught me by surprise too. So, +1 on having a content of
similar effect.

On Sat, Mar 19, 2011 at 07:05:59PM +0100, Georg Brandl wrote:
> +1.  (Also I don't understand why we'd need permission from an author to
> *remove* content.)

And hypothetically, if the author refuses what do we do? :)

-- 
Senthil

From nad at acm.org  Mon Mar 21 12:06:56 2011
From: nad at acm.org (Ned Deily)
Date: Mon, 21 Mar 2011 04:06:56 -0700
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<AANLkTiktF+E2VsbP-exEJRQDUYXw18zFfOM27mgvRAGL@mail.gmail.com>
	<20110317133050.AE51624CB5D@kimball.webabinitio.net>
	<4D86BCAD.4070406@netwok.org> <4D871440.2000200@timgolden.me.uk>
Message-ID: <nad-515DDD.04065621032011@news.gmane.org>

In article <4D871440.2000200 at timgolden.me.uk>,
 Tim Golden <mail at timgolden.me.uk> wrote:
> A further tip in case it helps anyone: hg import (and its mq
> counterpart hg qimport) can patch directly from a URL. This
> is handy when I want to try out someone's patch directly from
> the issue page on bugs.python.org. [Maybe everyone else knew
> this, but I found it out by accident!]

Using a URL can be useful but be aware that for hg import, just as with 
the patch utility, you need to know what if any strip value to use, that 
is, the -p parameter.  So you generally need to examine the patch file 
first.

hg qimport currently does not provide a way to specify the strip count; 
it requires the patch to have been generated with a strip count of 1.
     http://mercurial.selenic.com/bts/issue311 

hg import defaults to 1 but can be changed with -p.

Svn-generated diffs/patches generally need a strip count of 0.

-- 
 Ned Deily,
 nad at acm.org


From john at arbash-meinel.com  Mon Mar 21 12:14:34 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Mon, 21 Mar 2011 12:14:34 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <4D871DE1.6020307@v.loewis.de>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D871DE1.6020307@v.loewis.de>
Message-ID: <4D87331A.4000306@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/21/2011 10:44 AM, "Martin v. L?wis" wrote:
>> My understanding is that svn does not detect fast forwards, only lack
>> of conflicts, and therefore in case of concurrent development it is
>> possible that the repository contains a version that never existed in
>> any developer's workspace.  
> 
> I can't understand how you draw this conclusion ("therefore").
> 
> If you do an svn up, it merges local changes with remote changes;
> if that works without conflicts, it tells you what files it merged,
> but lets you commit.
> 
> Still, in this case, the merge result did exist in the sandbox
> of the developer performing the merge. Subversion never ever creates
> versions in the repository that didn't before exist in some working
> copy. The notion that it may have done a server-side merge or some
> such is absurd.

It does so at the *tree* level, not at an individual file level.

1) svn doesn't require you to run 'svn up' unless there is a direct
change to the file you are committing. So there is plenty of opportunity
to have cross-file failures.

 The standard example is I change foo.py's foo() function to add a new
 mandatory parameter. I 'svn up' and run the test suite, updating all
 callers to supply that parameter. You update bar.py to call foo.foo()
 not realizing I'm updating it. You 'svn up' and run the test suite.
 Both my test suite and your test suite were perfect. So we both 'svn
 commit'.
 There is now a race condition. Both of our commits will succeed.
 (revisions 10 and 11 lets say). Revision 11 is now broken (will fail
 to pass the test suite.)

2) svn's default lack of tree-wide synchronization means that no matter
   how diligent we are, there is a race condition. (As I'm pretty sure
   both 'svn commit' can run concurrently since they don't officially
   modify the same file.)

3) IIRC, there is a way to tell "svn commit", "this is my base revno,
   if the server is newer, abort the commit". It is used by bzr-svn to
   ensure we always commit tree-wide state safely. However, I don't
   think svn itself makes much use of it, or makes it easy to use.



Blindly merging in trunk / rebasing your changes has the same hole.
Though you at least can be aware that it is there, rather than the
system hiding the fact that you were out of date.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2HMxoACgkQJdeBCYSNAAMaewCfW3DK8hW4hBKOA+5zbyaxyptH
MMQAoKGw2uWUWafBK2+Jl5A6XMK+0z9f
=5R0+
-----END PGP SIGNATURE-----

From skip at pobox.com  Mon Mar 21 12:14:30 2011
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 21 Mar 2011 06:14:30 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <19847.13078.526390.539879@montanaro.dyndns.org>

    Stephen> It would be possible for the svn-based workflow to require that
    Stephen> after testing in one's workspace, one does an svn update, and
    Stephen> if any changes are made to files in the workspace, the whole
    Stephen> build and test procedure must be repeated.  I don't see that
    Stephen> that has advantages over the hg workflow, though -- it should
    Stephen> cause an addition build-test cycle in exactly the same revision
    Stephen> sequences that the hg workflow does.

It, however requires every developer to become facile, if not expert, with
the ins and outs of the Python/Mercurial workflow.  This discourages casual
or intermittent contributions.  My main contribution to the Python codebase
over the past couple years has been to intercept trivial "bug reports" sent
to the webmaster address calling out typos in the documentation or the
website.  Handling such reports was trivial with Subversion.  Update, edit,
check in.  That is no longer the case with Mercurial.  (And for the website
will no longer be the case in the fairly near future if I understand
correctly.)

I believe it runs counter to the professed intention of the switch away from
a centralized version control system, to make it easier for more people to
contribute to Python.  It certainly seems harder for this old dog.

Skip


From ncoghlan at gmail.com  Mon Mar 21 12:14:49 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 Mar 2011 21:14:49 +1000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <4D871DE1.6020307@v.loewis.de>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D871DE1.6020307@v.loewis.de>
Message-ID: <AANLkTimcu-cu8en8munSk51uNFw_Tz-DORRakQYdToqF@mail.gmail.com>

On Mon, Mar 21, 2011 at 7:44 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> If you do an svn up, it merges local changes with remote changes;
> if that works without conflicts, it tells you what files it merged,
> but lets you commit.
>
> Still, in this case, the merge result did exist in the sandbox
> of the developer performing the merge. Subversion never ever creates
> versions in the repository that didn't before exist in some working
> copy. The notion that it may have done a server-side merge or some
> such is absurd.

If you do an svn commit, and there are no files in conflict (or that
require merging), svn will let the commit go through. It doesn't care
if someone else may have updated *other* files in the meantime, so
long as none of the files in the current commit were touched. Thus, if
you don't do an svn up immediately before committing, you may get an
implicit merge of orthogonal changesets on the server. svn will only
complain if the changesets aren't orthogonal (i.e. "file x.y is not up
to date"). This may break the buildbots if, for example, one commit
changed an internal API in a backwards incompatible way, while the
latter commit used that API (or vice-versa).

hg broadens the check and complains if *any* files are not up to date
on any of the branches being pushed, thus making it a requirement to
do a hg pull and merge on all affected branches before the hg push can
succeed. In theory, this provides an opportunity for the developer
doing the merge to double check that it didn't break anything, in
practice (at least in the near term) we're more likely to see an
SVN-like practice of pushing the merged changes without rerunning the
full test suite.

Just accepting that, and filtering python-checkins to make it easier
to skip over merge commits seems to cover the important points here,
though.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Mon Mar 21 12:19:37 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 Mar 2011 21:19:37 +1000
Subject: [Python-Dev] [GSoC] Porting on RPM3
In-Reply-To: <4D871F68.4000608@v.loewis.de>
References: <AANLkTik0C8JdwCafpgeoq10_nm7J4yRBqR-LSSqniwOO@mail.gmail.com>
	<4D871F68.4000608@v.loewis.de>
Message-ID: <AANLkTimPdV_A3tixGS_z74T5rSe9S7D1WG1136DNf=zm@mail.gmail.com>

On Mon, Mar 21, 2011 at 7:50 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 21.03.2011 07:37, schrieb Prashant Kumar:
>> Hello,
>> ? ? My name is ?Prashant Kumar and I've worked on porting few python
>> libraries(distutils2, configobj) and I've been looking at the ideas
>> list for GSoC for a project related to porting.
>>
>> ? ? I came across [1] ?and found it interesting. It mentions that some
>> of the work has already been done; I would like to look at the code
>> repository for the same, could someone provide me the link for the
>> same?
>
> Not so much the code but the person who did the porting. This was Dave
> Malcolm (CC'ed); please get in touch with him. Please familiarize
> yourself with the existing Python bindings (in the latest RPM 4 release
> from rpm.org). You'll notice that this already has Python 3 support;
> not sure whether that's the most recent code, though.

Also, if you're interested in any other work on porting (possibly even
in the context of GSoC if you can find a mentor), I believe the
majority of folks working on that kind of thing are now coordinating
their efforts on the python-porting [1] mailing list.

Cheers,
Nick.

[1] http://mail.python.org/mailman/listinfo/python-porting

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Mon Mar 21 12:29:25 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 Mar 2011 21:29:25 +1000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <19847.13078.526390.539879@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
Message-ID: <AANLkTimTEPGFMW2CQC+ER12vxJ2oAdoPaGivShKZYaWD@mail.gmail.com>

On Mon, Mar 21, 2011 at 9:14 PM,  <skip at pobox.com> wrote:
> I believe it runs counter to the professed intention of the switch away from
> a centralized version control system, to make it easier for more people to
> contribute to Python. ?It certainly seems harder for this old dog.

I agree it's harder *now*, but I don't think it will stay that way. As
best practices like installing the whitespace hook client-side evolve
and are codified then the devguide can become a lot more prescriptive
for new (and current) users.

Remember, we knew from the beginning that core devs were going to see
the least benefit from the switch, and were at the most risk of having
to relearn things. The principle benefit of a DVCS (i.e. making it
far, far easier to keep a clone repository up to date so that
externally maintained patches are less likely to go stale) doesn't
really apply to us (although we can certainly take advantage of it if
we choose to - I did that myself when creating my own sandbox
repository).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From mal at egenix.com  Mon Mar 21 13:20:59 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 21 Mar 2011 13:20:59 +0100
Subject: [Python-Dev] Copyright notices
In-Reply-To: <AANLkTimEqTPhSBhfRXWJa5cpitFLms_XqrYaebTtpann@mail.gmail.com>
References: <AANLkTimEqTPhSBhfRXWJa5cpitFLms_XqrYaebTtpann@mail.gmail.com>
Message-ID: <4D8742AB.3050701@egenix.com>

Nadeem Vawda wrote:
> I was wondering what the policy is regarding copyright notices and license
> boilerplate text at the top of source files.
> 
> I am currently rewriting the bz2 module (see http://bugs.python.org/issue5863),
> splitting the existing Modules/bz2module.c into Modules/_bz2module.c and
> Lib/bz2.py.
> 
> Are new files expected to include a copyright notice and/or license boilerplate
> text? 

Since you'll be adding new IP to Python, the new code you write should
contain your copyright and the standard PSF contributor agreement
notice, e.g.

"""
(c) Copyright 2011 by Nadeem Vawda. Licensed to PSF under a Contributor Agreement.
"""

(please also make sure you have sent the signed agreement to the PSF;
see http://www.python.org/psf/contrib/)

We don't have a general copyright or license boiler plate for Python
source files.

> Also, is it necessary for _bz2module.c (new) to retain the copyright
> notices from bz2module.c (old)? In the tracker issue, Antoine said he didn't
> think so, but suggested that I get some additional opinions.

If the file copies significant code parts from older files, the
copyright notices from those files will have to added to the
file comment as well - ideally with a note explaining to which parts
those copyrights apply and where they originated.

If you are replacing the old implementation with a new one,
you don't need to copy over the old copyright statements.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 21 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From stephen at xemacs.org  Mon Mar 21 13:34:39 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 21 Mar 2011 21:34:39 +0900
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <4D871DE1.6020307@v.loewis.de>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D871DE1.6020307@v.loewis.de>
Message-ID: <87zkoozm74.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. L?wis" writes:
 > > My understanding is that svn does not detect fast forwards, only lack
 > > of conflicts, and therefore in case of concurrent development it is
 > > possible that the repository contains a version that never existed in
 > > any developer's workspace.
 > 
 > I can't understand how you draw this conclusion ("therefore").

A fast forward is a case where some ancestor of the workspace is the
tip of the repository.  When the tip is not an ancestor, it must
contain changes not yet in the workspace.  If a VCS does not check for
fast-forward, then if those changes are in files not changed in the
workspace, there will be no conflict, and in theory there could indeed
be a silent server-side merge.  QED, "therefore".

This seems especially plausible for VCSes that allow only a subset of
files to be committed/pushed.

 > Subversion never ever creates versions in the repository that
 > didn't before exist in some working copy.

John Arbash-Meinel disagrees with you, so I think I'll go with his
opinion absent a really convincing argument otherwise.  No disrespect
to you intended, but John is an expert I've known for years.

 > The notion that it may have done a server-side merge or some
 > such is absurd.

False, quite possibly; I'm not an expert on Subversion internals.
Absurd, definitely not.  CVS does it (and much worse, but it certainly
does this too).

 > You make it sound as if you have never used subversion.

These days, it's awful hard to avoid using Subversion.  However, I
have no experience with committing in Python, and I don't have that
much experience that I can claim to be authoritative, nor have I
managed a multiuser Subversion repository.


From solipsis at pitrou.net  Mon Mar 21 13:38:32 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 13:38:32 +0100
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
References: <4D86C16F.8080403@v.loewis.de>
Message-ID: <20110321133832.60154cda@pitrou.net>

On Mon, 21 Mar 2011 04:09:35 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
> one outputting int; the other one outputting Py_ssize_t.
> 
> The former should have been removed in 3.0, but this was forgotten.
> 
> Still, I would like people to move over to the new version, so
> that extension modules will typically support 64-bit collections
> well. Therefore, I'd like to propose that the int version is deprecated
> in 3.3.

+1 !

> Given the recent discussion about backwards compatibility: what's
> the best approach? What warning should be emitted, if any?
> (the warning would only be generated if an s# or similar format
>  was actually encountered - not just if merely PyArg_ParseTuple is
>  called).

I'd say a DeprecationWarning. They are quiet by default anyway...

Regards

Antoine.



From p.f.moore at gmail.com  Mon Mar 21 14:04:07 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 21 Mar 2011 13:04:07 +0000
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <4D86AFB8.4040006@skippinet.com.au>
References: <4D8446E0.7030401@skippinet.com.au> <4D84FAB8.3040301@v.loewis.de>
	<4D856DCB.5000600@skippinet.com.au> <4D85CACA.1070400@v.loewis.de>
	<4D85D637.3040403@skippinet.com.au>
	<4D866EAC.8050701@skippinet.com.au>
	<4D86913E.7010407@canterbury.ac.nz> <4D8698AC.2070908@v.loewis.de>
	<4D86A539.1050004@skippinet.com.au> <4D86A99E.9060908@v.loewis.de>
	<4D86AFB8.4040006@skippinet.com.au>
Message-ID: <AANLkTim_N=45eBUcnw0T59=gDr05HyxTEF6npuHhsyn0@mail.gmail.com>

On 21 March 2011 01:54, Mark Hammond <mhammond at skippinet.com.au> wrote:
> ie, let's say we are forced to choose between the following 3 options:
>
> * No launcher at all (the status-quo), causing demonstrable breakage in
> Windows file associations whenever Python 2.x and Python 3.x scripts exist
> on the same box.
>
> * An in-process launcher which caused breakage in a number of reasonably
> common scenarios for Python programmers, and such breakage could easily be
> demonstrated.
>
> * An out-of-process launcher which caused breakage for the hypothetical
> program mentioned above, of which no instance can be found and no breakage
> actually demonstrated.
>
> I personally would conclude that the last option is the least worst scenario
> by a wide margin.

I haven't had time to read the PEP yet, so my apologies if this is
made explicit there, but is the launcher expected to be solely for
implementing file associations? I thought there had been discussions
of using it to start the interactive interpreter, and for it having
command line arguments (implying direct command line usage). If it can
be used directly, there are many other scenarios that might be
impacted. Consider a service implemented using SRVANY which uses the
launcher. Stopping the service kills the launcher, leaving Python (and
the script, ie the service) running...

Paul.

From rdmurray at bitdance.com  Mon Mar 21 14:40:15 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 21 Mar 2011 09:40:15 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20110321134015.B8ED364DAA@kimball.webabinitio.net>

On Mon, 21 Mar 2011 18:33:00 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> R. David Murray writes:
>  > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>  > > No, at best the DVCS workflow forces the developer on a branch to
>  > > merge and test the revisions that will actually be added to the
>  > > repository, and perhaps notice system-level anomolies before pushing.
>  > 
>  > hg does not force the developer to test, it only forces the merge.
> 
> I didn't say any VCS forces the test; I said that the workflow can (in
> the best case).  That's also inaccurate, of course.  I should have
> said "require", not "force".

The workflow in svn "can" "require" this same thing:  before committing,
you do an svn up and run the test suite.

The hg workflow "can" "not require" this as well:  before committing,
do an hg pull -u, merge heads, and *don't* run the test suite.

HG the tool does *NOT* change this aspect of things.  If this change
is to be made (tip should always be a repository state over which the
full regrtest suite has been run), then that is a *cultural* change that
we would need to make.  And could have made with svn.

We didn't.  We probably won't with hg.  Because the test suite takes
to long to run and the buildbots will do it anyway.

It's a discussion we could have, but as far as I can see it is completely
independent of the choice of tool.

Your point seems to boil down to the fact that many developers may
not have thought about the fact that committing to svn without an svn up
could mean they hadn't run regrtest over the *current* state of the repo.
This may be true, I don't know.  I did think about it.  When we moved
to hg, I did not re-think about it; nothing about the hg workflow
change forced me to re-think about it.  I did not change my habits,
and that includes not re-running the test suite after a merge heads,
unless there's a conflict (just like svn).

That is, not only did the change in the tool and consequent change in
the workflow have *zero* impact on this aspect of the way I work with
CPython, it didn't even trigger me to *think* about it.

--
R. David Murray           http://www.bitdance.com

From eric at trueblade.com  Mon Mar 21 15:02:37 2011
From: eric at trueblade.com (Eric Smith)
Date: Mon, 21 Mar 2011 10:02:37 -0400 (EDT)
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
In-Reply-To: <20110321133832.60154cda@pitrou.net>
References: <4D86C16F.8080403@v.loewis.de> <20110321133832.60154cda@pitrou.net>
Message-ID: <263da19a93c59499891007112283d00d.squirrel@mail.trueblade.com>

> On Mon, 21 Mar 2011 04:09:35 +0100
> "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
>> one outputting int; the other one outputting Py_ssize_t.
>>
>> The former should have been removed in 3.0, but this was forgotten.
>>
>> Still, I would like people to move over to the new version, so
>> that extension modules will typically support 64-bit collections
>> well. Therefore, I'd like to propose that the int version is deprecated
>> in 3.3.
>
> +1 !

Agreed.

>> Given the recent discussion about backwards compatibility: what's
>> the best approach? What warning should be emitted, if any?
>> (the warning would only be generated if an s# or similar format
>>  was actually encountered - not just if merely PyArg_ParseTuple is
>>  called).
>
> I'd say a DeprecationWarning. They are quiet by default anyway...

Why not a PendingDeprecationWarning?

Eric.


From solipsis at pitrou.net  Mon Mar 21 15:12:53 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 15:12:53 +0100
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
References: <4D86C16F.8080403@v.loewis.de> <20110321133832.60154cda@pitrou.net>
	<263da19a93c59499891007112283d00d.squirrel@mail.trueblade.com>
Message-ID: <20110321151253.30d3f49c@pitrou.net>

> 
> >> Given the recent discussion about backwards compatibility: what's
> >> the best approach? What warning should be emitted, if any?
> >> (the warning would only be generated if an s# or similar format
> >>  was actually encountered - not just if merely PyArg_ParseTuple is
> >>  called).
> >
> > I'd say a DeprecationWarning. They are quiet by default anyway...
> 
> Why not a PendingDeprecationWarning?

Is there still a difference?



From victor.stinner at haypocalc.com  Mon Mar 21 15:21:13 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Mon, 21 Mar 2011 15:21:13 +0100
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
In-Reply-To: <4D86C16F.8080403@v.loewis.de>
References: <4D86C16F.8080403@v.loewis.de>
Message-ID: <1300717273.24680.1.camel@marge>

Le lundi 21 mars 2011 ? 04:09 +0100, "Martin v. L?wis" a ?crit :
> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
> one outputting int; the other one outputting Py_ssize_t.
> 
> The former should have been removed in 3.0, but this was forgotten.
> 
> Still, I would like people to move over to the new version, so
> that extension modules will typically support 64-bit collections
> well. Therefore, I'd like to propose that the int version is deprecated
> in 3.3.

By the way, what is the status of migration to Py_ssize_t of CPython
extensions? I suppose that adding a warning will quickly give an answer.

Victor


From stefan_ml at behnel.de  Mon Mar 21 15:35:01 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 21 Mar 2011 15:35:01 +0100
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
In-Reply-To: <1300717273.24680.1.camel@marge>
References: <4D86C16F.8080403@v.loewis.de> <1300717273.24680.1.camel@marge>
Message-ID: <im7nmm$css$1@dough.gmane.org>

Victor Stinner, 21.03.2011 15:21:
> Le lundi 21 mars 2011 ? 04:09 +0100, "Martin v. L?wis" a ?crit :
>> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
>> one outputting int; the other one outputting Py_ssize_t.
>>
>> The former should have been removed in 3.0, but this was forgotten.
>>
>> Still, I would like people to move over to the new version, so
>> that extension modules will typically support 64-bit collections
>> well. Therefore, I'd like to propose that the int version is deprecated
>> in 3.3.
>
> By the way, what is the status of migration to Py_ssize_t of CPython
> extensions? I suppose that adding a warning will quickly give an answer.

You'll get a series of very visible warnings from the C compiler when 
compiling a non-Py_ssize_t extension on a 64bit platform, which is a rather 
common platform type these days. So I'd doubt that there are any 
still-in-use extensions left that have not migrated.

Stefan


From solipsis at pitrou.net  Mon Mar 21 15:48:40 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 15:48:40 +0100
Subject: [Python-Dev] Copyright notices
References: <AANLkTimEqTPhSBhfRXWJa5cpitFLms_XqrYaebTtpann@mail.gmail.com>
	<4D8742AB.3050701@egenix.com>
Message-ID: <20110321154840.276000c6@pitrou.net>

On Mon, 21 Mar 2011 13:20:59 +0100
"M.-A. Lemburg" <mal at egenix.com> wrote:
> Nadeem Vawda wrote:
> > I was wondering what the policy is regarding copyright notices and license
> > boilerplate text at the top of source files.
> > 
> > I am currently rewriting the bz2 module (see http://bugs.python.org/issue5863),
> > splitting the existing Modules/bz2module.c into Modules/_bz2module.c and
> > Lib/bz2.py.
> > 
> > Are new files expected to include a copyright notice and/or license boilerplate
> > text? 
> 
> Since you'll be adding new IP to Python, the new code you write should
> contain your copyright and the standard PSF contributor agreement
> notice, e.g.

I agree with Raymond's argument that we shouldn't add *new* copyright
boilerplate:
http://mail.python.org/pipermail/python-dev/2009-January/085267.html

(the original question was about whether to keep the old one)

Authorship (and therefore "IP") is much better documented by version
control than by static chunks of text. These often become hopelessly
outdated, and therefore give wrong information about who actually
authored the code.

Regards

Antoine.



From stephen at xemacs.org  Mon Mar 21 15:55:32 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 21 Mar 2011 23:55:32 +0900
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <19847.13078.526390.539879@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
Message-ID: <87y648zfob.fsf@uwakimon.sk.tsukuba.ac.jp>

skip at pobox.com writes:

 > I believe it runs counter to the professed intention of the switch
 > away from a centralized version control system, to make it easier
 > for more people to contribute to Python.  It certainly seems harder
 > for this old dog.

Well, you may be an old dog, but you're also an early adopter.  That
means both that you get to pay for our mistakes (our = authors of PEPs
374 and 385), and that it's going to take a while to disentangle
implementation issues from the real long-run costs and benefits.

Costs of transition were admitted up front.  The professed intention
was to make things *harder* in the short run (but as little as
possible!), while making contribution to Python significantly more
attractive (but not necessarily less work!) in the long run.  I don't
think anybody tried to hide the fact that changing habits would be
required, or to claim that it would be costless.  There were a few
people with a Pollyanna "try it, you'll like it" attitude, but
certainly those of us involved in PEP 374 knew better than that -- we
knew there were people like you whose patterns of contribution worked
just fine with the svn-based workflow and didn't need or want to
change.  That's why PEP 374 was necessary!

Yes, based on the description you give of your principal contribution
pattern, you take a complexity/effort hit in the transition.  I think
it can be alleviated quite a bit with the help of your reports, but
that will take some time.  All I can say about that time is "Sorry!"
and "Thank you for trying the system while it's still in beta."

I hope you will give it some more time to shake down.

From hrvoje.niksic at avl.com  Mon Mar 21 15:56:17 2011
From: hrvoje.niksic at avl.com (Hrvoje Niksic)
Date: Mon, 21 Mar 2011 15:56:17 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <87zkoozm74.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>
	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D871DE1.6020307@v.loewis.de>
	<87zkoozm74.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D876711.1060707@avl.com>

On 03/21/2011 01:34 PM, Stephen J. Turnbull wrote:
>   >  Subversion never ever creates versions in the repository that
>   >  didn't before exist in some working copy.
>
> John Arbash-Meinel disagrees with you, so I think I'll go with his
> opinion

Besides, it's easy to confirm:

# create a repository and two checkouts:
[~/work]$ svnadmin create repo
[~/work]$ svn co file:///home/hniksic/work/repo checkout1
Checked out revision 0.
[~/work]$ svn co file:///home/hniksic/work/repo checkout2
Checked out revision 0.

# add a file to checkout 1
[~/work]$ cd checkout1
[~/work/checkout1]$ touch a && svn add a && svn commit -m c1
A         a
Adding         a
Transmitting file data .
Committed revision 1.

# now add a file to the second checkout without ever seeing
# the new file added to the first one
[~/work/checkout1]$ cd ../checkout2
[~/work/checkout2]$ touch b && svn add b && svn commit -m c2
A         b
Adding         b
Transmitting file data .
Committed revision 2.

The second commit would be rejected by a DVCS on the grounds of a merge 
with revision "1" never having happened.  What svn calls revision two is 
in reality based on revision 0, a fact the DVCS is aware of.

The message "committed revision 2", while technically accurate, is 
misleading if you believe the revision numbers to apply to the entire 
tree (as the svn manual will happily point out).  It doesn't indicate 
that what you have in your tree when the message is displayed can be 
very different from the state of a freshly-checked-out revision 2.  In 
this case, it's missing the file "a":

[~/work/checkout2]$ ls
b

This automatic merging often causes people who migrate to a DVCS to feel 
that they have to go through an unnecessary extra step in their 
workflows.  But once you grasp the "hole" in the svn workflow, what svn 
does (and what one used to take for granted) tends to become 
unacceptable, to put it mildly.

Hrvoje

From adrian at cadifra.com  Mon Mar 21 15:59:51 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Mon, 21 Mar 2011 15:59:51 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <20110321134015.B8ED364DAA@kimball.webabinitio.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>
	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
Message-ID: <4D8767E7.8020702@cadifra.com>

On 2011-03-21 14:40, R. David Murray wrote:
> On Mon, 21 Mar 2011 18:33:00 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>> R. David Murray writes:
>>  > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>>  > > No, at best the DVCS workflow forces the developer on a branch to
>>  > > merge and test the revisions that will actually be added to the
>>  > > repository, and perhaps notice system-level anomolies before pushing.
>>  > 
>>  > hg does not force the developer to test, it only forces the merge.
>>
>> I didn't say any VCS forces the test; I said that the workflow can (in
>> the best case).  That's also inaccurate, of course.  I should have
>> said "require", not "force".
> 
> The workflow in svn "can" "require" this same thing:  before committing,
> you do an svn up and run the test suite.

But with svn you have to redo the test after the commit *if* someone
else committed just before you in the mean time, thereby changing the
preconditions "behind your back", thus creating a different state of the
tree compared to the state in which it was at the time you ran your test.

With a DVCS, you can't push in that situation. At least not without
creating a new head (which would require --force in Mercurial).

From eric at trueblade.com  Mon Mar 21 16:24:24 2011
From: eric at trueblade.com (Eric Smith)
Date: Mon, 21 Mar 2011 11:24:24 -0400 (EDT)
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
In-Reply-To: <20110321151253.30d3f49c@pitrou.net>
References: <4D86C16F.8080403@v.loewis.de> <20110321133832.60154cda@pitrou.net>
	<263da19a93c59499891007112283d00d.squirrel@mail.trueblade.com>
	<20110321151253.30d3f49c@pitrou.net>
Message-ID: <816f28542cb584e8f3acec4ab619d568.squirrel@mail.trueblade.com>

>>
>> >> Given the recent discussion about backwards compatibility: what's
>> >> the best approach? What warning should be emitted, if any?
>> >> (the warning would only be generated if an s# or similar format
>> >>  was actually encountered - not just if merely PyArg_ParseTuple is
>> >>  called).
>> >
>> > I'd say a DeprecationWarning. They are quiet by default anyway...
>>
>> Why not a PendingDeprecationWarning?
>
> Is there still a difference?

Only that it takes one extra release to go from
pending->deprecated->removed, as opposed to deprecated->removed.

Eric.


From barry at python.org  Mon Mar 21 16:25:31 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 11:25:31 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <19847.13078.526390.539879@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
Message-ID: <20110321112531.0c98a191@limelight.wooz.org>

On Mar 21, 2011, at 06:14 AM, skip at pobox.com wrote:

>It, however requires every developer to become facile, if not expert, with
>the ins and outs of the Python/Mercurial workflow.  This discourages casual
>or intermittent contributions.  My main contribution to the Python codebase
>over the past couple years has been to intercept trivial "bug reports" sent
>to the webmaster address calling out typos in the documentation or the
>website.  Handling such reports was trivial with Subversion.  Update, edit,
>check in.  That is no longer the case with Mercurial.  (And for the website
>will no longer be the case in the fairly near future if I understand
>correctly.)
>
>I believe it runs counter to the professed intention of the switch away from
>a centralized version control system, to make it easier for more people to
>contribute to Python.  It certainly seems harder for this old dog.

Does Mercurial have a way of acting like a centralized vcs to the end user,
the way Bazaar does?  IOW, if Skip or others were more comfortable with a
centralized workflow (which is entirely valid imo), can they set up their
local workspace to enable that mode of operation?

If so, the devguide could describe that as a transitional step from the old
svn way of doing things.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/9f88cd1b/attachment.pgp>

From victor.stinner at haypocalc.com  Mon Mar 21 16:26:08 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Mon, 21 Mar 2011 16:26:08 +0100
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
In-Reply-To: <im7nmm$css$1@dough.gmane.org>
References: <4D86C16F.8080403@v.loewis.de> <1300717273.24680.1.camel@marge>
	<im7nmm$css$1@dough.gmane.org>
Message-ID: <1300721168.10044.2.camel@marge>

Le lundi 21 mars 2011 ? 15:35 +0100, Stefan Behnel a ?crit :
> Victor Stinner, 21.03.2011 15:21:
> > Le lundi 21 mars 2011 ? 04:09 +0100, "Martin v. L?wis" a ?crit :
> >> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
> >> one outputting int; the other one outputting Py_ssize_t.
> >>
> >> The former should have been removed in 3.0, but this was forgotten.
> >>
> >> Still, I would like people to move over to the new version, so
> >> that extension modules will typically support 64-bit collections
> >> well. Therefore, I'd like to propose that the int version is deprecated
> >> in 3.3.
> >
> > By the way, what is the status of migration to Py_ssize_t of CPython
> > extensions? I suppose that adding a warning will quickly give an answer.
> 
> You'll get a series of very visible warnings from the C compiler when 
> compiling a non-Py_ssize_t extension on a 64bit platform, which is a rather 
> common platform type these days. So I'd doubt that there are any 
> still-in-use extensions left that have not migrated.

Which instrution does emit a warning? If a module still use int, the
compiler was not emit any warning on call to PyArg_Parse*() because the
size arguments are passed as pointers in the magical "..." argument.

But when you switch to Py_ssize_t, you may get errors because Py_ssize_t
may be casted to a narrower type (like int).

Victor


From solipsis at pitrou.net  Mon Mar 21 16:38:58 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 16:38:58 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
	<20110321112531.0c98a191@limelight.wooz.org>
Message-ID: <20110321163858.54f97606@pitrou.net>

On Mon, 21 Mar 2011 11:25:31 -0400
Barry Warsaw <barry at python.org> wrote:
> 
> Does Mercurial have a way of acting like a centralized vcs to the end user,
> the way Bazaar does?  IOW, if Skip or others were more comfortable with a
> centralized workflow (which is entirely valid imo), can they set up their
> local workspace to enable that mode of operation?

I believe something like "hg pull -u && hg ci && hg push" would
emulate such behaviour: it would first put your working copy in sync
with remote, then let you commit, then push your new change.

We cannot emulate "svnmerge" for porting between branches, though - and
I doubt bzr can do it. That's because merges in common DVCSes are based
on the DAG, while svnmerge is a prettily ad-hoc free-form thing.

> If so, the devguide could describe that as a transitional step from the old
> svn way of doing things.

I think we should let things settle a few weeks before starting to
describe more workflows in the devguide.

Regards

Antoine.



From solipsis at pitrou.net  Mon Mar 21 16:39:59 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 16:39:59 +0100
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
References: <4D86C16F.8080403@v.loewis.de> <20110321133832.60154cda@pitrou.net>
	<263da19a93c59499891007112283d00d.squirrel@mail.trueblade.com>
	<20110321151253.30d3f49c@pitrou.net>
	<816f28542cb584e8f3acec4ab619d568.squirrel@mail.trueblade.com>
Message-ID: <20110321163959.701bfa78@pitrou.net>

On Mon, 21 Mar 2011 11:24:24 -0400 (EDT)
"Eric Smith" <eric at trueblade.com> wrote:
> >>
> >> >> Given the recent discussion about backwards compatibility: what's
> >> >> the best approach? What warning should be emitted, if any?
> >> >> (the warning would only be generated if an s# or similar format
> >> >>  was actually encountered - not just if merely PyArg_ParseTuple is
> >> >>  called).
> >> >
> >> > I'd say a DeprecationWarning. They are quiet by default anyway...
> >>
> >> Why not a PendingDeprecationWarning?
> >
> > Is there still a difference?
> 
> Only that it takes one extra release to go from
> pending->deprecated->removed, as opposed to deprecated->removed.

Well, some things have been issueing deprecation warnings for several
releases, I think. And given Guido's latest stance on the subject we
may see more of them in the future.

Regards

Antoine.



From barry at python.org  Mon Mar 21 17:07:43 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 12:07:43 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <20110321163858.54f97606@pitrou.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
	<20110321112531.0c98a191@limelight.wooz.org>
	<20110321163858.54f97606@pitrou.net>
Message-ID: <20110321120743.6e71919b@limelight.wooz.org>

On Mar 21, 2011, at 04:38 PM, Antoine Pitrou wrote:

>On Mon, 21 Mar 2011 11:25:31 -0400
>Barry Warsaw <barry at python.org> wrote:
>> 
>> Does Mercurial have a way of acting like a centralized vcs to the end user,
>> the way Bazaar does?  IOW, if Skip or others were more comfortable with a
>> centralized workflow (which is entirely valid imo), can they set up their
>> local workspace to enable that mode of operation?
>
>I believe something like "hg pull -u && hg ci && hg push" would
>emulate such behaviour: it would first put your working copy in sync
>with remote, then let you commit, then push your new change.

Actually, I meant something like 'bzr checkout':

http://doc.bazaar.canonical.com/bzr.2.3/en/user-reference/checkouts-help.html

This would allow individual developers to treat the repository in a
centralized way like they did for svn, but still allowing other developers to
work in a distributed way.

>We cannot emulate "svnmerge" for porting between branches, though - and
>I doubt bzr can do it. That's because merges in common DVCSes are based
>on the DAG, while svnmerge is a prettily ad-hoc free-form thing.

Sure.

>> If so, the devguide could describe that as a transitional step from the old
>> svn way of doing things.
>
>I think we should let things settle a few weeks before starting to
>describe more workflows in the devguide.

Okay.  I wonder if the merge dance will get easier now that the rush of
changes during Pycon settles down.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/c354347e/attachment.pgp>

From barry at python.org  Mon Mar 21 17:20:15 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 12:20:15 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <im5akg$ptc$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
Message-ID: <20110321122015.3add347b@limelight.wooz.org>

On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:

>On 20.03.2011 16:21, Guido van Rossum wrote:
>> What is "rebase"? Why does everyone want it and hate it at the same time?
>
>Basically, rebase is a way to avoid having pointless merge commits on the
>same branch.

There's something I don't understand about rebase.  It seems like most git and
hg users I hear from advocate rebase, while (ISTM) few Bazaar users do.

I'd like to understand whether that's a cultural thing or whether it's a
byproduct of some aspect of the respective tools.

It could be cultural in that communities using git and hg don't want those
local commits to ever show up in their shared repository, even though they are
mostly harmless.  In this graph:

>          A --- B ------------.
>         /                     \
>... --- X --- C --- D --- E --- M

A and B do exist, but I shouldn't care or notice them unless I explicitly
drill down.  The mainline still goes from X to C to D to E to M, and looking
at the differences between E and M should tell me all I need to know.
I.e. specifically, I can ignore A and B for most purposes.

It could be that some aspect of the tools causes A and B to not be hidden as
well as they should, so that when looking at the history for example, the fact
that A and B exist is a jarring or annoying artifact that would be better if
they didn't exist.

I'm asking because I don't know hg and git well enough to answer the
question.  In my own use of Bazaar over the last 4+ years, I've almost never
rebased or even been asked to.  Not that some Bazaar users don't use rebase,
but I just don't think it's that common (John can correct me if I'm wrong).

I'm not trolling, I really want to understand.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/7950dad8/attachment.pgp>

From stefan_ml at behnel.de  Mon Mar 21 17:38:00 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 21 Mar 2011 17:38:00 +0100
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
In-Reply-To: <1300721168.10044.2.camel@marge>
References: <4D86C16F.8080403@v.loewis.de>
	<1300717273.24680.1.camel@marge>	<im7nmm$css$1@dough.gmane.org>
	<1300721168.10044.2.camel@marge>
Message-ID: <im7ut9$svl$1@dough.gmane.org>

Victor Stinner, 21.03.2011 16:26:
> Le lundi 21 mars 2011 ? 15:35 +0100, Stefan Behnel a ?crit :
>> Victor Stinner, 21.03.2011 15:21:
>>> Le lundi 21 mars 2011 ? 04:09 +0100, "Martin v. L?wis" a ?crit :
>>>> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
>>>> one outputting int; the other one outputting Py_ssize_t.
>>>>
>>>> The former should have been removed in 3.0, but this was forgotten.
>>>>
>>>> Still, I would like people to move over to the new version, so
>>>> that extension modules will typically support 64-bit collections
>>>> well. Therefore, I'd like to propose that the int version is deprecated
>>>> in 3.3.
>>>
>>> By the way, what is the status of migration to Py_ssize_t of CPython
>>> extensions? I suppose that adding a warning will quickly give an answer.
>>
>> You'll get a series of very visible warnings from the C compiler when
>> compiling a non-Py_ssize_t extension on a 64bit platform, which is a rather
>> common platform type these days. So I'd doubt that there are any
>> still-in-use extensions left that have not migrated.
>
> Which instrution does emit a warning? If a module still use int, the
> compiler was not emit any warning on call to PyArg_Parse*() because the
> size arguments are passed as pointers in the magical "..." argument.

Ah, I thought you were talking about Py_ssize_t migration in general, not 
specific to the PyArg_Parse*() functions. I faintly remember seeing lots of 
Py_ssize_t related warnings in Pyrex code ages ago (I think my first Pyrex 
patches date back to the time when Py2.5 came out). They were at least 
obvious to me at the time.

But now that I think about it, I guess it's a lot easier to miss a place 
like PyArg_Parse*() when manually migrating code. The conversion of the 
type string is really not obvious and the C compiler can't provide any 
help. I dropped their usage in Cython years ago for performance reasons, 
but I think Pyrex still uses them, and they are extremely common in hand 
written C code as well as code generated by several wrapper generators, 
which tend to have their own ways of declaring input types. So it's 
actually hard to tell how well extensions are prepared here.

Stefan


From skip at pobox.com  Mon Mar 21 17:44:08 2011
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 21 Mar 2011 11:44:08 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <4D876711.1060707@avl.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D871DE1.6020307@v.loewis.de>
	<87zkoozm74.fsf@uwakimon.sk.tsukuba.ac.jp> <4D876711.1060707@avl.com>
Message-ID: <19847.32856.903323.462779@montanaro.dyndns.org>


Thanks for the example, Hrvoje.

    Hrvoje> This automatic merging often causes people who migrate to a DVCS
    Hrvoje> to feel that they have to go through an unnecessary extra step
    Hrvoje> in their workflows.  But once you grasp the "hole" in the svn
    Hrvoje> workflow, what svn does (and what one used to take for granted)
    Hrvoje> tends to become unacceptable, to put it mildly.

In the run-up to a release when there is lots of activity happening, do you
find yourself in a race with other developers to push your changes cleanly?
Suppose I am ready to check in some changes.  I pull, merge, update.  Run
the unit tests again.  That takes awhile.  Then I go to push only to find
someone else has already pushed a changeset.  I then have to lather, rinse,
repeat.  This might happen more than once, especially in the last few days
before an alpha (or the first beta) release.  Historically, most of the
churn in Python's code base occurs at that time.

I don't know how likely this would be to happen, though I can imagine if it
turns out to be a PITA w/ Mercurial that this is where most checkin problems
("fast-forward" in Stephen's terminology) would happen with Subversion.

Skip

From cournape at gmail.com  Mon Mar 21 17:52:49 2011
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 22 Mar 2011 01:52:49 +0900
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110321122015.3add347b@limelight.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
Message-ID: <AANLkTi=s+9no6FkxAMwii9N8RtXjwDUhTxZwmMxmWHQz@mail.gmail.com>

On Tue, Mar 22, 2011 at 1:20 AM, Barry Warsaw <barry at python.org> wrote:
> On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
>
>>On 20.03.2011 16:21, Guido van Rossum wrote:
>>> What is "rebase"? Why does everyone want it and hate it at the same time?
>>
>>Basically, rebase is a way to avoid having pointless merge commits on the
>>same branch.
>
> There's something I don't understand about rebase. ?It seems like most git and
> hg users I hear from advocate rebase, while (ISTM) few Bazaar users do.

I cannot talk for the communities in general, but that's mostly
cultural from what I have seen, although the tools reflect the
cultural aspect (like fast forward being the default for merge in
git). Hg up to recently did not have rebase at all, so it is less
ingrained it seems.

The reason why I like using rebase in general is because it fits the
way I like thinking about git: as a patch management system when I
work alone on a branch. I don't think private history is that useful
in general, but that depends on the projects of course. Another aspect
is that some people learnt git first through git-svn, where rebase is
the defacto way of working.

The issue of committing something that does not correspond to a tested
working tree is moot IMO: the only way to do it correctly and reliably
is to have some kind of gateway to actually test the commit before
adding it for good to the reference repo. In my experience, the most
common way to commit a broken working tree is to forget adding a new
file or removing an old file (e.g. the code depends on some old file
which has been removed while the old .pyc is still there), and none of
svn/bzr/hg/git prevents that.

David

From stephen at xemacs.org  Mon Mar 21 18:02:00 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 22 Mar 2011 02:02:00 +0900
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <20110321120743.6e71919b@limelight.wooz.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
	<20110321112531.0c98a191@limelight.wooz.org>
	<20110321163858.54f97606@pitrou.net>
	<20110321120743.6e71919b@limelight.wooz.org>
Message-ID: <87wrjsz9tj.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > Actually, I meant something like 'bzr checkout':

No.  Of the DVCSes, only bzr has that.

 > This would allow individual developers to treat the repository in a
 > centralized way like they did for svn, but still allowing other
 > developers to work in a distributed way.

I don't think that is true for Python, because of the "forward
porting" workflow when a patch is relevant to several branches.  They
are still going to have to do a merge, and do it in the right
direction.  I think "checkout" only makes emulation of centralized
workflow trivial in a single-active-branch development model.  I could
be wrong, but offhand I don't see how it would work.

From p.f.moore at gmail.com  Mon Mar 21 17:58:23 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 21 Mar 2011 16:58:23 +0000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110321122015.3add347b@limelight.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
Message-ID: <AANLkTin40w0c2YWNHtLx50FdZy06m=dKV+HzxsA1OATK@mail.gmail.com>

On 21 March 2011 16:20, Barry Warsaw <barry at python.org> wrote:
> It could be that some aspect of the tools causes A and B to not be hidden as
> well as they should, so that when looking at the history for example, the fact
> that A and B exist is a jarring or annoying artifact that would be better if
> they didn't exist.

My understanding is that Bazaar has a strong concept of the "mainline"
in the DAG, whereas hg (and presumably git, although I know little of
git) expose all parts of the DAG as equal. So yes, A and B are "not
hidden as well as they should" in hg and git.

There's a cultural argument over that "should", of course...

Paul.

From solipsis at pitrou.net  Mon Mar 21 18:07:40 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 18:07:40 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
Message-ID: <20110321180740.27947057@pitrou.net>

On Mon, 21 Mar 2011 12:20:15 -0400
Barry Warsaw <barry at python.org> wrote:
> On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
> 
> >On 20.03.2011 16:21, Guido van Rossum wrote:
> >> What is "rebase"? Why does everyone want it and hate it at the same time?
> >
> >Basically, rebase is a way to avoid having pointless merge commits on the
> >same branch.
> 
> There's something I don't understand about rebase.  It seems like most git and
> hg users I hear from advocate rebase, while (ISTM) few Bazaar users do.

I don't think many hg users advocate rebase, really. AFAICT the
Mercurial developers themselves don't seem to use it (they do use mq,
OTOH).

Regards

Antoine.



From raymond.hettinger at gmail.com  Mon Mar 21 18:16:05 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 21 Mar 2011 10:16:05 -0700
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <20110321112531.0c98a191@limelight.wooz.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
	<20110321112531.0c98a191@limelight.wooz.org>
Message-ID: <2BCDC99C-B199-4959-9404-51F0E12F7420@gmail.com>


On Mar 21, 2011, at 8:25 AM, Barry Warsaw wrote:
> 
> Does Mercurial have a way of acting like a centralized vcs to the end user,
> the way Bazaar does?  IOW, if Skip or others were more comfortable with a
> centralized workflow (which is entirely valid imo), can they set up their
> local workspace to enable that mode of operation?

I don't think that is the main source of complexity.

The more difficult and fragile part of the workflows are:
* requiring commits to be cross-linked between branches
* and wanting changesets to be collapsed or rebased
  (two operations that destroy and rewrite history).


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/b43bf0ae/attachment.html>

From rdmurray at bitdance.com  Mon Mar 21 18:19:29 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 21 Mar 2011 13:19:29 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <4D8767E7.8020702@cadifra.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<4D8767E7.8020702@cadifra.com>
Message-ID: <20110321171930.02BBE13F980@kimball.webabinitio.net>

On Mon, 21 Mar 2011 15:59:51 +0100, Adrian Buehlmann <adrian at cadifra.com> wrote:
> On 2011-03-21 14:40, R. David Murray wrote:
> > On Mon, 21 Mar 2011 18:33:00 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> >> R. David Murray writes:
> >>  > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> >>  > > No, at best the DVCS workflow forces the developer on a branch to
> >>  > > merge and test the revisions that will actually be added to the
> >>  > > repository, and perhaps notice system-level anomolies before pushing.
> >>  > 
> >>  > hg does not force the developer to test, it only forces the merge.
> >>
> >> I didn't say any VCS forces the test; I said that the workflow can (in
> >> the best case).  That's also inaccurate, of course.  I should have
> >> said "require", not "force".
> > 
> > The workflow in svn "can" "require" this same thing:  before committing,
> > you do an svn up and run the test suite.
> 
> But with svn you have to redo the test after the commit *if* someone
> else committed just before you in the mean time, thereby changing the
> preconditions "behind your back", thus creating a different state of the
> tree compared to the state in which it was at the time you ran your test.
> 
> With a DVCS, you can't push in that situation. At least not without
> creating a new head (which would require --force in Mercurial).

So you are worried about the small window between me doing an 'svn up',
seeing no changes, and doing an 'svn ci'?  I suppose that is a legitimate
concern, but considering the fact that if the same thing happens in hg,
the only difference is that I know about it and have to do more work[*],
I don't think it really changes anything.  Well, it means that if your
culture uses the "always test" workflow you can't be *perfect* about it
if you use svn[**], which I must suppose has been your (and Stephen's)
point from the beginning.

[*] that is, I'm *not* going to rerun the test suite even if I have to
pull/up/merge, unless there are conflicts.

[**] Possibly you could do it using svn locking, but even if you
could it wouldn't be worth it.

--
R. David Murray           http://www.bitdance.com

From tseaver at palladion.com  Mon Mar 21 18:20:13 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 21 Mar 2011 13:20:13 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <87y648zfob.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>
	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<19847.13078.526390.539879@montanaro.dyndns.org>
	<87y648zfob.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <im81cd$cvn$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/21/2011 10:55 AM, Stephen J. Turnbull wrote:
> skip at pobox.com writes:
> 
>  > I believe it runs counter to the professed intention of the switch
>  > away from a centralized version control system, to make it easier
>  > for more people to contribute to Python.  It certainly seems harder
>  > for this old dog.
> 
> Well, you may be an old dog, but you're also an early adopter.  That
> means both that you get to pay for our mistakes (our = authors of PEPs
> 374 and 385), and that it's going to take a while to disentangle
> implementation issues from the real long-run costs and benefits.
> 
> Costs of transition were admitted up front.  The professed intention
> was to make things *harder* in the short run (but as little as
> possible!), while making contribution to Python significantly more
> attractive (but not necessarily less work!) in the long run.

In our experience with migrating pyramid and repoze components from SVN
to github, the real wins come not from merging changes inside a
repository but in making it dirt-simple for people *wihtout commit
privileges* to give me trivial-to-merge patches (via a public fork).  I
pooh-poohed that advantage at last year's PyCon when people were urging
us to move to github / bitbucket;  by this year's conference, I have
cheerfully eaten my words.

As the developer working inside the "main" repository, I don't find git
/ hg / bzr much easier to use than svn.  Because I care about projects
using all three, I have to know all three, while still keeping up svn
chops:  I find that mental overhead annoying.

>  I don't
> think anybody tried to hide the fact that changing habits would be
> required, or to claim that it would be costless.  There were a few
> people with a Pollyanna "try it, you'll like it" attitude, but
> certainly those of us involved in PEP 374 knew better than that -- we
> knew there were people like you whose patterns of contribution worked
> just fine with the svn-based workflow and didn't need or want to
> change.  That's why PEP 374 was necessary!
> 
> Yes, based on the description you give of your principal contribution
> pattern, you take a complexity/effort hit in the transition.  I think
> it can be alleviated quite a bit with the help of your reports, but
> that will take some time.  All I can say about that time is "Sorry!"
> and "Thank you for trying the system while it's still in beta."
> 
> I hope you will give it some more time to shake down.

The "push race" problem in hg definitely bit us at PyCon this year while
sprinting to get WebOb's test coverage to 100% (preparing for the
Python3 port).  I haven't seen that issue so much with git or bzr, but I
may not have used them in such a race-friendly environment (ten or
eleven developers working in parallel on the WebOb test modules).


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2HiM0ACgkQ+gerLs4ltQ6jvQCgy29sT5kOuq0HwzMTxNltHj5Q
QH0An0kUTXiZWLTn07YvIwlWIm2LI8Gr
=bZ1G
-----END PGP SIGNATURE-----


From stefan_ml at behnel.de  Mon Mar 21 18:47:20 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 21 Mar 2011 18:47:20 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im7b1a$14l$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>	<im4sb2$lg1$1@dough.gmane.org>	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>	<im5028$7h7$1@dough.gmane.org>	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>	<im5pr1$7da$1@dough.gmane.org>	<AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>
	<im7b1a$14l$1@dough.gmane.org>
Message-ID: <im82v8$mhb$1@dough.gmane.org>

Stefan Behnel, 21.03.2011 11:58:
> Guido van Rossum, 21.03.2011 03:46:
>> Have you tried replacing selected stdlib modules with their
>> Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g.
>> what about Enthought's Python distros?) Depending on how well that
>> goes I might warm up to Cython more!
>
> Hmm, I hadn't heard about that before. I'll ask on our mailing list if
> anyone's aware of them. I doubt that the stdlib participates in the
> critical parts of scientific computation code. Maybe alternative CSV
> parsers or something like that, but I'd be surprised if they were
> compatible with what's in the stdlib.

Sorry, I misread your statement above. You were actually proposing to let 
us work on the existing stdlib modules, and then to get other, already 
Cython-enabled distributions to ship Cython compiled stdlib modules for 
testing.

Yes, I think this is a good idea. Their entry level for using Cython at 
build time will be much lower than for general CPython.

Would you say it's worth a GSoC project to get some of the Python stdlib 
modules compiled and/or some of the C modules rewritten in Cython? The 
Cython project would surely provide collective help through its user 
mailing list, code review, etc.

Stefan


From barry at python.org  Mon Mar 21 18:53:51 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 13:53:51 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <20110321171930.02BBE13F980@kimball.webabinitio.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<4D8767E7.8020702@cadifra.com>
	<20110321171930.02BBE13F980@kimball.webabinitio.net>
Message-ID: <20110321135351.20632230@limelight.wooz.org>

On Mar 21, 2011, at 01:19 PM, R. David Murray wrote:

>So you are worried about the small window between me doing an 'svn up',
>seeing no changes, and doing an 'svn ci'?  I suppose that is a legitimate
>concern, but considering the fact that if the same thing happens in hg,
>the only difference is that I know about it and have to do more work[*],
>I don't think it really changes anything.  Well, it means that if your
>culture uses the "always test" workflow you can't be *perfect* about it
>if you use svn[**], which I must suppose has been your (and Stephen's)
>point from the beginning.
>
>[*] that is, I'm *not* going to rerun the test suite even if I have to
>pull/up/merge, unless there are conflicts.

I think if we really want full testing of all changesets landing on
hg.python.org/cpython we're going to need a submit robot like PQM or Tarmac,
although the latter is probably too tightly wedded to the Launchpad API, and I
don't know if the former supports Mercurial.

With the benefits such robots bring, it's also important to understand the
downsides.  There are more moving parts to maintain, and because landings are
serialized, long test suites can sometimes cause significant backlogs.  Other
than during the Pycon sprints, the backlog probably wouldn't be that big.

Another complication we'd have is running the test suite cross-platform, but I
suspect that almost nobody does that today anyway.  So the buildbot farm would
still be important.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/a3c3bd17/attachment.pgp>

From fuzzyman at voidspace.org.uk  Mon Mar 21 19:01:48 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 21 Mar 2011 18:01:48 +0000
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im82v8$mhb$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>	<im4sb2$lg1$1@dough.gmane.org>	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>	<im5028$7h7$1@dough.gmane.org>	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>	<im5pr1$7da$1@dough.gmane.org>	<AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>	<im7b1a$14l$1@dough.gmane.org>
	<im82v8$mhb$1@dough.gmane.org>
Message-ID: <4D87928C.1010805@voidspace.org.uk>

On 21/03/2011 17:47, Stefan Behnel wrote:
> Stefan Behnel, 21.03.2011 11:58:
>> Guido van Rossum, 21.03.2011 03:46:
>>> Have you tried replacing selected stdlib modules with their
>>> Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g.
>>> what about Enthought's Python distros?) Depending on how well that
>>> goes I might warm up to Cython more!
>>
>> Hmm, I hadn't heard about that before. I'll ask on our mailing list if
>> anyone's aware of them. I doubt that the stdlib participates in the
>> critical parts of scientific computation code. Maybe alternative CSV
>> parsers or something like that, but I'd be surprised if they were
>> compatible with what's in the stdlib.
>
> Sorry, I misread your statement above. You were actually proposing to 
> let us work on the existing stdlib modules, and then to get other, 
> already Cython-enabled distributions to ship Cython compiled stdlib 
> modules for testing.
>
> Yes, I think this is a good idea. Their entry level for using Cython 
> at build time will be much lower than for general CPython.
>
> Would you say it's worth a GSoC project to get some of the Python 
> stdlib modules compiled and/or some of the C modules rewritten in 
> Cython? The Cython project would surely provide collective help 
> through its user mailing list, code review, etc.

Assuming its possible it sounds like an awesome project.

Michael

>
> Stefan
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From fijall at gmail.com  Mon Mar 21 19:12:46 2011
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 21 Mar 2011 12:12:46 -0600
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im4q17$aje$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<im4q17$aje$1@dough.gmane.org>
Message-ID: <AANLkTimQR51-LZMwJiCKSrkNEhHvZjgjUViMAqYOEWgA@mail.gmail.com>

[skipping the whole long discussion]

>
> Cython is meant to compile Python code. A "cython version" would just be a
> pure Python module, usable with all other implementations, but with type
> annotations that make it compile to more optimal C code. Type annotations
> can be provided in an external file (.pxd), using decorators and/or using
> Python 3 annotation syntax. There's also a port of Cython to IronPython
> being written. Additionally, other implementations (such as PyPy) could
> start using the available type declarations in order to improve their
> optimisation capabilities as well.
>

No, PyPy won't be any faster by using Cython type annotations. That
would be missing the whole point. JIT is finding types actually used
without an actual need to tell it to do so. If you really want to
assert isinstance(x, SomeType) would be good enough, but that won't
make anything faster. Places where PyPy is slower than Cython-compiled
code for numeric benchmarks is precisely where those type annotations
actually break Python semantics - for example overflow checking.

Also, from what we (and Unladen Swallow team) found out so far is that
people are actually interested in benchmarks that are "real world",
which in python world usually means "using twisted" or "using django"
or another "using very large library which is a bit hard to find a
hotspot in". That usually means execution time is spread across a
million calls, which makes it infeasible (if not incorrect) to apply
type annotations. That's where (I think) speed.python.org will go,
because that's where most people who contributed benchmarks are
interested in.

We would be happy to run those benchmarks against any VM that can
reasonably run them. Feel also free to contribute a way to run (a
subset of) benchmarks to run under cython, but what we won't do is we
won't provide a custom version of those benchmarks to run with Cython
(type annotations).

Cheers,
fijal

From barry at python.org  Mon Mar 21 19:29:54 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 14:29:54 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110321180740.27947057@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
Message-ID: <20110321142954.4e301fb2@limelight.wooz.org>

On Mar 21, 2011, at 06:07 PM, Antoine Pitrou wrote:

>On Mon, 21 Mar 2011 12:20:15 -0400
>Barry Warsaw <barry at python.org> wrote:
>> On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
>> 
>> >On 20.03.2011 16:21, Guido van Rossum wrote:
>> >> What is "rebase"? Why does everyone want it and hate it at the same time?
>> >
>> >Basically, rebase is a way to avoid having pointless merge commits on the
>> >same branch.
>> 
>> There's something I don't understand about rebase.  It seems like most git and
>> hg users I hear from advocate rebase, while (ISTM) few Bazaar users do.
>
>I don't think many hg users advocate rebase, really. AFAICT the
>Mercurial developers themselves don't seem to use it (they do use mq,
>OTOH).

I guess that begs the question then. ;)  

What harm would there be in relaxing the SHOULD in this paragraph to MAY?

"You should collapse changesets of a single feature or bugfix before pushing
the result to the main repository. The reason is that we don?t want the
history to be full of intermediate commits recording the private history of
the person working on a patch. If you are using the rebase extension, consider
adding the --collapse option to hg rebase. The collapse extension is another
choice."

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/bdddd2ed/attachment.pgp>

From stutzbach at google.com  Mon Mar 21 19:33:36 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Mon, 21 Mar 2011 11:33:36 -0700
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <20110321163858.54f97606@pitrou.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
	<20110321112531.0c98a191@limelight.wooz.org>
	<20110321163858.54f97606@pitrou.net>
Message-ID: <AANLkTi=oCu4F5XY6HboqfyHDuDkzWG_CkFmWeMK+nK4m@mail.gmail.com>

On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> We cannot emulate "svnmerge" for porting between branches, though - and
> I doubt bzr can do it. That's because merges in common DVCSes are based
> on the DAG, while svnmerge is a prettily ad-hoc free-form thing.


The equivalent way to how we had been using svnmerge would be to use hg
transplant to move patches between branches (and never merging the
branches).

Conversely, the current hg workflow would be similar to committing changes
to the earliest applicable svn branch, then doing a full svnmerge to later
branches.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/4f5f7b53/attachment.html>

From dasdasich at googlemail.com  Mon Mar 21 19:33:55 2011
From: dasdasich at googlemail.com (DasIch)
Date: Mon, 21 Mar 2011 19:33:55 +0100
Subject: [Python-Dev] GSoC: speed.python.org
Message-ID: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>

Hello Guys,
I'm interested in participating in the Google Summer of Code this year
and I've been looking at projects in the Wiki, particularly
speed.pypy.org[1] as I'm very interested in the current VM
development. However given my knowledge that project raised several
questions:

1. Up until now the only 3.x Implementation is CPyhon. IronPython,
Jython and PyPy don't support it - and to my knowledge won't get
support for it during or before GSoC - and could not benefit from it.
It seems that a comparison between a Python 2.x implementation and a
3.x implementation is rather pointless; so is this intended to be
rather an additional "feature" to have 3.x there as well?

2. As a follow-up to 1: It is not specified whether the benchmarks
should be ported using a tool such as 2to3, if this should not happen
or if this is up to the student, this needs clarification. This may be
more clear if it were considered under which "umbrella" this project
is actually supposed to happen; will those ported benchmarks end up in
CPython or will there be a separate repository for all VMs?

3. Several benchmarks (at least the Django and Twisted ones) have
dependencies which are not (yet) ported to 3.x and porting those
dependencies during GSoC as part of this project is an unrealistic
goal. Should those benchmarks, at least for now, be ignored?

[1]: http://wiki.python.org/moin/SpeedDotPythonDotOrg

From solipsis at pitrou.net  Mon Mar 21 19:38:18 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 19:38:18 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
Message-ID: <20110321193818.66fee202@pitrou.net>

On Mon, 21 Mar 2011 14:29:54 -0400
Barry Warsaw <barry at python.org> wrote:
> >
> >I don't think many hg users advocate rebase, really. AFAICT the
> >Mercurial developers themselves don't seem to use it (they do use mq,
> >OTOH).
> 
> I guess that begs the question then. ;)  
> 
> What harm would there be in relaxing the SHOULD in this paragraph to MAY?
> 
> "You should collapse changesets of a single feature or bugfix before pushing
> the result to the main repository.

Because it's really SHOULD.
Apparently some people misunderstand this statement. "collapse
changesets of a single feature or bugfix" doesn't mean you must avoid
merges. If that's the impression it gives then the wording SHOULD (;-))
be changed.

The paragraph is aimed at the temptation people may have to commit many
changesets for a single feature/bugfix and push them all even though
some of them don't leave the source tree in a stable state. What it
says is that we don't want work-in-progress changesets in the public
history.

Again, a better wording is welcome.

Regards

Antoine.



From fijall at gmail.com  Mon Mar 21 19:44:30 2011
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 21 Mar 2011 12:44:30 -0600
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
Message-ID: <AANLkTikDbvtdNsCipWeTxY7-cpRN_ydwNrj499zujJ85@mail.gmail.com>

On Mon, Mar 21, 2011 at 12:33 PM, DasIch <dasdasich at googlemail.com> wrote:
> Hello Guys,
> I'm interested in participating in the Google Summer of Code this year
> and I've been looking at projects in the Wiki, particularly
> speed.pypy.org[1] as I'm very interested in the current VM
> development. However given my knowledge that project raised several
> questions:
>
> 1. Up until now the only 3.x Implementation is CPyhon. IronPython,
> Jython and PyPy don't support it - and to my knowledge won't get
> support for it during or before GSoC - and could not benefit from it.
> It seems that a comparison between a Python 2.x implementation and a
> 3.x implementation is rather pointless; so is this intended to be
> rather an additional "feature" to have 3.x there as well?
>
> 2. As a follow-up to 1: It is not specified whether the benchmarks
> should be ported using a tool such as 2to3, if this should not happen
> or if this is up to the student, this needs clarification. This may be
> more clear if it were considered under which "umbrella" this project
> is actually supposed to happen; will those ported benchmarks end up in
> CPython or will there be a separate repository for all VMs?
>
> 3. Several benchmarks (at least the Django and Twisted ones) have
> dependencies which are not (yet) ported to 3.x and porting those
> dependencies during GSoC as part of this project is an unrealistic
> goal. Should those benchmarks, at least for now, be ignored?
>
> [1]: http://wiki.python.org/moin/SpeedDotPythonDotOrg
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

Hi.

There might be two independent SoCs but as far as I know, a very
interesting SoC on it's own (and one I'm willing to mentor) would be
to:

1. Get this stuff running on speed.python.org
2. Improve backend infrastructure so it actually *can* easily run
multiple VMs, especially that some benchmarks won't run on all.
3. Fix some bugs in frontend, improve things that don't look quite as
good if that should be for the general Python community.

Note that this is a bit orthogonal to port benchmarks to Python 3.
Also if noone would run those benchmarks, just porting them to Python
3 makes little sense.

Cheers,
fijal

From solipsis at pitrou.net  Mon Mar 21 19:48:48 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 19:48:48 +0100
Subject: [Python-Dev] GSoC: speed.python.org
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
Message-ID: <20110321194848.64ad8abb@pitrou.net>

On Mon, 21 Mar 2011 19:33:55 +0100
DasIch <dasdasich at googlemail.com> wrote:
> 
> 3. Several benchmarks (at least the Django and Twisted ones) have
> dependencies which are not (yet) ported to 3.x and porting those
> dependencies during GSoC as part of this project is an unrealistic
> goal. Should those benchmarks, at least for now, be ignored?

Why not reuse the benchmarks in http://hg.python.org/benchmarks/ ?
Many of them are 3.x-compatible.
I don't understand why people are working on multiple benchmark suites
without cooperating these days.

Regards

Antoine.



From jnoller at gmail.com  Mon Mar 21 19:48:20 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Mon, 21 Mar 2011 14:48:20 -0400
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
Message-ID: <AANLkTikoXhUfkuUPPT+xfJ0ZvMkU8vFn5VUSjp+rnrAL@mail.gmail.com>

Some remarks below.

On Mon, Mar 21, 2011 at 2:33 PM, DasIch <dasdasich at googlemail.com> wrote:
> Hello Guys,
> I'm interested in participating in the Google Summer of Code this year
> and I've been looking at projects in the Wiki, particularly
> speed.pypy.org[1] as I'm very interested in the current VM
> development. However given my knowledge that project raised several
> questions:
>
> 1. Up until now the only 3.x Implementation is CPyhon. IronPython,
> Jython and PyPy don't support it - and to my knowledge won't get
> support for it during or before GSoC - and could not benefit from it.
> It seems that a comparison between a Python 2.x implementation and a
> 3.x implementation is rather pointless; so is this intended to be
> rather an additional "feature" to have 3.x there as well?
>

You are correct: But the point of this GSOC project is to do the
porting, the initial deployment of speed.python.org will be on the 2.x
implementation with 3.x to follow as other VMs migrate.

> 2. As a follow-up to 1: It is not specified whether the benchmarks
> should be ported using a tool such as 2to3, if this should not happen
> or if this is up to the student, this needs clarification. This may be
> more clear if it were considered under which "umbrella" this project
> is actually supposed to happen; will those ported benchmarks end up in
> CPython or will there be a separate repository for all VMs?
>

We will have a common repository for all benchmarks, for all of the
implementations.

> 3. Several benchmarks (at least the Django and Twisted ones) have
> dependencies which are not (yet) ported to 3.x and porting those
> dependencies during GSoC as part of this project is an unrealistic
> goal. Should those benchmarks, at least for now, be ignored?
>

IMHO: Yes. I think MvL can expand on this as well.

> [1]: http://wiki.python.org/moin/SpeedDotPythonDotOrg

FYI, I recommend coordinating with Miquel Torres (cc'ed) and Maciej
Fijalkowski from PyPy on these questions / this project as well. I am
currently coordinating getting the hardware setup for this project's
hosting.

jesse

From jnoller at gmail.com  Mon Mar 21 19:51:47 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Mon, 21 Mar 2011 14:51:47 -0400
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <20110321194848.64ad8abb@pitrou.net>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
Message-ID: <AANLkTinPYctO3uiYYvCz4OmgtJKtUyJGQcVq-BumKVKu@mail.gmail.com>

On Mon, Mar 21, 2011 at 2:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 21 Mar 2011 19:33:55 +0100
> DasIch <dasdasich at googlemail.com> wrote:
>>
>> 3. Several benchmarks (at least the Django and Twisted ones) have
>> dependencies which are not (yet) ported to 3.x and porting those
>> dependencies during GSoC as part of this project is an unrealistic
>> goal. Should those benchmarks, at least for now, be ignored?
>
> Why not reuse the benchmarks in http://hg.python.org/benchmarks/ ?
> Many of them are 3.x-compatible.
> I don't understand why people are working on multiple benchmark suites
> without cooperating these days.
>
> Regards
>
> Antoine.

Antoine: The goal is to *get* PyPy, Jython, IronPython, etc all using
a common set of benchmarks. The idea stems from http://speed.pypy.org/
- those benchmarks grew from the unladen swallow benchmarks, which I
think are the ones in http://hg.python.org/benchmarks/.

So, yeah - the goal is to get us all reading off the same page. The
PyPy people can speak to the changes they made/had to make.

jesse

From solipsis at pitrou.net  Mon Mar 21 19:45:27 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 19:45:27 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <AANLkTi=oCu4F5XY6HboqfyHDuDkzWG_CkFmWeMK+nK4m@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
	<20110321112531.0c98a191@limelight.wooz.org>
	<20110321163858.54f97606@pitrou.net>
	<AANLkTi=oCu4F5XY6HboqfyHDuDkzWG_CkFmWeMK+nK4m@mail.gmail.com>
Message-ID: <1300733127.3516.4.camel@localhost.localdomain>

Le lundi 21 mars 2011 ? 11:33 -0700, Daniel Stutzbach a ?crit :
> On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
>         We cannot emulate "svnmerge" for porting between branches,
>         though - and
>         I doubt bzr can do it. That's because merges in common DVCSes
>         are based
>         on the DAG, while svnmerge is a prettily ad-hoc free-form
>         thing.
> 
> 
> The equivalent way to how we had been using svnmerge would be to use
> hg transplant to move patches between branches (and never merging the
> branches).

Yes, this has been discussed several times before the migration.
Using "hg transplant" is seriously suboptimal compared to the model
promoted by a "DAG of changesets"-based DVCS. Also, transplant has its
own weaknesses.

Regards

Antoine.



From stutzbach at google.com  Mon Mar 21 19:56:21 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Mon, 21 Mar 2011 11:56:21 -0700
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <im5akg$ptc$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
Message-ID: <AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>

On Sun, Mar 20, 2011 at 9:39 AM, Georg Brandl <g.brandl at gmx.net> wrote:

> Now, "hg pull --rebase" prevents that by "re-basing" the A-B history
> line onto the latest remote head.  After rebasing, the history looks
> like this:
>
> ... --- X --- C --- D --- E --- A' --- B'
>

Rebasing also allows you to collapse the commits, so you can make the tree
look like this:

... --- X --- C --- D --- E --- AB'

Collapsing commits is useful for keeping the repository clean.  For example,
I make commit A and send it for review.  Someone points out some flaws and I
make commit B.  I don't want the flawed version checked in to the main
repository, so I collapse the commits into one commit AB'.

Keeping the repository clean makes it easier to use a bisection search to
hunt down the introduction of a bug.  If  every developer's intermediate
commits make it into the main repository, it's hard to go back to an older
revision to test something, because many of the older revisions will be
broken in some way.

In reality
> it works fine if you know the limits: rebasing really only should be
> applied if the changesets are not already known somewhere else,
> only in the local repo you're working with.


The changesets must only be in the local repo *and* they must not have been
merged into another branch yet.

On Sun, Mar 20, 2011 at 9:21 AM, Guido van Rossum <guido at python.org> wrote:

> Why does everyone want it and hate it at the same time?
>

People love it because it's a very powerful tool.  People hate it because it
allows you to shoot yourself in the foot.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/c7bbf427/attachment.html>

From solipsis at pitrou.net  Mon Mar 21 19:58:52 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 19:58:52 +0100
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <AANLkTinPYctO3uiYYvCz4OmgtJKtUyJGQcVq-BumKVKu@mail.gmail.com>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
	<AANLkTinPYctO3uiYYvCz4OmgtJKtUyJGQcVq-BumKVKu@mail.gmail.com>
Message-ID: <1300733932.3516.5.camel@localhost.localdomain>

Le lundi 21 mars 2011 ? 14:51 -0400, Jesse Noller a ?crit :
> On Mon, Mar 21, 2011 at 2:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Mon, 21 Mar 2011 19:33:55 +0100
> > DasIch <dasdasich at googlemail.com> wrote:
> >>
> >> 3. Several benchmarks (at least the Django and Twisted ones) have
> >> dependencies which are not (yet) ported to 3.x and porting those
> >> dependencies during GSoC as part of this project is an unrealistic
> >> goal. Should those benchmarks, at least for now, be ignored?
> >
> > Why not reuse the benchmarks in http://hg.python.org/benchmarks/ ?
> > Many of them are 3.x-compatible.
> > I don't understand why people are working on multiple benchmark suites
> > without cooperating these days.
> >
> > Regards
> >
> > Antoine.
> 
> Antoine: The goal is to *get* PyPy, Jython, IronPython, etc all using
> a common set of benchmarks. The idea stems from http://speed.pypy.org/
> - those benchmarks grew from the unladen swallow benchmarks, which I
> think are the ones in http://hg.python.org/benchmarks/.

Ok, I can stand corrected. Last time I looked, speed.pypy.org had an
entirely disjunct set of benchmarks.

Regards

Antoine.



From skip at pobox.com  Mon Mar 21 20:06:03 2011
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 21 Mar 2011 14:06:03 -0500
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <20110321194848.64ad8abb@pitrou.net>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
Message-ID: <19847.41371.662914.210531@montanaro.dyndns.org>


    Antoine> Why not reuse the benchmarks in
    Antoine> http://hg.python.org/benchmarks/ ?

These looks like basically the same benchmarks as the Unladen Swallow folks
put together, right?  Is there any value in them as regression tests (maybe
with more elaborate inputs and/or longer runtimes)?  If so, I think there is
value it having both 2.x and 3.x versions, even if the 3.x stuff won't be
useful for speed comparisons.

Skip

From skip at pobox.com  Mon Mar 21 20:09:31 2011
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 21 Mar 2011 14:09:31 -0500
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
Message-ID: <19847.41579.85252.481397@montanaro.dyndns.org>


    Daniel> If every developer's intermediate commits make it into the main
    Daniel> repository, it's hard to go back to an older revision to test
    Daniel> something, because many of the older revisions will be broken in
    Daniel> some way.

This is what I discovered with my trivial doc patch last week.  I was quite
surprised to see all my local checkins turn up on the python-checkins
mailing list.  Is there not some way to automatically collapse a series of
local commits into one large commit when you do the push?

Skip

From solipsis at pitrou.net  Mon Mar 21 20:10:30 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 20:10:30 +0100
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <19847.41371.662914.210531@montanaro.dyndns.org>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
	<19847.41371.662914.210531@montanaro.dyndns.org>
Message-ID: <1300734630.3516.8.camel@localhost.localdomain>

Le lundi 21 mars 2011 ? 14:06 -0500, skip at pobox.com a ?crit :
> Antoine> Why not reuse the benchmarks in
>     Antoine> http://hg.python.org/benchmarks/ ?
> 
> These looks like basically the same benchmarks as the Unladen Swallow folks
> put together, right?

Yes, it's basically the continuation of their work. Most changes since
then have been relatively minor.

> Is there any value in them as regression tests (maybe
> with more elaborate inputs and/or longer runtimes)?

You mean to check behaviour or to check for performance regressions?
IMHO the test suite is long enough to run already and performance tests
should be kept in a separate suite. Whether that suite should be
separate from the main distribution is another question.

Regards

Antoine.



From skip at pobox.com  Mon Mar 21 20:30:45 2011
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 21 Mar 2011 14:30:45 -0500
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <1300734630.3516.8.camel@localhost.localdomain>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
	<19847.41371.662914.210531@montanaro.dyndns.org>
	<1300734630.3516.8.camel@localhost.localdomain>
Message-ID: <19847.42853.999917.731738@montanaro.dyndns.org>


    >> Is there any value in them as regression tests (maybe with more
    >> elaborate inputs and/or longer runtimes)?

    Antoine> You mean to check behaviour or to check for performance
    Antoine> regressions?

Both.  Semantic regressions, and secondarily, performance regressions.
I can understand the need to stabilize the code and inputs for measuring
performance.  As bad a benchmark as pystone is, one of its saving graces is
that it hasn't changed in so long.

When looking for semantic problems I can see that you would add new packages
to the suite where they expose problems, just as we do today for unit tests.

Skip

From solipsis at pitrou.net  Mon Mar 21 20:36:45 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 20:36:45 +0100
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <19847.42853.999917.731738@montanaro.dyndns.org>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
	<19847.41371.662914.210531@montanaro.dyndns.org>
	<1300734630.3516.8.camel@localhost.localdomain>
	<19847.42853.999917.731738@montanaro.dyndns.org>
Message-ID: <20110321203645.03366eb5@pitrou.net>

On Mon, 21 Mar 2011 14:30:45 -0500
skip at pobox.com wrote:
> 
>     >> Is there any value in them as regression tests (maybe with more
>     >> elaborate inputs and/or longer runtimes)?
> 
>     Antoine> You mean to check behaviour or to check for performance
>     Antoine> regressions?
> 
> Both.  Semantic regressions, and secondarily, performance regressions.
> I can understand the need to stabilize the code and inputs for measuring
> performance.  As bad a benchmark as pystone is, one of its saving graces is
> that it hasn't changed in so long.

I think that semantic regressions would be better checked by running
the test suites of these third-party libraries, not benchmarks.
Ideally a separate suite of buildbots or builders could do that. We had
the community buildbots but it seems they ran out of steam.

Regards

Antoine.

From raymond.hettinger at gmail.com  Mon Mar 21 20:40:08 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 21 Mar 2011 12:40:08 -0700
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
Message-ID: <ECD3C64A-3930-4065-A6F7-AD2D525CAC00@gmail.com>


On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
> 
> People love it because it's a very powerful tool.  People hate it because it allows you to shoot yourself in the foot.

There's a certain irony in this.   The original motivation for version control
was to be a safety rope, to serve as a productivity tool to make sure
that work never got lost.

Now we seem to be advocating a complex, fragile workflow that
is hard to learn, hard to get right, that let's you shoot yourself in 
the foot, and that has rebasing/collapsing steps that destroy and 
rewrite history (an possibly muck-up your repo if there was an
intervening push).

If we gave-up on the "svnmerge on steroids workflow",
the use of Hg would become dirt simple.   I've used it that way
in personal projects for a couple months and it is 
remarkably easy, taking only minutes to learn.
It also works with Hg right out of the box; no need
for extensions, customizations, or a slew of advanced Hg
features.

If someone has to completely master nuances of Hg
to follow the required workflow, then we're doing it wrong.

ISTM, there has been substantial mission creep from 
the workflow described in the PEP.  If the current workflow
had been described there, I don't think it would have been
readily accepted.


Raymond




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/469207b7/attachment.html>

From solipsis at pitrou.net  Mon Mar 21 20:48:04 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 20:48:04 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<ECD3C64A-3930-4065-A6F7-AD2D525CAC00@gmail.com>
Message-ID: <20110321204804.718f93f3@pitrou.net>

On Mon, 21 Mar 2011 12:40:08 -0700
Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
> 
> Now we seem to be advocating a complex, fragile workflow that
> is hard to learn, hard to get right, that let's you shoot yourself in 
> the foot, and that has rebasing/collapsing steps that destroy and 
> rewrite history (an possibly muck-up your repo if there was an
> intervening push).

FWIW, rebase is *not* advocated in the devguide. It's not even a
suggestion. The only sentence which mentions it starts with

   "If you are using the rebase_ extension"

which is a pretty clear hint that it's an individual choice and not
something we recommend.

Regards

Antoine.



From g.brandl at gmx.net  Mon Mar 21 20:57:40 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 21 Mar 2011 20:57:40 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <ECD3C64A-3930-4065-A6F7-AD2D525CAC00@gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<ECD3C64A-3930-4065-A6F7-AD2D525CAC00@gmail.com>
Message-ID: <im8aj0$70o$1@dough.gmane.org>

On 21.03.2011 20:40, Raymond Hettinger wrote:
> 
> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>>
>>
>> People love it because it's a very powerful tool.  People hate it because it
>> allows you to shoot yourself in the foot.
> 
> There's a certain irony in this.   The original motivation for version control
> was to be a safety rope, to serve as a productivity tool to make sure
> that work never got lost.
>
> Now we seem to be advocating a complex, fragile workflow that
> is hard to learn, hard to get right, that let's you shoot yourself in 
> the foot, and that has rebasing/collapsing steps that destroy and 
> rewrite history (an possibly muck-up your repo if there was an
> intervening push).

That last one is not true.

> If we gave-up on the "svnmerge on steroids workflow",
> the use of Hg would become dirt simple.   I've used it that way
> in personal projects for a couple months and it is 
> remarkably easy, taking only minutes to learn.
> It also works with Hg right out of the box; no need
> for extensions, customizations, or a slew of advanced Hg
> features.

Whether you use rebase or not is completely unrelated to the branch
workflow.  (Indeed, without branch merging rebase works even better,
since as we saw it doesn't handle branch merges.)

Georg


From ben+python at benfinney.id.au  Mon Mar 21 20:57:58 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 22 Mar 2011 06:57:58 +1100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
Message-ID: <87wrjs456h.fsf@benfinney.id.au>

Barry Warsaw <barry at python.org> writes:

> There's something I don't understand about rebase. It seems like most
> git and hg users I hear from advocate rebase, while (ISTM) few Bazaar
> users do.
>
> I'd like to understand whether that's a cultural thing or whether it's
> a byproduct of some aspect of the respective tools.

As I understand it, the justification usually given for rewriting
history is so that others get a clean view of what one has done.

As a user of Bazaar primarily, that's addressing the problem in the
wrong place: why rewrite *my* history, which is useful to me as is, when
the other person is using Bazaar and so doesn't see revisions they don't
care about?

The advantages given for rewriting history (?don't show individual
commits that went into a merge?) are null for a Bazaar user. Bazaar
doesn't show me those commits within merges anyway, unless I ask for
them.

That is, when showing the log of a branch, each merge appears as a
single entry, unless I ask to expand levels when viewing them. The
detailed revision data is always there, but it doesn't get in the way
unless I ask for it.

That seems to me the ideal: preserve all revision history for those
cases when some user will care about it, but *present* history cleanly
by default.

Whether adding support in Mercurial or Git for similar
clean-presentation-by-default would obviate the need for rewriting
history, I can't tell.

-- 
 \      ?The best mind-altering drug is truth.? ?Jane Wagner, via Lily |
  `\                                                            Tomlin |
_o__)                                                                  |
Ben Finney
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/7211f104/attachment.pgp>

From g.brandl at gmx.net  Mon Mar 21 20:58:41 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 21 Mar 2011 20:58:41 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <19847.41579.85252.481397@montanaro.dyndns.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<19847.41579.85252.481397@montanaro.dyndns.org>
Message-ID: <im8akt$70o$2@dough.gmane.org>

On 21.03.2011 20:09, skip at pobox.com wrote:
> 
>     Daniel> If every developer's intermediate commits make it into the main
>     Daniel> repository, it's hard to go back to an older revision to test
>     Daniel> something, because many of the older revisions will be broken in
>     Daniel> some way.
> 
> This is what I discovered with my trivial doc patch last week.  I was quite
> surprised to see all my local checkins turn up on the python-checkins
> mailing list.  Is there not some way to automatically collapse a series of
> local commits into one large commit when you do the push?

There is, but this is again "changing history", with all the possible
benefits and caveats that have been shown in this thread.

Georg



From barry at python.org  Mon Mar 21 21:19:01 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 16:19:01 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
Message-ID: <20110321161901.6fdb7d50@limelight.wooz.org>

On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:

>Keeping the repository clean makes it easier to use a bisection search to
>hunt down the introduction of a bug.  If  every developer's intermediate
>commits make it into the main repository, it's hard to go back to an older
>revision to test something, because many of the older revisions will be
>broken in some way.

So maybe this gets at my earlier question about rebase being cultural
vs. technology, and the response about bzr having a strong sense of mainline
where hg doesn't.

I don't use the bzr-bisect plugin too much, but I think by default it only
follows commits on the main line, unless a bisect point is identified within a
merge (i.e. side) line.  So again, those merged intermediate changes are
mostly ignored until they're needed.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/60eeb776/attachment.pgp>

From barry at python.org  Mon Mar 21 21:22:56 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 16:22:56 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <im8akt$70o$2@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<19847.41579.85252.481397@montanaro.dyndns.org>
	<im8akt$70o$2@dough.gmane.org>
Message-ID: <20110321162256.32d2007c@limelight.wooz.org>

On Mar 21, 2011, at 08:58 PM, Georg Brandl wrote:

>On 21.03.2011 20:09, skip at pobox.com wrote:
>> 
>>     Daniel> If every developer's intermediate commits make it into the main
>>     Daniel> repository, it's hard to go back to an older revision to test
>>     Daniel> something, because many of the older revisions will be broken in
>>     Daniel> some way.
>> 
>> This is what I discovered with my trivial doc patch last week.  I was quite
>> surprised to see all my local checkins turn up on the python-checkins
>> mailing list.  Is there not some way to automatically collapse a series of
>> local commits into one large commit when you do the push?
>
>There is, but this is again "changing history", with all the possible
>benefits and caveats that have been shown in this thread.

I think Ben Finney hit the nail on the head here.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/58736cbd/attachment.pgp>

From barry at python.org  Mon Mar 21 21:24:38 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 16:24:38 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <87wrjs456h.fsf@benfinney.id.au>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
Message-ID: <20110321162438.671efe42@limelight.wooz.org>

On Mar 22, 2011, at 06:57 AM, Ben Finney wrote:

>Barry Warsaw <barry at python.org> writes:
>
>> There's something I don't understand about rebase. It seems like most
>> git and hg users I hear from advocate rebase, while (ISTM) few Bazaar
>> users do.
>>
>> I'd like to understand whether that's a cultural thing or whether it's
>> a byproduct of some aspect of the respective tools.
>
>As I understand it, the justification usually given for rewriting
>history is so that others get a clean view of what one has done.
>
>As a user of Bazaar primarily, that's addressing the problem in the
>wrong place: why rewrite *my* history, which is useful to me as is, when
>the other person is using Bazaar and so doesn't see revisions they don't
>care about?
>
>The advantages given for rewriting history (?don't show individual
>commits that went into a merge?) are null for a Bazaar user. Bazaar
>doesn't show me those commits within merges anyway, unless I ask for
>them.
>
>That is, when showing the log of a branch, each merge appears as a
>single entry, unless I ask to expand levels when viewing them. The
>detailed revision data is always there, but it doesn't get in the way
>unless I ask for it.
>
>That seems to me the ideal: preserve all revision history for those
>cases when some user will care about it, but *present* history cleanly
>by default.
>
>Whether adding support in Mercurial or Git for similar
>clean-presentation-by-default would obviate the need for rewriting
>history, I can't tell.

Thanks Ben, for such a clear description.  This jives with my observations
exactly.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/fc92f84f/attachment.pgp>

From dasdasich at googlemail.com  Mon Mar 21 21:24:42 2011
From: dasdasich at googlemail.com (DasIch)
Date: Mon, 21 Mar 2011 21:24:42 +0100
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <20110321194848.64ad8abb@pitrou.net>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
Message-ID: <AANLkTinvBcL63zJcZVjAOSws=iqdvF9+zZq=Uned392k@mail.gmail.com>

On Mon, Mar 21, 2011 at 7:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 21 Mar 2011 19:33:55 +0100
> DasIch <dasdasich at googlemail.com> wrote:
>>
>> 3. Several benchmarks (at least the Django and Twisted ones) have
>> dependencies which are not (yet) ported to 3.x and porting those
>> dependencies during GSoC as part of this project is an unrealistic
>> goal. Should those benchmarks, at least for now, be ignored?
>
> Why not reuse the benchmarks in http://hg.python.org/benchmarks/ ?
> Many of them are 3.x-compatible.
> I don't understand why people are working on multiple benchmark suites
> without cooperating these days.

I haven't looked to closely but those benchmarks appear to be the ones
developed by the unladen swallow guys and those are used by PyPy among
others.

The difference is that PyPy has more benchmarks particularly ones that
measure performance of real world applications. As good benchmarks are
very hard to come by those appear to be a better starting point.

From barry at python.org  Mon Mar 21 21:33:31 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 16:33:31 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110321193818.66fee202@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
Message-ID: <20110321163331.4277ffd0@limelight.wooz.org>

On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:

>On Mon, 21 Mar 2011 14:29:54 -0400
>Barry Warsaw <barry at python.org> wrote:
>> >
>> >I don't think many hg users advocate rebase, really. AFAICT the
>> >Mercurial developers themselves don't seem to use it (they do use mq,
>> >OTOH).
>> 
>> I guess that begs the question then. ;)  
>> 
>> What harm would there be in relaxing the SHOULD in this paragraph to MAY?
>> 
>> "You should collapse changesets of a single feature or bugfix before pushing
>> the result to the main repository.
>
>Because it's really SHOULD.
>Apparently some people misunderstand this statement. "collapse
>changesets of a single feature or bugfix" doesn't mean you must avoid
>merges. If that's the impression it gives then the wording SHOULD (;-))
>be changed.
>
>The paragraph is aimed at the temptation people may have to commit many
>changesets for a single feature/bugfix and push them all even though
>some of them don't leave the source tree in a stable state. What it
>says is that we don't want work-in-progress changesets in the public
>history.
>
>Again, a better wording is welcome.

I guess it depends on what "work-in-progress changesets" means. ;)

If I'm working on a new feature, I am going to make lots of local commits, any
one of which may not actually be stable.  However, when my work on that
feature branch completes, I will have a fully functional, stable branch that's
ready to merge into the default branch.

As Ben described clearly, with Bazaar, I'd just merge my work-in-progress
branch to default and be done.  Tools such as bisect and log would ignore all
my intermediate changes by default, although you *can* drill down into them if
you want.  But I take it that with our Mercurial workflow, we'd rather all
those intermediate commits in my local branch were manually collapsed before I
merge to default.

My discomfort with this is not just that it changes history, but that it
throws away valuable information.  Sure, you're not going to care if I fixed a
typo in NEWS, but you might indeed care that I've addressed the issues you
raised in your first, second, and third reviews.  Each of those would be
represented by a changeset in my local line of development, and by a side
branch in the mainline DAG once my merge is completed.  You might want to dig
into that sideline to see if indeed I addressed the issues in your second
review of my code.  If we have to manually collapse changesets at feature
branch merge time, you can't do that.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/8d05d977/attachment.pgp>

From tseaver at palladion.com  Mon Mar 21 21:43:01 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 21 Mar 2011 16:43:01 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110321163331.4277ffd0@limelight.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<20110321180740.27947057@pitrou.net>	<20110321142954.4e301fb2@limelight.wooz.org>	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
Message-ID: <im8d8l$oro$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/21/2011 04:33 PM, Barry Warsaw wrote:
> On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:
> 
>> On Mon, 21 Mar 2011 14:29:54 -0400
>> Barry Warsaw <barry at python.org> wrote:
>>>>
>>>> I don't think many hg users advocate rebase, really. AFAICT the
>>>> Mercurial developers themselves don't seem to use it (they do use mq,
>>>> OTOH).
>>>
>>> I guess that begs the question then. ;)  
>>>
>>> What harm would there be in relaxing the SHOULD in this paragraph to MAY?
>>>
>>> "You should collapse changesets of a single feature or bugfix before pushing
>>> the result to the main repository.
>>
>> Because it's really SHOULD.
>> Apparently some people misunderstand this statement. "collapse
>> changesets of a single feature or bugfix" doesn't mean you must avoid
>> merges. If that's the impression it gives then the wording SHOULD (;-))
>> be changed.
>>
>> The paragraph is aimed at the temptation people may have to commit many
>> changesets for a single feature/bugfix and push them all even though
>> some of them don't leave the source tree in a stable state. What it
>> says is that we don't want work-in-progress changesets in the public
>> history.
>>
>> Again, a better wording is welcome.
> 
> I guess it depends on what "work-in-progress changesets" means. ;)
> 
> If I'm working on a new feature, I am going to make lots of local commits, any
> one of which may not actually be stable.  However, when my work on that
> feature branch completes, I will have a fully functional, stable branch that's
> ready to merge into the default branch.
> 
> As Ben described clearly, with Bazaar, I'd just merge my work-in-progress
> branch to default and be done.  Tools such as bisect and log would ignore all
> my intermediate changes by default, although you *can* drill down into them if
> you want.  But I take it that with our Mercurial workflow, we'd rather all
> those intermediate commits in my local branch were manually collapsed before I
> merge to default.
> 
> My discomfort with this is not just that it changes history, but that it
> throws away valuable information.  Sure, you're not going to care if I fixed a
> typo in NEWS, but you might indeed care that I've addressed the issues you
> raised in your first, second, and third reviews.  Each of those would be
> represented by a changeset in my local line of development, and by a side
> branch in the mainline DAG once my merge is completed.  You might want to dig
> into that sideline to see if indeed I addressed the issues in your second
> review of my code.  If we have to manually collapse changesets at feature
> branch merge time, you can't do that.

Having bisect able to use the intermediate changesets (as an option)
could even make it easier to pinpoint the correct fix for a bug
(assuming people don't routinely make local changes of complete
"guts-on-the-table" messes).


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2HuFUACgkQ+gerLs4ltQ6+bACeLETaWB34XZwvJIPYkP3mddrU
JRoAoKCNTnkjFlQe8xXNJdyYUDHoSiFs
=ksyC
-----END PGP SIGNATURE-----


From db3l.net at gmail.com  Mon Mar 21 21:44:44 2011
From: db3l.net at gmail.com (David Bolen)
Date: Mon, 21 Mar 2011 16:44:44 -0400
Subject: [Python-Dev] Have we lost changeset info in the buildbots
References: <4D7E496F.8050302@jcea.es> <20110314180756.45711629@pitrou.net>
	<m2sjupv6jg.fsf@valheru.db3l.homeip.net>
	<1300582839.20491.1.camel@marge>
Message-ID: <m2r5a0td8j.fsf@valheru.db3l.homeip.net>

Victor Stinner <victor.stinner at haypocalc.com> writes:

> Le lundi 14 mars 2011 ? 15:36 -0400, David Bolen a ?crit :
>>
>> Speaking of bbreport, I sometimes use the published page on that site
>> (http://code.google.com/p/bbreport/wiki/PythonBuildbotReport) to check
>> over things, but looking at it today, it seems to most recently have been
>> generated back in January.  Or is the generated date line wrong?
>
> I ran a cron task to regenerate this page each hour, but I didn't get
> any feedback and I stopped to use it, so I just removed the cron task.
>
> Do you want that I restart this cron task?

If it's a hassle to maintain, it's probably not worth it.  I can't say
it's critical to me, but I do find it helpful to review periodically
given how it summarizes issues that may aggregate up to a builder or
slave.  I just keep it open on a tab along with the build slave
summary page which is my primary check, so it's a bit simpler than
having to re-run a command line tool for quick checks.

I did submit one feature request (issue 16) early on when I first
started using it about seeing if it was possible to include slave (and
not just builder) information.

-- David


From solipsis at pitrou.net  Mon Mar 21 21:53:26 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 21:53:26 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
Message-ID: <20110321215326.0767c775@pitrou.net>

On Mon, 21 Mar 2011 16:33:31 -0400
Barry Warsaw <barry at python.org> wrote:
> Each of those would be
> represented by a changeset in my local line of development, and by a side
> branch in the mainline DAG once my merge is completed.  You might want to dig
> into that sideline to see if indeed I addressed the issues in your second
> review of my code.  If we have to manually collapse changesets at feature
> branch merge time, you can't do that.

I'd rather take a look at the final aggregate patch to see if it looks
correct, actually. It's easy to have incremental changes which look
good but lead to a questionable patch in the end. Better to review it
in aggregate, IMO.

Regards

Antoine.



From barry at python.org  Mon Mar 21 22:09:41 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 17:09:41 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
Message-ID: <20110321170941.44685dfa@neurotica.wooz.org>

On Mar 18, 2011, at 07:40 PM, Guido van Rossum wrote:

>On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Tres Seaver wrote:
>>
>>> I'm not even sure why you would want __version__ in 99% of modules: ?in
>>> the ordinary cases, a module's version should be either the Python
>>> version (for a module shipped in the stdlib), or the release of the
>>> distribution which shipped it.
>>
>> It's useful to be able to find out the version of a module
>> you're using at run time so you can cope with API changes.
>>
>> I had a case just recently where the behaviour of something
>> in pywin32 changed between one release and the next. I looked
>> for an attribute called 'version' or something similar to
>> test, but couldn't find anything.
>>
>> +1 on having a standard place to look for version info.
>
>I believe __version__ *is* the standard (like __author__). IIRC it was
>proposed by Ping. I think this convention is so old that there isn't a
>PEP for it. So yes, we might as well write it down. But it's really
>nothing new.

I started an Informational PEP on this at Pycon, and will try to finish a
draft of it this week.  (I'm claiming 396 for it.)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/4118c544/attachment.pgp>

From barry at python.org  Mon Mar 21 22:10:44 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 17:10:44 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <20110319135143.199b0868@pitrou.net>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
	<20110319031219.GC19053@unaka.lan>
	<20110319135143.199b0868@pitrou.net>
Message-ID: <20110321171044.70930bb5@neurotica.wooz.org>

On Mar 19, 2011, at 01:51 PM, Antoine Pitrou wrote:

>On Fri, 18 Mar 2011 20:12:19 -0700
>Toshio Kuratomi <a.badger at gmail.com> wrote:
>> There is a section in PEP8 about __version__ but it serves a slightly
>> different purpose there:
>> 
>> """
>> Version Bookkeeping
>> 
>>     If you have to have Subversion, CVS, or RCS crud in your source file, do
>>     it as follows.
>> 
>>         __version__ = "$Revision: 88433 $"
>>         # $Source$
>
>This should be updated (or rather, removed) now that we use Mercurial...

I've made a note about it and will address it in PEP 396.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/7b4735ed/attachment.pgp>

From benjamin at python.org  Mon Mar 21 22:15:19 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 21 Mar 2011 16:15:19 -0500
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <ECD3C64A-3930-4065-A6F7-AD2D525CAC00@gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<ECD3C64A-3930-4065-A6F7-AD2D525CAC00@gmail.com>
Message-ID: <AANLkTin1rf1nZqtPpEGeGHX6PRVVfsw7W9_jbu5-x9gZ@mail.gmail.com>

2011/3/21 Raymond Hettinger <raymond.hettinger at gmail.com>:
>
> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>
> People love it because it's a very powerful tool. ?People hate it because it
> allows you to shoot yourself in the foot.
>
> There's a certain irony in this. ? The original motivation for version
> control
> was to be a safety rope, to serve as a productivity tool to make sure
> that work never got lost.
> Now we seem to be advocating a complex, fragile workflow that
> is hard to learn, hard to get right, that let's you shoot yourself in
> the foot,?and that has rebasing/collapsing steps that destroy and
> rewrite?history (an possibly muck-up your repo if there was an
> intervening push).
> If we gave-up on the "svnmerge on steroids workflow",
> the use of Hg would become dirt simple. ? I've used it that way
> in personal projects for a couple months and it is
> remarkably?easy, taking only minutes to learn.
> It also works with Hg right out of the box; no need
> for extensions, customizations, or a slew of advanced Hg
> features.

Python, though, is not your run-of-the-mill pet project. There's
always going to be a learning curve into its development.



-- 
Regards,
Benjamin

From timothy.c.delaney at gmail.com  Mon Mar 21 22:20:40 2011
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Tue, 22 Mar 2011 08:20:40 +1100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <87wrjs456h.fsf@benfinney.id.au>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
Message-ID: <AANLkTikQHPiqbmVpVOe9GuDj+DJR5pM1RGiX8tgaor8p@mail.gmail.com>

On 2011-03-22, Ben Finney <ben+python at benfinney.id.au> wrote:

> That seems to me the ideal: preserve all revision history for those
> cases when some user will care about it, but *present* history cleanly
> by default.
>
> Whether adding support in Mercurial or Git for similar
> clean-presentation-by-default would obviate the need for rewriting
> history, I can't tell.

That's my thought as well - it's the presentation that makes things
difficult for people. I'm used to it (having used ClearCase for many
years before Mercurial) but I do find the presentation suboptimal.

I've recently been thinking about prototyping a "mainline" option for
hgrc that the various hg commands would follow (starting with hg log
and glog). Something like:

mainline = default, 3.3, 3.2, 2.7, 3.1, 3.0, 2.6, 2.5

defaulting to:

mainline = default

All hg commands would aquire an "operate on all branches" option.

The algorithm for hg log would be fairly trivial to change, but hg
glog would be a significant departure (and so would the hgweb log view
- I've played with this before and it's non-trivial).

The idea for glog and hgweb log would be to straight lines for the
mainlines wherever possible (multiple heads on the same mainline
branch would obviously cause deviations). The order the branches are
listed in the "mainline" option would be the order to display the
branches (so you could ensure that your current version was displayed
first). Merges would be indicated with a separate symbol and the name
of the branch that was merged. Similarly, when viewing all branches,
keeping a straight line would be similarly important.

You'd end up using more horizontal space, but we all seem to have
widescreen monitors these days.

From barry at python.org  Mon Mar 21 22:25:05 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Mar 2011 17:25:05 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110321215326.0767c775@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
Message-ID: <20110321172505.33b3d507@neurotica.wooz.org>

On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:

>I'd rather take a look at the final aggregate patch to see if it looks
>correct, actually. It's easy to have incremental changes which look
>good but lead to a questionable patch in the end. Better to review it
>in aggregate, IMO.

I think it would be good to have the option to do either.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/58b159ef/attachment.pgp>

From solipsis at pitrou.net  Mon Mar 21 22:31:53 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 22:31:53 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
	<20110321172505.33b3d507@neurotica.wooz.org>
Message-ID: <20110321223153.1a0128ed@pitrou.net>

On Mon, 21 Mar 2011 17:25:05 -0400
Barry Warsaw <barry at python.org> wrote:
> On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
> 
> >I'd rather take a look at the final aggregate patch to see if it looks
> >correct, actually. It's easy to have incremental changes which look
> >good but lead to a questionable patch in the end. Better to review it
> >in aggregate, IMO.
> 
> I think it would be good to have the option to do either.

Technically, nothing prevents anyone from committing many small
changesets representing incomplete development. It's just that it
pollutes history, similarly as it polluted history with SVN.

Regards

Antoine.



From ncoghlan at gmail.com  Mon Mar 21 22:32:33 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Mar 2011 07:32:33 +1000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <2BCDC99C-B199-4959-9404-51F0E12F7420@gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
	<20110321112531.0c98a191@limelight.wooz.org>
	<2BCDC99C-B199-4959-9404-51F0E12F7420@gmail.com>
Message-ID: <AANLkTikOiiF_pv9ih3n44m_Jwm_vnDvT-o_SkbKHXtsG@mail.gmail.com>

On Tue, Mar 22, 2011 at 3:16 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> I don't think that is the main source of complexity.
> The more difficult and fragile part of the workflows are:
> * requiring commits to be cross-linked between branches
> * and wanting changesets to be collapsed or rebased
> ??(two operations that destroy and rewrite history).

Yep, that sounds about right. I think in the long run the first one
*will* turn out to be a better work flow, but it's definitely quite a
shift from our historical way of doing things.

As far as the second point goes, I'm coming to the view that we should
avoid rebase/strip/rollback when intending to push to the main
repository, and do long term work in *separate* cloned repositories.
Then an rdiff with the relevant cpython branch will create a nice
collapsed patch ready for application to the main repository (I have
yet to succeed in generating a nice patch without using rdiff, but I
still have some more experimentation to do with MvL's last proposed
command for that before giving up on the idea).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Mon Mar 21 22:47:19 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 22:47:19 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <ECD3C64A-3930-4065-A6F7-AD2D525CAC00@gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<ECD3C64A-3930-4065-A6F7-AD2D525CAC00@gmail.com>
Message-ID: <4D87C767.1060302@v.loewis.de>

> ISTM, there has been substantial mission creep from 
> the workflow described in the PEP.  If the current workflow
> had been described there, I don't think it would have been
> readily accepted.

I don't think PEP 385 actually *was* accepted at all (PEP 374
was, selecting Mercurial). I had meant to insist on a formal
review of the PEP, but gave up on that due to the time pressure
to complete the conversion before PyCon.

Some of the open issues of the PEP are actually still open.

Regards,
Martin

From martin at v.loewis.de  Mon Mar 21 22:48:56 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 21 Mar 2011 22:48:56 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <4D87331A.4000306@arbash-meinel.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D871DE1.6020307@v.loewis.de>
	<4D87331A.4000306@arbash-meinel.com>
Message-ID: <4D87C7C8.8020106@v.loewis.de>

> It does so at the *tree* level, not at an individual file level.

Thanks - I stand corrected. I was thinking about the file level only (at
which it doesn't do server-side merging - right?).

Regards,
Martin

From guido at python.org  Mon Mar 21 22:51:37 2011
From: guido at python.org (Guido van Rossum)
Date: Mon, 21 Mar 2011 14:51:37 -0700
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110321223153.1a0128ed@pitrou.net>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
	<20110321172505.33b3d507@neurotica.wooz.org>
	<20110321223153.1a0128ed@pitrou.net>
Message-ID: <AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>

On Mon, Mar 21, 2011 at 2:31 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 21 Mar 2011 17:25:05 -0400
> Barry Warsaw <barry at python.org> wrote:
>> On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
>>
>> >I'd rather take a look at the final aggregate patch to see if it looks
>> >correct, actually. It's easy to have incremental changes which look
>> >good but lead to a questionable patch in the end. Better to review it
>> >in aggregate, IMO.
>>
>> I think it would be good to have the option to do either.
>
> Technically, nothing prevents anyone from committing many small
> changesets representing incomplete development. It's just that it
> pollutes history, similarly as it polluted history with SVN.

But what the best/right thing to do? Consider the following very
common scenario.

Let's say I'm working on a fairly substantial feature that may take
weeks to complete. My way of working is to explore different
approaches until I'm happy. I like to make checkpoints while I'm
exploring so that I can easily backtrack from experiments. I'm not
pushing any of this to the central repo; I'm just using a local repo.
Over a few weeks this can easily lead to 100+ commits. Occasionally I
push patches to Rietveld for review. When my reviewer and me are happy
we want to push my work to the core repo. But do you really want my
100 commits (many of which represent dead ends) in the core repo? Many
of them probably have checkin messages that make no sense to anyone.

I know I would be sorely tempted to use hg export + hg import (and
extensive testing after the latter of course) so that the approved
changes can land with a single thud in the core repo. But maybe I'm a
dinosaur?

-- 
--Guido van Rossum (python.org/~guido)

From ncoghlan at gmail.com  Mon Mar 21 22:56:28 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Mar 2011 07:56:28 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110321172505.33b3d507@neurotica.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
	<20110321172505.33b3d507@neurotica.wooz.org>
Message-ID: <AANLkTin_Cm8Wf9g=an3AXcQE8Wp=406dSErUzQWy-piE@mail.gmail.com>

On Tue, Mar 22, 2011 at 7:25 AM, Barry Warsaw <barry at python.org> wrote:
> On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
>
>>I'd rather take a look at the final aggregate patch to see if it looks
>>correct, actually. It's easy to have incremental changes which look
>>good but lead to a questionable patch in the end. Better to review it
>>in aggregate, IMO.
>
> I think it would be good to have the option to do either.

One of the key elements here is the way we use python-checkins for
after-the-fact review. That works a *lot* better when changes land in
cohesive chunks. Maybe that's a low-tech technique which isn't up with
the latest snazzy DVCS features, but it's certainly served us well for
a long time and should be preserved if possible.

However, keeping the history clean should come a distant second to
keeping it *correct*, so I now believe we should actively discourage
use of the history editing extensions when working on changes intended
to be pushed to the main repository.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Mon Mar 21 22:58:14 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 22:58:14 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
	<20110321112531.0c98a191@limelight.wooz.org>
	<2BCDC99C-B199-4959-9404-51F0E12F7420@gmail.com>
	<AANLkTikOiiF_pv9ih3n44m_Jwm_vnDvT-o_SkbKHXtsG@mail.gmail.com>
Message-ID: <20110321225814.33a3f3ea@pitrou.net>

On Tue, 22 Mar 2011 07:32:33 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> As far as the second point goes, I'm coming to the view that we should
> avoid rebase/strip/rollback when intending to push to the main
> repository, and do long term work in *separate* cloned repositories.
> Then an rdiff with the relevant cpython branch will create a nice
> collapsed patch ready for application to the main repository (I have
> yet to succeed in generating a nice patch without using rdiff, but I
> still have some more experimentation to do with MvL's last proposed
> command for that before giving up on the idea).

If you use named branches it's very easy, as explained in the devguide:
http://docs.python.org/devguide/committing.html#long-term-development-of-features

Regards

Antoine.



From solipsis at pitrou.net  Mon Mar 21 22:58:57 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 22:58:57 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<ECD3C64A-3930-4065-A6F7-AD2D525CAC00@gmail.com>
	<4D87C767.1060302@v.loewis.de>
Message-ID: <20110321225857.0e710eb8@pitrou.net>

On Mon, 21 Mar 2011 22:47:19 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> > ISTM, there has been substantial mission creep from 
> > the workflow described in the PEP.  If the current workflow
> > had been described there, I don't think it would have been
> > readily accepted.
> 
> I don't think PEP 385 actually *was* accepted at all (PEP 374
> was, selecting Mercurial). I had meant to insist on a formal
> review of the PEP, but gave up on that due to the time pressure
> to complete the conversion before PyCon.

I don't think a formal review of the PEP would have brought any of the
points which have been made after (or even during) the conversion.

Regards

Antoine.



From ncoghlan at gmail.com  Mon Mar 21 23:00:33 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Mar 2011 08:00:33 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
	<20110321172505.33b3d507@neurotica.wooz.org>
	<20110321223153.1a0128ed@pitrou.net>
	<AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>
Message-ID: <AANLkTi=fzNV8JO_WwnGey-6BEHVCkWJMgJKZba6cr+p0@mail.gmail.com>

On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum <guido at python.org> wrote:
> Let's say I'm working on a fairly substantial feature that may take
> weeks to complete. My way of working is to explore different
> approaches until I'm happy. I like to make checkpoints while I'm
> exploring so that I can easily backtrack from experiments. I'm not
> pushing any of this to the central repo; I'm just using a local repo.
> Over a few weeks this can easily lead to 100+ commits. Occasionally I
> push patches to Rietveld for review. When my reviewer and me are happy
> we want to push my work to the core repo. But do you really want my
> 100 commits (many of which represent dead ends) in the core repo? Many
> of them probably have checkin messages that make no sense to anyone.
>
> I know I would be sorely tempted to use hg export + hg import (and
> extensive testing after the latter of course) so that the approved
> changes can land with a single thud in the core repo. But maybe I'm a
> dinosaur?

I don't think so. That line of reasoning is why one of the first
things I did after the transition was complete was to create a
personal sandbox repository on hg.python.org (using the server side
clone feature in the web interface). Any long term work will be done
on feature branches there (e.g. that's where the LHS precedence work
currently lives), with the "main" repository used only for applying
completed patches.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Mon Mar 21 23:00:25 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 23:00:25 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <2BCDC99C-B199-4959-9404-51F0E12F7420@gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>
	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<19847.13078.526390.539879@montanaro.dyndns.org>	<20110321112531.0c98a191@limelight.wooz.org>
	<2BCDC99C-B199-4959-9404-51F0E12F7420@gmail.com>
Message-ID: <4D87CA79.1010509@v.loewis.de>

> I don't think that is the main source of complexity.
> 
> The more difficult and fragile part of the workflows are:
> * requiring commits to be cross-linked between branches
> * and wanting changesets to be collapsed or rebased
>   (two operations that destroy and rewrite history).

I think there would be no technical problems with
giving up the latter - it's just an expression of personal
taste that the devguide says what it says.

As for the former, I think it objectively improves the quality of the
maintenance releases to have "managed backports", i.e. tracking that
fixes are actually similar and correlated across branches.

If you find this too complex to manage, one option would be to opt
out of "backporting", i.e. apply changes only to the most recent
branches. In many cases, the harm done by not backporting a fix
is rather small - the bug may only affect only infrequent cases,
or many users may be using a different branch, anyway. Others could
then still backport the change if they consider it important (and
do a subsequent "null merge" to properly link the backport).

Regards,
Martin

From guido at python.org  Mon Mar 21 23:03:41 2011
From: guido at python.org (Guido van Rossum)
Date: Mon, 21 Mar 2011 15:03:41 -0700
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTi=fzNV8JO_WwnGey-6BEHVCkWJMgJKZba6cr+p0@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
	<20110321172505.33b3d507@neurotica.wooz.org>
	<20110321223153.1a0128ed@pitrou.net>
	<AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>
	<AANLkTi=fzNV8JO_WwnGey-6BEHVCkWJMgJKZba6cr+p0@mail.gmail.com>
Message-ID: <AANLkTin=izAXGKgPJxPkpbaO=7SSLvGO4eQcZvvhKK8=@mail.gmail.com>

On Mon, Mar 21, 2011 at 3:00 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum <guido at python.org> wrote:
>> Let's say I'm working on a fairly substantial feature that may take
>> weeks to complete. My way of working is to explore different
>> approaches until I'm happy. I like to make checkpoints while I'm
>> exploring so that I can easily backtrack from experiments. I'm not
>> pushing any of this to the central repo; I'm just using a local repo.
>> Over a few weeks this can easily lead to 100+ commits. Occasionally I
>> push patches to Rietveld for review. When my reviewer and me are happy
>> we want to push my work to the core repo. But do you really want my
>> 100 commits (many of which represent dead ends) in the core repo? Many
>> of them probably have checkin messages that make no sense to anyone.
>>
>> I know I would be sorely tempted to use hg export + hg import (and
>> extensive testing after the latter of course) so that the approved
>> changes can land with a single thud in the core repo. But maybe I'm a
>> dinosaur?
>
> I don't think so. That line of reasoning is why one of the first
> things I did after the transition was complete was to create a
> personal sandbox repository on hg.python.org (using the server side
> clone feature in the web interface). Any long term work will be done
> on feature branches there (e.g. that's where the LHS precedence work
> currently lives), with the "main" repository used only for applying
> completed patches.

Ah. I just discovered
http://docs.python.org/devguide/committing.html#long-term-development-of-features
which explains how to do this (it came up in the other thread :-). So
my use case is perfectly covered. Great!

-- 
--Guido van Rossum (python.org/~guido)

From nadeem.vawda at gmail.com  Mon Mar 21 23:06:47 2011
From: nadeem.vawda at gmail.com (Nadeem Vawda)
Date: Tue, 22 Mar 2011 00:06:47 +0200
Subject: [Python-Dev] Copyright notices
In-Reply-To: <20110321154840.276000c6@pitrou.net>
References: <AANLkTimEqTPhSBhfRXWJa5cpitFLms_XqrYaebTtpann@mail.gmail.com>
	<4D8742AB.3050701@egenix.com> <20110321154840.276000c6@pitrou.net>
Message-ID: <AANLkTik=urJJ0HNnHnYZ9_mARWu_6GefwfeBTH7SuVf9@mail.gmail.com>

On Mon, Mar 21, 2011 at 2:20 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> Nadeem Vawda wrote:
>> [snip]
>
> Since you'll be adding new IP to Python, the new code you write should
> contain your copyright and the standard PSF contributor agreement
> notice, e.g.
>
> """
> (c) Copyright 2011 by Nadeem Vawda. Licensed to PSF under a Contributor Agreement.
> """
>
> (please also make sure you have sent the signed agreement to the PSF;
> see http://www.python.org/psf/contrib/)
>
> We don't have a general copyright or license boiler plate for Python
> source files.
>
>> [snip]
>
> If the file copies significant code parts from older files, the
> copyright notices from those files will have to added to the
> file comment as well - ideally with a note explaining to which parts
> those copyrights apply and where they originated.
>
> If you are replacing the old implementation with a new one,
> you don't need to copy over the old copyright statements.

Thanks for the information. I still need to submit a Contributor Agreement, so
I'll do that as soon as possible.

(As an aside, it might be useful to include this info more explicitly in the
devguide, to make it easier for newbies to find. I'll put together a patch
when I get a chance.)

On Mon, Mar 21, 2011 at 4:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 21 Mar 2011 13:20:59 +0100
> "M.-A. Lemburg" <mal at egenix.com> wrote:
>> Since you'll be adding new IP to Python, the new code you write should
>> contain your copyright and the standard PSF contributor agreement
>> notice, e.g.
>
> I agree with Raymond's argument that we shouldn't add *new* copyright
> boilerplate:
> http://mail.python.org/pipermail/python-dev/2009-January/085267.html

I agree that it would be preferable not to clutter the code with copyright
notices unnecessarily, especially since you can get the same information from
the version control history. However, as things stand, the CA requires their
inclusion, and changing it would (I imagine) involve a lot of work.

Regards,
Nadeem

From martin at v.loewis.de  Mon Mar 21 23:09:43 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 23:09:43 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<20110321180740.27947057@pitrou.net>	<20110321142954.4e301fb2@limelight.wooz.org>	<20110321193818.66fee202@pitrou.net>	<20110321163331.4277ffd0@limelight.wooz.org>	<20110321215326.0767c775@pitrou.net>	<20110321172505.33b3d507@neurotica.wooz.org>	<20110321223153.1a0128ed@pitrou.net>
	<AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>
Message-ID: <4D87CCA7.40002@v.loewis.de>

> I know I would be sorely tempted to use hg export + hg import (and
> extensive testing after the latter of course) so that the approved
> changes can land with a single thud in the core repo. But maybe I'm a
> dinosaur?

I certainly agree that there are cases where collapsing changes is
desirable - in particular when the author of the changes thinks it is.

However, what some of us requesting is that the "SHOULD collapse"
in the devguide is changed to a "MAY collapse", making it strictly
an option of the committer. If there is one substantial change,
a typo change, and three merges, asking for a collapse of the typo
change is IMO complicating things too much.

OTOH, collapsing weeks of work isn't that much overhead, relatively.
Plus you may want to push the feature branch to hg.python.org/guido,
so that people can still look at it if they want to.

Regards,
Martin


From solipsis at pitrou.net  Mon Mar 21 23:15:38 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 23:15:38 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87CCA7.40002@v.loewis.de>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
	<20110321172505.33b3d507@neurotica.wooz.org>
	<20110321223153.1a0128ed@pitrou.net>
	<AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>
	<4D87CCA7.40002@v.loewis.de>
Message-ID: <1300745738.3516.13.camel@localhost.localdomain>


> However, what some of us requesting is that the "SHOULD collapse"
> in the devguide is changed to a "MAY collapse", making it strictly
> an option of the committer. If there is one substantial change,
> a typo change, and three merges, asking for a collapse of the typo
> change is IMO complicating things too much.

Well, it's "should", not "must" ;)
When writing this, I had in mind that other projects have different
workflows, where indeed people never collapse and many tiny changesets
(which are only significant as part of a bigger work) end up in the main
history. The point is to signal that it's not how we work.

Regards

Antoine.



From martin at v.loewis.de  Mon Mar 21 23:16:35 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 23:16:35 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTin_Cm8Wf9g=an3AXcQE8Wp=406dSErUzQWy-piE@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<20110321180740.27947057@pitrou.net>	<20110321142954.4e301fb2@limelight.wooz.org>	<20110321193818.66fee202@pitrou.net>	<20110321163331.4277ffd0@limelight.wooz.org>	<20110321215326.0767c775@pitrou.net>	<20110321172505.33b3d507@neurotica.wooz.org>
	<AANLkTin_Cm8Wf9g=an3AXcQE8Wp=406dSErUzQWy-piE@mail.gmail.com>
Message-ID: <4D87CE43.1010403@v.loewis.de>

> One of the key elements here is the way we use python-checkins for
> after-the-fact review.

I think this can be achieved with a better email hook. I would propose
that there will be one email message per push per branch (rather than
one per changeset). For each branch, it should report what changesets
contributed, and what the final diff between the old head of the branch
and the new head of the branch is.

Or perhaps put the diffs into attachments, one per branch.

Or perhaps suppress the diffs for the branches if the only changesets
on the branches are merges.

In the rare case that a single push includes unrelated changes, people
can still look at the individual changesets in the repo to figure it all
out.

Regards,
Martin

From fijall at gmail.com  Mon Mar 21 23:21:35 2011
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 21 Mar 2011 16:21:35 -0600
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <AANLkTinvBcL63zJcZVjAOSws=iqdvF9+zZq=Uned392k@mail.gmail.com>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
	<AANLkTinvBcL63zJcZVjAOSws=iqdvF9+zZq=Uned392k@mail.gmail.com>
Message-ID: <AANLkTimcCRPS=xtJHqCcqpLnVH7L1k+t6Wf-P6VD-U-y@mail.gmail.com>

On Mon, Mar 21, 2011 at 2:24 PM, DasIch <dasdasich at googlemail.com> wrote:
> On Mon, Mar 21, 2011 at 7:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Mon, 21 Mar 2011 19:33:55 +0100
>> DasIch <dasdasich at googlemail.com> wrote:
>>>
>>> 3. Several benchmarks (at least the Django and Twisted ones) have
>>> dependencies which are not (yet) ported to 3.x and porting those
>>> dependencies during GSoC as part of this project is an unrealistic
>>> goal. Should those benchmarks, at least for now, be ignored?
>>
>> Why not reuse the benchmarks in http://hg.python.org/benchmarks/ ?
>> Many of them are 3.x-compatible.
>> I don't understand why people are working on multiple benchmark suites
>> without cooperating these days.
>
> I haven't looked to closely but those benchmarks appear to be the ones
> developed by the unladen swallow guys and those are used by PyPy among
> others.
>
> The difference is that PyPy has more benchmarks particularly ones that
> measure performance of real world applications. As good benchmarks are
> very hard to come by those appear to be a better starting point.

The benchmark running code didn't change significantly. The actual
benchmarks however did. US's micro-benchmarks were removed and new
things were added (the biggest addition is probably the whole set of
twisted benchmarks). The original idea was to converge and have the
common repo on hg.python.org, but since unladen run out of steam,
nobody bothered to update the hg.python.org one so we continued on our
own.

Cheers,
fijal

From mhammond at skippinet.com.au  Mon Mar 21 23:22:32 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 22 Mar 2011 09:22:32 +1100
Subject: [Python-Dev] Draft PEP and reference implementation of a Python
 launcher for Windows
In-Reply-To: <AANLkTim_N=45eBUcnw0T59=gDr05HyxTEF6npuHhsyn0@mail.gmail.com>
References: <4D8446E0.7030401@skippinet.com.au>
	<4D84FAB8.3040301@v.loewis.de>	<4D856DCB.5000600@skippinet.com.au>
	<4D85CACA.1070400@v.loewis.de>	<4D85D637.3040403@skippinet.com.au>	<4D866EAC.8050701@skippinet.com.au>	<4D86913E.7010407@canterbury.ac.nz>
	<4D8698AC.2070908@v.loewis.de>	<4D86A539.1050004@skippinet.com.au>
	<4D86A99E.9060908@v.loewis.de>	<4D86AFB8.4040006@skippinet.com.au>
	<AANLkTim_N=45eBUcnw0T59=gDr05HyxTEF6npuHhsyn0@mail.gmail.com>
Message-ID: <4D87CFA8.9080800@skippinet.com.au>

On 22/03/2011 12:04 AM, Paul Moore wrote:
> I haven't had time to read the PEP yet, so my apologies if this is
> made explicit there, but is the launcher expected to be solely for
> implementing file associations? I thought there had been discussions
> of using it to start the interactive interpreter, and for it having
> command line arguments (implying direct command line usage). If it can
> be used directly, there are many other scenarios that might be
> impacted. Consider a service implemented using SRVANY which uses the
> launcher. Stopping the service kills the launcher, leaving Python (and
> the script, ie the service) running...

The intention is for the script to be used to interactively start a 
Python interpreter for the convenience of the developers working 
interactively.  It is not intended to replace all current uses of 
python.exe though, hence the different name.

Problems with things like SVRANY will be caused if those things use file 
associations to implicitly launch the executable associated with .py 
files - but those problems are caused by having py.exe associated with 
.py files, not with the fact that py.exe can also be used to launch 
python interactively.  IOW, SVRANY type use-cases should continue to use 
python.exe.  If problems are caused due to the change in associations, 
those problems would be caused even if py.exe did not have facilities 
designed for interactive use.

FWIW, I do accept that if an in-process model was used there may be less 
problems if use-cases like SVRANY happened to use py.exe, so should be 
supported if possible.  But while updating the PEP last night to 
reference 64bit and 32bit considerations, this idea hit another snag.  I 
changed the PEP to say:

     On 64bit Windows with both 32bit and 64bit implementations of the
     same (major.minor) Python version installed, the 64bit version will
     always be preferred.  This will be true for both 32bit and 64bit
     implementations of the launcher - a 32bit launcher will prefer to
     execute a 64bit Python installation of the same version if
     available.  This is so the behaviour of the launcher can be
     predicted knowing only what versions are installed on the PC and
     without regard to the order in which they were installed.

I think that is sensible as needing to know the order of past 
installations to predict the behaviour is undesirable.  However, that 
would also be impossible to achieve in an in-process model - a 32bit 
launcher could not load a 64bit Python into its process, and vice-versa. 
  Even if the wording of the above paragraph changes, if there remains a 
case where a 64bit launcher needs to load a 32bit Python or vice-versa, 
the same issue will arise.

I'm starting to think the only reasonable compromise will be to use 
child processes but use the win32 "job" API to arrange for Windows to 
kill the child should be the parent be killed - this will need more 
research and experimentation though - see 
http://msdn.microsoft.com/en-us/library/ms684161%28v=vs.85%29.aspx for 
an overview.

Cheers,

Mark

From solipsis at pitrou.net  Mon Mar 21 23:27:01 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Mar 2011 23:27:01 +0100
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <AANLkTimcCRPS=xtJHqCcqpLnVH7L1k+t6Wf-P6VD-U-y@mail.gmail.com>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
	<AANLkTinvBcL63zJcZVjAOSws=iqdvF9+zZq=Uned392k@mail.gmail.com>
	<AANLkTimcCRPS=xtJHqCcqpLnVH7L1k+t6Wf-P6VD-U-y@mail.gmail.com>
Message-ID: <1300746421.3516.16.camel@localhost.localdomain>

Le lundi 21 mars 2011 ? 16:21 -0600, Maciej Fijalkowski a ?crit :
> The original idea was to converge and have the
> common repo on hg.python.org, but since unladen run out of steam,
> nobody bothered to update the hg.python.org one so we continued on our
> own.

I'm not sure who is "nobody" in that statement...
The repo certainly didn't receive a lot of changes, but it *did* get
several of them anyway, post-unladen:
http://hg.python.org/benchmarks/

Regards

Antoine.



From ncoghlan at gmail.com  Mon Mar 21 23:27:13 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Mar 2011 08:27:13 +1000
Subject: [Python-Dev] [Python-checkins] cpython: Prepare for move of
	email tests.
In-Reply-To: <E1Q1lIE-0003Zl-Tq@dinsdale.python.org>
References: <E1Q1lIE-0003Zl-Tq@dinsdale.python.org>
Message-ID: <AANLkTikzY0PfOSTKX__7vMKwPzs18eV8mNrU9wAvtYZQ@mail.gmail.com>

On Tue, Mar 22, 2011 at 6:01 AM, r.david.murray
<python-checkins at python.org> wrote:
> http://hg.python.org/cpython/rev/7d5d859c959e
> changeset: ? 68817:7d5d859c959e
> user: ? ? ? ?R David Murray <rdmurray at bitdance.com>
> date: ? ? ? ?Mon Mar 21 16:01:23 2011 -0400
> summary:
> ?Prepare for move of email tests.
>
> files:
> ?.hgeol
>
> diff --git a/.hgeol b/.hgeol
> --- a/.hgeol
> +++ b/.hgeol
> @@ -27,6 +27,7 @@
> ?**.zip ?= BIN
>
> ?Lib/email/test/data/msg_26.txt = BIN
> +Lib/test/test_email/data/msg_26.txt = BIN
> ?Lib/test/sndhdrdata/sndhdr.* = BIN
> ?Lib/test/decimaltestdata/*.decTest = BIN

If any else gets errors from the EOL hook attempting to merge the
email test changes to a separate repository, make sure to do a "hg
push -f -r <rev>" for this revision before pushing the rest of the
changes.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Mon Mar 21 23:29:49 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 23:29:49 +0100
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <AANLkTikoXhUfkuUPPT+xfJ0ZvMkU8vFn5VUSjp+rnrAL@mail.gmail.com>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<AANLkTikoXhUfkuUPPT+xfJ0ZvMkU8vFn5VUSjp+rnrAL@mail.gmail.com>
Message-ID: <4D87D15D.80104@v.loewis.de>

>> 3. Several benchmarks (at least the Django and Twisted ones) have
>> dependencies which are not (yet) ported to 3.x and porting those
>> dependencies during GSoC as part of this project is an unrealistic
>> goal. Should those benchmarks, at least for now, be ignored?
>>
> 
> IMHO: Yes. I think MvL can expand on this as well.

Indeed. It is, in fact, not true that Django hasn't been ported to
Python 3. So anybody porting the benchmark should IMO also consider
the Django ones. For the Twisted ones, I think some progress was
made at PyCon, but I don't know what the status is.

But in general, Jesse is right: if there is an external dependency
that hasn't been ported to Python 3 yet, that should rather be
a GSoC project of its own (assuming the project maintainers agree
to then integrate the project results).

>> [1]: http://wiki.python.org/moin/SpeedDotPythonDotOrg
> 
> FYI, I recommend coordinating with Miquel Torres (cc'ed) and Maciej
> Fijalkowski from PyPy on these questions / this project as well. I am
> currently coordinating getting the hardware setup for this project's
> hosting.

I also agree that the GSoC project should focus on the coding/porting
part. Setting up infrastructure is not a good GSoC project, as this
is rather a long-term commitment to keep it running.

Regards,
Martin

From martin at v.loewis.de  Mon Mar 21 23:35:30 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 23:35:30 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <1300745738.3516.13.camel@localhost.localdomain>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<20110321180740.27947057@pitrou.net>	<20110321142954.4e301fb2@limelight.wooz.org>	<20110321193818.66fee202@pitrou.net>	<20110321163331.4277ffd0@limelight.wooz.org>	<20110321215326.0767c775@pitrou.net>	<20110321172505.33b3d507@neurotica.wooz.org>	<20110321223153.1a0128ed@pitrou.net>	<AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>	<4D87CCA7.40002@v.loewis.de>
	<1300745738.3516.13.camel@localhost.localdomain>
Message-ID: <4D87D2B2.5060901@v.loewis.de>

> Well, it's "should", not "must" ;)
> When writing this, I had in mind that other projects have different
> workflows, where indeed people never collapse and many tiny changesets
> (which are only significant as part of a bigger work) end up in the main
> history. The point is to signal that it's not how we work.

Having to be nitpicking here "not how you (Antoine) want us to work".
"We" aren't using mercurial long enough to make such a statement.

I still propose to loosen this restriction, and go with that for a
while. Perhaps improve the email hook to give more condensed reports.
If people then complain about too much fine-grainedness, we could
tighten it again.

Regards,
Martin

From martin at v.loewis.de  Mon Mar 21 23:39:43 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 23:39:43 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im82v8$mhb$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>	<im4sb2$lg1$1@dough.gmane.org>	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>	<im5028$7h7$1@dough.gmane.org>	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>	<im5pr1$7da$1@dough.gmane.org>	<AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>	<im7b1a$14l$1@dough.gmane.org>
	<im82v8$mhb$1@dough.gmane.org>
Message-ID: <4D87D3AF.6080607@v.loewis.de>

> Would you say it's worth a GSoC project to get some of the Python stdlib
> modules compiled and/or some of the C modules rewritten in Cython? 

I'm almost as excited as Michael: *if* you can get upfront agreement of
some distribution creator to integrate the code, then it's a great
project. Alternatively, if the project objective would include creating
a Python distribution (even as a source tarball), it would be great.
If it merely transforms some stdlib modules which then get used nowhere,
it is not so great.

Regards,
Martin

From martin at v.loewis.de  Mon Mar 21 23:44:18 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Mar 2011 23:44:18 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <im7b1a$14l$1@dough.gmane.org>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>	<im4sb2$lg1$1@dough.gmane.org>	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>	<im5028$7h7$1@dough.gmane.org>	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>	<im5pr1$7da$1@dough.gmane.org>	<AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>
	<im7b1a$14l$1@dough.gmane.org>
Message-ID: <4D87D4C2.4030101@v.loewis.de>

Am 21.03.2011 11:58, schrieb Stefan Behnel:
> [long post ahead, again]
> 
> Guido van Rossum, 21.03.2011 03:46:
>> Thanks for the clarifications. I now have a much better understanding
>> of what Cython is. But I'm not sold. For one, your attitude about
>> strict language compatibility worries me when it comes to the stdlib.
> 
> Not sure what you mean exactly. Given our large user base, we do worry a
> lot about things like backwards compatibility, for example.
> 
> If you are referring to compatibility with Python, I don't think anyone
> in the project really targets Cython as a a drop-in replacement for a
> Python runtime. We aim to compile Python code, yes, and there's a
> hand-wavy idea in the back of our head that we may want a plain Python
> compatibility mode at some point that will disable several important
> optimisations.

I think that's the attitude Guido worries about: if you don't have the
desire to provide 100% Python compatibility under all circumstances
(i.e. including if someone passes parameters of "incorrect" types),
then there is very little chance that we would replace a Python module
with a Cython-compiled one.

The only exception would be cases where the Python semantics is murky
(e.g. where Jython or so actually behaves differently for the same
 Python code, and still claims language conformance). E.g. the exact
message on a TypeError might change when compiling with Cython,
but the cases in which you get a TypeError must not change.

Regards,
Martin

From steve at pearwood.info  Mon Mar 21 23:53:05 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 22 Mar 2011 09:53:05 +1100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikQHPiqbmVpVOe9GuDj+DJR5pM1RGiX8tgaor8p@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<87wrjs456h.fsf@benfinney.id.au>
	<AANLkTikQHPiqbmVpVOe9GuDj+DJR5pM1RGiX8tgaor8p@mail.gmail.com>
Message-ID: <4D87D6D1.109@pearwood.info>

Tim Delaney wrote:

> You'd end up using more horizontal space, but we all seem to have
> widescreen monitors these days.

Not even close to "we all".


-- 
Steven

From solipsis at pitrou.net  Tue Mar 22 00:02:27 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 22 Mar 2011 00:02:27 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87D2B2.5060901@v.loewis.de>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
	<20110321172505.33b3d507@neurotica.wooz.org>
	<20110321223153.1a0128ed@pitrou.net>
	<AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>
	<4D87CCA7.40002@v.loewis.de>
	<1300745738.3516.13.camel@localhost.localdomain>
	<4D87D2B2.5060901@v.loewis.de>
Message-ID: <20110322000227.6e3aa433@pitrou.net>

On Mon, 21 Mar 2011 23:35:30 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> 
> Having to be nitpicking here "not how you (Antoine) want us to work".
> "We" aren't using mercurial long enough to make such a statement.

Well, being directive and giving strong workflow indications seems to
be what many people are expecting of "us" (aka Georg, I, and the few
other people involved in writing the hg version of the devguide).

> I still propose to loosen this restriction, and go with that for a
> while. Perhaps improve the email hook to give more condensed reports.

The buildbot hook must then also be changed to only consider
the changegroup heads. It should be quite simple except that modified
files must be computed accross the whole bunch of ancestor changsets in
the changegroup (should be doable in the same step that computes the
heads).

Both the hooks and the devguide are modifiable by anyone (*), of course.

(*) with push access

Regards

Antoine.

From guido at python.org  Tue Mar 22 00:04:56 2011
From: guido at python.org (Guido van Rossum)
Date: Mon, 21 Mar 2011 16:04:56 -0700
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <4D87D4C2.4030101@v.loewis.de>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>
	<im4nrg$ph$1@dough.gmane.org>
	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>
	<20110320124049.70610337@pitrou.net> <im4sb2$lg1$1@dough.gmane.org>
	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>
	<im5028$7h7$1@dough.gmane.org>
	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>
	<im5pr1$7da$1@dough.gmane.org>
	<AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>
	<im7b1a$14l$1@dough.gmane.org> <4D87D4C2.4030101@v.loewis.de>
Message-ID: <AANLkTik2CGSW9yAhzJBX4-UFrh1YrMHVVhHwj4T8C1c1@mail.gmail.com>

On Mon, Mar 21, 2011 at 3:44 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 21.03.2011 11:58, schrieb Stefan Behnel:
>> [long post ahead, again]
>>
>> Guido van Rossum, 21.03.2011 03:46:
>>> Thanks for the clarifications. I now have a much better understanding
>>> of what Cython is. But I'm not sold. For one, your attitude about
>>> strict language compatibility worries me when it comes to the stdlib.
>>
>> Not sure what you mean exactly. Given our large user base, we do worry a
>> lot about things like backwards compatibility, for example.
>>
>> If you are referring to compatibility with Python, I don't think anyone
>> in the project really targets Cython as a a drop-in replacement for a
>> Python runtime. We aim to compile Python code, yes, and there's a
>> hand-wavy idea in the back of our head that we may want a plain Python
>> compatibility mode at some point that will disable several important
>> optimisations.
>
> I think that's the attitude Guido worries about: if you don't have the
> desire to provide 100% Python compatibility under all circumstances
> (i.e. including if someone passes parameters of "incorrect" types),
> then there is very little chance that we would replace a Python module
> with a Cython-compiled one.
>
> The only exception would be cases where the Python semantics is murky
> (e.g. where Jython or so actually behaves differently for the same
> ?Python code, and still claims language conformance). E.g. the exact
> message on a TypeError might change when compiling with Cython,
> but the cases in which you get a TypeError must not change.

One other significant use case is the situation where we have an
optional replacement module written in C (e.g. heapqmodule.c vs.
heapq.py). There are usually many semantic differences between the C
and pure-python module that we don't care about (e.g. monkeypatching
won't work).

The size of Cython as a dependency and its development speed are still
problems though. In general for the core I don't think we want the
repo to contain generated code that can only be regenerated using a
3rd party dependency. (True, we have a few generated files, e.g.
configure; but in that case the generator -- autoconf --  is a
standard installed tool on Linux and is used by most open source
projects.)

Still, I think it would be great if someone tried something like this
for a specific stdlib module and came back with a story about the
experience, rather than having a theoretical discussion about possible
pros and cons.

-- 
--Guido van Rossum (python.org/~guido)

From fijall at gmail.com  Tue Mar 22 00:06:09 2011
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 21 Mar 2011 17:06:09 -0600
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <1300746421.3516.16.camel@localhost.localdomain>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
	<AANLkTinvBcL63zJcZVjAOSws=iqdvF9+zZq=Uned392k@mail.gmail.com>
	<AANLkTimcCRPS=xtJHqCcqpLnVH7L1k+t6Wf-P6VD-U-y@mail.gmail.com>
	<1300746421.3516.16.camel@localhost.localdomain>
Message-ID: <AANLkTimF-WFyN8cCOrPiXp-_ortdyGXHPAcaeLBgDqQj@mail.gmail.com>

On Mon, Mar 21, 2011 at 4:27 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le lundi 21 mars 2011 ? 16:21 -0600, Maciej Fijalkowski a ?crit :
>> The original idea was to converge and have the
>> common repo on hg.python.org, but since unladen run out of steam,
>> nobody bothered to update the hg.python.org one so we continued on our
>> own.
>
> I'm not sure who is "nobody" in that statement...
> The repo certainly didn't receive a lot of changes, but it *did* get
> several of them anyway, post-unladen:
> http://hg.python.org/benchmarks/

Ok.

Indeed, sorry, I didn't follow too closely. It's worth considering
what would be the obvious next goal. This repo changed (and I believe
you're the main person according to the change log) to provide python
3 support. On the other hand our repo changed to accomodate changes
that were required to push it to speed.pypy.org as well as adding lots
of new benchmarks. What's the desired goal of this repo then?

Cheers,
fijal

>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

From rndblnch at gmail.com  Tue Mar 22 00:06:21 2011
From: rndblnch at gmail.com (rndblnch)
Date: Mon, 21 Mar 2011 23:06:21 +0000 (UTC)
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
	<4D6AB409.40001@canterbury.ac.nz>
Message-ID: <loom.20110322T000609-760@post.gmane.org>

Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:
> Guido van Rossum wrote:
> > Ok. Will you hvae time to port your patches to 3.3?
> I'm not sure -- I'll see what I can do.

If this can help, I have written a script that transforms greg's patch into a
patch that applies on cpython current tip.
The script is available here:
http://iihm.imag.fr/blanch/misc/pep380_transform.py

Hope this will help to get pep 380 into Python 3.3...
If I can help to make it happend in any way, don't hesitate to ask, I really
would like to finally have it and start playing with "yield from" :)

renaud
 




From solipsis at pitrou.net  Tue Mar 22 00:20:57 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 22 Mar 2011 00:20:57 +0100
Subject: [Python-Dev] GSoC: speed.python.org
In-Reply-To: <AANLkTimF-WFyN8cCOrPiXp-_ortdyGXHPAcaeLBgDqQj@mail.gmail.com>
References: <AANLkTinWOniHA7L==3AQkwAgjhgBr7T1ZyPURmFqGp8h@mail.gmail.com>
	<20110321194848.64ad8abb@pitrou.net>
	<AANLkTinvBcL63zJcZVjAOSws=iqdvF9+zZq=Uned392k@mail.gmail.com>
	<AANLkTimcCRPS=xtJHqCcqpLnVH7L1k+t6Wf-P6VD-U-y@mail.gmail.com>
	<1300746421.3516.16.camel@localhost.localdomain>
	<AANLkTimF-WFyN8cCOrPiXp-_ortdyGXHPAcaeLBgDqQj@mail.gmail.com>
Message-ID: <20110322002057.21064ae0@pitrou.net>

On Mon, 21 Mar 2011 17:06:09 -0600
Maciej Fijalkowski <fijall at gmail.com> wrote:
> 
> Indeed, sorry, I didn't follow too closely. It's worth considering
> what would be the obvious next goal. This repo changed (and I believe
> you're the main person according to the change log) to provide python
> 3 support. On the other hand our repo changed to accomodate changes
> that were required to push it to speed.pypy.org as well as adding lots
> of new benchmarks. What's the desired goal of this repo then?

AFAIR, the goal when it was created was precisely to share a benchmark
suite accross VMs, instead of having many efforts scattered around.
You'd have to ask whoever created the repo on hg.python.org, though.

It should not be difficult to reconcile changes anyway. I think you have
push rights on hg.python.org :)

Regards

Antoine.

From guido at python.org  Tue Mar 22 00:21:39 2011
From: guido at python.org (Guido van Rossum)
Date: Mon, 21 Mar 2011 16:21:39 -0700
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
In-Reply-To: <loom.20110322T000609-760@post.gmane.org>
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
	<4D6AB409.40001@canterbury.ac.nz>
	<loom.20110322T000609-760@post.gmane.org>
Message-ID: <AANLkTik6CZbJj2cPO+807vcp85S3qTfC-w5fMjmdzkuj@mail.gmail.com>

On Mon, Mar 21, 2011 at 4:06 PM, rndblnch <rndblnch at gmail.com> wrote:
> Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:
>> Guido van Rossum wrote:
>> > Ok. Will you hvae time to port your patches to 3.3?
>> I'm not sure -- I'll see what I can do.
>
> If this can help, I have written a script that transforms greg's patch into a
> patch that applies on cpython current tip.
> The script is available here:
> http://iihm.imag.fr/blanch/misc/pep380_transform.py
>
> Hope this will help to get pep 380 into Python 3.3...
> If I can help to make it happend in any way, don't hesitate to ask, I really
> would like to finally have it and start playing with "yield from" :)

In the light of the recent discussion about Hg clones, perhaps you
could make this a server-side clone so it's easier for others to play
along?

-- 
--Guido van Rossum (python.org/~guido)

From greg.ewing at canterbury.ac.nz  Tue Mar 22 00:46:22 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 22 Mar 2011 12:46:22 +1300
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <87wrjs456h.fsf@benfinney.id.au>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
Message-ID: <4D87E34E.2000201@canterbury.ac.nz>

Ben Finney wrote:

> That seems to me the ideal: preserve all revision history for those
> cases when some user will care about it, but *present* history cleanly
> by default.

Seems to me the basic problem here is the way Mercurial
presents you with a big pile of changesets and not much
way of imposing any structure on them.

There should be a hierarchy of changesets, so you can
look at the top level and get the big picture, while
being able to drill down into the details when you
need to.

-- 
Greg

From merwok at netwok.org  Tue Mar 22 00:52:06 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 22 Mar 2011 00:52:06 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87E34E.2000201@canterbury.ac.nz>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz>
Message-ID: <4D87E4A6.1090404@netwok.org>

Le 22/03/2011 00:46, Greg Ewing a ?crit :
> Ben Finney wrote:
>> That seems to me the ideal: preserve all revision history for those
>> cases when some user will care about it, but *present* history cleanly
>> by default.
> 
> Seems to me the basic problem here is the way Mercurial
> presents you with a big pile of changesets and not much
> way of imposing any structure on them.
> 
> There should be a hierarchy of changesets, so you can
> look at the top level and get the big picture, while
> being able to drill down into the details when you
> need to.

That?s one way of saying ?Mercurial should be Bazaar? <wink>.

Bazaar apparently has a notion of mainline whereas Mercurial believes
that all changesets are created equal.  The tools are different.

Regards

From eltoder at gmail.com  Tue Mar 22 01:08:09 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Mon, 21 Mar 2011 20:08:09 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87E4A6.1090404@netwok.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz> <4D87E4A6.1090404@netwok.org>
Message-ID: <AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>

> Bazaar apparently has a notion of mainline whereas Mercurial believes
> that all changesets are created equal. ?The tools are different.

Mercurial has named branches. When viewing history you can restrict it
to just one named branch, which, I think, will have an effect similar
to "mainline".

Eugene

From merwok at netwok.org  Tue Mar 22 01:10:49 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 22 Mar 2011 01:10:49 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D7D06F3.7020700@v.loewis.de>
References: <4D7D06F3.7020700@v.loewis.de>
Message-ID: <4D87E909.8050602@netwok.org>

Le 13/03/2011 19:03, "Martin v. L?wis" a ?crit :
> I've added a feature in the bug tracker where submitters can post 
> Mercurial repository URLs, and then repeatedly create patches. Roundup 
> will extract the current patch (cpython-default:submitter-default),
> and attach the patch to the issue (which then allows Rietveld review
> of the patch).

These features are truly excellent.  Well done, sir, and thank you!

From greg.ewing at canterbury.ac.nz  Tue Mar 22 01:27:33 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 22 Mar 2011 13:27:33 +1300
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au> <4D87E34E.2000201@canterbury.ac.nz>
	<4D87E4A6.1090404@netwok.org>
	<AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>
Message-ID: <4D87ECF5.1050407@canterbury.ac.nz>

Eugene Toder wrote:

> Mercurial has named branches. When viewing history you can restrict it
> to just one named branch, which, I think, will have an effect similar
> to "mainline".

So with Hg, could you get the same effect by pushing your
local changes into a temporary named branch, and then
merging it with the main branch?

-- 
Greg

From martin at v.loewis.de  Tue Mar 22 01:32:50 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 22 Mar 2011 01:32:50 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<87wrjs456h.fsf@benfinney.id.au>	<4D87E34E.2000201@canterbury.ac.nz>
	<4D87E4A6.1090404@netwok.org>
	<AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>
Message-ID: <4D87EE32.9040109@v.loewis.de>

Am 22.03.2011 01:08, schrieb Eugene Toder:
>> Bazaar apparently has a notion of mainline whereas Mercurial believes
>> that all changesets are created equal.  The tools are different.
> 
> Mercurial has named branches. When viewing history you can restrict it
> to just one named branch, which, I think, will have an effect similar
> to "mainline".

Not if the changes you want to suppress are actually also on the same
branch as the one whose mainline you are trying to see (which they
typically are, with the branch typically being "default").

Regards,
Martin

From martin at v.loewis.de  Tue Mar 22 01:49:44 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 22 Mar 2011 01:49:44 +0100
Subject: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
In-Reply-To: <im7ut9$svl$1@dough.gmane.org>
References: <4D86C16F.8080403@v.loewis.de>	<1300717273.24680.1.camel@marge>	<im7nmm$css$1@dough.gmane.org>	<1300721168.10044.2.camel@marge>
	<im7ut9$svl$1@dough.gmane.org>
Message-ID: <4D87F228.6040502@v.loewis.de>

> But now that I think about it, I guess it's a lot easier to miss a place
> like PyArg_Parse*() when manually migrating code. The conversion of the
> type string is really not obvious and the C compiler can't provide any
> help. 

I actually have a GCC extension allowing the compiler to detect type
errors in PyArg_ParseTuple.

Regards,
Martin

From eltoder at gmail.com  Tue Mar 22 02:02:16 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Mon, 21 Mar 2011 21:02:16 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87EE32.9040109@v.loewis.de>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz> <4D87E4A6.1090404@netwok.org>
	<AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>
	<4D87EE32.9040109@v.loewis.de>
Message-ID: <AANLkTikJ22CkmGLfXe2V=J3sdtOq9YrTZ77kwobhTV5d@mail.gmail.com>

> Not if the changes you want to suppress are actually also on the same
> branch as the one whose mainline you are trying to see (which they
> typically are, with the branch typically being "default").

Right, that would amount to not using named branches. But if you
develop on a named feature-branch and merge into "default" when ready
your local history is easy to filter-out without rebasing or
collapsing.

Eugene

From guido at python.org  Tue Mar 22 02:02:59 2011
From: guido at python.org (Guido van Rossum)
Date: Mon, 21 Mar 2011 18:02:59 -0700
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D87E909.8050602@netwok.org>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
Message-ID: <AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>

On Mon, Mar 21, 2011 at 5:10 PM, ?ric Araujo <merwok at netwok.org> wrote:
> Le 13/03/2011 19:03, "Martin v. L?wis" a ?crit :
>> I've added a feature in the bug tracker where submitters can post
>> Mercurial repository URLs, and then repeatedly create patches. Roundup
>> will extract the current patch (cpython-default:submitter-default),
>> and attach the patch to the issue (which then allows Rietveld review
>> of the patch).
>
> These features are truly excellent. ?Well done, sir, and thank you!

I'm having a hard time discovering how to use the feature (though I
think I've seen issues using it). What's the magical UI?

-- 
--Guido van Rossum (python.org/~guido)

From tjreedy at udel.edu  Tue Mar 22 02:05:41 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 21 Mar 2011 21:05:41 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <AANLkTimcu-cu8en8munSk51uNFw_Tz-DORRakQYdToqF@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>
	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D871DE1.6020307@v.loewis.de>
	<AANLkTimcu-cu8en8munSk51uNFw_Tz-DORRakQYdToqF@mail.gmail.com>
Message-ID: <im8sl5$f6j$1@dough.gmane.org>

On 3/21/2011 7:14 AM, Nick Coghlan wrote:

> hg broadens the check and complains if *any* files are not up to date
> on any of the branches being pushed, thus making it a requirement to
> do a hg pull and merge on all affected branches before the hg push can
> succeed. In theory, this provides an opportunity for the developer
> doing the merge to double check that it didn't break anything, in
> practice (at least in the near term) we're more likely to see an
> SVN-like practice of pushing the merged changes without rerunning the
> full test suite.

Now that you and John have (finally) explained how 'non-conflict' merges 
can actually contain a conflict (and there could be such for docs as 
well as code*), I think there is a pretty clear guideline for when to 
re-test.

If my change adds or changes in one file a reference to something in 
another file, or changes or subtracts in one file something that might 
be referenced by other files, and the the change could affect the 
cross-file linkage, and the pulled changes merged with my changes might 
have such linkages, then I should rerun tests on the new merged state. 
(I say 'might' because it is easier and safer to just rerun than to 
check very hard.) Otherwise, it should be safe not to. Correct?

-- 
Terry Jan Reedy


From stephen at xemacs.org  Tue Mar 22 02:27:41 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 22 Mar 2011 10:27:41 +0900
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <20110321134015.B8ED364DAA@kimball.webabinitio.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
Message-ID: <877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>

R. David Murray writes:

 > The workflow in svn "can" "require" this same thing:  before committing,
 > you do an svn up and run the test suite.

No, it can't.  That's not good enough, if you care about tree-wide
consistency, because svn's approach has a race condition.  You say you
don't care, but for many, that was an artifact of svn's inability to
enforce tree-wide up-to-dateness, and they don't want to go back (see
Hrvoje's post).  If you say that is *not* Python project policy, OK,
neither Hrvoje nor I claim to determine policy.

 > That is, not only did the change in the tool and consequent change in
 > the workflow have *zero* impact on this aspect of the way I work with
 > CPython, it didn't even trigger me to *think* about it.

That's too bad, because now there often is a better way.  If you think
you're ready to merge, then commit, merge, and run the tests *after*
the merge.  You still have an untested revision in the DAG, but it
will not be tip.  If the tests fail, update, lather, rinse, repeat.

This won't be pleasant if people are sprinting and lots of commits are
coming, because you're likely to repeatedly lose the push race.  But
in those conditions, nothing is guaranteed to work in decentralized
fashion (that's one reason why the Linux kernel uses Linus and
lieutenants as a serialization mechanism).

From dmalcolm at redhat.com  Tue Mar 22 02:06:22 2011
From: dmalcolm at redhat.com (David Malcolm)
Date: Mon, 21 Mar 2011 21:06:22 -0400
Subject: [Python-Dev] [GSoC] Porting on RPM3
In-Reply-To: <4D871F68.4000608@v.loewis.de>
References: <AANLkTik0C8JdwCafpgeoq10_nm7J4yRBqR-LSSqniwOO@mail.gmail.com>
	<4D871F68.4000608@v.loewis.de>
Message-ID: <1300755982.2666.4869.camel@surprise>

[CCing Panu Matilainen, the maintainer of rpm, or, at least rpm 4.*,
which is what all major distributions are using AIUI]

On Mon, 2011-03-21 at 10:50 +0100, "Martin v. L?wis" wrote:
> Am 21.03.2011 07:37, schrieb Prashant Kumar:
> > Hello,
> >     My name is  Prashant Kumar and I've worked on porting few python
> > libraries(distutils2, configobj) and I've been looking at the ideas
> > list for GSoC for a project related to porting.
> > 
> >     I came across [1]  and found it interesting. It mentions that some

Hi Prashant!  Thanks for the interest.

Panu: [1] is http://wiki.python.org/moin/RPMOnPython3 , a Google Summer
of Code proposal to work on the Python 3 bindings to RPM.

> > of the work has already been done; I would like to look at the code
> > repository for the same, could someone provide me the link for the
> > same?

> Not so much the code but the person who did the porting. This was Dave
> Malcolm (CC'ed); please get in touch with him. Please familiarize
> yourself with the existing Python bindings (in the latest RPM 4 release
> from rpm.org). You'll notice that this already has Python 3 support;
> not sure whether that's the most recent code, though.

Panu Matilainen also worked on the python 3 port of the librpm python
bindings.

For the rpm source code, see: http://rpm.org/wiki/GetSource  (the python
bindings are in a subdirectory of the main source tree).

My initial patchbomb landed on the mailing list here:
  http://lists.rpm.org/pipermail/rpm-maint/2009-October/002528.html
and Panu committed and fixed up the patches around then.

My understanding is that the current status is that the bindings work,
but all values that were formerly exposed to Python 2 as "str" are now
exposed to Python 3 as "bytes", which would require changing all
consumers of the code.

I believe Panu has also been working on a rewrite of the Python
bindings, since the existing code is a little messy.

Panu, am I remembering this correctly?

The idea is that these types are fundamentally string-like, but
unfortunately rpm has always been a bit loose in its interpretation of
the encoding of byte values in package files and package databases.
There are millions of rpm files out there, and millions of rpm
databases, and all of these are in _some_ encoding.  I have seen
specfiles in which parts of the file were encoded in UTF-8 and other
parts were encoded in Latin-1 (this broke one of my python scripts
horribly).

Martin and I discussed this last week at PyCon.  I believe the proposal
that we came up with was:
  - try to interpret bytes as UTF-8, using the "surrogateescape"
mechanism, so that if it fails, we can at least preserve the exact bytes
and round-trip

Ultimately, this does mean trying to impose some kind of encoding
standard on rpm files and rpm databases, which I think would be a Good
Thing, but is perhaps something of scope creep compared to what the
proposal at [1] says.  See e.g. http://rpm.org/ticket/30

Other ideas that occur:
  - does rpmlint check for encoding yet?
  - what to do e.g. about canonicalization?  What happens if one rpm
provide a feature named "caf?" (where the "?" is U+00E9) and another rpm
requires a feature named "caf?" (where the "?" is U+0065 LATIN SMALL
LETTER E + U+0301 COMBINING ACUTE ACCENT)?  IIRC we ruled that rpms in
Fedora had to have ASCII names, and I'm guessing this applies to
metadata, but we do allow UTF-8 filenames within package payloads
(again, IIRC)

I should mention that I'm drowning in email, and more likely to receive
email to which I am directly listed in the "To" or "CC".

Alas, it's also worth mentioning that there was a hostile fork of rpm,
at rpm5.org, and that the "#rpm" channel on Freenode relates to that
fork.   I would advise not bothering with the rpm5 code; my
understanding is that all major Linux distributions that use rpm use the
rpm 4.* code hosted at rpm.org, not the rpm5 fork (and I have no
personal interest in a GSOC project to work on python 3 support there).
I doublechecked that fork in its CVS repository, and it does not yet
have any of the Python 3 support.

Hope this is helpful
Dave


From doug.hellmann at gmail.com  Tue Mar 22 02:50:53 2011
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Mon, 21 Mar 2011 21:50:53 -0400
Subject: [Python-Dev] blogroll for the new blog
Message-ID: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>

We are nearly ready to launch the new blog for python-dev. If you have a personal blog where you talk about your Python work, we would like to include a link in the sidebar as part of our blog-roll. Send me the URL (off-list) and I'll make sure you are included.

Doug


From orsenthil at gmail.com  Tue Mar 22 02:57:19 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Tue, 22 Mar 2011 09:57:19 +0800
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
Message-ID: <AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>

On Tue, Mar 22, 2011 at 9:02 AM, Guido van Rossum <guido at python.org> wrote:
> On Mon, Mar 21, 2011 at 5:10 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> Le 13/03/2011 19:03, "Martin v. L?wis" a ?crit :
>>> I've added a feature in the bug tracker where submitters can post
>>> Mercurial repository URLs, and then repeatedly create patches. Roundup
>>> will extract the current patch (cpython-default:submitter-default),
>>> and attach the patch to the issue (which then allows Rietveld review
>>> of the patch).
>>
>> These features are truly excellent. ?Well done, sir, and thank you!
>
> I'm having a hard time discovering how to use the feature (though I
> think I've seen issues using it). What's the magical UI?

Have a look at this issue:
http://bugs.python.org/issue11591

The magical UI is the FORM textbox element "Remote hg repo:"
where the user provided his bitbucket URL for the path he was working on.

And when you pressed "Create Patch" button, it created a patch and
then attached to the issue tracker.
You can click on the review button to post that patch to reitveld and
do the review,.

Also somewhere else, it was mentioned that hg import can take a remote
url of the patch and import it directly.
(If we want, portion can be bit automated in the future to take latest
patch if we provide the issue #)

So, it all becomes super cool.

But, I have a couple of doubts in this magic, which I think MvL can
shed some light

- In the above issue, why is two same bitbutket urls are provided. (It
is redundant).
- Also, how is it that system is creating patch from a repository
outside of hg.python.org? What if the user had an older version in
remote repo and tip in the hg.python.org has moved forward?

-- 
Senthil

From orsenthil at gmail.com  Tue Mar 22 03:10:57 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Tue, 22 Mar 2011 10:10:57 +0800
Subject: [Python-Dev] blogroll for the new blog
In-Reply-To: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
Message-ID: <20110322021057.GB2704@kevin>

Doug Hellmann wrote:
> We are nearly ready to launch the new blog for python-dev. 

Cool. But I always thought planet.python.org was a kind of blog for
python-dev. How will python-dev blog be different? Will add additional
redundancy to my RSS reader which gets planet posts as well as
individual posts from the same author? 

Yes, this question is not related to blogroll but was for my
understanding and I am sorry, if it was already discussed elsewhere and I
missed it. Perhaps you will be covering this in the introductory
post too, if not, it would be a good idea to cover this point. 

Thanks,
Senthil

From carl at meyerloewen.net  Tue Mar 22 03:15:00 2011
From: carl at meyerloewen.net (Carl Meyer)
Date: Mon, 21 Mar 2011 22:15:00 -0400
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
References: <4D7D06F3.7020700@v.loewis.de>
	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
Message-ID: <4D880624.7040606@meyerloewen.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Senthil,

On 03/21/2011 09:57 PM, Senthil Kumaran wrote:
> - In the above issue, why is two same bitbutket urls are provided. (It
> is redundant).

I updated the patch, and the second time around the "remote hg repo" box
was empty. I wasn't sure what to do so I filled it again. Probably would
be nice if this was detected and the repo not listed a second time.

> - Also, how is it that system is creating patch from a repository
> outside of hg.python.org? What if the user had an older version in
> remote repo and tip in the hg.python.org has moved forward?

Don't know exactly how it's implemented, but I would guess it's using
"hg incoming --patch" or similar, which would handle this transparently;
the newer revisions at hg.python.org would just be ignored in generating
the diff.

Carl


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2IBiQACgkQFRcxmeyPUXLnTACeII/z+gSZPt5d1ycyn2rcqaxr
4/kAn3l/JQdT2lMk2M6Ll+EA4mTEo39B
=hxIJ
-----END PGP SIGNATURE-----

From a.badger at gmail.com  Tue Mar 22 03:23:21 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 21 Mar 2011 19:23:21 -0700
Subject: [Python-Dev] [GSoC] Porting on RPM3
In-Reply-To: <1300755982.2666.4869.camel@surprise>
References: <AANLkTik0C8JdwCafpgeoq10_nm7J4yRBqR-LSSqniwOO@mail.gmail.com>
	<4D871F68.4000608@v.loewis.de>
	<1300755982.2666.4869.camel@surprise>
Message-ID: <20110322022321.GG19053@unaka.lan>

On Mon, Mar 21, 2011 at 09:06:22PM -0400, David Malcolm wrote:
> 
> Other ideas that occur:
>   - does rpmlint check for encoding yet?
>   - what to do e.g. about canonicalization?  What happens if one rpm
> provide a feature named "caf?" (where the "?" is U+00E9) and another rpm
> requires a feature named "caf?" (where the "?" is U+0065 LATIN SMALL
> LETTER E + U+0301 COMBINING ACUTE ACCENT)?

This depends on whether we're modifying things at the rpm level or only at
the python-bindings level.  If it's at the rpm level, then yeah, Panu will
have to discuss whether we want to enforce a canonical form or not.  If this
is at the python-binding level only, then the only sensible answer is that
those describe two distinct features.  rpm will treat those as two separate
provides so we need to as well.

> IIRC we ruled that rpms in
> Fedora had to have ASCII names,

Correct.  But there's other distributions that likely do allow non-ASCII
characters in package names.  If we're talking about things at the rpm
level, we need to be conscious that Fedora is only one of the consumers of
rpm.

> and I'm guessing this applies to
> metadata,

Incorrect.  We do allow (or I guess I should say, we don't prohibit)
non-ASCII characters in other metadata (for instance virtual Provides).  In
fact, it may have been part of the compromise within Fedora that packages
that have a common non-ASCII name upstream could create a virtual provide
for the non-ASCII name even though the package itself had to be ASCII.

> but we do allow UTF-8 filenames within package payloads
> (again, IIRC)
> 
Right.  And for those who aren't familiar with the rpm packaging format,
filenames are usable in dependencies.  So package foo could have:
  Requires: /usr/bin/caf?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/61107c31/attachment.pgp>

From robertc at robertcollins.net  Tue Mar 22 03:33:41 2011
From: robertc at robertcollins.net (Robert Collins)
Date: Tue, 22 Mar 2011 15:33:41 +1300
Subject: [Python-Dev] blogroll for the new blog
In-Reply-To: <20110322021057.GB2704@kevin>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
	<20110322021057.GB2704@kevin>
Message-ID: <AANLkTinjufNdMu+ZDUqMBN9=dUF_B3aGfJ6NmC7H4s-y@mail.gmail.com>

On Tue, Mar 22, 2011 at 3:10 PM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> Doug Hellmann wrote:
>> We are nearly ready to launch the new blog for python-dev.
>
> Cool. But I always thought planet.python.org was a kind of blog for
> python-dev. How will python-dev blog be different? Will add additional
> redundancy to my RSS reader which gets planet posts as well as
> individual posts from the same author?
>
> Yes, this question is not related to blogroll but was for my
> understanding and I am sorry, if it was already discussed elsewhere and I
> missed it. Perhaps you will be covering this in the introductory
> post too, if not, it would be a good idea to cover this point.

I share the question though; if the answer is 'they are pretty
similar', then you might like to copy my python sub-feed from
planet.python.org too.

-Rob

From stephen at xemacs.org  Tue Mar 22 03:43:11 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 22 Mar 2011 11:43:11 +0900
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87EE32.9040109@v.loewis.de>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz> <4D87E4A6.1090404@netwok.org>
	<AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>
	<4D87EE32.9040109@v.loewis.de>
Message-ID: <874o6vooxs.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. L?wis" writes:

 > Not if the changes you want to suppress are actually also on the same
 > branch as the one whose mainline you are trying to see (which they
 > typically are, with the branch typically being "default").

There is no "also on" with Mercurial named branches.  Every commit is
on exactly one named branch, and that include both branch and merge
nodes.



From jnoller at gmail.com  Tue Mar 22 03:43:04 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Mon, 21 Mar 2011 22:43:04 -0400
Subject: [Python-Dev] blogroll for the new blog
In-Reply-To: <20110322021057.GB2704@kevin>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
	<20110322021057.GB2704@kevin>
Message-ID: <AANLkTinUkXDsjZae016aJ29WEhtAi7qOoUN7x+C124QY@mail.gmail.com>

On Mon, Mar 21, 2011 at 10:10 PM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> Doug Hellmann wrote:
>> We are nearly ready to launch the new blog for python-dev.
>
> Cool. But I always thought planet.python.org was a kind of blog for
> python-dev. How will python-dev blog be different? Will add additional
> redundancy to my RSS reader which gets planet posts as well as
> individual posts from the same author?
>

This is for developers *of* Python. Doug is just offering to link to
your personal account. We are setting up a "Development of Python"
blog which will feature content from CPython, PyPy, etc. Think of it
as an announcement location for new/interesting changes. Some of
which, yes, might be cross posted to individual authors' blogs
depending on if they feel it warrants it.

> Yes, this question is not related to blogroll but was for my
> understanding and I am sorry, if it was already discussed elsewhere and I
> missed it. Perhaps you will be covering this in the introductory
> post too, if not, it would be a good idea to cover this point.

Think of this as a place to say "Hey, we just changed the CAPI to be
incompatible with 3.2!" or "PyPy discovered how to bend space time,
and is now faster than pure ASM".

It's a blog for language development, not general development-with-the
language - heck, maybe some of the cooler python-ideas proposals could
see the light of day on it.

jesse

From doug.hellmann at gmail.com  Tue Mar 22 03:48:02 2011
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Mon, 21 Mar 2011 22:48:02 -0400
Subject: [Python-Dev] blogroll for the new blog
In-Reply-To: <20110322021057.GB2704@kevin>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
	<20110322021057.GB2704@kevin>
Message-ID: <F7D8BC0A-E555-4F3A-B555-5F799AF51C21@gmail.com>


On Mar 21, 2011, at 10:10 PM, Senthil Kumaran wrote:

> Doug Hellmann wrote:
>> We are nearly ready to launch the new blog for python-dev. 
> 
> Cool. But I always thought planet.python.org was a kind of blog for
> python-dev. How will python-dev blog be different? Will add additional
> redundancy to my RSS reader which gets planet posts as well as
> individual posts from the same author? 
> 
> Yes, this question is not related to blogroll but was for my
> understanding and I am sorry, if it was already discussed elsewhere and I
> missed it. Perhaps you will be covering this in the introductory
> post too, if not, it would be a good idea to cover this point. 

Blogs linked from the blogroll will appear on the sidebar of Python Insider with your name and a link to your blog (or whatever URL you give me, I suppose). This isn't an aggregator feed.

We will be writing all new content based on the activities of the Python development team. There was a brief discussion immediately before PyCon (http://mail.python.org/pipermail/python-dev/2011-March/109027.html) and it also came up during the Language Summit.

Doug


From stephen at xemacs.org  Tue Mar 22 04:02:07 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 22 Mar 2011 12:02:07 +0900
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <87wrjs456h.fsf@benfinney.id.au>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
Message-ID: <8739mfoo28.fsf@uwakimon.sk.tsukuba.ac.jp>

Ben Finney writes:

 > As a user of Bazaar primarily, that's addressing the problem in the
 > wrong place: why rewrite *my* history, which is useful to me as is, when
 > the other person is using Bazaar and so doesn't see revisions they don't
 > care about?

Speaking for myself, I rewrite my git history because it is *not*
useful to me as is.  Almost all of my git commits have a informational
half-life measured in hours once they're off tip, because I commit
with *every* save (I have an after-save-hook to do this), which I do
"early and often".  Effectively, I use git as an extension to XEmacs's
undo/redo mechanism.

I don't do this (yet, anyway) for hg or bzr because the projects where
I use those typically I only submit by patch or one-off commits rather
than long-ish branches.

 > Whether adding support in Mercurial or Git for similar
 > clean-presentation-by-default would obviate the need for rewriting
 > history, I can't tell.

It would probably decrease it, because many projects do have a
relatively centralized workflow where the bazaar approach of having a
distinguished mainline works well.  It is *highly* unlikely that it
would obviate it.  Aside from those of us who take a packrat approach
to committing as above, many git users (can't really speak for hg)
have a working style which involves lots of dynamic sharing "sideways"
with other users before pushing to the public mainline.  In these
workflows rebasing is a reasonable mechanism for "chunking" related
changes in the DAG, and helps to spread out the work of resolving
conflicts over time, while concentrating it in terms of the project's
module structure.


From timothy.c.delaney at gmail.com  Tue Mar 22 06:32:41 2011
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Tue, 22 Mar 2011 16:32:41 +1100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87D6D1.109@pearwood.info>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<AANLkTikQHPiqbmVpVOe9GuDj+DJR5pM1RGiX8tgaor8p@mail.gmail.com>
	<4D87D6D1.109@pearwood.info>
Message-ID: <AANLkTi=-F0ZzWGd9z8WTp+=g0Q+kzJxugxwkVS0udwZP@mail.gmail.com>

On 2011-03-22, Steven D'Aprano <steve at pearwood.info> wrote:
> Tim Delaney wrote:
>
>> You'd end up using more horizontal space, but we all seem to have
>> widescreen monitors these days.
>
> Not even close to "we all".

Fair enough - that was a fairly stupid statement on my part. Blame it
on being on dial-up (26kbps!) for the last 24 hours.

I do heartily recommend getting one though. If nothing else, it really
helps with visualising the interrelationships between multiple
branches (named or anonymous), even with the current sub-optimal (IMO)
layout.

Tim Delaney

From ben+python at benfinney.id.au  Tue Mar 22 06:59:27 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 22 Mar 2011 16:59:27 +1100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au> <4D87E34E.2000201@canterbury.ac.nz>
Message-ID: <87k4fr4rwg.fsf@benfinney.id.au>

Greg Ewing <greg.ewing at canterbury.ac.nz> writes:

> There should be a hierarchy of changesets, so you can look at the top
> level and get the big picture, while being able to drill down into the
> details when you need to.

Yes, that's exactly what Bazaar does. Perhaps the Python team can make a
big request to Mercurial to implement the same there (since I realise
the ?use Bazaar instead? train has already left the station for the
Python team).

-- 
 \          ?When we talk to God, we're praying. When God talks to us, |
  `\         we're schizophrenic.? ?Jane Wagner, via Lily Tomlin, 1985 |
_o__)                                                                  |
Ben Finney


From stefan_ml at behnel.de  Tue Mar 22 07:32:26 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 22 Mar 2011 07:32:26 +0100
Subject: [Python-Dev] VM and Language summit info for those not at Pycon
 (and those that are!)
In-Reply-To: <4D87D4C2.4030101@v.loewis.de>
References: <AANLkTi=NT1oUBUx_73qtKEtTu++LaKT-ce1OP58qDiQo@mail.gmail.com>	<im4nrg$ph$1@dough.gmane.org>	<AANLkTi=Gg_Qc9f=UpoQpbdyjr=j=aUPJoLSzrkeJ2S1R@mail.gmail.com>	<20110320124049.70610337@pitrou.net>	<im4sb2$lg1$1@dough.gmane.org>	<AANLkTi=0mDwYc+PP9EgA7SYQrArAAgNRP59VA54qvop8@mail.gmail.com>	<im5028$7h7$1@dough.gmane.org>	<AANLkTinHVK6LBOErT3Et6rnnj-uar7Ky2M01DmQbihDT@mail.gmail.com>	<im5pr1$7da$1@dough.gmane.org>	<AANLkTi=u=FScQ9NWS9t0PfyQv0gzb4Z82iT0cnom1S7h@mail.gmail.com>	<im7b1a$14l$1@dough.gmane.org>
	<4D87D4C2.4030101@v.loewis.de>
Message-ID: <im9fpr$sur$1@dough.gmane.org>

"Martin v. L?wis", 21.03.2011 23:44:
> Am 21.03.2011 11:58, schrieb Stefan Behnel:
>> Guido van Rossum, 21.03.2011 03:46:
>>> Thanks for the clarifications. I now have a much better understanding
>>> of what Cython is. But I'm not sold. For one, your attitude about
>>> strict language compatibility worries me when it comes to the stdlib.
>>
>> Not sure what you mean exactly. Given our large user base, we do worry a
>> lot about things like backwards compatibility, for example.
>>
>> If you are referring to compatibility with Python, I don't think anyone
>> in the project really targets Cython as a a drop-in replacement for a
>> Python runtime. We aim to compile Python code, yes, and there's a
>> hand-wavy idea in the back of our head that we may want a plain Python
>> compatibility mode at some point that will disable several important
>> optimisations.
>
> I think that's the attitude Guido worries about: if you don't have the
> desire to provide 100% Python compatibility under all circumstances
> (i.e. including if someone passes parameters of "incorrect" types),
> then there is very little chance that we would replace a Python module
> with a Cython-compiled one.

We are aware of potential differences and generally consider (most of) them 
bugs. We even try to keep our exception messages in line with CPython 
(usually py3k, CPython has changed its own messages quite a bit during its 
lifetime, as our doctests can tell), and try to make optimised code as safe 
as possible by default. For example, we automatically raise TypeErrors on 
invalid arguments *iff* there is a user declared type for them, and we 
raise OverflowErrors during C type conversions and even some C calculations 
unless explicitly disabled by the user. If in doubt, we always try to copy 
CPython's own behaviour.

So it's almost always up to the user to explicitly divert from normal 
Python behaviour for performance reasons. And Cython's type driven code 
adaptations allow for a *very* broad range of explicit diversions that 
users can deploy in order to balance the user visible impact with the 
performance requirements.

Stefan


From martin at v.loewis.de  Tue Mar 22 07:51:32 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 22 Mar 2011 07:51:32 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikJ22CkmGLfXe2V=J3sdtOq9YrTZ77kwobhTV5d@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<87wrjs456h.fsf@benfinney.id.au>	<4D87E34E.2000201@canterbury.ac.nz>	<4D87E4A6.1090404@netwok.org>	<AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>	<4D87EE32.9040109@v.loewis.de>
	<AANLkTikJ22CkmGLfXe2V=J3sdtOq9YrTZ77kwobhTV5d@mail.gmail.com>
Message-ID: <4D8846F4.7030604@v.loewis.de>

Am 22.03.2011 02:02, schrieb Eugene Toder:
>> Not if the changes you want to suppress are actually also on the same
>> branch as the one whose mainline you are trying to see (which they
>> typically are, with the branch typically being "default").
>
> Right, that would amount to not using named branches. But if you
> develop on a named feature-branch and merge into "default" when ready
> your local history is easy to filter-out without rebasing or
> collapsing.

Ah. We don't support this kind of development - no new named branches
are allowed in the central repository.

Regards,
Martin

From martin at v.loewis.de  Tue Mar 22 07:53:42 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 22 Mar 2011 07:53:42 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <874o6vooxs.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<87wrjs456h.fsf@benfinney.id.au>	<4D87E34E.2000201@canterbury.ac.nz>	<4D87E4A6.1090404@netwok.org>	<AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>	<4D87EE32.9040109@v.loewis.de>
	<874o6vooxs.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D884776.50607@v.loewis.de>

Am 22.03.2011 03:43, schrieb Stephen J. Turnbull:
> "Martin v. L?wis" writes:
> 
>  > Not if the changes you want to suppress are actually also on the same
>  > branch as the one whose mainline you are trying to see (which they
>  > typically are, with the branch typically being "default").
> 
> There is no "also on" with Mercurial named branches.  Every commit is
> on exactly one named branch, and that include both branch and merge
> nodes.

Right. Therefore, there isn't really a mainline in mercurial.

Regards,
Martin

From martin at v.loewis.de  Tue Mar 22 08:00:11 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 22 Mar 2011 08:00:11 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D880624.7040606@meyerloewen.net>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<4D880624.7040606@meyerloewen.net>
Message-ID: <4D8848FB.4070307@v.loewis.de>

> Don't know exactly how it's implemented, but I would guess it's using
> "hg incoming --patch" or similar, which would handle this transparently;
> the newer revisions at hg.python.org would just be ignored in generating
> the diff.

That doesn't work exactly: hg incoming --patch could generate multiple
patches for the same file. The button tries to combine them into a
single patch per file (which turns out to be difficult).

Regards,
Martin

From skippy.hammond at gmail.com  Tue Mar 22 08:08:34 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Tue, 22 Mar 2011 18:08:34 +1100
Subject: [Python-Dev] Module version variable
In-Reply-To: <20110321170941.44685dfa@neurotica.wooz.org>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>	<4D80F460.6010307@voidspace.org.uk>	<20110316183322.A34F424A614@kimball.webabinitio.net>	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>	<4D81367B.9010808@trueblade.com>
	<ilrgoc$efd$1@dough.gmane.org>	<4D8414E4.7060001@canterbury.ac.nz>	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
	<20110321170941.44685dfa@neurotica.wooz.org>
Message-ID: <4D884AF2.3000804@gmail.com>

On 22/03/2011 8:09 AM, Barry Warsaw wrote:
> I started an Informational PEP on this at Pycon, and will try to finish a
> draft of it this week.  (I'm claiming 396 for it.)

We nearly had a race for that number! FYI, I just checked in pep-0397 
leaving 396 for you :)

Cheers,

Mark

From mhammond at skippinet.com.au  Tue Mar 22 08:21:44 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 22 Mar 2011 18:21:44 +1100
Subject: [Python-Dev] Second draft:  PEP397: Python launcher for Windows
Message-ID: <4D884E08.1020709@skippinet.com.au>

Hi all,
   I've made some changes to the draft PEP and checked it into the PEP 
repository as PEP397.  The reference implementation is currently being 
tracked at http://bugs.python.org/issue11629.

Most of the changes should not be too controversial, but of note:

* I've added lots of discussion about the child-process issue and the 
wording now states, basically, that in-process is not feasible, but if 
we use the win32 Job API we can arrange for the child to be killed with 
the parent on Windows XP and later.  The reference implementation 
demonstrates this thanks to an example from Curt Hagenlocher.

* 64bit and 32bit considerations have been added, along with basic 
information about other distros and implementations.

* The somewhat controversial optional first command-line parameter which 
allows you to specify a particular version for interactive use has grown 
an almost-certain-to-be-controversial option to specify the bittedness 
of the Python you wish to start.  I've added this mainly as it would 
scratch my personal itch as I tend to have 32bit and 64bit 
implementations of most versions available and while this isn't 
particularly common, I'm going to attempt to defend it on the principle 
of "just don't use it if you don't like it" :)  Note the reference 
implementation does not yet implement this, nor does it implement the 
general policy about 32bit vs 64bit considerations.

Please let me know what you think and what objections/comments/etc remain.

Thanks,

Mark
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pep-0397.txt
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/5087fe04/attachment.txt>

From stephen at xemacs.org  Tue Mar 22 08:47:40 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 22 Mar 2011 16:47:40 +0900
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D8846F4.7030604@v.loewis.de>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz> <4D87E4A6.1090404@netwok.org>
	<AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>
	<4D87EE32.9040109@v.loewis.de>
	<AANLkTikJ22CkmGLfXe2V=J3sdtOq9YrTZ77kwobhTV5d@mail.gmail.com>
	<4D8846F4.7030604@v.loewis.de>
Message-ID: <87zkon8ulf.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. L?wis" writes:
 > Am 22.03.2011 02:02, schrieb Eugene Toder:
 > >> Not if the changes you want to suppress are actually also on the same
 > >> branch as the one whose mainline you are trying to see (which they
 > >> typically are, with the branch typically being "default").
 > >
 > > Right, that would amount to not using named branches. But if you
 > > develop on a named feature-branch and merge into "default" when ready
 > > your local history is easy to filter-out without rebasing or
 > > collapsing.
 > 
 > Ah. We don't support this kind of development - no new named branches
 > are allowed in the central repository.

Maybe it would be possible to allow *closed* named branches, which
would support such filtering.


From hrvoje.niksic at avl.com  Tue Mar 22 09:30:32 2011
From: hrvoje.niksic at avl.com (Hrvoje Niksic)
Date: Tue, 22 Mar 2011 09:30:32 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <19847.32856.903323.462779@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D871DE1.6020307@v.loewis.de>
	<87zkoozm74.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D876711.1060707@avl.com>
	<19847.32856.903323.462779@montanaro.dyndns.org>
Message-ID: <4D885E28.10601@avl.com>

On 03/21/2011 05:44 PM, skip at pobox.com wrote:
>
> Thanks for the example, Hrvoje.
>
>      Hrvoje>  This automatic merging often causes people who migrate to a DVCS
>      Hrvoje>  to feel that they have to go through an unnecessary extra step
>      Hrvoje>  in their workflows.  But once you grasp the "hole" in the svn
>      Hrvoje>  workflow, what svn does (and what one used to take for granted)
>      Hrvoje>  tends to become unacceptable, to put it mildly.
>
> In the run-up to a release when there is lots of activity happening, do you
> find yourself in a race with other developers to push your changes cleanly?

I work on a small project in comparison to Python, so this doesn't 
happen to me personally.  But such a race is certain to happen on larger 
projects.  But it doesn't mean that we are helpless to prevent it. 
After all, one of the selling points of DVCS is the ability to support 
different integration workflows.

If you (we) are running into a push race with the other developers over 
the central repository's head, this could indicate that the project is 
large enough that the centralized workflow is no longer the appropriate 
one.  If you are not familiar with other DVCS workflows, take a look at, 
for example, chapter 5 of the "Pro Git" book, which describes the 
alternatives such as integrator-manager and dictator-lieutenant 
workflows: http://progit.org/book/ch5-1.html

Python obviously wouldn't benefit from a strict hierarchy implied by the 
dictator-lieutenants model, but perhaps it could switch to something 
between that and the integrator model for the releases. The release 
manager could act as the dictator (as well as integrator), while the 
core committers would be lieutenants (as well as developers).  Just a 
thought.

Hrvoje

From john at arbash-meinel.com  Tue Mar 22 10:30:22 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Tue, 22 Mar 2011 10:30:22 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <4D87C7C8.8020106@v.loewis.de>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D871DE1.6020307@v.loewis.de>
	<4D87331A.4000306@arbash-meinel.com> <4D87C7C8.8020106@v.loewis.de>
Message-ID: <4D886C2E.5000904@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/21/2011 10:48 PM, "Martin v. L?wis" wrote:
>> It does so at the *tree* level, not at an individual file level.
> 
> Thanks - I stand corrected. I was thinking about the file level only (at
> which it doesn't do server-side merging - right?).
> 
> Regards,
> Martin

AIUI, you are correct, svn doesn't do server-side content merging.
John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2IbC4ACgkQJdeBCYSNAANhCQCgpmKnD7QmZQ8Cv1DGPkJw22Q0
/uYAoMc0VNoLq2VMFpu3+uzS2M93x08P
=TL8l
-----END PGP SIGNATURE-----

From john.arbash.meinel at gmail.com  Tue Mar 22 10:31:49 2011
From: john.arbash.meinel at gmail.com (John Arbash Meinel)
Date: Tue, 22 Mar 2011 10:31:49 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <im8sl5$f6j$1@dough.gmane.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D871DE1.6020307@v.loewis.de>	<AANLkTimcu-cu8en8munSk51uNFw_Tz-DORRakQYdToqF@mail.gmail.com>
	<im8sl5$f6j$1@dough.gmane.org>
Message-ID: <4D886C85.5040405@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/22/2011 2:05 AM, Terry Reedy wrote:
> On 3/21/2011 7:14 AM, Nick Coghlan wrote:
> 
>> hg broadens the check and complains if *any* files are not up to date
>> on any of the branches being pushed, thus making it a requirement to
>> do a hg pull and merge on all affected branches before the hg push can
>> succeed. In theory, this provides an opportunity for the developer
>> doing the merge to double check that it didn't break anything, in
>> practice (at least in the near term) we're more likely to see an
>> SVN-like practice of pushing the merged changes without rerunning the
>> full test suite.
> 
> Now that you and John have (finally) explained how 'non-conflict' merges
> can actually contain a conflict (and there could be such for docs as
> well as code*), I think there is a pretty clear guideline for when to
> re-test.
> 
> If my change adds or changes in one file a reference to something in
> another file, or changes or subtracts in one file something that might
> be referenced by other files, and the the change could affect the
> cross-file linkage, and the pulled changes merged with my changes might
> have such linkages, then I should rerun tests on the new merged state.
> (I say 'might' because it is easier and safer to just rerun than to
> check very hard.) Otherwise, it should be safe not to. Correct?
> 

I would agree with 'might' with the very large caveat that cross-file
linkage tends to exist in far more places than most people think. I know
I've done a few "single line fixes" where the test suite showed me that
it wasn't as simple as that. :)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2IbIUACgkQJdeBCYSNAAPsbQCbB53ctC5DQ8hQo1U/1crNsxLc
d5EAoIF1/x9hBW2z4X9EfGNaaGM3V8A+
=2HN+
-----END PGP SIGNATURE-----

From john at arbash-meinel.com  Tue Mar 22 10:38:10 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Tue, 22 Mar 2011 10:38:10 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <AANLkTikOiiF_pv9ih3n44m_Jwm_vnDvT-o_SkbKHXtsG@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>
	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<19847.13078.526390.539879@montanaro.dyndns.org>	<20110321112531.0c98a191@limelight.wooz.org>	<2BCDC99C-B199-4959-9404-51F0E12F7420@gmail.com>
	<AANLkTikOiiF_pv9ih3n44m_Jwm_vnDvT-o_SkbKHXtsG@mail.gmail.com>
Message-ID: <4D886E02.1030008@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/21/2011 10:32 PM, Nick Coghlan wrote:
> On Tue, Mar 22, 2011 at 3:16 AM, Raymond Hettinger
> <raymond.hettinger at gmail.com> wrote:
>> I don't think that is the main source of complexity.
>> The more difficult and fragile part of the workflows are:
>> * requiring commits to be cross-linked between branches
>> * and wanting changesets to be collapsed or rebased
>>   (two operations that destroy and rewrite history).
> 
> Yep, that sounds about right. I think in the long run the first one
> *will* turn out to be a better work flow, but it's definitely quite a
> shift from our historical way of doing things.
> 
> As far as the second point goes, I'm coming to the view that we should
> avoid rebase/strip/rollback when intending to push to the main
> repository, and do long term work in *separate* cloned repositories.
> Then an rdiff with the relevant cpython branch will create a nice
> collapsed patch ready for application to the main repository (I have
> yet to succeed in generating a nice patch without using rdiff, but I
> still have some more experimentation to do with MvL's last proposed
> command for that before giving up on the idea).
> 
> Cheers,
> Nick.
> 

I don't know what mercurial specifically supports. I believe git has a
'--squash' option at merge/commit time. And bzr has "bzr revert
- --forget-merges". Which lets you do a merge as normal, and then tell it
to forget all of the history that you just merged (treating the commit
as just a collapsed patch).

It is trivial to do this as a DVCS (it is just *omitting* the extra
parent pointer for commit). Though Mercurial's model of extra heads
existing in the branch may make it a bit trickier. (If you omit the head
when committing, it still stays around looking like it is unmerged, so
you need 1 more step of killing the extra head.)

Regardless, I'm sure it is something that could be implemented and
streamlined for Python's use. Maybe someone knows a Mercurial command to
already do it?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2IbgIACgkQJdeBCYSNAANAlACfZkegH6t9y0PUH9xufcbCB4PX
8ykAn0A6i7D/+LJ+9+9OwoA27hkAiHUc
=eh4I
-----END PGP SIGNATURE-----

From john at arbash-meinel.com  Tue Mar 22 10:45:08 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Tue, 22 Mar 2011 10:45:08 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <20110321135351.20632230@limelight.wooz.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>
	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321134015.B8ED364DAA@kimball.webabinitio.net>	<4D8767E7.8020702@cadifra.com>	<20110321171930.02BBE13F980@kimball.webabinitio.net>
	<20110321135351.20632230@limelight.wooz.org>
Message-ID: <4D886FA4.7040502@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/21/2011 6:53 PM, Barry Warsaw wrote:
> On Mar 21, 2011, at 01:19 PM, R. David Murray wrote:
> 
>> So you are worried about the small window between me doing an 'svn up',
>> seeing no changes, and doing an 'svn ci'?  I suppose that is a legitimate
>> concern, but considering the fact that if the same thing happens in hg,
>> the only difference is that I know about it and have to do more work[*],
>> I don't think it really changes anything.  Well, it means that if your
>> culture uses the "always test" workflow you can't be *perfect* about it
>> if you use svn[**], which I must suppose has been your (and Stephen's)
>> point from the beginning.
>>
>> [*] that is, I'm *not* going to rerun the test suite even if I have to
>> pull/up/merge, unless there are conflicts.
> 
> I think if we really want full testing of all changesets landing on
> hg.python.org/cpython we're going to need a submit robot like PQM or Tarmac,
> although the latter is probably too tightly wedded to the Launchpad API, and I
> don't know if the former supports Mercurial.
> 
> With the benefits such robots bring, it's also important to understand the
> downsides.  There are more moving parts to maintain, and because landings are
> serialized, long test suites can sometimes cause significant backlogs.  Other
> than during the Pycon sprints, the backlog probably wouldn't be that big.
> 
> Another complication we'd have is running the test suite cross-platform, but I
> suspect that almost nobody does that today anyway.  So the buildbot farm would
> still be important.
> 
> -Barry

I'm personally a huge fan of 2(multi)-tier testing. So you have a basic
(and fast) test suite that runs across all your modules before every
commit in your mainline. Then a much larger (and slower) test suite that
runs regression testing across all platforms/etc that runs
asynchronously. Which gives you some basic protection against brown-bag
failures (you committed a typo in the main Python.h file, breaking
everyone). And still avoids a huge pushback on throughput.

I think Launchpad is currently looking to do batch-PQM. So that every
commit to the final mainline must pass the full test suite. However the
automated bot can grab multiple requests from the queue at a time, on
the premise that 90% of the time, none of them will break anything. So
you end up with a 100% stable trunk (any given revision committed by the
bot did pass the full test suite), but still get most of the throughput.

Also, by working in batch mode, if you have 20 submissions, and
submission #2 would have broken the test suite, it only bumps some (say
the first 5) submissions, and the other 15 still get to land in an
orderly fashion. You could even put any bumped submissions into a
deferred 'one-by-one' queue.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Ib6QACgkQJdeBCYSNAAPJWwCggyeS5DZlm/DR7bo+1AmpD9rr
YmMAoLFmmu7VBTJJX/khyigaOPU9dDE9
=68rK
-----END PGP SIGNATURE-----

From ncoghlan at gmail.com  Tue Mar 22 11:11:02 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Mar 2011 20:11:02 +1000
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
In-Reply-To: <AANLkTik6CZbJj2cPO+807vcp85S3qTfC-w5fMjmdzkuj@mail.gmail.com>
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
	<4D6AB409.40001@canterbury.ac.nz>
	<loom.20110322T000609-760@post.gmane.org>
	<AANLkTik6CZbJj2cPO+807vcp85S3qTfC-w5fMjmdzkuj@mail.gmail.com>
Message-ID: <AANLkTimpM8ysUzJL1idHoKXuFCpbYgAjzaGb2DFsVF=u@mail.gmail.com>

On Tue, Mar 22, 2011 at 9:21 AM, Guido van Rossum <guido at python.org> wrote:
> In the light of the recent discussion about Hg clones, perhaps you
> could make this a server-side clone so it's easier for others to play
> along?

Anyone without push rights for hg.python.org may want to fork the
mirror the bitbucket folks set up during the PyCon sprints to avoid
having to push the whole repository up to a separate hosting site:
https://bitbucket.org/mirror/cpython

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Mar 22 11:16:47 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Mar 2011 20:16:47 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87D2B2.5060901@v.loewis.de>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
	<20110321172505.33b3d507@neurotica.wooz.org>
	<20110321223153.1a0128ed@pitrou.net>
	<AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>
	<4D87CCA7.40002@v.loewis.de>
	<1300745738.3516.13.camel@localhost.localdomain>
	<4D87D2B2.5060901@v.loewis.de>
Message-ID: <AANLkTins3EfETmQ1iS=PSQDkrG+u11kaHeS0a_1V=Ysr@mail.gmail.com>

On Tue, Mar 22, 2011 at 8:35 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Well, it's "should", not "must" ;)
>> When writing this, I had in mind that other projects have different
>> workflows, where indeed people never collapse and many tiny changesets
>> (which are only significant as part of a bigger work) end up in the main
>> history. The point is to signal that it's not how we work.
>
> Having to be nitpicking here "not how you (Antoine) want us to work".
> "We" aren't using mercurial long enough to make such a statement.
>
> I still propose to loosen this restriction, and go with that for a
> while. Perhaps improve the email hook to give more condensed reports.
> If people then complain about too much fine-grainedness, we could
> tighten it again.

I think our experience from the sprints was enough to realise that
wording couldn't realistically mean "never do micro commits". If you
commit something, then notice a typo, or that you forgot to update
NEWS or ACKS, then sure, go ahead and push the main commit along with
any small cleanups and merges that were needed.

It was more designed to say "please land big changes as a single
coherent patch, not as a long series of experimentation and
micro-commits".

So "SHOULD" is the right word - we really do want to try to keep
things to coherent patches, but will occasionally have small cleanup
commits as well. That isn't really any different from the way we
worked with SVN, with later commits to add NEWS entries, fix issue
references, etc when the original commit missed something.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From john at arbash-meinel.com  Tue Mar 22 11:19:07 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Tue, 22 Mar 2011 11:19:07 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110321161901.6fdb7d50@limelight.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<20110321161901.6fdb7d50@limelight.wooz.org>
Message-ID: <4D88779B.3040508@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/21/2011 9:19 PM, Barry Warsaw wrote:
> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
> 
>> Keeping the repository clean makes it easier to use a bisection search to
>> hunt down the introduction of a bug.  If  every developer's intermediate
>> commits make it into the main repository, it's hard to go back to an older
>> revision to test something, because many of the older revisions will be
>> broken in some way.
> 
> So maybe this gets at my earlier question about rebase being cultural
> vs. technology, and the response about bzr having a strong sense of mainline
> where hg doesn't.
> 
> I don't use the bzr-bisect plugin too much, but I think by default it only
> follows commits on the main line, unless a bisect point is identified within a
> merge (i.e. side) line.  So again, those merged intermediate changes are
> mostly ignored until they're needed.
> 
> -Barry

Bazaar is, to my knowledge, the only DVCS that has a "mainline"
emphasis. Which shows up in quite a few areas. The defaults for 'log',
having branch-stable revnos[1], and the 'bzr checkout' model for
managing a mainline.

The cultural aspects of this also show up. Since we default to not
showing merge commits in 'bzr log' (or even when shown, they are shown
indented), there is less impetus to remove them by default.[2]

Guido mentioned that when he does long-term development, there are a lot
of advantages to having intermediate snapshots that he can roll back to,
which have questionable benefit in being in the final repository, since
some states were dead-ends that weren't pursued.

I certainly can understand that, but there is at least an argument that
preserving "this approach is a dead-end" also has some merit. If someone
comes to you and says "why didn't you implement it this way", you can
point to it and say "I tried, it didn't work". Which would also give
them a point to start if they really think it is an avenue to pursue
further.

I also remember something my Math teacher once said. That some of the
early proofs were so polished that nobody knew how to "reproduce" them.
Sure, anyone could follow the final proof and say "yes that is correct",
but nobody could *learn* from the proof, because it was missing those
human-level steps of intuition that helped understand *how* the proof
was developed, rather than just what the final state was.

That is not to say that the python.org primary repository should be a
teaching repository. However, I know that I'm personally quite curious
to see how Guido does his work. Insight into the minds of how
interesting people do interesting things and all.


Another key point of how tools influence and interact with culture.
Because bzr has a strong mainline bias, it leads to people interacting
with the tool differently, which strengthens and reinforces it. In
Mercurial, it would be trivial to add a "hg log --only-mainline" that
would always follow a specific parent and show that to you. However,
because Mercurial doesn't default to that view, people don't try to
preserve the mainline. For example, in these graphs are logically the
same, but result in a very different mainline view:


 A -- B -- C
       \    \
         D -- E

 A -- B -- C -- E
       \      /
         D --

If you consider D as "I did my work" and E as "and I integrated that
back into trunk".

If you merge the trunk revision C into E, and then push, you end up with
this graph:

 A -- B -- D -- E
       \      /
         C --

And suddenly the revision which was an "important" C change is now gone
on the mainline, and your personal "and I did D" is now a primary
revision. It doesn't matter much for a single revision D and C, but for
anything long lived, you end up with 100 Guido exploratory D revisions,
and some 50+ other python-dev super-stable trunk C revisions. And unless
the tool helps you preserve the ordering[3], you really don't want to
trying to treat them with different levels of authority. Hence, you tend
to collapse, because you really can only trust "E" to be a final stable
change.

John
=:->



[1] any copy of "trunk" has the same revision-id matching revno 1234,
    in Mercurial the numbers in 'hg log' correspond to the ordering in
    the physical repository, so depend on what order revisions were
    merged, etc.

[2] The downside is people having their work merged and then wondering
    "where did my commits go", and it looking like this guy named Patch
    was an extremely productive developer of Launchpad and Bazaar
    (Patch Queue Manager.)

[3] In Bazaar, you can set 'append_revisions_only = True' for
    integration branches. Which will refuse to push E if it would
    remove C as a mainline revision.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Id5sACgkQJdeBCYSNAAMnjgCbBFiMtdkj8hvJ19dPn3Maz3Bo
TrwAmwfgmg0YMGaCPM+W+kAVVDVvrOlY
=6oWG
-----END PGP SIGNATURE-----

From skip at pobox.com  Tue Mar 22 11:54:21 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 05:54:21 -0500
Subject: [Python-Dev] crosses branches?
Message-ID: <19848.32733.782152.25450@montanaro.dyndns.org>

I came across a new message I neither understood before or after searching
for it on Google (and thus the documentation):

    % hg pull -u
    pulling from /Users/skip/src/hgpython/2.6
    searching for changes
    adding changesets
    adding manifests
    adding file changes
    added 242 changesets with 766 changes to 263 files
    abort: crosses branches (use 'hg merge' or use 'hg update -c')

What does "crosses branches" mean?  From the couple instances I saw in the
docs I found I couldn't tell.

This was in my 2.5 repository, which I recall Guido saying he updated
recently (copyright file or something?).

I should point out that I have a local commit which I don't want to push.
That fixes the build problem with the unexpanded $HeadURL$ svn keyword:

    changeset:   68309:c3caaf979b9e
    branch:      2.5
    parent:      68263:7790ad8332ba
    user:        Skip Montanaro <skip at pobox.com>
    date:        Sun Mar 06 21:31:25 2011 -0600
    summary:     manually expand the defunct HeadURL subversion keyword

Skip

From adrian at cadifra.com  Tue Mar 22 12:07:43 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Tue, 22 Mar 2011 12:07:43 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D88779B.3040508@arbash-meinel.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>	<20110321161901.6fdb7d50@limelight.wooz.org>
	<4D88779B.3040508@arbash-meinel.com>
Message-ID: <4D8882FF.2040609@cadifra.com>

On 2011-03-22 11:19, John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 3/21/2011 9:19 PM, Barry Warsaw wrote:
>> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>>
>>> Keeping the repository clean makes it easier to use a bisection search to
>>> hunt down the introduction of a bug.  If  every developer's intermediate
>>> commits make it into the main repository, it's hard to go back to an older
>>> revision to test something, because many of the older revisions will be
>>> broken in some way.
>>
>> So maybe this gets at my earlier question about rebase being cultural
>> vs. technology, and the response about bzr having a strong sense of mainline
>> where hg doesn't.
>>
>> I don't use the bzr-bisect plugin too much, but I think by default it only
>> follows commits on the main line, unless a bisect point is identified within a
>> merge (i.e. side) line.  So again, those merged intermediate changes are
>> mostly ignored until they're needed.
>>
>> -Barry
> 
> Bazaar is, to my knowledge, the only DVCS that has a "mainline"
> emphasis. Which shows up in quite a few areas. The defaults for 'log',
> having branch-stable revnos[1], and the 'bzr checkout' model for
> managing a mainline.
> 

FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
branch name is reserved, and it implies that the head with the highest
revision number from that branch will be checked out on 'hg clone'.

Which is why it makes sense to have something sensible on the default
branch in Mercurial repositories. Or inadvertent people may be surprised
when they clone ("After cloning, the files I have seem to be from a very
old state of the project, WTF?").

What's more, 'hg log' suppresses printing the line 'branch: default' for
changesets on that branch and commits after 'hg init' go into the
default branch if 'hg branch <name>' hasn't been used. So, the initial
branch name of a fresh working copy is 'default'.

From ncoghlan at gmail.com  Tue Mar 22 12:11:42 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Mar 2011 21:11:42 +1000
Subject: [Python-Dev] Useful "hg log" trick to only see revisions in the
	current branch
Message-ID: <AANLkTi=4TQYjSngtZ=-CjBe2S3BA8pw7J=VC3d-AOSUn@mail.gmail.com>

"hg log -b ." restricts the hg log output to the changesets in the
currently active branch.

Other commands (such as "hg outgoing") similarly accept "-b ." to
request restricting their operation to the current branch.

Also, for anyone that wasn't already aware, "hg update" supports tab
completion when switching branches, which can make life a bit easier
when working with named branches.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Mar 22 12:40:58 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Mar 2011 21:40:58 +1000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <20110321225814.33a3f3ea@pitrou.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19847.13078.526390.539879@montanaro.dyndns.org>
	<20110321112531.0c98a191@limelight.wooz.org>
	<2BCDC99C-B199-4959-9404-51F0E12F7420@gmail.com>
	<AANLkTikOiiF_pv9ih3n44m_Jwm_vnDvT-o_SkbKHXtsG@mail.gmail.com>
	<20110321225814.33a3f3ea@pitrou.net>
Message-ID: <AANLkTimaQqvKiFiQuc1X7O83ux_dABg243LOr_-TXeT2@mail.gmail.com>

On Tue, Mar 22, 2011 at 7:58 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 22 Mar 2011 07:32:33 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> As far as the second point goes, I'm coming to the view that we should
>> avoid rebase/strip/rollback when intending to push to the main
>> repository, and do long term work in *separate* cloned repositories.
>> Then an rdiff with the relevant cpython branch will create a nice
>> collapsed patch ready for application to the main repository (I have
>> yet to succeed in generating a nice patch without using rdiff, but I
>> still have some more experimentation to do with MvL's last proposed
>> command for that before giving up on the idea).
>
> If you use named branches it's very easy, as explained in the devguide:
> http://docs.python.org/devguide/committing.html#long-term-development-of-features

Yeah, it turns out I had messed up the 'respect_LHS_precedence' branch
in my sandbox , which is why the diffs from there were broken (I had
temporarily merged those changes to "default" and then reverted them,
but subsequently merged the reversion back to the feature branch.
Oops. Fixed now, though, so "hg diff -r default" is once again doing
the right thing).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From techtonik at gmail.com  Tue Mar 22 12:57:39 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 22 Mar 2011 13:57:39 +0200
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
	first experience)
Message-ID: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>

I didn't touch Python3 until PyCon, and my first user experience is
not really good. I've got a feeling that Python3 became more ugly,
because it doesn't allow me to think about the logic anymore, and
requires more low-level workarounds even for basic user input/output.

For example, now I need to remember that on Windows I need to flush
output every time when I want the result of print() with end!='\n' to
appear on the screen immediately. And for the most of my legacy
scripts I used end='\n' when I want to output some progress to user. I
am surprised to know this never worked on Linux, but what I really
didn't expect is to see that choice is made not in user's favor, but
in a favor of speed. This way we'll be writing in a cross-platform
assembly language named 'Python' soon. =)
http://bugs.python.org/issue11633
-- 
anatoly t.

From rndblnch at gmail.com  Tue Mar 22 13:06:35 2011
From: rndblnch at gmail.com (rndblnch)
Date: Tue, 22 Mar 2011 12:06:35 +0000 (UTC)
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
	<4D6AB409.40001@canterbury.ac.nz>
	<loom.20110322T000609-760@post.gmane.org>
	<AANLkTik6CZbJj2cPO+807vcp85S3qTfC-w5fMjmdzkuj@mail.gmail.com>
	<AANLkTimpM8ysUzJL1idHoKXuFCpbYgAjzaGb2DFsVF=u@mail.gmail.com>
Message-ID: <loom.20110322T125508-35@post.gmane.org>

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> On Tue, Mar 22, 2011 at 9:21 AM, Guido van Rossum <guido <at> python.org>
wrote:
> > In the light of the recent discussion about Hg clones, perhaps you
> > could make this a server-side clone so it's easier for others to play
> > along?

I don't have push rights so I can not push anything to <http://hg.python.org/>.
However, I tried to click the "server side clone", and to my surprise, it
worked. I was expecting that some verification would be made, but there is now
a new feature branch at: <http://hg.python.org/features/pep-380/>.
Sorry to have done that, once again, I was not expecting to actually have the
rights to cause any side-effect on <http://hg.python.org/>. I guess that it may
not be desirable to allow anyone do such server-side clone.

Anyway, I can not push to this feature branch, so for now it's just a clone of
the curent tip.

> Anyone without push rights for hg.python.org may want to fork the
> mirror the bitbucket folks set up during the PyCon sprints to avoid
> having to push the whole repository up to a separate hosting site:
> https://bitbucket.org/mirror/cpython

Done here:
<https://bitbucket.org/rndblnch/cpython-pep380/>

The pep-380 changeset is pushed on top of current tip and is visible here:
<https://bitbucket.org/rndblnch/cpython-pep380/changeset/40b19d1933ea>

renaud





From ncoghlan at gmail.com  Tue Mar 22 13:15:22 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Mar 2011 22:15:22 +1000
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
In-Reply-To: <loom.20110322T125508-35@post.gmane.org>
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
	<4D6AB409.40001@canterbury.ac.nz>
	<loom.20110322T000609-760@post.gmane.org>
	<AANLkTik6CZbJj2cPO+807vcp85S3qTfC-w5fMjmdzkuj@mail.gmail.com>
	<AANLkTimpM8ysUzJL1idHoKXuFCpbYgAjzaGb2DFsVF=u@mail.gmail.com>
	<loom.20110322T125508-35@post.gmane.org>
Message-ID: <AANLkTi=Rfud3_sjTrnVN0=EdbTFqn0CXGNL004Vbufrh@mail.gmail.com>

On Tue, Mar 22, 2011 at 10:06 PM, rndblnch <rndblnch at gmail.com> wrote:
> Sorry to have done that, once again, I was not expecting to actually have the
> rights to cause any side-effect on <http://hg.python.org/>. I guess that it may
> not be desirable to allow anyone do such server-side clone.

Unmodified clones don't actually take up much space due to the way the
filesystem on the server works, and if they don't get updated within a
short period of being created (i.e. by someone with commit rights),
the server gets rid of them automatically.

>> Anyone without push rights for hg.python.org may want to fork the
>> mirror the bitbucket folks set up during the PyCon sprints to avoid
>> having to push the whole repository up to a separate hosting site:
>> https://bitbucket.org/mirror/cpython
>
> Done here:
> <https://bitbucket.org/rndblnch/cpython-pep380/>
>
> The pep-380 changeset is pushed on top of current tip and is visible here:
> <https://bitbucket.org/rndblnch/cpython-pep380/changeset/40b19d1933ea>

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From sjoerd at acm.org  Tue Mar 22 13:09:27 2011
From: sjoerd at acm.org (Sjoerd Mullender)
Date: Tue, 22 Mar 2011 13:09:27 +0100
Subject: [Python-Dev] crosses branches?
In-Reply-To: <19848.32733.782152.25450@montanaro.dyndns.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
Message-ID: <4D889177.6050601@acm.org>

On 2011-03-22 11:54, skip at pobox.com wrote:
> I came across a new message I neither understood before or after searching
> for it on Google (and thus the documentation):
> 
>     % hg pull -u
>     pulling from /Users/skip/src/hgpython/2.6
>     searching for changes
>     adding changesets
>     adding manifests
>     adding file changes
>     added 242 changesets with 766 changes to 263 files
>     abort: crosses branches (use 'hg merge' or use 'hg update -c')
> 
> What does "crosses branches" mean?  From the couple instances I saw in the
> docs I found I couldn't tell.
> 
> This was in my 2.5 repository, which I recall Guido saying he updated
> recently (copyright file or something?).
> 
> I should point out that I have a local commit which I don't want to push.
> That fixes the build problem with the unexpanded $HeadURL$ svn keyword:
> 
>     changeset:   68309:c3caaf979b9e
>     branch:      2.5
>     parent:      68263:7790ad8332ba
>     user:        Skip Montanaro <skip at pobox.com>
>     date:        Sun Mar 06 21:31:25 2011 -0600
>     summary:     manually expand the defunct HeadURL subversion keyword

Since you have a local change, you cannot use hg pull -u (or rather, hg
update).  Hg wouldn't know where to update to since there are 2 heads in
the branch you're on: the new head from the server and your own head
with your change.

There are two possibilities: hg merge + hg commit to merge your change
with the change from the server, or hg rebase (after you enable the
extension and with extra arguments to specify source and destination
revisions).  This would take your change and graft if on top of the head
from the server.

Instead of using hg pull -u, you could have used hg pull --rebase (after
enabling the extension) to do the rebase automatically.  But that is for
next time.

-- 
Sjoerd Mullender

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 371 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/143dfe53/attachment.pgp>

From pmatilai at laiskiainen.org  Tue Mar 22 10:29:25 2011
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 22 Mar 2011 11:29:25 +0200
Subject: [Python-Dev] [GSoC] Porting on RPM3
In-Reply-To: <1300755982.2666.4869.camel@surprise>
References: <AANLkTik0C8JdwCafpgeoq10_nm7J4yRBqR-LSSqniwOO@mail.gmail.com>	
	<4D871F68.4000608@v.loewis.de>
	<1300755982.2666.4869.camel@surprise>
Message-ID: <4D886BF5.4000903@laiskiainen.org>

On 03/22/2011 03:06 AM, David Malcolm wrote:
> [CCing Panu Matilainen, the maintainer of rpm, or, at least rpm 4.*,
> which is what all major distributions are using AIUI]
>
> On Mon, 2011-03-21 at 10:50 +0100, "Martin v. L?wis" wrote:
>> Am 21.03.2011 07:37, schrieb Prashant Kumar:
>>> Hello,
>>>      My name is  Prashant Kumar and I've worked on porting few python
>>> libraries(distutils2, configobj) and I've been looking at the ideas
>>> list for GSoC for a project related to porting.
>>>
>>>      I came across [1]  and found it interesting. It mentions that some
>
> Hi Prashant!  Thanks for the interest.
>
> Panu: [1] is http://wiki.python.org/moin/RPMOnPython3 , a Google Summer
> of Code proposal to work on the Python 3 bindings to RPM.
>
>>> of the work has already been done; I would like to look at the code
>>> repository for the same, could someone provide me the link for the
>>> same?
>
>> Not so much the code but the person who did the porting. This was Dave
>> Malcolm (CC'ed); please get in touch with him. Please familiarize
>> yourself with the existing Python bindings (in the latest RPM 4 release
>> from rpm.org). You'll notice that this already has Python 3 support;
>> not sure whether that's the most recent code, though.
>
> Panu Matilainen also worked on the python 3 port of the librpm python
> bindings.
>
> For the rpm source code, see: http://rpm.org/wiki/GetSource  (the python
> bindings are in a subdirectory of the main source tree).
>
> My initial patchbomb landed on the mailing list here:
>    http://lists.rpm.org/pipermail/rpm-maint/2009-October/002528.html
> and Panu committed and fixed up the patches around then.
>
> My understanding is that the current status is that the bindings work,
> but all values that were formerly exposed to Python 2 as "str" are now
> exposed to Python 3 as "bytes", which would require changing all
> consumers of the code.

That's more or less where it stands.

> I believe Panu has also been working on a rewrite of the Python
> bindings, since the existing code is a little messy.
> Panu, am I remembering this correctly?

The python binding rewrite was abandoned (it just didn't work out for 
various reasons) and usable bits merged into the existing bindings.
So yes you're correct - there /was/ such a thing but any new work should 
go to the bindings that exist in the main rpm source tree.

> The idea is that these types are fundamentally string-like, but
> unfortunately rpm has always been a bit loose in its interpretation of
> the encoding of byte values in package files and package databases.
> There are millions of rpm files out there, and millions of rpm
> databases, and all of these are in _some_ encoding.  I have seen
> specfiles in which parts of the file were encoded in UTF-8 and other
> parts were encoded in Latin-1 (this broke one of my python scripts
> horribly).

More precisely, it's not being "a bit loose" about encoding, rpm simply 
doesn't know diddly about encodings and does not make any assumptions or 
interpretations about them. A string in rpm is just a sequence of 
arbitrary non-zero byte values terminated with \0.

> Martin and I discussed this last week at PyCon.  I believe the proposal
> that we came up with was:
>    - try to interpret bytes as UTF-8, using the "surrogateescape"
> mechanism, so that if it fails, we can at least preserve the exact bytes
> and round-trip

Right, based on a quick skim of the surrogateescape PEP, that seems like 
a reasonable approach (rpm is much like the traditional POSIX interfaces 
which simply do not deal with encoding at all)

> Ultimately, this does mean trying to impose some kind of encoding
> standard on rpm files and rpm databases, which I think would be a Good
> Thing, but is perhaps something of scope creep compared to what the
> proposal at [1] says.  See e.g. http://rpm.org/ticket/30

Note that any frpm forced encoding standard could only affect new 
packages, but rpm and the bindings need to be able deal with all the 
junk out in the wild pretty much forever.

>
> Other ideas that occur:
>    - does rpmlint check for encoding yet?

IIRC rpmlint can (depending on config probably) check for encoding of 
the paths and the spec itself. However this still doesn't guarantee all 
the string-data in header to be utf, as practically any part(s) of the 
data can come from macros, which are not encoding-aware either.

>    - what to do e.g. about canonicalization?  What happens if one rpm
> provide a feature named "caf?" (where the "?" is U+00E9) and another rpm
> requires a feature named "caf?" (where the "?" is U+0065 LATIN SMALL
> LETTER E + U+0301 COMBINING ACUTE ACCENT)?  IIRC we ruled that rpms in
> Fedora had to have ASCII names, and I'm guessing this applies to
> metadata, but we do allow UTF-8 filenames within package payloads
> (again, IIRC)

Ouch. Did I already mention that UTF and the encoding business makes my 
head hurt? I guess I didn't, can't think straight because by now I have 
that headache...

Anyway, pretty much all rules in this area are distro specific, as rpm 
doesn't enforce anything wrt encoding.

The bindings cannot go changing header contents to their liking, so any 
canonicalization would have to go into rpm proper, the build-side of 
things to be exact so the runtime doesn't have to care. Requiring rpm to 
fiddle with encodings + canonicalization for every single string it 
processes at runtime would require enormous changes throughout rpm, and 
presumably at a massive performance cost too.

	- Panu -


From skip at pobox.com  Tue Mar 22 13:21:24 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 07:21:24 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <19848.37956.665020.538633@montanaro.dyndns.org>


    Stephen> This won't be pleasant if people are sprinting and lots of
    Stephen> commits are coming, because you're likely to repeatedly lose
    Stephen> the push race.  But in those conditions, nothing is guaranteed
    Stephen> to work in decentralized fashion (that's one reason why the
    Stephen> Linux kernel uses Linus and lieutenants as a serialization
    Stephen> mechanism).

So DVCS scales up to a point, then it breaks and you need to revert to some
sort of serialization scheme?

Skip

From foom at fuhm.net  Tue Mar 22 13:25:10 2011
From: foom at fuhm.net (James Y Knight)
Date: Tue, 22 Mar 2011 08:25:10 -0400
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
	first experience)
In-Reply-To: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
Message-ID: <C06BACFD-6F02-4621-AC7F-19BC98B66BAA@fuhm.net>

On Mar 22, 2011, at 7:57 AM, anatoly techtonik wrote:
> For example, now I need to remember that on Windows I need to flush
> output every time when I want the result of print() with end!='\n' to
> appear on the screen immediately. And for the most of my legacy
> scripts I used end='\n' when I want to output some progress to user. I
> am surprised to know this never worked on Linux, but what I really
> didn't expect is to see that choice is made not in user's favor, but
> in a favor of speed. This way we'll be writing in a cross-platform
> assembly language named 'Python' soon. =)
> http://bugs.python.org/issue11633

Yes, on linux, the C library sets up stderr to be unbuffered and stdout to be fully buffered unless it points to a terminal, in which case it's line buffered. (Of course that  can always be overridden using setvbuf.) So, yes, your program never worked on linux. If you'd sent the progress messages to stderr, it should've always worked, however.

This is partially specified by POSIX (it leaves leeway up to the implementor to choose line buffered or unbuffered when fully buffered isn't called for):
> At program start-up, three streams are predefined and need not be opened explicitly: standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). When opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device.


James

From skip at pobox.com  Tue Mar 22 13:26:25 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 07:26:25 -0500
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
Message-ID: <19848.38257.349896.870255@montanaro.dyndns.org>


    Senthil> Have a look at this issue:
    Senthil> http://bugs.python.org/issue11591

    Senthil> The magical UI is the FORM textbox element "Remote hg repo:"
    Senthil> where the user provided his bitbucket URL for the path he was
    Senthil> working on.

I still don't understand what that's supposed to look like.  Is it supposed
to be a URL which refers to my local repository?  If so, I suspect that
means I have to somehow make my repo globally visible and drill a hole in my
NAT firewall.

    Senthil> And when you pressed "Create Patch" button, it created a patch
    Senthil> and then attached to the issue tracker.  You can click on the
    Senthil> review button to post that patch to reitveld and do the
    Senthil> review,.

Sorry, I don't see a "Create Patch" button anywhere.  Are you referring to
some sort of Mercurial GUI?

Skip

From skip at pobox.com  Tue Mar 22 13:31:52 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 07:31:52 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <4D885E28.10601@avl.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D871DE1.6020307@v.loewis.de>
	<87zkoozm74.fsf@uwakimon.sk.tsukuba.ac.jp> <4D876711.1060707@avl.com>
	<19847.32856.903323.462779@montanaro.dyndns.org>
	<4D885E28.10601@avl.com>
Message-ID: <19848.38584.994788.790558@montanaro.dyndns.org>


    Hrvoje> If you are not familiar with other DVCS workflows, take a look
    Hrvoje> at, for example, chapter 5 of the "Pro Git" book, which
    Hrvoje> describes the alternatives such as integrator-manager and
    Hrvoje> dictator-lieutenant workflows: http://progit.org/book/ch5-1.html

Thanks.  That more-or-less answers the question I posed for Stephen a few
minutes ago.  (Oh, that I could read multiple messages in parallel!)

S

From rdmurray at bitdance.com  Tue Mar 22 13:49:46 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 22 Mar 2011 08:49:46 -0400
Subject: [Python-Dev] Useful "hg log" trick to only see revisions in the
	current branch
In-Reply-To: <AANLkTi=4TQYjSngtZ=-CjBe2S3BA8pw7J=VC3d-AOSUn@mail.gmail.com>
References: <AANLkTi=4TQYjSngtZ=-CjBe2S3BA8pw7J=VC3d-AOSUn@mail.gmail.com>
Message-ID: <20110322124947.2AF52EC887@kimball.webabinitio.net>

On Tue, 22 Mar 2011 21:11:42 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Also, for anyone that wasn't already aware, "hg update" supports tab
> completion when switching branches, which can make life a bit easier
> when working with named branches.

You are the second person I've heard say this, and it is a little
misleading.  At the point at which you hit 'tab' when typing an hg update
command, hg isn't running.  So it can't be 'hg update' that supports
tab completion, it must be your shell that supports tab completion *for*
hg update.  My zsh shell does, while my bash shell doesn't: because I
don't use bash, I installed mercurial without bash-completion.

So: there is completion support for hg update for both bash and zsh.
Not sure about other shells.

--
R. David Murray           http://www.bitdance.com

From orsenthil at gmail.com  Tue Mar 22 13:51:20 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Tue, 22 Mar 2011 20:51:20 +0800
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <19848.38257.349896.870255@montanaro.dyndns.org>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
Message-ID: <20110322125120.GA3274@kevin>

On Tue, Mar 22, 2011 at 07:26:25AM -0500, skip at pobox.com wrote:
> 
>     Senthil> The magical UI is the FORM textbox element "Remote hg repo:"
>     Senthil> where the user provided his bitbucket URL for the path he was
>     Senthil> working on.
> 
> I still don't understand what that's supposed to look like.  Is it supposed
> to be a URL which refers to my local repository?  

No, it is the "Remote Repository". It could be one at bitbucket.org or
code.google.com, both of which support creating mercurial
repositories. Or it could be a repository at hg.python.org and with a
url like hg.python.org/sandbox/skip or hg.python.org/skip

You will have to 'push' your changes to those so that they are
publicly visible and then point that url in the bug-tracker.

> If so, I suspect that
> means I have to somehow make my repo globally visible and drill a hole in my
> NAT firewall.

You can do that or use one of existing facilities available for
pushing your code to a public hg repository.


>     Senthil> And when you pressed "Create Patch" button, it created a patch
> Sorry, I don't see a "Create Patch" button anywhere.  Are you referring to
> some sort of Mercurial GUI?

No, the same http://bugs.python.org/issue11591
You have to be logged into the tracker to see "Create Patch" under a
section called "Repositories containing patches"

-- 
Senthil

From merwok at netwok.org  Tue Mar 22 13:53:28 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 22 Mar 2011 13:53:28 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <19848.38257.349896.870255@montanaro.dyndns.org>
References: <4D7D06F3.7020700@v.loewis.de>
	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
Message-ID: <4D889BC8.4080909@netwok.org>

> I still don't understand what that's supposed to look like.  Is it supposed
> to be a URL which refers to my local repository?
No, to a repository published somewhere (hg.python.org, bitbucket (make
a server-side clone of mirror/cpython), any other hosting service).

You have to use one public repo per bug, as roundup will only use the
default branch to compute the diff.  Maybe adding support for named
branches so that you can have one repo used for many bug reports would
be useful.

> Sorry, I don't see a "Create Patch" button anywhere.
On the right of the field containing the repo URI on
http://bugs.python.org/issue11591

Regards

From Tim.Golden at cbsoutdoor.co.uk  Tue Mar 22 14:08:21 2011
From: Tim.Golden at cbsoutdoor.co.uk (Tim Golden)
Date: Tue, 22 Mar 2011 13:08:21 +0000
Subject: [Python-Dev] blogroll for the new blog
Message-ID: <17E3183FF8D8EB47839A7E240AD39FA82FD331F889@SVR-EXCH-VMBX.gb.vo.local>

Well I've created a python-dev category under my usual blog so if you wouldn't mind adding that:

  http://ramblings.timgolden.me.uk/category/tech/python/python-dev/

TJG
Tim Golden
Senior Analyst Programmer

CBS Outdoor UK
Camden Wharf
28 Jamestown Road
London
NW1 7BY
T: 020 7482 3000
F: 020 7267 4944


http://www.cbsoutdoor.co.uk/
http://www.cbsoutdoor.co.uk/
http://www.cbsoutdoor.co.uk/Newsletter-sign-up
Don't waste paper. Think before you print.
The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed, and may also be privileged. If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this e-mail in error, please e-mail the sender by replying to this message. CBS Outdoor Ltd reserves the right to monitor e-mail communications from external/internal sources for the purposes of ensuring correct and appropriate use of CBS Outdoor facilities. CBS Outdoor Limited, registered in England and Wales with company number 02866133 and registered address at Camden Wharf, 28 Jamestown Road, London, NW1 7BY.




________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

From skip at pobox.com  Tue Mar 22 15:11:07 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 09:11:07 -0500
Subject: [Python-Dev] crosses branches?
In-Reply-To: <4D889177.6050601@acm.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
Message-ID: <19848.44539.573781.500799@montanaro.dyndns.org>


    Sjoerd> Since you have a local change, you cannot use hg pull -u (or
    Sjoerd> rather, hg update).  Hg wouldn't know where to update to since
    Sjoerd> there are 2 heads in the branch you're on: the new head from the
    Sjoerd> server and your own head with your change.

I see lots of heads, but that never prevented an update before.  How do I
tell which two heads are key to this case?  For completeness, here's the
output of hg heads in my 2.5 repository.  I only see one labelled "2.5".
What is the other head to which you referred?

    changeset:   68827:3114f26d5d54
    tag:         tip
    user:        Victor Stinner <victor.stinner at haypocalc.com>
    date:        Tue Mar 22 10:46:35 2011 +0100
    summary:     Issue #11630, issue #3080: Fix refleak introduced by
    ef2b6305d395

    changeset:   68804:f316e6d6271a
    branch:      2.7
    parent:      68801:6b2edc385ffe
    parent:      68803:b99c94261225
    user:        Martin v. L?wis <martin at v.loewis.de>
    date:        Mon Mar 21 10:32:02 2011 +0100
    summary:     null merge

    changeset:   68309:c3caaf979b9e
    branch:      2.5
    parent:      68263:7790ad8332ba
    user:        Skip Montanaro <skip at pobox.com>
    date:        Sun Mar 06 21:31:25 2011 -0600
    summary:     manually expand the defunct HeadURL subversion keyword

    changeset:   68249:4cd9f5e89061
    branch:      3.0
    user:        Georg Brandl <georg at python.org>
    date:        Sat Mar 05 15:09:43 2011 +0100
    summary:     Close 3.0 branch.

    changeset:   68241:b77918288f7d
    branch:      legacy-trunk
    user:        Georg Brandl <georg at python.org>
    date:        Sat Mar 05 14:57:44 2011 +0100
    summary:     Close legacy-trunk branch.

    changeset:   68239:ceec209b26d4
    branch:      2.4
    user:        Georg Brandl <georg at python.org>
    date:        Sat Mar 05 14:56:41 2011 +0100
    summary:     Close 2.4 branch.

    changeset:   68237:364638d6434d
    branch:      2.3
    user:        Georg Brandl <georg at python.org>
    date:        Sat Mar 05 14:55:46 2011 +0100
    summary:     Close 2.3 branch.

    changeset:   68235:61b0263d6881
    branch:      2.2
    user:        Georg Brandl <georg at python.org>
    date:        Sat Mar 05 14:55:23 2011 +0100
    summary:     Close 2.2 branch.

    changeset:   68233:e849d484029f
    branch:      2.1
    user:        Georg Brandl <georg at python.org>
    date:        Sat Mar 05 14:54:46 2011 +0100
    summary:     Close 2.1 branch.

    changeset:   68231:5fd74354d73b
    branch:      2.0
    user:        Georg Brandl <georg at python.org>
    date:        Sat Mar 05 14:54:19 2011 +0100
    summary:     Close 2.0 branch.

    Sjoerd> There are two possibilities: hg merge + hg commit to merge your
    Sjoerd> change with the change from the server, or hg rebase (after you
    Sjoerd> enable the extension and with extra arguments to specify source
    Sjoerd> and destination revisions).  This would take your change and
    Sjoerd> graft if on top of the head from the server.

Looking here at the Common Cases section:

    http://mercurial.selenic.com/wiki/RebaseProject

I can see how I have now apparently got this situation:

     C1 --> C2 --> S1
            \
             \ --> ... Cn

(where S1 is my local change and C? are the central changesets)

Rebase will do this, right?

     C1 --> C2 --> ... --> Cn --> S1

Am I going to have to rebase then every time I re-pull that repository and
incorporate new upstream changes?  Wouldn't I rather want the chain of
revisions to look like this after the rebase step?

     C1 --> C2 --> S1 --> ... --> Cn

Skip


From barry at python.org  Tue Mar 22 15:14:17 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Mar 2011 10:14:17 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87CCA7.40002@v.loewis.de>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<20110321180740.27947057@pitrou.net>
	<20110321142954.4e301fb2@limelight.wooz.org>
	<20110321193818.66fee202@pitrou.net>
	<20110321163331.4277ffd0@limelight.wooz.org>
	<20110321215326.0767c775@pitrou.net>
	<20110321172505.33b3d507@neurotica.wooz.org>
	<20110321223153.1a0128ed@pitrou.net>
	<AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>
	<4D87CCA7.40002@v.loewis.de>
Message-ID: <20110322101417.17bdec82@neurotica.wooz.org>

On Mar 21, 2011, at 11:09 PM, Martin v. L?wis wrote:

>However, what some of us requesting is that the "SHOULD collapse"
>in the devguide is changed to a "MAY collapse", making it strictly
>an option of the committer.

+1

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/b7f45e26/attachment.pgp>

From barry at python.org  Tue Mar 22 15:22:08 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Mar 2011 10:22:08 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D8882FF.2040609@cadifra.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<20110321161901.6fdb7d50@limelight.wooz.org>
	<4D88779B.3040508@arbash-meinel.com> <4D8882FF.2040609@cadifra.com>
Message-ID: <20110322102208.78d0a279@neurotica.wooz.org>

On Mar 22, 2011, at 12:07 PM, Adrian Buehlmann wrote:

>FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
>branch name is reserved, and it implies that the head with the highest
>revision number from that branch will be checked out on 'hg clone'.

I think that's different than what John was describing, or perhaps Python's
use of it has the effect of being different.  IIUC, in Mercurial, within the
default branch there's no clear "main line" of development assigned to a path
within the DAG.  All paths are created equal, so it's not possible to
e.g. have log or bisect suppress one path containing feature sub-commits from
the point of departure to the point of recombination (merge).

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/8a550b7b/attachment.pgp>

From barry at python.org  Tue Mar 22 15:25:57 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Mar 2011 10:25:57 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87E4A6.1090404@netwok.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz> <4D87E4A6.1090404@netwok.org>
Message-ID: <20110322102557.516914f6@neurotica.wooz.org>

On Mar 22, 2011, at 12:52 AM, ?ric Araujo wrote:

>Bazaar apparently has a notion of mainline whereas Mercurial believes
>that all changesets are created equal.  The tools are different.

I'm curious: what are the benefits of the Mercurial model?

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/83c05102/attachment.pgp>

From barry at python.org  Tue Mar 22 15:28:16 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Mar 2011 10:28:16 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D8846F4.7030604@v.loewis.de>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz> <4D87E4A6.1090404@netwok.org>
	<AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>
	<4D87EE32.9040109@v.loewis.de>
	<AANLkTikJ22CkmGLfXe2V=J3sdtOq9YrTZ77kwobhTV5d@mail.gmail.com>
	<4D8846F4.7030604@v.loewis.de>
Message-ID: <20110322102816.38747b1e@neurotica.wooz.org>

On Mar 22, 2011, at 07:51 AM, Martin v. L?wis wrote:

>Am 22.03.2011 02:02, schrieb Eugene Toder:
>>> Not if the changes you want to suppress are actually also on the same
>>> branch as the one whose mainline you are trying to see (which they
>>> typically are, with the branch typically being "default").
>>
>> Right, that would amount to not using named branches. But if you
>> develop on a named feature-branch and merge into "default" when ready
>> your local history is easy to filter-out without rebasing or
>> collapsing.
>
>Ah. We don't support this kind of development - no new named branches
>are allowed in the central repository.

It does sound like that restriction is a source of friction for us.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/88215025/attachment.pgp>

From fdrake at acm.org  Tue Mar 22 15:30:45 2011
From: fdrake at acm.org (Fred Drake)
Date: Tue, 22 Mar 2011 10:30:45 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110322102557.516914f6@neurotica.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au> <4D87E34E.2000201@canterbury.ac.nz>
	<4D87E4A6.1090404@netwok.org>
	<20110322102557.516914f6@neurotica.wooz.org>
Message-ID: <AANLkTi=GdVCkMTHQaDkTuaTU7WmwnzPdYYV8pUcE2cWH@mail.gmail.com>

On Tue, Mar 22, 2011 at 10:25 AM, Barry Warsaw <barry at python.org> wrote:
> I'm curious: what are the benefits of the Mercurial model?

If we're all left confused and unable to use the tools to change the
software, we won't break things.  This is good.  :-)


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein

From p.f.moore at gmail.com  Tue Mar 22 15:41:07 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 22 Mar 2011 14:41:07 +0000
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D889BC8.4080909@netwok.org>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
	<4D889BC8.4080909@netwok.org>
Message-ID: <AANLkTi=7zfaLW65gP9VBQr-aJ1bCVbdu5to_h+sHYdkP@mail.gmail.com>

On 22 March 2011 12:53, ?ric Araujo <merwok at netwok.org> wrote:
>> I still don't understand what that's supposed to look like. ?Is it supposed
>> to be a URL which refers to my local repository?
> No, to a repository published somewhere (hg.python.org, bitbucket (make
> a server-side clone of mirror/cpython), any other hosting service).
>
> You have to use one public repo per bug, as roundup will only use the
> default branch to compute the diff. ?Maybe adding support for named
> branches so that you can have one repo used for many bug reports would
> be useful.

I don't know if it's supported here, but Mercurial allows branch names
in URLS. See "hg help urls" but it's basically something like

    http://hg.python.org/cpython#3.1

Paul.

From sjoerd at acm.org  Tue Mar 22 15:39:55 2011
From: sjoerd at acm.org (Sjoerd Mullender)
Date: Tue, 22 Mar 2011 15:39:55 +0100
Subject: [Python-Dev] crosses branches?
In-Reply-To: <19848.44539.573781.500799@montanaro.dyndns.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
	<19848.44539.573781.500799@montanaro.dyndns.org>
Message-ID: <4D88B4BB.1020700@acm.org>

On 2011-03-22 15:11, skip at pobox.com wrote:
> 
>     Sjoerd> Since you have a local change, you cannot use hg pull -u (or
>     Sjoerd> rather, hg update).  Hg wouldn't know where to update to since
>     Sjoerd> there are 2 heads in the branch you're on: the new head from the
>     Sjoerd> server and your own head with your change.
> 
> I see lots of heads, but that never prevented an update before.  How do I
> tell which two heads are key to this case?  For completeness, here's the
> output of hg heads in my 2.5 repository.  I only see one labelled "2.5".
> What is the other head to which you referred?

Two heads in the same branch.
Are you sure the hg pull part worked?  When I update I see there are
changes on the 2.5 branch which I would expect to see in your list.
It probably never happened before because nobody committed a change to
the 2.5 branch since you made your change.

So, try hg pull and the look at the heads again.

>     changeset:   68827:3114f26d5d54
>     tag:         tip
>     user:        Victor Stinner <victor.stinner at haypocalc.com>
>     date:        Tue Mar 22 10:46:35 2011 +0100
>     summary:     Issue #11630, issue #3080: Fix refleak introduced by
>     ef2b6305d395
> 
>     changeset:   68804:f316e6d6271a
>     branch:      2.7
>     parent:      68801:6b2edc385ffe
>     parent:      68803:b99c94261225
>     user:        Martin v. L?wis <martin at v.loewis.de>
>     date:        Mon Mar 21 10:32:02 2011 +0100
>     summary:     null merge
> 
>     changeset:   68309:c3caaf979b9e
>     branch:      2.5
>     parent:      68263:7790ad8332ba
>     user:        Skip Montanaro <skip at pobox.com>
>     date:        Sun Mar 06 21:31:25 2011 -0600
>     summary:     manually expand the defunct HeadURL subversion keyword
> 
>     changeset:   68249:4cd9f5e89061
>     branch:      3.0
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 15:09:43 2011 +0100
>     summary:     Close 3.0 branch.
> 
>     changeset:   68241:b77918288f7d
>     branch:      legacy-trunk
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:57:44 2011 +0100
>     summary:     Close legacy-trunk branch.
> 
>     changeset:   68239:ceec209b26d4
>     branch:      2.4
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:56:41 2011 +0100
>     summary:     Close 2.4 branch.
> 
>     changeset:   68237:364638d6434d
>     branch:      2.3
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:55:46 2011 +0100
>     summary:     Close 2.3 branch.
> 
>     changeset:   68235:61b0263d6881
>     branch:      2.2
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:55:23 2011 +0100
>     summary:     Close 2.2 branch.
> 
>     changeset:   68233:e849d484029f
>     branch:      2.1
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:54:46 2011 +0100
>     summary:     Close 2.1 branch.
> 
>     changeset:   68231:5fd74354d73b
>     branch:      2.0
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:54:19 2011 +0100
>     summary:     Close 2.0 branch.
> 
>     Sjoerd> There are two possibilities: hg merge + hg commit to merge your
>     Sjoerd> change with the change from the server, or hg rebase (after you
>     Sjoerd> enable the extension and with extra arguments to specify source
>     Sjoerd> and destination revisions).  This would take your change and
>     Sjoerd> graft if on top of the head from the server.
> 
> Looking here at the Common Cases section:
> 
>     http://mercurial.selenic.com/wiki/RebaseProject
> 
> I can see how I have now apparently got this situation:
> 
>      C1 --> C2 --> S1
>             \
>              \ --> ... Cn
> 
> (where S1 is my local change and C? are the central changesets)
> 
> Rebase will do this, right?
> 
>      C1 --> C2 --> ... --> Cn --> S1
> 
> Am I going to have to rebase then every time I re-pull that repository and
> incorporate new upstream changes?  Wouldn't I rather want the chain of
> revisions to look like this after the rebase step?
> 
>      C1 --> C2 --> S1 --> ... --> Cn
> 
> Skip
> 


-- 
Sjoerd Mullender

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 371 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/551c5ff4/attachment.pgp>

From john at arbash-meinel.com  Tue Mar 22 16:09:13 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Tue, 22 Mar 2011 16:09:13 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110322102208.78d0a279@neurotica.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>	<20110321161901.6fdb7d50@limelight.wooz.org>	<4D88779B.3040508@arbash-meinel.com>
	<4D8882FF.2040609@cadifra.com>
	<20110322102208.78d0a279@neurotica.wooz.org>
Message-ID: <4D88BB99.7010504@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/22/2011 3:22 PM, Barry Warsaw wrote:
> On Mar 22, 2011, at 12:07 PM, Adrian Buehlmann wrote:
> 
>> FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
>> branch name is reserved, and it implies that the head with the highest
>> revision number from that branch will be checked out on 'hg clone'.
> 
> I think that's different than what John was describing, or perhaps Python's
> use of it has the effect of being different.  IIUC, in Mercurial, within the
> default branch there's no clear "main line" of development assigned to a path
> within the DAG.  All paths are created equal, so it's not possible to
> e.g. have log or bisect suppress one path containing feature sub-commits from
> the point of departure to the point of recombination (merge).
> 
> -Barry

If you think of "mainline" as "trunk" or "master", then yes, Mercurial's
concept is "default".

If you think of "mainline" as a series of commits in a linear sequence,
then there isn't specifically a "main" "line" in Mercurial's world view.

In Bazaar, the sequence of first-parents in the history of a branch's
tip is considered special. Based on the concept that:

 cd me
 bzr merge ../you
 bzr commit -m "I merged you"

Is not the same *social* thing as:

 cd ../you
 bzr merge ../me
 bzr commit -m "You merged me"

Logically, the contents of the tree should be the same. The name of the
person doing it is often different. If you have "blessed branch"
approach to development (which almost all projects do at some level or
other) then merging something into the "blessed branch" is not the same
as merging the "blessed branch" into your personal branch.

For python, the "blessed branch" is http://hg.python.org/cpython.

Consider, if someone merges/pushes a change to that branch, it has very
different social consequences than if someone merges that branch into
their own feature branch. Namely, it is going to be part of the next
released tarball.


Note that hg does distinguish it a little bit. If you look here:
http://hg.python.org/cpython/graph

There is a clear separation of what was merged into the line on the
left, versus what was committed elsewhere. However, there is no
distinction on:
http://hg.python.org/cpython/shortlog

Note also that because 'hg log' doesn't default to only showing you
things on a given branch, you can end up with log views like this:
http://hg.python.org/cpython/graph/693415328363

Where "Relax timing check" has nothing to do with "Issue #10833", but
because the data in the repository has Relax Timing Check placed after
Issue #10833 physically on disk, they end up both getting shown in the
log view.

It certainly is much worse in
http://hg.python.org/cpython/shortlog/693415328363

Where there is no way to tell that the revisions are unrelated, and just
happen to physically reside in same repository.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Iu5kACgkQJdeBCYSNAAMVQACgpGd53yMnQBjJXuoVLElxC6qN
OqwAmwTdxjIS5tjkf0+iK62DvT/uPLdz
=1YLF
-----END PGP SIGNATURE-----

From john at arbash-meinel.com  Tue Mar 22 16:20:14 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Tue, 22 Mar 2011 16:20:14 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110322102557.516914f6@neurotica.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<87wrjs456h.fsf@benfinney.id.au>	<4D87E34E.2000201@canterbury.ac.nz>
	<4D87E4A6.1090404@netwok.org>
	<20110322102557.516914f6@neurotica.wooz.org>
Message-ID: <4D88BE2E.7070607@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/22/2011 3:25 PM, Barry Warsaw wrote:
> On Mar 22, 2011, at 12:52 AM, ?ric Araujo wrote:
> 
>> Bazaar apparently has a notion of mainline whereas Mercurial believes
>> that all changesets are created equal.  The tools are different.
> 
> I'm curious: what are the benefits of the Mercurial model?
> 
> -Barry
> 

- From discussions in #bzr, I would say the primary complaint to our model
is that people feel it means that not all revisions are created equal.

Though honestly, that is true. Getting a revision into Linus's kernel
tree is not the same as getting it into my own branch of the kernel.

I do remember discussions where people felt bad that after integrating
someone else's work, by default it showed their name, rather than the
names of the people who had done the actual work. (Though you could
always use --author if you really wanted to change the name on that commit.)


There is a technical argument. A merging B should be idempotent to B
merging A. And certainly, the file-content should be the same after
either operation.

But as I mentioned in the other email, Barry merging my work and
committing it to the hg.python.org/cpython branch is very different
socially than me merging cpython's branch. So bzr is somewhat
distinguishing "things done on this branch" from "things done in other
branches that I have included into this branch.".


Simplicity. If you enforce the mainline concept with
"append_revisions_only=True" on your trunk branches. Then people who try
to do:

 cd my-work
 merge trunk && commit
 push trunk

Will be blocked. While if you did
 cd trunk
 merge my-work && commit
 push trunk

It would succeed. If a tool doesn't give you a benefit from maintaining
a mainline, there is overhead in preserving it.

If your tool defaults to fast-forward merging, it is also really hard to
get the behavior. (git does this with a config option to disable it, bzr
has it as an option to merge [defaulting to off], and I'm not sure what
Mercurial's default is.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Ivi4ACgkQJdeBCYSNAAOhzwCg0tD1KdR53fH7OEzhom0IaPOL
niYAn2KsY2jPLJmbXWf8sIauMW+y2hHC
=NFdA
-----END PGP SIGNATURE-----

From skip at pobox.com  Tue Mar 22 16:37:04 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 10:37:04 -0500
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <20110322125120.GA3274@kevin>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
	<20110322125120.GA3274@kevin>
Message-ID: <19848.49696.338477.542385@montanaro.dyndns.org>


    >> I still don't understand what that's supposed to look like.  Is it
    >> supposed to be a URL which refers to my local repository?

    Senthil> No, it is the "Remote Repository". It could be one at
    Senthil> bitbucket.org or code.google.com, both of which support
    Senthil> creating mercurial repositories. Or it could be a repository at
    Senthil> hg.python.org and with a url like hg.python.org/sandbox/skip or
    Senthil> hg.python.org/skip

    Senthil> You will have to 'push' your changes to those so that they are
    Senthil> publicly visible and then point that url in the bug-tracker.

I can see this turning into a giant bowl of spaghetti.  How in the world are
people supposed to understand how all these repositories are related to each
other?

    Senthil> You can do that or use one of existing facilities available for
    Senthil> pushing your code to a public hg repository.

Doesn't that just complicate my setup?  Let's just consider the cpython repo
(is that the right term? maybe branch instead?).  Today, I have a local
repository named "cpython" which refers to ssh://hg at hg.python.org/cpython as
its default.  Now you suggest I need to create another public repository.
So my "chain of command" becomes: local depends on my global, which depends
on the real cpython global.  Now replicate that for the different active
branches (2.7, 3.2 at least).

    Senthil> And when you pressed "Create Patch" button, it created a patch

    >> Sorry, I don't see a "Create Patch" button anywhere.  Are you
    >> referring to some sort of Mercurial GUI?

    Senthil> No, the same http://bugs.python.org/issue11591 You have to be
    Senthil> logged into the tracker to see "Create Patch" under a section
    Senthil> called "Repositories containing patches"

I was logged in.  It is not obvious.  In addition, now that I've found it, I
see that there are two.  WTF?

The Roundup interface is getting extraordinarily messy.  In the above case I
count 23 user interface components for just that one case, not including all
the Remove buttons for the individual comments:

   5 in classification
   13 in process
   1 Submit changes button
   2 under Files/file name
   2 under Files/Repositories containing patches

The above count does not include simple HTML links, which themselves can be
just as important as the buttons, text areas and pop up menus.

Skip


From skip at pobox.com  Tue Mar 22 16:56:10 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 10:56:10 -0500
Subject: [Python-Dev] crosses branches?
In-Reply-To: <4D88B4BB.1020700@acm.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
	<19848.44539.573781.500799@montanaro.dyndns.org>
	<4D88B4BB.1020700@acm.org>
Message-ID: <19848.50842.822463.535818@montanaro.dyndns.org>


    Sjoerd> Are you sure the hg pull part worked?

Pretty sure:

    2.7% hg pull
    Enter passphrase for key '/Users/skip/.ssh/id_rsa':
    pulling from ssh://hg at hg.python.org/cpython
    searching for changes
    no changes found
    2.7% cd ../2.6
    2.6% hg pull
    pulling from /Users/skip/src/hgpython/2.7
    searching for changes
    no changes found
    2.6% cd ../2.5
    2.5% hg pull
    pulling from /Users/skip/src/hgpython/2.6
    searching for changes
    no changes found

    Sjoerd> So, try hg pull and the look at the heads again.

Looks the same to me.

Skip

From sjoerd at acm.org  Tue Mar 22 17:32:17 2011
From: sjoerd at acm.org (Sjoerd Mullender)
Date: Tue, 22 Mar 2011 17:32:17 +0100
Subject: [Python-Dev] crosses branches?
In-Reply-To: <19848.50842.822463.535818@montanaro.dyndns.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
	<19848.44539.573781.500799@montanaro.dyndns.org>
	<4D88B4BB.1020700@acm.org>
	<19848.50842.822463.535818@montanaro.dyndns.org>
Message-ID: <4D88CF11.6010401@acm.org>

On 2011-03-22 16:56, skip at pobox.com wrote:
> 
>     Sjoerd> Are you sure the hg pull part worked?
> 
> Pretty sure:
> 
>     2.7% hg pull
>     Enter passphrase for key '/Users/skip/.ssh/id_rsa':
>     pulling from ssh://hg at hg.python.org/cpython
>     searching for changes
>     no changes found
>     2.7% cd ../2.6
>     2.6% hg pull
>     pulling from /Users/skip/src/hgpython/2.7
>     searching for changes
>     no changes found
>     2.6% cd ../2.5
>     2.5% hg pull
>     pulling from /Users/skip/src/hgpython/2.6
>     searching for changes
>     no changes found
> 
>     Sjoerd> So, try hg pull and the look at the heads again.
> 
> Looks the same to me.
> 
> Skip

Perhaps looking at the glog output will shed some light.  If you don't
have it yet, enable the graphlog extension, after which you can use hg
glog to look at your clone.  Look in particular at the changeset which
is marked with an @ sign instead of an o.  That (or those if you're in
the middle of a merge) is the "parent" of your working set.

-- 
Sjoerd Mullender

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 371 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/0182783a/attachment.pgp>

From sjoerd at acm.org  Tue Mar 22 17:37:23 2011
From: sjoerd at acm.org (Sjoerd Mullender)
Date: Tue, 22 Mar 2011 17:37:23 +0100
Subject: [Python-Dev] crosses branches?
In-Reply-To: <19848.44539.573781.500799@montanaro.dyndns.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
	<19848.44539.573781.500799@montanaro.dyndns.org>
Message-ID: <4D88D043.70306@acm.org>

On 2011-03-22 15:11, skip at pobox.com wrote:

I realized I didn't answer this:

> Looking here at the Common Cases section:
> 
>     http://mercurial.selenic.com/wiki/RebaseProject
> 
> I can see how I have now apparently got this situation:
> 
>      C1 --> C2 --> S1
>             \
>              \ --> ... Cn
> 
> (where S1 is my local change and C? are the central changesets)
> 
> Rebase will do this, right?
> 
>      C1 --> C2 --> ... --> Cn --> S1

Yes, that's correct.

> Am I going to have to rebase then every time I re-pull that repository and
> incorporate new upstream changes?  Wouldn't I rather want the chain of
> revisions to look like this after the rebase step?
> 
>      C1 --> C2 --> S1 --> ... --> Cn

I guess you could try to reverse the source and destination changeset
for the rebase, but I think you will get into trouble this way.  What
rebase does, basically, is to remove the changesets being rebased from
the clone and adding them back somewhere else.  But in doing so, the
changeset changes identity.  This means that afterwards when you do a
pull, those moved changesets will be fetched again from the source clone
(they had been removed from yours, so aren't there anymore) and you will
get a similar graph again, but now the S1 will be a list of changesets
instead of the one.

-- 
Sjoerd Mullender

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 371 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/f0c72173/attachment.pgp>

From stutzbach at google.com  Tue Mar 22 18:17:45 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Tue, 22 Mar 2011 10:17:45 -0700
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <8739mfoo28.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<8739mfoo28.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTimR=iVfTcaJUxjaHjUJ0UDD4+HdbYTjsd1_5U+w@mail.gmail.com>

On Mon, Mar 21, 2011 at 8:02 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Speaking for myself, I rewrite my git history because it is *not*
> useful to me as is.  Almost all of my git commits have a informational
> half-life measured in hours once they're off tip, because I commit
> with *every* save (I have an after-save-hook to do this), which I do
> "early and often".  Effectively, I use git as an extension to XEmacs's
> undo/redo mechanism.
>

I, too, commit using git with every save (which I do early and often).  It's
saved my butt more than once.  Awhile ago I came across the following nice
tool that puts these intermediate commits in a side branch (that can later
be abandoned) so they never show up in the main history:

https://github.com/bartman/git-wip

I imagine something similar could be written for hg.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/20bea233/attachment-0001.html>

From jcea at jcea.es  Tue Mar 22 18:38:12 2011
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 22 Mar 2011 18:38:12 +0100
Subject: [Python-Dev] Workflow proposal
Message-ID: <4D88DE84.8050209@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Most of our problems are related to trying to keep a lineal history, and
races with pull-patch-commit-push cycle. I propose the following workflow.

All branches (except 2.7) MUST be merged to default, all the time. This
must be enforced by the push hook.

The workflow would be something like this:

1. Update the local clone.
2. I patch 3.1. Test the patch locally.
3. Commit the patch locally.
4. Merge the patch to 3.2 locally.
5. Merge the patch to "default" locally.
6. Push.

If there are no other pushes in the meantime, we are done. If there are
other pushes, we will have a "+1 head" and the push is rejected.

Now we have two options.

The easier and "mercurial" way would be:

6. Pull.
7. Merge the two heads.
8. Merge that merge to the other branches, as necessary. Since the two
heads were already merged to other branches, this merge should be trivial.
9. Push.

If we have some other pushes in the meantime, repeat again from 6. You
will eventually win the race :).

This head merging could be "ugly" to some people (not me), so other
approach would be, if the original "merging" is easy:

6. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and
"default". Leave the original commit in "3.1" alone.
7. Pull and rebase your commit to the incoming head. Now your local
history is lineal.
8. Do the merge to "3.2" and "default", locally.
9. Try to push.

If there are more pushes in the meantime, repeat from 6.

This second approach keep a lineal history, but it is more "dangerous"
and can be a pain if the merges to "3.2" and "default" are not trivial,
because you must do them several times.

This workflow works well ONLY if we forbid to have active branches
(except "default" and "2.7"). That is, forbidding having branches not
merged to new versions. That is, 3.1 merged to 3.2 and default, 3.2
merged to default. This should be implemented in the push hook.

If some patches in 3.1 should not be in 3.2/default, we MUST do a null
merge anyway. The "no active branches" must not be broken. It should be
a firm policy enforced by the push hook.

So good so far.

But there is a *legitime* reason for pushing a 3.1 patch without
merging... trying the patch in the buildbots, maybe redoing it a few
times, discussing it bugs.python.org, try several approaches, etc,
before closing the issue and merging to 3.2 and "default". But that is
an artifact of the way we interact with the buildbots. If I could do the
following, it would be AMAZING:

1. Write a patch in my local clone.
2. Commit it locally.
3. Push my clone to a SANDBOX in hg.python.org ("hg push sandbox"). This
sandbox is synchronized with the official HG repository. If my push
create a "+1 head", we have a race. I must pull and merge, and try to
push again.
4. When I get my patch in the sandbox. the sandbox accepts it, generate
a patch relative to current tip from hg.python.org, and strip that
commit. The sandbox must be always synchronized with hg.python.org. Its
only mission is to validate that your patch applies cleanly to current
tip, that you have push permissions (security).
5. The buildbots should checkout hg.python.org and apply your patch over
the working directory. Run the buildbots testing.
6. You wait for the results.
7. If you are not ok with the result, your keep modifying your clone.
When you want to try, you push to the sandbox, for trying.
8. When you are satisfied with the result, you do the merge to the other
branches and push to "hg.python.org".

Several people can use the sandbox at the same time, since it is
synchronized with hg.python.org and it strips your patch inmediatelly,
so nobody will see your patch. In fact, this sandbox could add your
patch automatically to the assigned issue (bugs.python.org).

We already have "cloned in the server" repositories, but I am not sure
how to delete them, how to push them to the buildbots (is it efficient?,
of the buildbots must pull the complete repo each time?), I must care
about pushing it the last changes in hg.python.org, etc.

Ideas?.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYjehJlgi5GaxT1NAQInJAQAn61i1YFwUB/IXkNazJZfRi3dVYVTikbE
t5qBpvFKZKA/s90y6fP6usa09DZVlYXsb95leMIaTc2BjXzgB5qd9I47rFlA+pbk
mjHbVoDmsNcjjI93lRhZV4p7MSeWWSkNDpF/H3qi/bPw3MKqkJFpT9sVkboBs3iO
UbtKE9+Dnno=
=GVMW
-----END PGP SIGNATURE-----

From barry at python.org  Tue Mar 22 19:25:29 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Mar 2011 14:25:29 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <4D886FA4.7040502@arbash-meinel.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<4D8767E7.8020702@cadifra.com>
	<20110321171930.02BBE13F980@kimball.webabinitio.net>
	<20110321135351.20632230@limelight.wooz.org>
	<4D886FA4.7040502@arbash-meinel.com>
Message-ID: <20110322142529.62c54e22@neurotica.wooz.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mar 22, 2011, at 10:45 AM, John Arbash Meinel wrote:

>I'm personally a huge fan of 2(multi)-tier testing. So you have a basic
>(and fast) test suite that runs across all your modules before every
>commit in your mainline. Then a much larger (and slower) test suite that
>runs regression testing across all platforms/etc that runs
>asynchronously.

Python sort of has that, but I guess it depends on your definition of "fast"
:).  Here are my run times.

'make quicktest': 18m
'make test'     : 30m
'make testall'  : 35m

It probably wouldn't be a bad idea to add a very fast "smoke test" for the
case where you get tripped up on the merge dance floor.  When that happens,
you could run your localized tests, and then a set of tests that run in just a
minute or two.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJNiOmZAAoJEBJutWOnSwa/GGgP/0A0glNa+8qf1Tg//Cqjp6G+
n1YX+0h9pciKqwr1O30y1V+cbak6AMGYG6AZq/Mj6vrcFCobJdhxZja9T7An4TxW
BzW1vCw3eEBG9WC4APG1yaIm4N2+RdDqneJCsh0e84T6J2BxOdJLhW2/Gs2UEN47
j3T4v1qVldGVD/hVms4Z5YjXt1A/jwio2q6tdCLhx6rQbf2D6iXWhZHqAepkJkz8
Rc7+FT8fqbdVQpLmmvf28IjxGANBf1rEhnA4YUaKv1syelo+o7ti+j3icVLG5XNn
qFqIXbTslxMv6DI818gPTYmPDDuGsoaBfXGS1VOeNBhE/Gmqy5h5VfE376Il+tCU
khb7usMzFUjm4BMRovCT+psfIENFqtncuknqrthp20T2UeERetKUCBET4ueIxhiw
T6Vt/AOCx+h31kkjX33xHsFI8mZSZi02Wm/GEAQWvE7w13eI5cA8bvnTR8Nm0aaF
3o/EmoeVPvLruBhmg8iTtLB6nESywntaeMmYIkPHDN7KmvNNKzs/Gg5/mP+77uHm
FdesGi3z8stH6YN7JMdV7CE0MXkoiEepXbdh0PnEMKEmdYuKAmJjnexVuPpRaz5K
KryfbMiFaGBFMBpw2wBc055pzuKBL+kRP9gLRhcpmtgb2PELNKSWnPgEHT1DXsGd
BzSsvD2GHs1rdPOGQyRu
=0qS1
-----END PGP SIGNATURE-----

From rdmurray at bitdance.com  Tue Mar 22 19:25:55 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 22 Mar 2011 14:25:55 -0400
Subject: [Python-Dev] crosses branches?
In-Reply-To: <4D88B4BB.1020700@acm.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
	<19848.44539.573781.500799@montanaro.dyndns.org>
	<4D88B4BB.1020700@acm.org>
Message-ID: <20110322182555.B40FE164C39@kimball.webabinitio.net>

On Tue, 22 Mar 2011 15:39:55 +0100, Sjoerd Mullender <sjoerd at acm.org> wrote:
> On 2011-03-22 15:11, skip at pobox.com wrote:
> > I see lots of heads, but that never prevented an update before.  How do I
> > tell which two heads are key to this case?  For completeness, here's the
> > output of hg heads in my 2.5 repository.  I only see one labelled "2.5"
> > What is the other head to which you referred?
> 
> Two heads in the same branch.
> Are you sure the hg pull part worked?  When I update I see there are
> changes on the 2.5 branch which I would expect to see in your list.
> It probably never happened before because nobody committed a change to
> the 2.5 branch since you made your change.

Note that one of the changes in 2.5 was Martin fixing the compile,
so your local commit is no longer required.  What you do with that
information, I don't really know (probably a null merge, but you'll
have to figure out the state of your repo first...or you could start
over with a fresh clone).

--
R. David Murray           http://www.bitdance.com

From rdmurray at bitdance.com  Tue Mar 22 19:29:25 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 22 Mar 2011 14:29:25 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <19848.37956.665020.538633@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
Message-ID: <20110322182925.54963164C39@kimball.webabinitio.net>

On Tue, 22 Mar 2011 07:21:24 -0500, skip at pobox.com wrote:
> 
>     Stephen> This won't be pleasant if people are sprinting and lots of
>     Stephen> commits are coming, because you're likely to repeatedly lose
>     Stephen> the push race.  But in those conditions, nothing is guaranteed
>     Stephen> to work in decentralized fashion (that's one reason why the
>     Stephen> Linux kernel uses Linus and lieutenants as a serialization
>     Stephen> mechanism).
> 
> So DVCS scales up to a point, then it breaks and you need to revert to some
> sort of serialization scheme?

Note that svnmerge broke at exactly the same scale point, for exactly the
same reason:  every svnmerge touched root properties, thereby effectively
serializing access to the tree.  There were lots of curses from people
trying to svnmerge at the sprints in previous years.

--
R. David Murray           http://www.bitdance.com

From jcea at jcea.es  Tue Mar 22 19:34:09 2011
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 22 Mar 2011 19:34:09 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D88779B.3040508@arbash-meinel.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>	<20110321161901.6fdb7d50@limelight.wooz.org>
	<4D88779B.3040508@arbash-meinel.com>
Message-ID: <4D88EBA1.4060406@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/03/11 11:19, John Arbash Meinel wrote:
> And suddenly the revision which was an "important" C change is now gone
> on the mainline, and your personal "and I did D" is now a primary
> revision. It doesn't matter much for a single revision D and C, but for
> anything long lived, you end up with 100 Guido exploratory D revisions,
> and some 50+ other python-dev super-stable trunk C revisions. And unless
> the tool helps you preserve the ordering[3], you really don't want to
> trying to treat them with different levels of authority. Hence, you tend
> to collapse, because you really can only trust "E" to be a final stable
> change.

Mercurial merge has a "left" and "right" parents concept. Some commands
only follow the "left" side. For instance, "hg log --follow-first".

We could have a trivial "push hook" to enforce that the current tip be
the "left/first" parent for any merge.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYjroJlgi5GaxT1NAQKWewP9GjCnnZhmwRXw+fQX7n9YpTXeE2y2fw6M
lPHkw3EFezYRZCyBE1GEM2pnMboJfoh/SxTRaPP68Tp8sAJ0A/5sN1Xh+hDax2wm
6oSOo6lbtDaEJHNpIZpeEu4Z5Axh9mn851atMvI1iImb1UCAsANsZ7AyNqPZVkxo
EbDa34Ppv2w=
=lYXJ
-----END PGP SIGNATURE-----

From fuzzyman at voidspace.org.uk  Tue Mar 22 20:12:37 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 22 Mar 2011 19:12:37 +0000
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D884E08.1020709@skippinet.com.au>
References: <4D884E08.1020709@skippinet.com.au>
Message-ID: <4D88F4A5.4060701@voidspace.org.uk>

On 22/03/2011 07:21, Mark Hammond wrote:
> Hi all,
>   I've made some changes to the draft PEP and checked it into the PEP 
> repository as PEP397.  The reference implementation is currently being 
> tracked at http://bugs.python.org/issue11629.
>

Hey Mark,

One way of supporting alternative implementations (that may not even 
have a standard install directory) is allowing configuration. e.g. 
config.ini

     [paths]
     ironpython = c:\Program Files\IronPython 2.7\ipy.exe
     ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
     jython = c:\Users\foobar\jython2.5\jython.exe

Pythons specified in this way should be recognised in the shebang line 
using any of the formats:

     #! ironpython
     #! /usr/bin/ironpython
     #! /usr/bin/env ironpython

This would also permit alternative install locations. (And it would be 
nice if the launcher could use the config file to *automatically* do the 
right thing for the 'w' variants.)

All the best,

Michael

> Most of the changes should not be too controversial, but of note:
>
> * I've added lots of discussion about the child-process issue and the 
> wording now states, basically, that in-process is not feasible, but if 
> we use the win32 Job API we can arrange for the child to be killed 
> with the parent on Windows XP and later.  The reference implementation 
> demonstrates this thanks to an example from Curt Hagenlocher.
>
> * 64bit and 32bit considerations have been added, along with basic 
> information about other distros and implementations.
>
> * The somewhat controversial optional first command-line parameter 
> which allows you to specify a particular version for interactive use 
> has grown an almost-certain-to-be-controversial option to specify the 
> bittedness of the Python you wish to start.  I've added this mainly as 
> it would scratch my personal itch as I tend to have 32bit and 64bit 
> implementations of most versions available and while this isn't 
> particularly common, I'm going to attempt to defend it on the 
> principle of "just don't use it if you don't like it" :)  Note the 
> reference implementation does not yet implement this, nor does it 
> implement the general policy about 32bit vs 64bit considerations.
>
> Please let me know what you think and what objections/comments/etc 
> remain.
>
> Thanks,
>
> Mark
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/145ba170/attachment.html>

From martin at v.loewis.de  Tue Mar 22 20:59:54 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 22 Mar 2011 20:59:54 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <19848.49696.338477.542385@montanaro.dyndns.org>
References: <4D7D06F3.7020700@v.loewis.de>
	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>	<20110322125120.GA3274@kevin>
	<19848.49696.338477.542385@montanaro.dyndns.org>
Message-ID: <4D88FFBA.6080201@v.loewis.de>

>     Senthil> You will have to 'push' your changes to those so that they are
>     Senthil> publicly visible and then point that url in the bug-tracker.
> 
> I can see this turning into a giant bowl of spaghetti.  How in the world are
> people supposed to understand how all these repositories are related to each
> other?

Yes, it will turn into a giant bowl of spaghetti - that's the whole
point of "Distributed" version control systems.

So: don't bother about this. There is certainly going to be a lot of
repository that you don't know about, just as you didn't know about
patches that may have circulated before. If people want you to know
about a clone, they have to tell you - one way of doing that is to
attach its link to a tracker issue.

> The Roundup interface is getting extraordinarily messy.

So what is your constructive proposal?

Regards,
Martin

From dirkjan at ochtman.nl  Tue Mar 22 21:44:04 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Tue, 22 Mar 2011 21:44:04 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <20110322182925.54963164C39@kimball.webabinitio.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
	<20110322182925.54963164C39@kimball.webabinitio.net>
Message-ID: <AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>

On Tue, Mar 22, 2011 at 19:29, R. David Murray <rdmurray at bitdance.com> wrote:
> Note that svnmerge broke at exactly the same scale point, for exactly the
> same reason: ?every svnmerge touched root properties, thereby effectively
> serializing access to the tree. ?There were lots of curses from people
> trying to svnmerge at the sprints in previous years.

The right solution here is to use different clones for different
projects/areas. The proposed interpreter/stdlib split, for example,
might reduce contention (although I imagine it would reduce it only by
a little bit?). Supposedly other meaningful subdivisions exist. Then
people working on those projects don't keep the central repo occupied,
instead only merging their project tree into the main tree on some
delayed schedule (say, weekly).

This is something that Mozilla has been doing, for example, their JS
interpreter is now developed in a separate clone. It might also be a
good match for sprints, where one room could have its own repo and the
other room has a different repo. Or all the packaging sprinters push
to their cpython-packaging repo.

Cheers,

Dirkjan

From ncoghlan at gmail.com  Tue Mar 22 21:46:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 06:46:17 +1000
Subject: [Python-Dev] [GSoC] Porting on RPM3
In-Reply-To: <4D886BF5.4000903@laiskiainen.org>
References: <AANLkTik0C8JdwCafpgeoq10_nm7J4yRBqR-LSSqniwOO@mail.gmail.com>
	<4D871F68.4000608@v.loewis.de>
	<1300755982.2666.4869.camel@surprise>
	<4D886BF5.4000903@laiskiainen.org>
Message-ID: <AANLkTi=dT4Ccmr6pFYig9eun_-k0VwrwTh80zVLLudEz@mail.gmail.com>

On Tue, Mar 22, 2011 at 7:29 PM, Panu Matilainen
<pmatilai at laiskiainen.org> wrote:
> The bindings cannot go changing header contents to their liking, so any
> canonicalization would have to go into rpm proper, the build-side of things
> to be exact so the runtime doesn't have to care. Requiring rpm to fiddle
> with encodings + canonicalization for every single string it processes at
> runtime would require enormous changes throughout rpm, and presumably at a
> massive performance cost too.

Just a hint from our experience with APIs like os/email/urllib.parse:
you pretty much end up *needing* to have parallel bytes and str APIs
(including higher level data structures that know how to encode and
decode themselves) to get this to work properly. The str APIs will
work 90% of the time, but you still need access to the raw bytes to
recover when the simple approach fails. One key choice to be made is
whether to go the brittle option (i.e. ASCII) for the implicit
decoding, or the permissive one (i.e. UTF-8 with surrogateescape). The
former punts on the complicated encoding issues (e.g. urllib.parse
does this, since correctly formed URLs are meant to be encoded into
pure ASCII), while the latter works by default in more situations, but
can allow malformed data to escape the IO layer and cause problems in
other parts of the program (e.g. many of the os APIs do this, since
real world applications often care more about round tripping correctly
between different OS interfaces).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Mar 22 21:50:39 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 06:50:39 +1000
Subject: [Python-Dev] Useful "hg log" trick to only see revisions in the
 current branch
In-Reply-To: <20110322124947.2AF52EC887@kimball.webabinitio.net>
References: <AANLkTi=4TQYjSngtZ=-CjBe2S3BA8pw7J=VC3d-AOSUn@mail.gmail.com>
	<20110322124947.2AF52EC887@kimball.webabinitio.net>
Message-ID: <AANLkTimUqL0bmXg1Rc4D+dkfGRrfj66SEQdk1hZTAYW=@mail.gmail.com>

On Tue, Mar 22, 2011 at 10:49 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> So: there is completion support for hg update for both bash and zsh.
> Not sure about other shells.

Thanks for clarifying that, I've long been hazy on the details of how
completion works across various utilities (it also clears up why the
bug with tab completion for a locally built Python landed in
bash-completion's lap).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From p.f.moore at gmail.com  Tue Mar 22 21:56:36 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 22 Mar 2011 20:56:36 +0000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
	<20110322182925.54963164C39@kimball.webabinitio.net>
	<AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>
Message-ID: <AANLkTi=vRjqKEgAJOEQ_EBTwHKbk-dey_ex56YSqsnYq@mail.gmail.com>

On 22 March 2011 20:44, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> The right solution here is to use different clones for different
> projects/areas.

I'm not trolling here, just trying to learn something about Mercurial.
Would having separate clones for the various releases (2.7, 3.1, 3.2,
...) rather than named branches, reduce contention? I imagine it would
make porting patches between versions harder, on the other hand...?

Paul.

From dirkjan at ochtman.nl  Tue Mar 22 21:59:58 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Tue, 22 Mar 2011 21:59:58 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <AANLkTi=vRjqKEgAJOEQ_EBTwHKbk-dey_ex56YSqsnYq@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
	<20110322182925.54963164C39@kimball.webabinitio.net>
	<AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>
	<AANLkTi=vRjqKEgAJOEQ_EBTwHKbk-dey_ex56YSqsnYq@mail.gmail.com>
Message-ID: <AANLkTi=6v_ism=YFC+KvJ-ykjS4pUgKBMuWzFtu5Sgip@mail.gmail.com>

On Tue, Mar 22, 2011 at 21:56, Paul Moore <p.f.moore at gmail.com> wrote:
> On 22 March 2011 20:44, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>> The right solution here is to use different clones for different
>> projects/areas.
>
> I'm not trolling here, just trying to learn something about Mercurial.
> Would having separate clones for the various releases (2.7, 3.1, 3.2,
> ...) rather than named branches, reduce contention? I imagine it would
> make porting patches between versions harder, on the other hand...?

Probably not really. In particular, since many changes are
forward-ported across branches, you'll still need to push to each of
the release branches... I'm not sure what the ratio for pure-feature
vs. bugfix is; if there is a significant number of pure-feature
patches (i.e. not on any of the release branches), it might help to
separate all of the release branches from the default branch.

Cheers,

Dirkjan

From steve at pearwood.info  Tue Mar 22 22:12:27 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 23 Mar 2011 08:12:27 +1100
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
Message-ID: <4D8910BB.8090307@pearwood.info>

anatoly techtonik wrote:
> I didn't touch Python3 until PyCon, and my first user experience is
> not really good. I've got a feeling that Python3 became more ugly,
> because it doesn't allow me to think about the logic anymore, and
> requires more low-level workarounds even for basic user input/output.

Do you have any examples other than print?

The main one that comes to my mind is that other than looping, any time 
I want to process dict.items() etc I often need to call list() first. 
Fortunately looping is about 90% of my use-cases for the dict methods, 
but the other 10% nearly always requires a list().


YMMV.



-- 
Steven


From ncoghlan at gmail.com  Tue Mar 22 22:20:30 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 07:20:30 +1000
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <4D88DE84.8050209@jcea.es>
References: <4D88DE84.8050209@jcea.es>
Message-ID: <AANLkTi=fKPgGDR4_RJRi4swbzinM1+f_QZsy9HXUS8PR@mail.gmail.com>

On Wed, Mar 23, 2011 at 3:38 AM, Jesus Cea <jcea at jcea.es> wrote:
> Now we have two options.
>
> The easier and "mercurial" way would be:
>
> 6. Pull.
> 7. Merge the two heads.
> 8. Merge that merge to the other branches, as necessary. Since the two
> heads were already merged to other branches, this merge should be trivial.
> 9. Push.
>
> If we have some other pushes in the meantime, repeat again from 6. You
> will eventually win the race :).

There's a third option (which is what I've been doing):

6. Pull
7. Merge the heads on the oldest branch that now has multiple heads
8. Merge that branch to the next branch in line as usual.
9. Repeat 7-8 until all branches, up to and including default have been merged
10. Push.

Repeat from 6 if there was another push race.

It keeps the same merge flow as a normal patch (e.g.
3.1->3.2->default) without messing with local history.

As far as the rest of the post goes, in principle I agree with the
goal of letting us run branches from sandbox repositories on the
buildbots, but am happy to leave the details to others to work out. If
the buildbots are currently working the way they did with SVN (clean
checkout every time) they may currently be doing a clean clone of the
repository for every build anyway.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Mar 22 22:26:08 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 07:26:08 +1000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
	<20110322182925.54963164C39@kimball.webabinitio.net>
	<AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>
Message-ID: <AANLkTinnc79Kktv4LoNUpNq870TKkosx8xLXmW-87Vgc@mail.gmail.com>

On Wed, Mar 23, 2011 at 6:44 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> This is something that Mozilla has been doing, for example, their JS
> interpreter is now developed in a separate clone. It might also be a
> good match for sprints, where one room could have its own repo and the
> other room has a different repo. Or all the packaging sprinters push
> to their cpython-packaging repo.

Yeah, that last is essentially what Tarek did for the Pycon sprints (I
think he even had multiple levels of it - I believe Arc was running a
staging clone as well).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From doug.hellmann at gmail.com  Tue Mar 22 22:26:08 2011
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Tue, 22 Mar 2011 17:26:08 -0400
Subject: [Python-Dev] "Meet the Team" on Python Insider
Message-ID: <21C8FF6A-51C2-40DB-9D9B-C0F5A3C234EC@gmail.com>

We would like to run a series of interviews with the Python developers to get the new blog going. There is a short list of questions below this message. If you would like to be included in the series, please reply directly to me with your answers.

We will be doing one or two posts per day, depending on the number of responses and availability of other information to post. We'll have to wait until we have several responses before we start, so we don't announce a new series and then post two messages before it peters out. Please help us by sending your answers as quickly as you can so we can tell what we'll be dealing with.

Posts will be published in roughly the order the responses are received, with the text exactly as you send it (unedited, except for formatting it as HTML). If the questions don't apply to you, you can't remember the answer, or don't have an answer, then you can either leave that question blank or interpret it more broadly and give some related information. Blank questions will be omitted from the posts.

Thanks,
Doug



Personal information:

name
location (city, country, whatever you want to give--we don't need your mailing address)
home page or blog url

Questions:

1. How long have you been using Python?

2. How long have you been a core committer?

3. How did you get started as a core developer? Do you remember your first commit?

4. Which parts of Python are you working on now?

5. What do you do with Python when you aren't doing core development work? (day job, other projects, etc.)

6. What do you do when you aren't programming?


From ncoghlan at gmail.com  Tue Mar 22 22:29:13 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 07:29:13 +1000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <AANLkTi=6v_ism=YFC+KvJ-ykjS4pUgKBMuWzFtu5Sgip@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
	<20110322182925.54963164C39@kimball.webabinitio.net>
	<AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>
	<AANLkTi=vRjqKEgAJOEQ_EBTwHKbk-dey_ex56YSqsnYq@mail.gmail.com>
	<AANLkTi=6v_ism=YFC+KvJ-ykjS4pUgKBMuWzFtu5Sgip@mail.gmail.com>
Message-ID: <AANLkTi=D8td+nChnJZp+qVuxcCykPMrwZvGk_rwTn8Vn@mail.gmail.com>

On Wed, Mar 23, 2011 at 6:59 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> Probably not really. In particular, since many changes are
> forward-ported across branches, you'll still need to push to each of
> the release branches... I'm not sure what the ratio for pure-feature
> vs. bugfix is; if there is a significant number of pure-feature
> patches (i.e. not on any of the release branches), it might help to
> separate all of the release branches from the default branch.

Not really - when you're working on a default-only change, push races
are pretty easy to deal with (merge, test, commit, push, no fiddling
about with different branches).

It's only when you've changed multiple branches *and* hg pull changes
multiple branches that correctly sorting out all the heads on each
branch gets a bit tedious.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From barry at python.org  Tue Mar 22 22:30:09 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Mar 2011 17:30:09 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <AANLkTin24CORfNhrX3pVWhWFKwp1ttUxJo6oqHhPqdX8@mail.gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
	<20110319031219.GC19053@unaka.lan>
	<AANLkTin24CORfNhrX3pVWhWFKwp1ttUxJo6oqHhPqdX8@mail.gmail.com>
Message-ID: <20110322173009.35e9b5da@neurotica.wooz.org>

On Mar 18, 2011, at 08:50 PM, Guido van Rossum wrote:

>I do distinctly recall __version__ being standardized for other
>purposes too, but I have no idea how to find that reference... It
>probably was well before 2000.

FWIW, I went spelunking in my email archives and the earliest reference to
__version__ I found was in a file called subproc.py posted to comp.lang.python
by Ken Manheimer.  It contained a CVS expanded $Revision$ keyword.

The message is dated January 12, 1995.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/21c3d767/attachment.pgp>

From ncoghlan at gmail.com  Tue Mar 22 22:31:13 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 07:31:13 +1000
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <20110322142529.62c54e22@neurotica.wooz.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<4D8767E7.8020702@cadifra.com>
	<20110321171930.02BBE13F980@kimball.webabinitio.net>
	<20110321135351.20632230@limelight.wooz.org>
	<4D886FA4.7040502@arbash-meinel.com>
	<20110322142529.62c54e22@neurotica.wooz.org>
Message-ID: <AANLkTimTreRdZ9A2nakEOYZ5LVej0PLRfSG02t0g7QXs@mail.gmail.com>

On Wed, Mar 23, 2011 at 4:25 AM, Barry Warsaw <barry at python.org> wrote:
> It probably wouldn't be a bad idea to add a very fast "smoke test" for the
> case where you get tripped up on the merge dance floor. ?When that happens,
> you could run your localized tests, and then a set of tests that run in just a
> minute or two.

What would such a smoke test cover, though? It's hard to think of
anything particularly useful in the middle ground between "Can you run
regrtest *at all*?" and "make quicktest".

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Mar 22 22:37:18 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 07:37:18 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110322102208.78d0a279@neurotica.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>
	<20110321161901.6fdb7d50@limelight.wooz.org>
	<4D88779B.3040508@arbash-meinel.com> <4D8882FF.2040609@cadifra.com>
	<20110322102208.78d0a279@neurotica.wooz.org>
Message-ID: <AANLkTi=AjbzOAWopTYrq=qn1pyWb0WpUV0YVnfX_g5Jh@mail.gmail.com>

On Wed, Mar 23, 2011 at 12:22 AM, Barry Warsaw <barry at python.org> wrote:
> I think that's different than what John was describing, or perhaps Python's
> use of it has the effect of being different. ?IIUC, in Mercurial, within the
> default branch there's no clear "main line" of development assigned to a path
> within the DAG. ?All paths are created equal, so it's not possible to
> e.g. have log or bisect suppress one path containing feature sub-commits from
> the point of departure to the point of recombination (merge).

I was playing actually with the "-b" (branch) option on hg log and
found its behaviour to be a little strange when used on a specific
file.

I'd made a mistake in my sandbox and, as part of a merge from default,
accidentally reverted all the changes on a feature branch.

However, when doing "hg log -b . Objects/abstract.c" the last change
it showed for the file was the last feature addition in the branch,
*NOT* the merge from default where I had accidentally clobbered those
changes.

By looking at changes made on the default branch *as well*, I was able
to identify the offending changeset, do a hg rollback and then commit
that on the feature branch so everything was back the way it should
be. However, I was very, very surprised that hg log on a specific file
within a branch didn't flag the merge revisions that had brought in
changes that affected that file.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From guido at python.org  Tue Mar 22 22:38:17 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Mar 2011 14:38:17 -0700
Subject: [Python-Dev] Module version variable
In-Reply-To: <20110322173009.35e9b5da@neurotica.wooz.org>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
	<20110319031219.GC19053@unaka.lan>
	<AANLkTin24CORfNhrX3pVWhWFKwp1ttUxJo6oqHhPqdX8@mail.gmail.com>
	<20110322173009.35e9b5da@neurotica.wooz.org>
Message-ID: <AANLkTikuhJDT5BPzr0X6Co1vu0LAPT99fukuPmavi3mh@mail.gmail.com>

All trails eventually lead to Ken! :-)

On Tue, Mar 22, 2011 at 2:30 PM, Barry Warsaw <barry at python.org> wrote:
> On Mar 18, 2011, at 08:50 PM, Guido van Rossum wrote:
>
>>I do distinctly recall __version__ being standardized for other
>>purposes too, but I have no idea how to find that reference... It
>>probably was well before 2000.
>
> FWIW, I went spelunking in my email archives and the earliest reference to
> __version__ I found was in a file called subproc.py posted to comp.lang.python
> by Ken Manheimer. ?It contained a CVS expanded $Revision$ keyword.
>
> The message is dated January 12, 1995.

-- 
--Guido van Rossum (python.org/~guido)

From ncoghlan at gmail.com  Tue Mar 22 22:40:49 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 07:40:49 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110322102816.38747b1e@neurotica.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz> <4D87E4A6.1090404@netwok.org>
	<AANLkTimD7-o2fvUJeddS5R0YFVHWihMYtFawESA6y74D@mail.gmail.com>
	<4D87EE32.9040109@v.loewis.de>
	<AANLkTikJ22CkmGLfXe2V=J3sdtOq9YrTZ77kwobhTV5d@mail.gmail.com>
	<4D8846F4.7030604@v.loewis.de>
	<20110322102816.38747b1e@neurotica.wooz.org>
Message-ID: <AANLkTi=nreED57kJbTHfr4WjccTxmN_V=5UF+SxCu=JC@mail.gmail.com>

On Wed, Mar 23, 2011 at 12:28 AM, Barry Warsaw <barry at python.org> wrote:
>>Ah. We don't support this kind of development - no new named branches
>>are allowed in the central repository.
>
> It does sound like that restriction is a source of friction for us.

I'd like to hold off on abandoning it, though. All the issues we
currently have with applying patches wouldn't magically go away if
those changes were simple merges from named branches instead. You also
create a risk of mistakes like branching from default for a bug fix,
then merging your bug fix branch into 3.1.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From phd at phdru.name  Tue Mar 22 22:46:00 2011
From: phd at phdru.name (Oleg Broytman)
Date: Wed, 23 Mar 2011 00:46:00 +0300
Subject: [Python-Dev] Module version variable
In-Reply-To: <20110322173009.35e9b5da@neurotica.wooz.org>
References: <20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
	<20110319031219.GC19053@unaka.lan>
	<AANLkTin24CORfNhrX3pVWhWFKwp1ttUxJo6oqHhPqdX8@mail.gmail.com>
	<20110322173009.35e9b5da@neurotica.wooz.org>
Message-ID: <20110322214600.GA1703@iskra.aviel.ru>

On Tue, Mar 22, 2011 at 05:30:09PM -0400, Barry Warsaw wrote:
> a file called subproc.py posted to comp.lang.python
> by Ken Manheimer.

   Can you believe - I still use the module?! (-:

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From merwok at netwok.org  Tue Mar 22 22:43:49 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 22 Mar 2011 22:43:49 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <20110322102557.516914f6@neurotica.wooz.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<87wrjs456h.fsf@benfinney.id.au>	<4D87E34E.2000201@canterbury.ac.nz>
	<4D87E4A6.1090404@netwok.org>
	<20110322102557.516914f6@neurotica.wooz.org>
Message-ID: <4D891815.3060605@netwok.org>

>> Bazaar apparently has a notion of mainline whereas Mercurial believes
>> that all changesets are created equal.  The tools are different.
> I'm curious: what are the benefits of the Mercurial model?

Simplicity.

From ncoghlan at gmail.com  Tue Mar 22 22:47:38 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 07:47:38 +1000
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D889BC8.4080909@netwok.org>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
	<4D889BC8.4080909@netwok.org>
Message-ID: <AANLkTikuO1Ob46imuZsnTQgaPMZ64es3wUEiE6aJgTi-@mail.gmail.com>

On Tue, Mar 22, 2011 at 10:53 PM, ?ric Araujo <merwok at netwok.org> wrote:
> You have to use one public repo per bug, as roundup will only use the
> default branch to compute the diff. ?Maybe adding support for named
> branches so that you can have one repo used for many bug reports would
> be useful.

Since I run my sandbox that way, I asked Martin about that at Pycon -
it's on his todo list for the integration.


-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From skip at pobox.com  Tue Mar 22 22:53:49 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 16:53:49 -0500
Subject: [Python-Dev] crosses branches?
In-Reply-To: <4D88CF11.6010401@acm.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
	<19848.44539.573781.500799@montanaro.dyndns.org>
	<4D88B4BB.1020700@acm.org>
	<19848.50842.822463.535818@montanaro.dyndns.org>
	<4D88CF11.6010401@acm.org>
Message-ID: <19849.6765.980365.999085@montanaro.dyndns.org>


    Sjoerd> Perhaps looking at the glog output will shed some light.  If you
    Sjoerd> don't have it yet, enable the graphlog extension, after which
    Sjoerd> you can use hg glog to look at your clone.  Look in particular
    Sjoerd> at the changeset which is marked with an @ sign instead of an o.
    Sjoerd> That (or those if you're in the middle of a merge) is the
    Sjoerd> "parent" of your working set.

    ...
    | | | | | | @  changeset:   68309:c3caaf979b9e
    | | | | | |/   branch:      2.5
    | | | | | |    parent:      68263:7790ad8332ba
    | | | | | |    user:        Skip Montanaro <skip at pobox.com>
    | | | | | |    date:        Sun Mar 06 21:31:25 2011 -0600
    | | | | | |    summary:     manually expand the defunct HeadURL subversion keyword
    ...

I see no other "parent"s.  I have to admit I don't know how to read this
output or what I should look for in the way of conflicts.  Also, it produced
20+MB of output, so I can't just paste it into this message and ask anyone
to read the tea leaves.

Oh, wait a minute.  It looks like Martin relented on his desire not to
modify the 2.5 Mercurial repo:

    | | | | o  changeset:   68802:f9763c363cc3
    | | | | |  branch:      2.5
    | | | | |  parent:      68696:cc959f114739
    | | | | |  user:        Martin v. L?wis <martin at v.loewis.de>
    | | | | |  date:        Mon Mar 21 10:30:07 2011 +0100
    | | | | |  summary:     Set subversion version identification to empty strings if this is not a subversion

I think that would make my local change unnecessary.  So, my next project is
to try and figure out how to undo my change.  This seemed to work:

    hg revert -r 68263 Python/sysmodule.c

Was that the right thing to do?

S

From tjreedy at udel.edu  Tue Mar 22 22:56:05 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 22 Mar 2011 17:56:05 -0400
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <4D88DE84.8050209@jcea.es>
References: <4D88DE84.8050209@jcea.es>
Message-ID: <imb5tl$15r$1@dough.gmane.org>

On 3/22/2011 1:38 PM, Jesus Cea wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Most of our problems are related to trying to keep a lineal history, and
> races with pull-patch-commit-push cycle. I propose the following workflow.
>
> All branches (except 2.7) MUST be merged to default, all the time. This
> must be enforced by the push hook.

Seems like a good idea. If a fix is in 3.2 and *not* in default, then we 
have a regression in default. This will be easier and less work when 3.1 
is out and we only have two sequential versions.

-- 
Terry Jan Reedy


From merwok at netwok.org  Tue Mar 22 22:57:06 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 22 Mar 2011 22:57:06 +0100
Subject: [Python-Dev] crosses branches?
In-Reply-To: <19849.6765.980365.999085@montanaro.dyndns.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>	<4D889177.6050601@acm.org>	<19848.44539.573781.500799@montanaro.dyndns.org>	<4D88B4BB.1020700@acm.org>	<19848.50842.822463.535818@montanaro.dyndns.org>	<4D88CF11.6010401@acm.org>
	<19849.6765.980365.999085@montanaro.dyndns.org>
Message-ID: <4D891B32.4010501@netwok.org>

> I think that would make my local change unnecessary.  So, my next project is
> to try and figure out how to undo my change.  This seemed to work:
> 
>     hg revert -r 68263 Python/sysmodule.c
> 
> Was that the right thing to do?

Use hg backout, not revert.

From barry at python.org  Tue Mar 22 23:00:41 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Mar 2011 18:00:41 -0400
Subject: [Python-Dev] Module version variable
In-Reply-To: <AANLkTikuhJDT5BPzr0X6Co1vu0LAPT99fukuPmavi3mh@mail.gmail.com>
References: <AANLkTi=0E=qDw7K6fTO+Z=bQ1eN+OKqUmb-8ay+KimsF@mail.gmail.com>
	<4D80F460.6010307@voidspace.org.uk>
	<20110316183322.A34F424A614@kimball.webabinitio.net>
	<68FA7C26-D853-402D-A3C2-586F5ADE1874@gmail.com>
	<AANLkTingAxp1K8Dfo6H1hiCLbLBmD=Wn=QHZnf3oc=rV@mail.gmail.com>
	<4D81367B.9010808@trueblade.com> <ilrgoc$efd$1@dough.gmane.org>
	<4D8414E4.7060001@canterbury.ac.nz>
	<AANLkTimDP6atDpXbOOwtnr+3SDdvNRsNdiyqvSDm8GZx@mail.gmail.com>
	<20110319031219.GC19053@unaka.lan>
	<AANLkTin24CORfNhrX3pVWhWFKwp1ttUxJo6oqHhPqdX8@mail.gmail.com>
	<20110322173009.35e9b5da@neurotica.wooz.org>
	<AANLkTikuhJDT5BPzr0X6Co1vu0LAPT99fukuPmavi3mh@mail.gmail.com>
Message-ID: <20110322180041.3c6057cf@limelight.wooz.org>

On Mar 22, 2011, at 02:38 PM, Guido van Rossum wrote:

>All trails eventually lead to Ken! :-)

Indeed!

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/577b2588/attachment.pgp>

From barry at python.org  Tue Mar 22 23:05:39 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 Mar 2011 18:05:39 -0400
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <AANLkTimTreRdZ9A2nakEOYZ5LVej0PLRfSG02t0g7QXs@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<4D8767E7.8020702@cadifra.com>
	<20110321171930.02BBE13F980@kimball.webabinitio.net>
	<20110321135351.20632230@limelight.wooz.org>
	<4D886FA4.7040502@arbash-meinel.com>
	<20110322142529.62c54e22@neurotica.wooz.org>
	<AANLkTimTreRdZ9A2nakEOYZ5LVej0PLRfSG02t0g7QXs@mail.gmail.com>
Message-ID: <20110322180539.7afef161@limelight.wooz.org>

On Mar 23, 2011, at 07:31 AM, Nick Coghlan wrote:

>On Wed, Mar 23, 2011 at 4:25 AM, Barry Warsaw <barry at python.org> wrote:
>> It probably wouldn't be a bad idea to add a very fast "smoke test" for the
>> case where you get tripped up on the merge dance floor. ?When that happens,
>> you could run your localized tests, and then a set of tests that run in just a
>> minute or two.
>
>What would such a smoke test cover, though? It's hard to think of
>anything particularly useful in the middle ground between "Can you run
>regrtest *at all*?" and "make quicktest".

make quicktest runs 340 tests, and I'm certain many don't need to be run in a
smoke test.  E.g. 

test_aifc
test_colorsys
test_concurrent_futures
(that's as far as it's gotten so far ;)

Or you could time each individual test, choose a cut off for total test run
and then run whatever you can within that time (on some reference machine).
Or maybe just remove the longest running 50% of the quick tests.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/8322ed4d/attachment.pgp>

From ncoghlan at gmail.com  Tue Mar 22 23:12:14 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 08:12:14 +1000
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <19848.49696.338477.542385@montanaro.dyndns.org>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
	<20110322125120.GA3274@kevin>
	<19848.49696.338477.542385@montanaro.dyndns.org>
Message-ID: <AANLkTikNVVLroV9XdxvJ+ZG6+VAvYLSLapxkT4gPueZY@mail.gmail.com>

On Wed, Mar 23, 2011 at 1:37 AM,  <skip at pobox.com> wrote:
> Doesn't that just complicate my setup? ?Let's just consider the cpython repo
> (is that the right term? maybe branch instead?). ?Today, I have a local
> repository named "cpython" which refers to ssh://hg at hg.python.org/cpython as
> its default. ?Now you suggest I need to create another public repository.
> So my "chain of command" becomes: local depends on my global, which depends
> on the real cpython global. ?Now replicate that for the different active
> branches (2.7, 3.2 at least).

Yes and no.

Historically, you had your local working copy of the SVN repository,
probably a few other working copies for the different maintenance
branches, and then a whole pile of patches for works in progress. If
you had a long running branch you wanted to work on, you probably had
a separate working copy for that as well. A lot of the patches were
probably made publicly available to others by posting them on a
tracker item.

Now, consider my own current hg setup (which I'm reasonably happy with so far):

I have 4 "clean" local repositories which correspond to the active
hg.python.org/cpython branches: py3k=default, python32=3.2,
python31=3.1 and python27=2.7
Of those 4, only py3k actually points at the server by default - the
others either point to py3k (python32, python27) or to python32
(python31).
I have a simple shell script that steps through all 4 branches doing a
"hg pull -u"

This part really isn't all that different from what I had with SVN,
except that it is all a *lot* faster, since everything happens locally
aside from the push/pull steps between my py3k repo and
hg.python.org/cpython.

The big difference is that I now only work in these repositories if I
am getting ready to commit something. Otherwise, I work in a separate
local repository: sandbox.

My public sandbox is a server-side clone of cpython that lives at
hg.python.org/sandbox/ncoghlan
I create feature branches there to work on things that I am developing
myself (when applying patches created by others I'll work in the main
repos)
The default, 3.2, 3.1, etc branches are exact mirrors of the
corresponding branches in cpython
I have an alias set up in .hgrc so that "hg pull cpython" will bring
my sandbox repo up to speed with the latest changes to the main
repository
By pushing changes to my public sandbox, they're not only available
for others to see, but also allow me to easily keep my desktop and
laptop in sync
A simple "hg diff -r default" (or "-r 3.2" etc) from one of my named
branches gives me a patch file I can then import into the main
repositories, ready to commit

I have no need to maintain multiple sandbox repositories, since I just
switch between branches and rebuild as necessary.

Once the named branch support in the roundup integration is working,
I'll never need to manually publish a patch to the tracker again -
I'll just point roundup at the appropriate named branch in my sandbox
and hit the "create patch" button.

And the most interesting part of all this? Someone without push rights
can use the *exact same workflow*, with the only difference being that
their sandbox would be somewhere like bitbucket or Google code, rather
than on hg.python.org.

Instead of dead patches living on the tracker, we instead have
significantly easier to update live branches living in cloned
repositories.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From v+python at g.nevcal.com  Tue Mar 22 23:42:27 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Tue, 22 Mar 2011 15:42:27 -0700
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D891815.3060605@netwok.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<87wrjs456h.fsf@benfinney.id.au>	<4D87E34E.2000201@canterbury.ac.nz>	<4D87E4A6.1090404@netwok.org>	<20110322102557.516914f6@neurotica.wooz.org>
	<4D891815.3060605@netwok.org>
Message-ID: <4D8925D3.1020208@g.nevcal.com>

On 3/22/2011 2:43 PM, ?ric Araujo wrote:
>>> Bazaar apparently has a notion of mainline whereas Mercurial believes
>>> that all changesets are created equal.  The tools are different.
>> I'm curious: what are the benefits of the Mercurial model?
> Simplicity.

That's an amusing response, after reading hundreds of emails on this 
list about 5-12 step sequences of commands required to perform one 
operation.  So I must ask: where is the simplicity manifested?

I've been waiting for the hg conversion to start attempting to 
contribute to Python in any significant way, because I didn't know SVN, 
and didn't know hg, and didn't figure I had time to learn both. I 
haven't read the new devguide yet, but from the activity on the list, it 
would seem that either no one else has either, or that it doesn't answer 
the important questions about the hg aspects of the development 
process.  On the other hand, perhaps 5-12 step sequences of commands are 
short in comparison to the steps required for other (non-hg) DVCS tools?

I don't recall 5-12 step sequences in the DVCS PEP when I read it once, 
for any of the tools, but things progressed from the time I read it, so 
maybe they would all have longer sequences.

Back when I used non-distributed VCS systems like SCCS, RCS, PVCS, CVS, 
and Clearcase, I don't recall any operations that took more than 2 or 3 
commands to achieve (merges, of course, were onerous in some of those, 
and locking sometimes stalled progress in some ways in some of those).

Now I'm wondering when the hg issues will be settled enough to attempt 
to read the devguide, and attempt to submit code to the http.server to 
try to fix the many bugs and limitations it has, many of which I've 
worked around or fixed in a private copy of server.py.  No one else 
seemed to be interested enough in those bugs when I reported them to fix 
them prior to the release 3.2, so it seems to me that code is basically 
unmaintained.  The present state of the code is sort of like a dead 
battery... it might function a little but has such severe limits that it 
is not particularly useful... and it is an itch I might be able to scratch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/0962f7ba/attachment.html>

From sjoerd at acm.org  Tue Mar 22 23:55:49 2011
From: sjoerd at acm.org (Sjoerd Mullender)
Date: Tue, 22 Mar 2011 23:55:49 +0100
Subject: [Python-Dev] crosses branches?
In-Reply-To: <19849.6765.980365.999085@montanaro.dyndns.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
	<19848.44539.573781.500799@montanaro.dyndns.org>
	<4D88B4BB.1020700@acm.org>
	<19848.50842.822463.535818@montanaro.dyndns.org>
	<4D88CF11.6010401@acm.org>
	<19849.6765.980365.999085@montanaro.dyndns.org>
Message-ID: <4D8928F5.3040806@acm.org>

On 2011-03-22 22:53, skip at pobox.com wrote:
> 
>     Sjoerd> Perhaps looking at the glog output will shed some light.  If you
>     Sjoerd> don't have it yet, enable the graphlog extension, after which
>     Sjoerd> you can use hg glog to look at your clone.  Look in particular
>     Sjoerd> at the changeset which is marked with an @ sign instead of an o.
>     Sjoerd> That (or those if you're in the middle of a merge) is the
>     Sjoerd> "parent" of your working set.
> 
>     ...
>     | | | | | | @  changeset:   68309:c3caaf979b9e
>     | | | | | |/   branch:      2.5
>     | | | | | |    parent:      68263:7790ad8332ba
>     | | | | | |    user:        Skip Montanaro <skip at pobox.com>
>     | | | | | |    date:        Sun Mar 06 21:31:25 2011 -0600
>     | | | | | |    summary:     manually expand the defunct HeadURL subversion keyword
>     ...

Here you see one of your heads.  The lines show the dependencies among
the changesets, and your change has no children (line going up), i.e.
it's a head.

> I see no other "parent"s.  I have to admit I don't know how to read this
> output or what I should look for in the way of conflicts.  Also, it produced
> 20+MB of output, so I can't just paste it into this message and ask anyone
> to read the tea leaves.
> 
> Oh, wait a minute.  It looks like Martin relented on his desire not to
> modify the 2.5 Mercurial repo:
> 
>     | | | | o  changeset:   68802:f9763c363cc3
>     | | | | |  branch:      2.5
>     | | | | |  parent:      68696:cc959f114739
>     | | | | |  user:        Martin v. L?wis <martin at v.loewis.de>
>     | | | | |  date:        Mon Mar 21 10:30:07 2011 +0100
>     | | | | |  summary:     Set subversion version identification to empty strings if this is not a subversion

Here I was mistaken, it's not a head since there is a line going up from
this changeset (you didn't show it, but it's there).  But the child of
this changeset is in a different branch (2.6).  So as far as the 2.5
branch is concerned, it's a head.

> 
> I think that would make my local change unnecessary.  So, my next project is
> to try and figure out how to undo my change.  This seemed to work:
> 
>     hg revert -r 68263 Python/sysmodule.c
> 
> Was that the right thing to do?

No.  Revert just reverts local (non-committed) changes.

Either you don't need your change anymore and you can strip it (if your
changeset never left this particular clone) (you need the rebase
extension for that), or you can tell Hg that you want to abandon your
head (I'm not actually sure this can be done, and if it can, how), or
you can merge the two changesets: hg update -C 68309; hg merge 68802; hg
commit.  And finally, you can rebase: hg rebase -s 68309 -d 68802.  The
rebase will graft your changeset on top of Martin's.

> 
> S


-- 
Sjoerd Mullender

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 371 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/74ca546e/attachment-0001.pgp>

From greg.ewing at canterbury.ac.nz  Tue Mar 22 23:58:26 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 23 Mar 2011 11:58:26 +1300
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <4D8910BB.8090307@pearwood.info>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
	<4D8910BB.8090307@pearwood.info>
Message-ID: <4D892992.6030808@canterbury.ac.nz>

Steven D'Aprano wrote:

> The main one that comes to my mind is that other than looping, any time 
> I want to process dict.items() etc I often need to call list() first.

I don't think that's such a bad thing. It makes it clear that
you're performing a more expensive operation than just looking
at the keys.

-- 
Greg

From orsenthil at gmail.com  Wed Mar 23 00:05:12 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 23 Mar 2011 07:05:12 +0800
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D8925D3.1020208@g.nevcal.com>
References: <1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz> <4D87E4A6.1090404@netwok.org>
	<20110322102557.516914f6@neurotica.wooz.org>
	<4D891815.3060605@netwok.org> <4D8925D3.1020208@g.nevcal.com>
Message-ID: <20110322230512.GA4059@kevin>

On Tue, Mar 22, 2011 at 03:42:27PM -0700, Glenn Linderman wrote:
> and didn't figure I had time to learn both. I haven't read the new devguide
> yet, but from the activity on the list, it would seem that either no one else

I think, it is a good idea to read that. You might find that many
discussions are stemming from assumptions rather than following the
instructions.

> the devguide, and attempt to submit code to the http.server to try to fix the
> many bugs and limitations it has, many of which I've worked around or fixed in
> a private copy of server.py.  No one else seemed to be interested enough in
> those bugs when I reported them to fix them prior to the release 3.2, so it

I remember your issues, many of them are I would say 'tricky' ones
which would need some time to review/fix. Let's see it to get it in
3.3 release.

> seems to me that code is basically unmaintained.  The present state of the code
> is sort of like a dead battery... it might function a little but has such
> severe limits that it is not particularly useful... and it is an itch I might
> be able to scratch.

If you wish, please maintain a mecurial repository and point the full
code in the bug-reports, it may be easy to pull a patch and patch the
current line of code. 

-- 
Senthil

From stutzbach at google.com  Wed Mar 23 00:08:52 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Tue, 22 Mar 2011 16:08:52 -0700
Subject: [Python-Dev] [Python-checkins] cpython (2.7): Issue 10787:
 Document the probability density function for random.gammavariate.
In-Reply-To: <E1Q2ARc-0006Et-Dv@dinsdale.python.org>
References: <E1Q2ARc-0006Et-Dv@dinsdale.python.org>
Message-ID: <AANLkTin5dBcLO2deh=uLpPZMe0KJBAVjHkqfZ8P7ZE79@mail.gmail.com>

Raymond,

The Doc/reference/datamodel.rst change appears unrelated and wasn't in the
3.x version of this commit.  Was the change intentional?

On Tue, Mar 22, 2011 at 3:52 PM, raymond.hettinger <
python-checkins at python.org> wrote:

> http://hg.python.org/cpython/rev/42816be02b9b
> changeset:   68845:42816be02b9b
> branch:      2.7
> parent:      68841:50cc60852a76
> user:        Raymond Hettinger <python at rcn.com>
> date:        Tue Mar 22 15:52:46 2011 -0700
> summary:
>  Issue 10787: Document the probability density function for
> random.gammavariate.
>
> files:
>  Doc/reference/datamodel.rst
>  Lib/random.py
>
> diff --git a/Doc/reference/datamodel.rst b/Doc/reference/datamodel.rst
> --- a/Doc/reference/datamodel.rst
> +++ b/Doc/reference/datamodel.rst
> @@ -1540,10 +1540,10 @@
>
>  The following methods only apply when an instance of the class containing
> the
>  method (a so-called *descriptor* class) appears in the class dictionary of
> -another new-style class, known as the *owner* class. In the examples
> below, "the
> -attribute" refers to the attribute whose name is the key of the property
> in the
> -owner class' ``__dict__``.  Descriptors can only be implemented as
> new-style
> -classes themselves.
> +another new-style class (known as the *owner* class) or one of its
> +descendants.  In the examples below, "the attribute" refers to the
> attribute
> +whose name is the key of the property in the owner class' ``__dict__``.
> +Descriptors can only be implemented as new-style classes themselves.
>
>
>  .. method:: object.__get__(self, instance, owner)
> diff --git a/Lib/random.py b/Lib/random.py
> --- a/Lib/random.py
> +++ b/Lib/random.py
> @@ -490,6 +490,12 @@
>
>         Conditions on the parameters are alpha > 0 and beta > 0.
>
> +        The probability distribution function is:
> +
> +                    x ** (alpha - 1) * math.exp(-x / beta)
> +          pdf(x) =  --------------------------------------
> +                      math.gamma(alpha) * beta ** alpha
> +
>         """
>
>         # alpha > 0, beta > 0, mean is alpha*beta, variance is
> alpha*beta**2
>
> --
> Repository URL: http://hg.python.org/cpython
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
>


-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/6d39f3ee/attachment.html>

From merwok at netwok.org  Wed Mar 23 00:26:04 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 23 Mar 2011 00:26:04 +0100
Subject: [Python-Dev] crosses branches?
In-Reply-To: <4D8928F5.3040806@acm.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>	<4D889177.6050601@acm.org>	<19848.44539.573781.500799@montanaro.dyndns.org>	<4D88B4BB.1020700@acm.org>	<19848.50842.822463.535818@montanaro.dyndns.org>	<4D88CF11.6010401@acm.org>	<19849.6765.980365.999085@montanaro.dyndns.org>
	<4D8928F5.3040806@acm.org>
Message-ID: <4D89300C.8040409@netwok.org>

Hi,

>> I have to admit I don't know how to read this output or what I should look
>> for in the way of conflicts.
Are these resources helpful?  (You don?t have to read them all, but if
the first doesn?t work, try the following one.)

About log:
http://mercurial.selenic.com/wiki/TutorialHistory
http://mercurial.selenic.com/wiki/GraphlogExtension
http://mercurial.aragost.com/kick-start/en/basic/#inspecting-history

About merges, heads and parents:
http://hginit.com/04.html
http://mercurial.selenic.com/wiki/Merge
http://mercurial.selenic.com/wiki/UnderstandingMercurial#Revisions.2C_changesets.2C_heads.2C_and_tip
http://mercurial.selenic.com/wiki/MultipleHeads

To help us troubleshoot your issue, can you confirm this: you were in a
clone with the 2.5 branch checked out (?hg id? will tell that), you
pulled from 2.6, and the update action (from ?pull -u?) failed.


>> [...] I think that would make my local change unnecessary.
Correct.

>> So, my next project is to try and figure out how to undo my change.
http://mercurial.selenic.com/wiki/PruningDeadBranches#Using_clone
If you follow that method, don?t forget to copy your .hg/hgrc to the new
clone.

>> This seemed to work:
?Seemed? is the right word :(  More on
http://mercurial.selenic.com/wiki/Revert or ?hg help revert?.


> No.  Revert just reverts local (non-committed) changes.
This is untrue; Skip used a -r argument.  See above.
One thing to understand is that revert changes file contents only,
whereas update moved you on the revision graph.

> [snip]
Advanced commands like strip (bundled with mq BTW, not rebase) should
*not* be recommended lightly to people who are still learning the normal
use of Mercurial, IMO.  Throwing mentions of rebase, strip, transplant
can be harmful.  Let?s focus on clone, pull, update and merge first.
(That?s why the devguide tries to select one or two workflows; we know
that Mercurial is hella flexible, but choice is not a good thing when
you?re learning.)

Regards

From merwok at netwok.org  Wed Mar 23 01:49:00 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 23 Mar 2011 01:49:00 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D8882FF.2040609@cadifra.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<AANLkTikuh7S2CKdpTodPtj=4JnhAepPTm-zwKjCHjjPg@mail.gmail.com>	<20110321161901.6fdb7d50@limelight.wooz.org>	<4D88779B.3040508@arbash-meinel.com>
	<4D8882FF.2040609@cadifra.com>
Message-ID: <4D89437C.8090305@netwok.org>

> FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
> branch name is reserved, and it implies that the head with the highest
> revision number from that branch will be checked out on 'hg clone'.

This does not fully maps to Bazaar?s concept of mainline, though.

An aside for Bazaar users: Kindly stop referring to Mercurial
repositories as branches, it?s confusing.  Thank you.

Regards

From merwok at netwok.org  Wed Mar 23 02:01:13 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 23 Mar 2011 02:01:13 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D8925D3.1020208@g.nevcal.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<87wrjs456h.fsf@benfinney.id.au>	<4D87E34E.2000201@canterbury.ac.nz>	<4D87E4A6.1090404@netwok.org>	<20110322102557.516914f6@neurotica.wooz.org>
	<4D891815.3060605@netwok.org> <4D8925D3.1020208@g.nevcal.com>
Message-ID: <4D894659.1010405@netwok.org>

>>> I'm curious: what are the benefits of the Mercurial model?
>> Simplicity.
> 
> That's an amusing response, after reading hundreds of emails on this 
> list
I think the great number of messages is caused by incomplete learning,
confusion caused by familiarity with other tools, FUD and anxiety.

Just in case my position is not clear: I have a lot of sympathy for
people who struggle with the new tool and workflow and do try to help.

> about 5-12 step sequences of commands required to perform one operation.
Committing, merging and sharing are not one operation.

> So I must ask: where is the simplicity manifested?
I used simplicity in its strict (or scientific, if this speaks to you)
meaning: not complex, not many-sided.  Having one thing (a notion of an
unnamed branch) instead of two things (a notion of trunk and a notion of
side branch) is by definition simpler.

I often describe Mercurial?s simplicity (or chosen stupidity) as the
reason for its robustness and consistency.  (For example, the frowning
upon history rewriting, or the absence of octopus merging.)

That said, I cannot learn Mercurial for you, not force you to read the
devguide.  I would advise you to learn Mercurial with one of the many
available resources (http://hginit.com/,
http://mercurial.aragost.com/kick-start/), proceed to the devguide,
clone https://bitbucket.org/mirror/cpython and start fixing things in
http.server (and thanks in advance for that work!).

Regards

From tjreedy at udel.edu  Wed Mar 23 02:20:21 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 22 Mar 2011 21:20:21 -0400
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D889BC8.4080909@netwok.org>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>
	<4D889BC8.4080909@netwok.org>
Message-ID: <imbhsk$p7u$1@dough.gmane.org>

On 3/22/2011 8:53 AM, ?ric Araujo wrote:
>> I still don't understand what that's supposed to look like.  Is it supposed
>> to be a URL which refers to my local repository?
> No, to a repository published somewhere (hg.python.org, bitbucket (make
> a server-side clone of mirror/cpython), any other hosting service).
>
> You have to use one public repo per bug, as roundup will only use the
> default branch to compute the diff.  Maybe adding support for named
> branches so that you can have one repo used for many bug reports would
> be useful.
>
>> Sorry, I don't see a "Create Patch" button anywhere.
> On the right of the field containing the repo URI on
> http://bugs.python.org/issue11591

Pressing that button seems to create a duplicate patch, which is not 
good. Given that there is no connection between the repository names 
(which seem to be duplicated) and the resulting file name, there is no 
way to tell whether to press the button or what the result will be.

-- 
Terry Jan Reedy



From mhammond at skippinet.com.au  Wed Mar 23 02:30:49 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 23 Mar 2011 12:30:49 +1100
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D88F4A5.4060701@voidspace.org.uk>
References: <4D884E08.1020709@skippinet.com.au>
	<4D88F4A5.4060701@voidspace.org.uk>
Message-ID: <4D894D49.9060507@skippinet.com.au>

On 23/03/2011 6:12 AM, Michael Foord wrote:
> On 22/03/2011 07:21, Mark Hammond wrote:
>> Hi all,
>> I've made some changes to the draft PEP and checked it into the PEP
>> repository as PEP397. The reference implementation is currently being
>> tracked at http://bugs.python.org/issue11629.
>>
>
> Hey Mark,
>
> One way of supporting alternative implementations (that may not even
> have a standard install directory) is allowing configuration. e.g.
> config.ini
>
> [paths]
> ironpython = c:\Program Files\IronPython 2.7\ipy.exe
> ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
> jython = c:\Users\foobar\jython2.5\jython.exe

Hi Michael,

I'd have no problem with that in general, but how would you feel about 
letting the PEP stand as it is without this additional requirement and 
then treat this as an additional feature to be thrashed out separately? 
  I intentionally worded the PEP to specifically allow these kinds of 
features to be added outside the PEP process.

For example, I guess the name of the INI file wouldn't be config.ini, 
and I guess there might need to be a strategy to allow it to exist in 
multiple places for when users want this feature but don't have write 
access to the location of py.exe.  Then people might want it to be in 
the cwd, or in any parent of the cwd, etc... Further, it might also be 
possible to support this with simple environment variables which might 
wind up being just as (or more) reasonable (the concept of per-user 
environment variables already exist and a UI already exists for editing 
them, and it would allow different cmd-prompts to have different "rules" 
with minimal complexity) - not that I am necessarily advocating this - 
I'd just prefer the PEP to not get bogged down with those kinds of issues.

Cheers,

Mark

From martin at v.loewis.de  Wed Mar 23 02:51:01 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 23 Mar 2011 02:51:01 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <imbhsk$p7u$1@dough.gmane.org>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>	<4D889BC8.4080909@netwok.org>
	<imbhsk$p7u$1@dough.gmane.org>
Message-ID: <4D895205.1050404@v.loewis.de>

> Pressing that button seems to create a duplicate patch, which is not
> good. Given that there is no connection between the repository names
> (which seem to be duplicated) and the resulting file name, there is no
> way to tell whether to press the button or what the result will be.

Don't worry about this. It will *not* normally generate the same file
twice, but notice that it already created it. It's just because the
same repository was added twice that you can get the same patch out of
it twice also.

Regards,
Martin


From stephen at xemacs.org  Wed Mar 23 02:39:01 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 23 Mar 2011 10:39:01 +0900
Subject: [Python-Dev]  Workflow proposal
In-Reply-To: <4D88DE84.8050209@jcea.es>
References: <4D88DE84.8050209@jcea.es>
Message-ID: <87vcza8vka.fsf@uwakimon.sk.tsukuba.ac.jp>

Executive summary:

If we're really serious about serializing the public branches, mq
seems to be the way to go.

Jesus Cea writes:

 > 6. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and
 > "default". Leave the original commit in "3.1" alone.

I would suggest "hg strip --keep" which leaves the working copy
unchanged.  Now commit those changes (locally).  This will result in a
spurious commit by Antoine's standards, but should dramatically
decrease the burden on the contributor.  Daredevils<wink> can strip
this one too before committing the merge.

Really it would be preferable to do all this with mq, though. It seems
to me that this is precisely what qrefresh does.  The main issue I can
see is that I don't know an mq command to pop off a "real" commit and
turn it back into an mq patch.  I guess "hg strip --keep; hg qnew
<patch-name>" should do it though.

 > 3. Push my clone to a SANDBOX in hg.python.org ("hg push sandbox"). This
 > sandbox is synchronized with the official HG repository.

This sounds messy and fragile to me.  Better to implement a true
changeset queue manager, IMHO.

From solipsis at pitrou.net  Wed Mar 23 03:41:15 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 03:41:15 +0100
Subject: [Python-Dev] Workflow proposal
References: <4D88DE84.8050209@jcea.es>
	<87vcza8vka.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20110323034115.5e6e5822@pitrou.net>

On Wed, 23 Mar 2011 10:39:01 +0900
"Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Executive summary:
> 
> If we're really serious about serializing the public branches, mq
> seems to be the way to go.

I really think that at this point we should continue practicing with
the current setup before deciding on refinements or changes.

>  > 6. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and
>  > "default". Leave the original commit in "3.1" alone.
> 
> I would suggest "hg strip --keep" which leaves the working copy
> unchanged.

Now, "hg strip" should definitely be absent of any recommended or even
suggested workflow. It's a power user tool for the experimented
developer/admin. Not the average hg command.

By the way, whether or not mq gets used is pretty much anyone's private
decision (unless we decide that patches must get split into logical
units and mailbombed for review ala mercurial-devel, which would be a
significant departure from our development habits).

Regards

Antoine.




From stephen at xemacs.org  Wed Mar 23 03:12:30 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 23 Mar 2011 11:12:30 +0900
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <19848.37956.665020.538633@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
Message-ID: <87tyeu8u0h.fsf@uwakimon.sk.tsukuba.ac.jp>

skip at pobox.com writes:
 > 
 >     Stephen> This won't be pleasant if people are sprinting and lots of
 >     Stephen> commits are coming, because you're likely to repeatedly lose
 >     Stephen> the push race.  But in those conditions, nothing is guaranteed
 >     Stephen> to work in decentralized fashion (that's one reason why the
 >     Stephen> Linux kernel uses Linus and lieutenants as a serialization
 >     Stephen> mechanism).
 > 
 > So DVCS scales up to a point, then it breaks and you need to revert to some
 > sort of serialization scheme?

No, software engineering scales up to a point, then it breaks and you
need a serialization scheme.  The problem is not the DVCS, it's the
demand for a *centralized*, authoritative, safe, stable version.  DVCS
can scale at least to Linux kernel pace if you only ask for
centralized authoritative.<wink>  DVCS is "No Silver Bullet", it only
helps with some accidental costs of development.  It doesn't help with
the costs of review and testing.

There are in fact problems with the current generation of DVCSes.
Lack of plists on commits, for example.  You'd like to have a "tested"
property, in fact two of them (one for the committer, one for the
buildbots).  You'd like to have a "checkpoint" property, which commits
would by default be ignored by "log" and "bisect".  You'd like to have
an "issues" property, a list of issues applicable to this commit.  But
again, these would only reduce accidental costs.


From tjreedy at udel.edu  Wed Mar 23 03:47:29 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 22 Mar 2011 22:47:29 -0400
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D895205.1050404@v.loewis.de>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>	<4D889BC8.4080909@netwok.org>	<imbhsk$p7u$1@dough.gmane.org>
	<4D895205.1050404@v.loewis.de>
Message-ID: <imbn00$jnh$1@dough.gmane.org>

On 3/22/2011 9:51 PM, "Martin v. L?wis" wrote:
>> Pressing that button seems to create a duplicate patch, which is not
>> good. Given that there is no connection between the repository names
>> (which seem to be duplicated) and the resulting file name, there is no
>> way to tell whether to press the button or what the result will be.
>
> Don't worry about this. It will *not* normally generate the same file
> twice, but notice that it already created it. It's just because the
> same repository was added twice that you can get the same patch out of
> it twice also.

Could duplicate repositories be prevented?


-- 
Terry Jan Reedy



From martin at v.loewis.de  Wed Mar 23 03:57:22 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 23 Mar 2011 03:57:22 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <imbn00$jnh$1@dough.gmane.org>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>	<4D889BC8.4080909@netwok.org>	<imbhsk$p7u$1@dough.gmane.org>	<4D895205.1050404@v.loewis.de>
	<imbn00$jnh$1@dough.gmane.org>
Message-ID: <4D896192.7080702@v.loewis.de>

Am 23.03.2011 03:47, schrieb Terry Reedy:
> On 3/22/2011 9:51 PM, "Martin v. L?wis" wrote:
>>> Pressing that button seems to create a duplicate patch, which is not
>>> good. Given that there is no connection between the repository names
>>> (which seem to be duplicated) and the resulting file name, there is no
>>> way to tell whether to press the button or what the result will be.
>>
>> Don't worry about this. It will *not* normally generate the same file
>> twice, but notice that it already created it. It's just because the
>> same repository was added twice that you can get the same patch out of
>> it twice also.
> 
> Could duplicate repositories be prevented?

Yes, that would be possible.

Regards,
Martin

From skip at pobox.com  Wed Mar 23 04:02:50 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 22:02:50 -0500
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTimR=iVfTcaJUxjaHjUJ0UDD4+HdbYTjsd1_5U+w@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<8739mfoo28.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTimR=iVfTcaJUxjaHjUJ0UDD4+HdbYTjsd1_5U+w@mail.gmail.com>
Message-ID: <19849.25306.644509.965547@montanaro.dyndns.org>


    Daniel> On Mon, Mar 21, 2011 at 8:02 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:
    >> ... because I commit with *every* save ...  Effectively, I use git as
    >> an extension to XEmacs's undo/redo mechanism.

    Daniel> I, too, commit using git with every save (which I do early and
    Daniel> often).  It's saved my butt more than once....

Interesting concept.  So, I take it your commit messages are generally
empty?  Care to share the hook function?  (I trust it understands when you
save files not under version control.)

Skip


From stephen at xemacs.org  Wed Mar 23 04:30:17 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 23 Mar 2011 12:30:17 +0900
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <20110323034115.5e6e5822@pitrou.net>
References: <4D88DE84.8050209@jcea.es>
	<87vcza8vka.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110323034115.5e6e5822@pitrou.net>
Message-ID: <87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>

Antoine Pitrou writes:

 > Now, "hg strip" should definitely be absent of any recommended or even
 > suggested workflow. It's a power user tool for the experimented
 > developer/admin. Not the average hg command.

So what you're saying is that Mercurial by itself can't support the
recommended workflow, because any "collapsing" of commits requires
stripping, whether done by hg strip or implicitly by some other
"non-average" hg command.

 > By the way, whether or not mq gets used is pretty much anyone's private
 > decision (unless we decide that patches must get split into logical
 > units and mailbombed for review ala mercurial-devel, which would be a
 > significant departure from our development habits).

I don't see the connection; mq supplies "qfinish" for the purpose of
turning a patch into a commit.  All I'm suggesting is that "qrefresh"
is a nicer way to handle both the collapsing process and the strip/
re-merge/recommit process, although there is the problem of reverting
the commit back to an mq patch, which AFAIK requires a "strip --keep"
followed by "qnew".


From skip at pobox.com  Wed Mar 23 04:25:56 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 22:25:56 -0500
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D88FFBA.6080201@v.loewis.de>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
	<20110322125120.GA3274@kevin>
	<19848.49696.338477.542385@montanaro.dyndns.org>
	<4D88FFBA.6080201@v.loewis.de>
Message-ID: <19849.26692.210909.7984@montanaro.dyndns.org>


    Senthil> You will have to 'push' your changes to those so that they are
    Senthil> publicly visible and then point that url in the bug-tracker.
    >> 
    >> I can see this turning into a giant bowl of spaghetti.  How in the
    >> world are people supposed to understand how all these repositories
    >> are related to each other?

    Martin> Yes, it will turn into a giant bowl of spaghetti - that's the
    Martin> whole point of "Distributed" version control systems.

No, you don't understand.  Just the repositories I will have to deal with
will turn into a big bowl of spaghetti.  I could care less about everything
else.

    >> The Roundup interface is getting extraordinarily messy.

    Martin> So what is your constructive proposal?

I don't know how constructive you will find it without a patch, but here is
a short brain dump.

In general, the display should be weighted more heavily with content most
relevant to the current stage of the issue.  Elide or condense the other
stuff.  I know nothing about modern day website development, but I imagine
someone who does could work some JavaScript magic without a lot of trouble.
For example:

    * As soon as a case is "active" (left as an exercise for the reader to
      determine) most of the content I find useful occurs below the fold
      (attached files, review links, recent messages).

    * As soon as a case is opened, maybe after initial triage (do we need a
      new stage, "triage complete"?) by a core developer, it seems unlikely
      that most of the elements of the classification section will change.
      That can probably be a collapsed, and available to expose with a
      little expander button for interested parties.

    * I suspect parts of the process section can get a similar treatment
      (status, dependencies, etc).  Adding to the nosy list or subtracting
      from it (need a new [-] button) should always be visible).  I don't
      find the limited width text field all that useful.

    * Maybe the Files section should migrate to the top of the page once it
      starts accumulating contents (or maybe when the stage is "patch
      review").  Again, collapse the display so only the most recent patches
      are visible seems reasonable to me.

    * I don't know if it's possible to do easily, but when uploading a new
      version of a patch the user could be prompted to select other patches
      (or maybe they could be selected based on having the same name?)
      which the new patch makes obsolete so they can be elided from the
      default display.

Skip

From merwok at netwok.org  Wed Mar 23 04:28:25 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 23 Mar 2011 04:28:25 +0100
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D88DE84.8050209@jcea.es>	<87vcza8vka.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110323034115.5e6e5822@pitrou.net>
	<87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D8968D9.5020802@netwok.org>

> So what you're saying is that Mercurial by itself can't support the
> recommended workflow, because any "collapsing" of commits requires
> stripping, whether done by hg strip or implicitly by some other
> "non-average" hg command.

Pretty average: http://mercurial.selenic.com/wiki/PruningDeadBranches

> I don't see the connection; mq supplies "qfinish" for the purpose of
> turning a patch into a commit.  All I'm suggesting is that "qrefresh"
> is a nicer way to handle both the collapsing process and the strip/
> re-merge/recommit process, although there is the problem of reverting
> the commit back to an mq patch, which AFAIK requires a "strip --keep"
> followed by "qnew".

I like mq as a power tool, but only for short-term work.  Most of the
time I don?t need it.  Refreshing is painful to me whereas merging is
straightforward.  Mercurial devs themselves advocate real branches
(named, pbranch or what-have-you) for long-term work.

Regards

From skip at pobox.com  Wed Mar 23 04:39:32 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 22:39:32 -0500
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
	<20110322182925.54963164C39@kimball.webabinitio.net>
	<AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>
Message-ID: <19849.27508.662752.815498@montanaro.dyndns.org>


    Dirkjan> The right solution here is to use different clones for
    Dirkjan> different projects/areas. The proposed interpreter/stdlib
    Dirkjan> split, for example, might reduce contention (although I imagine
    Dirkjan> it would reduce it only by a little bit?). 

How about splitting the documentation and the code into separate
repositories (I believe that is the proper term, though perhaps "clone" is -
Dirkjan is the expert)?

Moving onto something related, but different, I find that people bandy about
terms which I just can't seem to find defined very well anywhere I've
looked.  The Mercurial Glossary (http://mercurial.selenic.com/wiki/Glossary)
would seem to be the obvious place to look, but it doesn't define the terms
"branch" or "clone" (nor does it obviously differentiate a "named branch"
from any other kind of "branch").  I hesitate to overload those words with
the meanings I've acquired using Subversion and CVS, because they will
probably be wrong in subtle ways.  Also, "rebase" is not defined in the
glossary.

There are clearly lots of Mercurial-related documents on the web.  There is
no editorial  review of their quality other than Google page rank.  Is there a
prioritized list of stuff one should read?

Again, I reveal my ignorance with stunning alacrity.  My apologies to the
experts.

>From Joel Spolsky:

    If you've been using Subversion, Mercurial is going to be confusing.

Got that right...

Skip

From skip at pobox.com  Wed Mar 23 04:43:06 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 22:43:06 -0500
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <AANLkTi=fKPgGDR4_RJRi4swbzinM1+f_QZsy9HXUS8PR@mail.gmail.com>
References: <4D88DE84.8050209@jcea.es>
	<AANLkTi=fKPgGDR4_RJRi4swbzinM1+f_QZsy9HXUS8PR@mail.gmail.com>
Message-ID: <19849.27722.607245.552023@montanaro.dyndns.org>


    Nick> 7. Merge the heads on the oldest branch that now has multiple heads

Two more stupid questions:

1.  Don't all branches have multiple heads?  Every time I execute hg heads I
    see many.

2.  Oldest in what way?  Pythonically (2.6 is older than 2.7 though it might
    have more recent checkins) or revision-wise (rev 68001 is newer than
    68000)?

If I had more time I'm sure I could ask more questions.

Skip

From skip at pobox.com  Wed Mar 23 04:46:12 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 22 Mar 2011 22:46:12 -0500
Subject: [Python-Dev] crosses branches?
In-Reply-To: <4D891B32.4010501@netwok.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
	<19848.44539.573781.500799@montanaro.dyndns.org>
	<4D88B4BB.1020700@acm.org>
	<19848.50842.822463.535818@montanaro.dyndns.org>
	<4D88CF11.6010401@acm.org>
	<19849.6765.980365.999085@montanaro.dyndns.org>
	<4D891B32.4010501@netwok.org>
Message-ID: <19849.27908.850264.863245@montanaro.dyndns.org>


    >> hg revert -r 68263 Python/sysmodule.c
    >> 
    >> Was that the right thing to do?

    merwok> Use hg backout, not revert.

They differ, how?

S

From merwok at netwok.org  Wed Mar 23 04:47:29 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 23 Mar 2011 04:47:29 +0100
Subject: [Python-Dev] crosses branches?
In-Reply-To: <19849.27908.850264.863245@montanaro.dyndns.org>
References: <19848.32733.782152.25450@montanaro.dyndns.org>
	<4D889177.6050601@acm.org>
	<19848.44539.573781.500799@montanaro.dyndns.org>
	<4D88B4BB.1020700@acm.org>
	<19848.50842.822463.535818@montanaro.dyndns.org>
	<4D88CF11.6010401@acm.org>
	<19849.6765.980365.999085@montanaro.dyndns.org>
	<4D891B32.4010501@netwok.org>
	<19849.27908.850264.863245@montanaro.dyndns.org>
Message-ID: <4D896D51.9040707@netwok.org>

> They differ, how?

Well, they?re not the same commands at all.  Revert changes the contents
of one or more files; backout renders a changeset moot by creating a new
changeset with the reverse diff.

Regards

From ncoghlan at gmail.com  Wed Mar 23 05:00:55 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 14:00:55 +1000
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <19849.27722.607245.552023@montanaro.dyndns.org>
References: <4D88DE84.8050209@jcea.es>
	<AANLkTi=fKPgGDR4_RJRi4swbzinM1+f_QZsy9HXUS8PR@mail.gmail.com>
	<19849.27722.607245.552023@montanaro.dyndns.org>
Message-ID: <AANLkTin8CcPYGUFOfz1f7z082A-juU3JFOdih_B0XpzV@mail.gmail.com>

On Wed, Mar 23, 2011 at 1:43 PM,  <skip at pobox.com> wrote:
>
> ? ?Nick> 7. Merge the heads on the oldest branch that now has multiple heads
>
> Two more stupid questions:
>
> 1. ?Don't all branches have multiple heads? ?Every time I execute hg heads I
> ? ?see many.

The branches we mainly care about should generally only have 1 head in
the public repository (the tip for the default branch, the last merge
point to default for 3.2 and 2.7, the last merge point to 3.2 for
3.1).

> 2. ?Oldest in what way? ?Pythonically (2.6 is older than 2.7 though it might
> ? ?have more recent checkins) or revision-wise (rev 68001 is newer than
> ? ?68000)?

Oldest in terms of the bug fix merging workflow (i.e.
3.1->3.2->default, or 2.6->2.7 if you're actually updating more than
just 2.7 in the 2.x series)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From rdmurray at bitdance.com  Wed Mar 23 07:46:13 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 23 Mar 2011 02:46:13 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D8925D3.1020208@g.nevcal.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<87wrjs456h.fsf@benfinney.id.au>
	<4D87E34E.2000201@canterbury.ac.nz> <4D87E4A6.1090404@netwok.org>
	<20110322102557.516914f6@neurotica.wooz.org>
	<4D891815.3060605@netwok.org> <4D8925D3.1020208@g.nevcal.com>
Message-ID: <20110323064613.A854E1454A2@kimball.webabinitio.net>

On Tue, 22 Mar 2011 15:42:27 -0700, Glenn Linderman <v+python at g.nevcal.com> wrote:
> I don't recall 5-12 step sequences in the DVCS PEP when I read it once, 
> for any of the tools, but things progressed from the time I read it, so 
> maybe they would all have longer sequences.
> 
> Back when I used non-distributed VCS systems like SCCS, RCS, PVCS, CVS, 
> and Clearcase, I don't recall any operations that took more than 2 or 3 
> commands to achieve (merges, of course, were onerous in some of those, 
> and locking sometimes stalled progress in some ways in some of those).

The 12 step cases are exactly merges, and the merges themselves are easy
with hg.

For simply getting a patch in to the default branch, svn had:

svn up
<apply patch etc>
svn up
svn ci

Whereas hg has:

hg pull -u
<apply patch etc>
hg commit
hg push

Same number of steps, but as has been pointed out, the hg push guarantees
no one else has made changes, whereas that safety-belt svn up before
the svn ci doesn't.

--
R. David Murray           http://www.bitdance.com

From techtonik at gmail.com  Wed Mar 23 08:01:02 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 23 Mar 2011 09:01:02 +0200
Subject: [Python-Dev] 2to3 status, repositories and HACKING guide
Message-ID: <AANLkTi=Uh7f56LdZ_kgvwQVF7t_FYNgqpfH34DdgppNG@mail.gmail.com>

Hi,

Currently 2to3 page at http://wiki.python.org/moin/2to3 lists
http://svn.python.org/view/sandbox/trunk/2to3 as a repository for 2to3
tool. There is also an outdated repository at http://hg.python.org/
and the page says that the code is finally integrated into CPython 2.6
- you can see it at
http://hg.python.org/cpython/file/default/Lib/lib2to3. So, what
version is more up-to-date?

In svn repository there is a HACKING guide advising to use
find_pattern.py script for writing new fixer. However, there is no
find_pattern.py in CPython repository, no HACKING guide, no any
documentation about how to write fixers or description of PATTERN
format. Did I miss something?
--
anatoly t.

From dirkjan at ochtman.nl  Wed Mar 23 08:51:58 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Wed, 23 Mar 2011 08:51:58 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <87tyeu8u0h.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
	<87tyeu8u0h.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTim-OjUGyv-OYguE-Gm2be+nLQoc6VdJRN4_Thtp@mail.gmail.com>

On Wed, Mar 23, 2011 at 03:12, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> No, software engineering scales up to a point, then it breaks and you
> need a serialization scheme. ?The problem is not the DVCS, it's the
> demand for a *centralized*, authoritative, safe, stable version. ?DVCS
> can scale at least to Linux kernel pace if you only ask for
> centralized authoritative.<wink> ?DVCS is "No Silver Bullet", it only
> helps with some accidental costs of development. ?It doesn't help with
> the costs of review and testing.

Yeah, Linux employs the other solution here (which Mercurial also
uses, in fact, for development of Mercurial itself): only one person
pushes to the central repository, that person pulls from other
"staging" repositories as he is aware of changes being made.

> There are in fact problems with the current generation of DVCSes.
> Lack of plists on commits, for example. ?You'd like to have a "tested"
> property, in fact two of them (one for the committer, one for the
> buildbots). ?You'd like to have a "checkpoint" property, which commits
> would by default be ignored by "log" and "bisect". ?You'd like to have
> an "issues" property, a list of issues applicable to this commit. ?But
> again, these would only reduce accidental costs.

Mercurial does in fact have a mechanism to attach arbitrary metadata
to changesets (the extra dictionary), but there's no easy access from
the command-line. One could also argue that this is basically just a
special case of smart commit message formatting, which python-dev
already does, and could extend. (For example, Mozilla sometimes closes
their tree to general commits, but then has a CLOSED tag that can be
put in a commit message to override that.)

Cheers,

Dirkjan

From dirkjan at ochtman.nl  Wed Mar 23 09:00:58 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Wed, 23 Mar 2011 09:00:58 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
	what is "collapse"?
In-Reply-To: <19849.27508.662752.815498@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<877hbsndv6.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19848.37956.665020.538633@montanaro.dyndns.org>
	<20110322182925.54963164C39@kimball.webabinitio.net>
	<AANLkTik7Eg0BjJpUcw8HULU-ybW1_LA2oE_Aeq0qoL2h@mail.gmail.com>
	<19849.27508.662752.815498@montanaro.dyndns.org>
Message-ID: <AANLkTimFq2Q8uOWtsQWvFHWomkRsAJHzT27-jTMLMDH7@mail.gmail.com>

On Wed, Mar 23, 2011 at 04:39,  <skip at pobox.com> wrote:
>
> ? ?Dirkjan> The right solution here is to use different clones for
> ? ?Dirkjan> different projects/areas. The proposed interpreter/stdlib
> ? ?Dirkjan> split, for example, might reduce contention (although I imagine
> ? ?Dirkjan> it would reduce it only by a little bit?).
>
> How about splitting the documentation and the code into separate
> repositories (I believe that is the proper term, though perhaps "clone" is -
> Dirkjan is the expert)?

That might work. I guess the stdlib/interpreter split should also
think about how to split up the docs.

And yes, clone might be a better word to use in this context. The
repository word is slightly overloaded, in that it can be used both
for clone, or to distinguish the .hg part from the working dir part of
a clone, for example.

> Moving onto something related, but different, I find that people bandy about
> terms which I just can't seem to find defined very well anywhere I've
> looked. ?The Mercurial Glossary (http://mercurial.selenic.com/wiki/Glossary)
> would seem to be the obvious place to look, but it doesn't define the terms
> "branch" or "clone" (nor does it obviously differentiate a "named branch"
> from any other kind of "branch"). ?I hesitate to overload those words with
> the meanings I've acquired using Subversion and CVS, because they will
> probably be wrong in subtle ways. ?Also, "rebase" is not defined in the
> glossary.

One problem with branches in DVCS is that there are so many kinds of
them. The SVN repository, for example, would now be reflected by all
of the clones of python-dev lineage (starting with the same changeset)
everywhere. Each of these clones represent a branch, in the sense that
someone can commit there and thus deviate from all other repositories.
If you commit twice from the same parent changeset in your clone, you
end up with two heads (on the same named branch), which are also
separate branches in the distributed global python-dev DAG. And all of
these are "unnamed" branches, possibly residing on the same named
branch...

> There are clearly lots of Mercurial-related documents on the web. ?There is
> no editorial ?review of their quality other than Google page rank. ?Is there a
> prioritized list of stuff one should read?

The hg wiki is a good resource, but can be a bit disorganized. You
might also want to read the hgbook, which is slightly outdated but
should have thorough explanations. It's also available in dead-tree
form.

Cheers,

Dirkjan

From regebro at gmail.com  Wed Mar 23 10:16:06 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 23 Mar 2011 10:16:06 +0100
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <4D8910BB.8090307@pearwood.info>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
	<4D8910BB.8090307@pearwood.info>
Message-ID: <AANLkTikieVGwEkvKG9gRbRCmeaD=yJFhjELMkkOrtRfH@mail.gmail.com>

On Tue, Mar 22, 2011 at 22:12, Steven D'Aprano <steve at pearwood.info> wrote:
> The main one that comes to my mind is that other than looping, any time I
> want to process dict.items() etc I often need to call list() first.

"Process" no. If you want it to be a list, yes. This is because they
now return generators, which is a massive improvement.

> but what I really
> didn't expect is to see that choice is made not in user's favor, but
> in a favor of speed.

I'm not sure what choice you are talking of here... And in this case
Python 2 behaved differently on different platforms and Python 3
doesn't. That seems to be an improvement to me...

//Lennart

From stefan_ml at behnel.de  Wed Mar 23 10:47:33 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 23 Mar 2011 10:47:33 +0100
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
	first experience)
In-Reply-To: <4D8910BB.8090307@pearwood.info>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
	<4D8910BB.8090307@pearwood.info>
Message-ID: <imcfjl$7uf$1@dough.gmane.org>

Steven D'Aprano, 22.03.2011 22:12:
> anatoly techtonik wrote:
>> I didn't touch Python3 until PyCon, and my first user experience is
>> not really good. I've got a feeling that Python3 became more ugly,
>> because it doesn't allow me to think about the logic anymore, and
>> requires more low-level workarounds even for basic user input/output.
>
> Do you have any examples other than print?
>
> The main one that comes to my mind is that other than looping, any time I
> want to process dict.items() etc I often need to call list() first.
> Fortunately looping is about 90% of my use-cases for the dict methods, but
> the other 10% nearly always requires a list().

Sounds like Python 3 has the perfect default behaviour then.

Stefan


From skip at pobox.com  Wed Mar 23 11:53:32 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 23 Mar 2011 05:53:32 -0500
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <AANLkTikNVVLroV9XdxvJ+ZG6+VAvYLSLapxkT4gPueZY@mail.gmail.com>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
	<20110322125120.GA3274@kevin>
	<19848.49696.338477.542385@montanaro.dyndns.org>
	<AANLkTikNVVLroV9XdxvJ+ZG6+VAvYLSLapxkT4gPueZY@mail.gmail.com>
Message-ID: <19849.53548.27898.827337@montanaro.dyndns.org>


    Nick> Now, consider my own current hg setup ...

This is the first soup-to-nuts description of an individual setup I've seen.
Is it documented somewhere?  If not, could you maybe add it as a complete
example to the developer's guide?  I have the local setup similar to what
you describe, but haven't made the mental leap to a public sandbox.

One other question.  You wrote:

    Nick> My public sandbox is a server-side clone of cpython that lives at
    Nick> hg.python.org/sandbox/ncoghlan I create feature branches there to
    Nick> work on things that I am developing myself (when applying patches
    Nick> created by others I'll work in the main repos)

What do you mean by "main repos" in this statement?  Is "repos" singular and
short for "repository" or is it the plural of "repo"?  Neither quite makes
sense to me because I guess I don't know what you mean by "main".  What
is/are the "main repos"?  hg.python.org/sandbox/ncoghlan?
hg.python.org/cpython? 

Skip

From skip at pobox.com  Wed Mar 23 12:09:04 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 23 Mar 2011 06:09:04 -0500
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <19849.26692.210909.7984@montanaro.dyndns.org>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
	<20110322125120.GA3274@kevin>
	<19848.49696.338477.542385@montanaro.dyndns.org>
	<4D88FFBA.6080201@v.loewis.de>
	<19849.26692.210909.7984@montanaro.dyndns.org>
Message-ID: <19849.54480.384253.110088@montanaro.dyndns.org>

    Martin> Yes, it will turn into a giant bowl of spaghetti - that's the
    Martin> whole point of "Distributed" version control systems.

    skip> No, you don't understand.  Just the repositories I will have to
    skip> deal with will turn into a big bowl of spaghetti.  I could care
    skip> less about everything else.

Nick's message about his personal setup cleared up much of this for me.

Skip

From john at arbash-meinel.com  Wed Mar 23 12:39:41 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Wed, 23 Mar 2011 12:39:41 +0100
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D88DE84.8050209@jcea.es>	<87vcza8vka.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110323034115.5e6e5822@pitrou.net>
	<87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D89DBFD.5000707@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/23/2011 4:30 AM, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
> 
>  > Now, "hg strip" should definitely be absent of any recommended or even
>  > suggested workflow. It's a power user tool for the experimented
>  > developer/admin. Not the average hg command.
> 
> So what you're saying is that Mercurial by itself can't support the
> recommended workflow, because any "collapsing" of commits requires
> stripping, whether done by hg strip or implicitly by some other
> "non-average" hg command.
> 

Just as an aside, and I might be wrong. But reading through what strip
does, (and from my knowledge of the disk layout) it can't actually be
atomic. So if you kill it at the wrong time, it will have corrupted your
repository.

At least, that is from what I can tell. Which is that it has to rewrite
each file history to omit the revisions you are stripping, and then
rewrite the revision history to do the same. It would be possible to be
'stable' if you wrote a write-ahead-log and did all the work on the
side, and then any client that tries to read or write to the repository
finishes up the steps. But the individual file histories refer to the
global revision history (by index), so you don't have a 'top-down' view
that makes it all atomic by changing the top level object to point to
the new lower level objects.

It is possible that they only rewrite the revisions file, leaving blanks
for the old references. But the statement "it rewrites the numbers"
means it is collapsing the offsets in the index.
http://mercurial.selenic.com/wiki/Strip

I definitely would be very leery of putting that in any sort of
recommended documentation. It also makes me understand more why hg folks
value having "hg check" run very quickly...

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2J2/0ACgkQJdeBCYSNAAPFCACfeGHMB3/td31EuyateqzcoNFx
87sAoKxDt8i1rqllHogRBMxTGUDzSsdd
=RgPe
-----END PGP SIGNATURE-----

From steve at pearwood.info  Wed Mar 23 12:43:51 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 23 Mar 2011 22:43:51 +1100
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <4D892992.6030808@canterbury.ac.nz>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>	<4D8910BB.8090307@pearwood.info>
	<4D892992.6030808@canterbury.ac.nz>
Message-ID: <4D89DCF7.1050506@pearwood.info>

Greg Ewing wrote:
> Steven D'Aprano wrote:
> 
>> The main one that comes to my mind is that other than looping, any 
>> time I want to process dict.items() etc I often need to call list() 
>> first.
> 
> I don't think that's such a bad thing. It makes it clear that
> you're performing a more expensive operation than just looking
> at the keys.

Oh, I didn't mean to imply that it was a bad thing. But it certainly is 
less convenient.


-- 
Steven

From john at arbash-meinel.com  Wed Mar 23 12:45:41 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Wed, 23 Mar 2011 12:45:41 +0100
Subject: [Python-Dev] I am now lost - committed, pulled, merged,
 what is "collapse"?
In-Reply-To: <20110322180539.7afef161@limelight.wooz.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>	<20110319192128.522235fb@pitrou.net>	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>	<4D85FAE0.40107@jcea.es>	<877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>	<19846.24793.573280.126001@montanaro.dyndns.org>	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321065835.664EC16245C@kimball.webabinitio.net>	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>	<20110321134015.B8ED364DAA@kimball.webabinitio.net>	<4D8767E7.8020702@cadifra.com>	<20110321171930.02BBE13F980@kimball.webabinitio.net>	<20110321135351.20632230@limelight.wooz.org>	<4D886FA4.7040502@arbash-meinel.com>	<20110322142529.62c54e22@neurotica.wooz.org>	<AANLkTimTreRdZ9A2nakEOYZ5LVej0PLRfSG02t0g7QXs@mail.gmail.com>
	<20110322180539.7afef161@limelight.wooz.org>
Message-ID: <4D89DD65.5020901@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/22/2011 11:05 PM, Barry Warsaw wrote:
> On Mar 23, 2011, at 07:31 AM, Nick Coghlan wrote:
> 
>> On Wed, Mar 23, 2011 at 4:25 AM, Barry Warsaw <barry at python.org> wrote:
>>> It probably wouldn't be a bad idea to add a very fast "smoke test" for the
>>> case where you get tripped up on the merge dance floor.  When that happens,
>>> you could run your localized tests, and then a set of tests that run in just a
>>> minute or two.
>>
>> What would such a smoke test cover, though? It's hard to think of
>> anything particularly useful in the middle ground between "Can you run
>> regrtest *at all*?" and "make quicktest".
> 
> make quicktest runs 340 tests, and I'm certain many don't need to be run in a
> smoke test.  E.g. 
> 
> test_aifc
> test_colorsys
> test_concurrent_futures
> (that's as far as it's gotten so far ;)
> 
> Or you could time each individual test, choose a cut off for total test run
> and then run whatever you can within that time (on some reference machine).
> Or maybe just remove the longest running 50% of the quick tests.
> 
> -Barry

bzr can run its 30,000 tests in about 15-30min depending on your
specific hardware and platform (it also supports parallel running of the
test suite). I think it takes about 1hr running single-threaded on
Windows because "os.rename()" is a fairly slow operation and we do it a
lot in most tests (it is part of our locking primitive).


Unit-tests (tests directly on a function without setting up lots of
external state) generally can execute in milliseconds.

I don't specifically know what is in those 340 tests, but 18min/340 =
3.2s for each test. Which is *much* longer than simple smoke tests would
have to be.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2J3WUACgkQJdeBCYSNAAMI2ACgl6obH9WKlmRiK4K4ib1g6SR7
KqkAn1LNrlBaUTf/sc5s30tZq3F3hmNl
=DtQ8
-----END PGP SIGNATURE-----

From steve at pearwood.info  Wed Mar 23 13:01:40 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 23 Mar 2011 23:01:40 +1100
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <AANLkTikieVGwEkvKG9gRbRCmeaD=yJFhjELMkkOrtRfH@mail.gmail.com>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
	<4D8910BB.8090307@pearwood.info>
	<AANLkTikieVGwEkvKG9gRbRCmeaD=yJFhjELMkkOrtRfH@mail.gmail.com>
Message-ID: <4D89E124.3000204@pearwood.info>

Lennart Regebro wrote:
> On Tue, Mar 22, 2011 at 22:12, Steven D'Aprano <steve at pearwood.info> wrote:
>> The main one that comes to my mind is that other than looping, any time I
>> want to process dict.items() etc I often need to call list() first.
> 
> "Process" no. If you want it to be a list, yes. This is because they
> now return generators, which is a massive improvement.

Well, yes, that's what I meant when I said other than looping. (I'm 
aware that there are uses for lazy iterators other than for-loops.)

But the improvement is exactly what Anatoly is talking about: it's an 
improvement in speed over user convenience. If all you are doing is 
iterating over a moderately-sized dictionary, you probably don't care 
whether items() etc. returns a list or an iterator. But if you want to 
take those items away and do something with them, you need a list, and 
that's ever-so-slightly less convenient now than it was.

To be clear, I'm *not* objecting to this state of affairs. I think the 
trade-off in this case is the right thing to do. But Anatoly seems to 
think that Python3 has generally made the wrong trade-off, and I was 
hoping he would mention some other concrete examples.


For the record, this next double-quoted >> statement is not by me. It 
was actually from Anatoly Techtonik:

>> but what I really
>> didn't expect is to see that choice is made not in user's favor, but
>> in a favor of speed.
> 
> I'm not sure what choice you are talking of here... And in this case
> Python 2 behaved differently on different platforms and Python 3
> doesn't. That seems to be an improvement to me...


Lennart, please be a little more careful with your attributions.




-- 
Steven

From dirkjan at ochtman.nl  Wed Mar 23 13:23:49 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Wed, 23 Mar 2011 13:23:49 +0100
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <4D89DBFD.5000707@arbash-meinel.com>
References: <4D88DE84.8050209@jcea.es>
	<87vcza8vka.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110323034115.5e6e5822@pitrou.net>
	<87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D89DBFD.5000707@arbash-meinel.com>
Message-ID: <AANLkTikyM71UTr-C3yXfG0xfwxDXQ8V1GBW6WEusxdvM@mail.gmail.com>

On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> Just as an aside, and I might be wrong. But reading through what strip
> does, (and from my knowledge of the disk layout) it can't actually be
> atomic. So if you kill it at the wrong time, it will have corrupted your
> repository.
>
> At least, that is from what I can tell. Which is that it has to rewrite
> each file history to omit the revisions you are stripping, and then
> rewrite the revision history to do the same. It would be possible to be
> 'stable' if you wrote a write-ahead-log and did all the work on the
> side, and then any client that tries to read or write to the repository
> finishes up the steps. But the individual file histories refer to the
> global revision history (by index), so you don't have a 'top-down' view
> that makes it all atomic by changing the top level object to point to
> the new lower level objects.

The reason that shouldn't happen is the ordering. If we strip the
changelog first (what you call the global revision history), other
clients won't be able to "find" the any file-level revisions only
referenced by the revision just stripped, so it should be atomic.

Cheers,

Dirkjan

From ncoghlan at gmail.com  Wed Mar 23 13:31:21 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 22:31:21 +1000
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <19849.53548.27898.827337@montanaro.dyndns.org>
References: <4D7D06F3.7020700@v.loewis.de> <4D87E909.8050602@netwok.org>
	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>
	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>
	<19848.38257.349896.870255@montanaro.dyndns.org>
	<20110322125120.GA3274@kevin>
	<19848.49696.338477.542385@montanaro.dyndns.org>
	<AANLkTikNVVLroV9XdxvJ+ZG6+VAvYLSLapxkT4gPueZY@mail.gmail.com>
	<19849.53548.27898.827337@montanaro.dyndns.org>
Message-ID: <AANLkTinwMK0QxoUj3p+fNqCOxYy_=v3uG9A-cnG260Ge@mail.gmail.com>

On Wed, Mar 23, 2011 at 8:53 PM,  <skip at pobox.com> wrote:
>
> ? ?Nick> Now, consider my own current hg setup ...
>
> This is the first soup-to-nuts description of an individual setup I've seen.
> Is it documented somewhere? ?If not, could you maybe add it as a complete
> example to the developer's guide? ?I have the local setup similar to what
> you describe, but haven't made the mental leap to a public sandbox.

My personal setup is just a combination of two existing sections in
the devguide:
http://docs.python.org/devguide/committing.html#using-several-working-copies
http://docs.python.org/devguide/committing.html#long-term-development-of-features

I could probably skip the personal sandbox if I used Mercurial queues
to manage changes I didn't want to commit yet, but I'm currently
liking the sandbox for the offsite backup and ease of synchronisation
between my own machines.

> One other question. ?You wrote:
>
> ? ?Nick> My public sandbox is a server-side clone of cpython that lives at
> ? ?Nick> hg.python.org/sandbox/ncoghlan I create feature branches there to
> ? ?Nick> work on things that I am developing myself (when applying patches
> ? ?Nick> created by others I'll work in the main repos)
>
> What do you mean by "main repos" in this statement? ?Is "repos" singular and
> short for "repository" or is it the plural of "repo"? ?Neither quite makes
> sense to me because I guess I don't know what you mean by "main". ?What
> is/are the "main repos"? ?hg.python.org/sandbox/ncoghlan?
> hg.python.org/cpython?

By "main repos" I meant the 4 local repos that I have set up to
(ultimately) push to hg.python.org/cpython. That should answer the
singular-or-plural question, too :)

So far I haven't found it necessary to use my sandbox to try out
patches - I'll just try them as uncommitted changes in my main working
copy for the relevant branch and then use "hg revert" to abandon them
if I decide not to commit them.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From john at arbash-meinel.com  Wed Mar 23 13:38:46 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Wed, 23 Mar 2011 13:38:46 +0100
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <AANLkTikyM71UTr-C3yXfG0xfwxDXQ8V1GBW6WEusxdvM@mail.gmail.com>
References: <4D88DE84.8050209@jcea.es>
	<87vcza8vka.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110323034115.5e6e5822@pitrou.net>
	<87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D89DBFD.5000707@arbash-meinel.com>
	<AANLkTikyM71UTr-C3yXfG0xfwxDXQ8V1GBW6WEusxdvM@mail.gmail.com>
Message-ID: <4D89E9D6.20507@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/23/2011 1:23 PM, Dirkjan Ochtman wrote:
> On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel
> <john at arbash-meinel.com> wrote:
>> Just as an aside, and I might be wrong. But reading through what strip
>> does, (and from my knowledge of the disk layout) it can't actually be
>> atomic. So if you kill it at the wrong time, it will have corrupted your
>> repository.
>>
>> At least, that is from what I can tell. Which is that it has to rewrite
>> each file history to omit the revisions you are stripping, and then
>> rewrite the revision history to do the same. It would be possible to be
>> 'stable' if you wrote a write-ahead-log and did all the work on the
>> side, and then any client that tries to read or write to the repository
>> finishes up the steps. But the individual file histories refer to the
>> global revision history (by index), so you don't have a 'top-down' view
>> that makes it all atomic by changing the top level object to point to
>> the new lower level objects.
> 
> The reason that shouldn't happen is the ordering. If we strip the
> changelog first (what you call the global revision history), other
> clients won't be able to "find" the any file-level revisions only
> referenced by the revision just stripped, so it should be atomic.
> 
> Cheers,
> 
> Dirkjan

http://mercurial.selenic.com/wiki/Strip

Thats only true if you are stripping only from the top. According to the
strip page, you also might re-order the numbers.

Also, even with stripping the changelog first, it still leaves you with
data in your repo that is going to suddenly think it is associated with
the *next* commit you do. (So I make a change to 'foo.txt' commit it,
then strip, the next commit I only change 'bar.txt'. If the strip was
canceled 'hg log foo.txt' would include the latest revision as modifying
foo.txt)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2J6dYACgkQJdeBCYSNAAMQMQCfXvD4dGOVV8LB9LmtMNqXeHys
5xkAoJBWAXXVbZcCKC1GXDPjUMSNbVtn
=k1FG
-----END PGP SIGNATURE-----

From ncoghlan at gmail.com  Wed Mar 23 13:49:39 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 22:49:39 +1000
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I am
 now lost - committed, pulled, merged, what is "collapse"?)
Message-ID: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>

On Wed, Mar 23, 2011 at 9:45 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> I don't specifically know what is in those 340 tests, but 18min/340 =
> 3.2s for each test. Which is *much* longer than simple smoke tests would
> have to be.

The counts Barry is referring to there are actually counting test
*files*, rather than individual tests. We only have 359 of those in
total though (not counting those in subdirectories), so a "quicktest"
that omits less than 6% of them doesn't sound particularly quick (even
if it does leave out the slowest ones).

We should probably do another pass and add a few more tests to the
blacklist in the Makefile template (starting with
test_concurrent_futures).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Mar 23 13:58:26 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 22:58:26 +1000
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
Message-ID: <AANLkTi=z0TxiaNRqj-t3XyLmJeLXp1fJLuMP88amF-hH@mail.gmail.com>

On Tue, Mar 22, 2011 at 9:57 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> For example, now I need to remember that on Windows I need to flush
> output every time when I want the result of print() with end!='\n' to
> appear on the screen immediately. And for the most of my legacy
> scripts I used end='\n' when I want to output some progress to user. I
> am surprised to know this never worked on Linux, but what I really
> didn't expect is to see that choice is made not in user's favor, but
> in a favor of speed. This way we'll be writing in a cross-platform
> assembly language named 'Python' soon. =)

Python 3 actually chose *cross-platform consistency* over user
convenience when switching away from the platform IO implementations.

That means things like line buffering of stdout is now the default on
all platforms, including Windows, and there is now a meaningful
distinction between files opened in binary mode (returning bytes) and
files opened in text mode (returning strings) on all platforms, rather
than *just* on Windows (where the "b" mode flag was historically
always needed to avoid corrupting binary files that happened to
contain CRLF sequences).

There are several ways to get unbuffered IO back in a cross-platform
manner, but efficient codec operation means working that way by
default would be a really bad idea. Users may *say* they prefer
convenience over speed, but that's only true until the lack of speed
becomes intolerably slow.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From jcea at jcea.es  Wed Mar 23 14:05:19 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 23 Mar 2011 14:05:19 +0100
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <4D88DE84.8050209@jcea.es>
References: <4D88DE84.8050209@jcea.es>
Message-ID: <4D89F00F.4010004@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/03/11 18:38, Jesus Cea wrote:
> Most of our problems are related to trying to keep a lineal history, and
> races with pull-patch-commit-push cycle. I propose the following workflow.

The points of my proposal are:

1. The hg.python.org repository has the branches ALWAYS merged. This
must be enforced by the push hooks.

2. We need a way to test code in the buildbots, without committing the
patch to the "real" repository.

How to do "2" and how to solve the push race in "1", are not the point
:-). I do an approach suggestion for both, just for the sake of
completeness, for I want to stress that the my actual contribution is
"1" and "2" :).

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYnwD5lgi5GaxT1NAQKxVAP7BelEjoSz91zCQodvmdP8E03pP+W6xJhR
DAwMcerrqGfV/XP45HvMk8kjwHuGQvA4jmvi+M/8QWnpJ3g3YoTR7ADHzzpF1ngq
Fx0D3bAxwPFJQhiEMbFOrH3v5+9vbo5T26pUHUlDbF+/rcEY82m7GWAv4QqmceQ8
nbJ3PETIYf8=
=m9qH
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Wed Mar 23 14:30:00 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 14:30:00 +0100
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D88DE84.8050209@jcea.es>
	<87vcza8vka.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110323034115.5e6e5822@pitrou.net>
	<87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20110323143000.75743e55@pitrou.net>

On Wed, 23 Mar 2011 12:30:17 +0900
"Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Antoine Pitrou writes:
> 
>  > Now, "hg strip" should definitely be absent of any recommended or even
>  > suggested workflow. It's a power user tool for the experimented
>  > developer/admin. Not the average hg command.
> 
> So what you're saying is that Mercurial by itself can't support the
> recommended workflow, because any "collapsing" of commits requires
> stripping,

Not really. It requires that you either:
- work on your long-term features in a separate repo (and produce a
  diff at the end that you will apply to the main repo)
- use mq
- use a non-committing equivalent of mq (iterate on a patch which you
  periodically save with "hg di", for example; that's what I do for
  most patches)

Apparently some of you think "collapsing" should involve some specific
hg command. It doesn't. Perhaps the devguide should be rephrased there.

Regards

Antoine.

From solipsis at pitrou.net  Wed Mar 23 14:31:23 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 14:31:23 +0100
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
Message-ID: <20110323143123.4be80686@pitrou.net>

On Wed, 23 Mar 2011 22:49:39 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Wed, Mar 23, 2011 at 9:45 PM, John Arbash Meinel
> <john at arbash-meinel.com> wrote:
> > I don't specifically know what is in those 340 tests, but 18min/340 =
> > 3.2s for each test. Which is *much* longer than simple smoke tests would
> > have to be.
> 
> The counts Barry is referring to there are actually counting test
> *files*, rather than individual tests. We only have 359 of those in
> total though (not counting those in subdirectories), so a "quicktest"
> that omits less than 6% of them doesn't sound particularly quick (even
> if it does leave out the slowest ones).
> 
> We should probably do another pass and add a few more tests to the
> blacklist in the Makefile template (starting with
> test_concurrent_futures).

Does anyone use "make quicktest" for something useful?
There is a reason the regression test suite has many tests...
"Blacklisting" some of them sounds like a bad thing to do.

Regards

Antoine.



From victor.stinner at haypocalc.com  Wed Mar 23 14:32:36 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Wed, 23 Mar 2011 14:32:36 +0100
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <AANLkTi=z0TxiaNRqj-t3XyLmJeLXp1fJLuMP88amF-hH@mail.gmail.com>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
	<AANLkTi=z0TxiaNRqj-t3XyLmJeLXp1fJLuMP88amF-hH@mail.gmail.com>
Message-ID: <1300887156.29974.2.camel@marge>

Le mercredi 23 mars 2011 ? 22:58 +1000, Nick Coghlan a ?crit :
> There are several ways to get unbuffered IO back in a cross-platform
> manner, but efficient codec operation means working that way by
> default would be a really bad idea. Users may *say* they prefer
> convenience over speed, but that's only true until the lack of speed
> becomes intolerably slow.

Amaury proposed in the issue (#11633) that print does flush if the end
option is used. I vote +0, but only if we do that for the default file
(sys.stdout).

I only vote +0 because I think that it is easy to modify the code to add
a explicit call to sys.stdout.flush(). Sorry, but programming is hard:
you have to learn things! A better idea would be to *document* that
print() may not display immediatly the message if it doesn't contain a
newline (eg. if end=''), and give the solution (sys.stdout.flush()).

Victor


From ncoghlan at gmail.com  Wed Mar 23 14:37:15 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 23:37:15 +1000
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <20110323143000.75743e55@pitrou.net>
References: <4D88DE84.8050209@jcea.es>
	<87vcza8vka.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110323034115.5e6e5822@pitrou.net>
	<87oc528qeu.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110323143000.75743e55@pitrou.net>
Message-ID: <AANLkTinyH+ZPKWiwmk9AakppbRQH6Cpxd1X_fsGMP=OY@mail.gmail.com>

On Wed, Mar 23, 2011 at 11:30 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 23 Mar 2011 12:30:17 +0900
> "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>> Antoine Pitrou writes:
>>
>> ?> Now, "hg strip" should definitely be absent of any recommended or even
>> ?> suggested workflow. It's a power user tool for the experimented
>> ?> developer/admin. Not the average hg command.
>>
>> So what you're saying is that Mercurial by itself can't support the
>> recommended workflow, because any "collapsing" of commits requires
>> stripping,
>
> Not really. It requires that you either:
> - work on your long-term features in a separate repo (and produce a
> ?diff at the end that you will apply to the main repo)
> - use mq
> - use a non-committing equivalent of mq (iterate on a patch which you
> ?periodically save with "hg di", for example; that's what I do for
> ?most patches)
>
> Apparently some of you think "collapsing" should involve some specific
> hg command. It doesn't. Perhaps the devguide should be rephrased there.

What you've written here would actually make a pretty good start on a
definition of what we mean by collapsing changesets.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Mar 23 14:44:31 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Mar 2011 23:44:31 +1000
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323143123.4be80686@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
Message-ID: <AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>

On Wed, Mar 23, 2011 at 11:31 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 23 Mar 2011 22:49:39 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Wed, Mar 23, 2011 at 9:45 PM, John Arbash Meinel
>> <john at arbash-meinel.com> wrote:
>> > I don't specifically know what is in those 340 tests, but 18min/340 =
>> > 3.2s for each test. Which is *much* longer than simple smoke tests would
>> > have to be.
>>
>> The counts Barry is referring to there are actually counting test
>> *files*, rather than individual tests. We only have 359 of those in
>> total though (not counting those in subdirectories), so a "quicktest"
>> that omits less than 6% of them doesn't sound particularly quick (even
>> if it does leave out the slowest ones).
>>
>> We should probably do another pass and add a few more tests to the
>> blacklist in the Makefile template (starting with
>> test_concurrent_futures).
>
> Does anyone use "make quicktest" for something useful?
> There is a reason the regression test suite has many tests...
> "Blacklisting" some of them sounds like a bad thing to do.

Oops, lost a bit too much context when I changed the thread title.

This discussion started with Barry looking for a "smoke test" that
would be quick enough to run that more people would be willing to use
it to pick up gratuitous breakage due to a bad merge rather than
leaving it for the buildbots to discover.

Currently even "make quicktest" takes too long to run to be suitable
for that task. Leaving out a couple more egregiously slow tests and
possibly updating it to use the "-j" switch might make for a usable
option.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Wed Mar 23 14:48:59 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 14:48:59 +0100
Subject: [Python-Dev] python -m test -jN
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<4D8767E7.8020702@cadifra.com>
	<20110321171930.02BBE13F980@kimball.webabinitio.net>
	<20110321135351.20632230@limelight.wooz.org>
	<4D886FA4.7040502@arbash-meinel.com>
	<20110322142529.62c54e22@neurotica.wooz.org>
Message-ID: <20110323144859.0145d729@pitrou.net>


Hey Barry,

> Python sort of has that, but I guess it depends on your definition of "fast"
> :).  Here are my run times.
> 
> 'make quicktest': 18m
> 'make test'     : 30m
> 'make testall'  : 35m

Please take a look at http://docs.python.org/devguide/runtests.html
and learn about the -j option ;)

(on a dual-core 4-thread machine:

./python -m test -j4
[...]
600.34user 26.36system 4:13.44elapsed 247%CPU (0avgtext+0avgdata
871456maxresident)k 110544inputs+152624outputs
(72major+6806058minor)pagefaults 0swaps

)

Regards

Antoine.



From solipsis at pitrou.net  Wed Mar 23 14:52:36 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 14:52:36 +0100
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
Message-ID: <1300888356.3495.9.camel@localhost.localdomain>


> Oops, lost a bit too much context when I changed the thread title.
> 
> This discussion started with Barry looking for a "smoke test" that
> would be quick enough to run that more people would be willing to use
> it to pick up gratuitous breakage due to a bad merge rather than
> leaving it for the buildbots to discover.

Then many people will start running the "smoke test" rather than the
whole suite, which will create new kinds of problems. It's IMO a bad
idea. Let Barry learn about "-j" :)

> Currently even "make quicktest" takes too long to run to be suitable
> for that task. Leaving out a couple more egregiously slow tests and
> possibly updating it to use the "-j" switch might make for a usable
> option.

"-j" will precisely help cover the duration of these long tests. By the
way, you should use a higher "-j" number than you have CPUs, since some
tests spend most of their time sleeping and waiting.

"make quicktest" already skips test_io and test_socket, which test
fundamental parts of Python. I would vote for removing "make quicktest"
rather than promote such a questionable command.

Regards

Antoine.



From barry at python.org  Wed Mar 23 14:53:37 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Mar 2011 09:53:37 -0400
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323143123.4be80686@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
Message-ID: <20110323095337.26d9ddb2@neurotica.wooz.org>

On Mar 23, 2011, at 02:31 PM, Antoine Pitrou wrote:

>Does anyone use "make quicktest" for something useful?

Not currently.  Can it be made useful?  Should it be removed?

>There is a reason the regression test suite has many tests...
>"Blacklisting" some of them sounds like a bad thing to do.

If 'make quicktest' were actually quick - say could run in 1/10 the current
time, it could be used as a smoke test for merge-dance cases.  OTOH, running
some localized test for the feature or bug you're trying to land might be
enough.

In any case 'make quicktest' isn't really being honest with us <wink>.  We
should fix it or remove it.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/80db0928/attachment.pgp>

From victor.stinner at haypocalc.com  Wed Mar 23 14:55:48 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Wed, 23 Mar 2011 14:55:48 +0100
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <AANLkTi=z0TxiaNRqj-t3XyLmJeLXp1fJLuMP88amF-hH@mail.gmail.com>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
	<AANLkTi=z0TxiaNRqj-t3XyLmJeLXp1fJLuMP88amF-hH@mail.gmail.com>
Message-ID: <1300888548.29974.5.camel@marge>

Le mercredi 23 mars 2011 ? 22:58 +1000, Nick Coghlan a ?crit :
> There are several ways to get unbuffered IO back in a cross-platform
> manner, ...

Oh, by the way: TextIOWrapper doesn't support unbuffered mode. Only
fully buffered and line buffered modes. So print("Test", end='') doesn't
display immediatly Test, even with "python -u".

python -u is only useful if the output is redirected to a pipe/a file,
if you would like a line buffering (instead of a full buffering).

Victor

(This email thread begins to be a little bit redundant with the issue on
the bug tracker)


From solipsis at pitrou.net  Wed Mar 23 15:03:19 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 15:03:19 +0100
Subject: [Python-Dev] new blog
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
Message-ID: <20110323150319.6ed5fedd@pitrou.net>

On Mon, 21 Mar 2011 21:50:53 -0400
Doug Hellmann <doug.hellmann at gmail.com> wrote:
> We are nearly ready to launch the new blog for python-dev.

Is any core dev allowed to post on this blog? (how?)
Or is there an editorial team dedicated to writing posts?

Regards

Antoine.



From solipsis at pitrou.net  Wed Mar 23 15:08:10 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 15:08:10 +0100
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
Message-ID: <20110323150810.38efce46@pitrou.net>

On Wed, 23 Mar 2011 09:53:37 -0400
Barry Warsaw <barry at python.org> wrote:
> OTOH, running
> some localized test for the feature or bug you're trying to land might be
> enough.

Might indeed. Quite often, though, some change in a library affects
another one (especially when we're talking about things like socket
or threading).

Really, people already don't run the test suite enough before
committing/pushing (and ironically these same people often don't check
the buildbots afterwards). I don't think we want to promote more laxism.

Regards

Antoine.



From ncoghlan at gmail.com  Wed Mar 23 15:22:09 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 24 Mar 2011 00:22:09 +1000
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323095337.26d9ddb2@neurotica.wooz.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
Message-ID: <AANLkTikxZeBBw_cO2A-9Tp5O0+JTro066nF78c0Me=o6@mail.gmail.com>

On Wed, Mar 23, 2011 at 11:53 PM, Barry Warsaw <barry at python.org> wrote:
> In any case 'make quicktest' isn't really being honest with us <wink>. ?We
> should fix it or remove it.

It took about 11 minutes wall clock time for me. One thing I noticed
is that it does the "run it twice to ensure the .pyc files are there
the second time" trick, so we could halve the run time right there.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ysj.ray at gmail.com  Wed Mar 23 15:01:10 2011
From: ysj.ray at gmail.com (Ray Allen)
Date: Wed, 23 Mar 2011 22:01:10 +0800
Subject: [Python-Dev] Issue 9523: Ask for a review on C code
Message-ID: <AANLkTi=mMeY+dF05UP6Ehg9946pad89bA=fEXF4YvZWC@mail.gmail.com>

Hi all,
    Currently I worked out a patch for http://bugs.python.org/issue9523,
which adds full support of Collections.MutableMapping interface to ndbm and
gdbm objects, as well as . And thanks for eric doing reviews mainly on
python code and doc! Could someone do a review on the C code? Thanks very
much for help! :)

-- 
Ray Allen
Best wishes!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/fc032e7e/attachment.html>

From ncoghlan at gmail.com  Wed Mar 23 15:29:03 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 24 Mar 2011 00:29:03 +1000
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323150810.38efce46@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
Message-ID: <AANLkTinTiMNFserBsfzJNnMRCw+A6sKWhH0rWWRebtgx@mail.gmail.com>

On Thu, Mar 24, 2011 at 12:08 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Really, people already don't run the test suite enough before
> committing/pushing (and ironically these same people often don't check
> the buildbots afterwards). I don't think we want to promote more laxism.

Encouraging a step up from "none" to "some" in a merge-dance case
would still be an improvement. And if it encourages more pre-push
testing when people aren't currently taking the time to run the full
test suite (even though they're meant to), so much the better.

And the quick test does exercise quite a few significant things like
threading, sockets and threaded import.

Entirely independent of the "make quicktest" question, it would be
nice if the default behaviour of regrtest was updated to check the
number of cores a machine has and default to using that many processes
(leaving people to turn it down if they don't want to dedicate the
whole machine to the run). I keep forgetting to include the -j4 when I
run the tests manually, so the tests take nearly 4 times as long as
they need to (and of course, the test targets in the make file don't
use it at all, either).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From jnoller at gmail.com  Wed Mar 23 15:29:45 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 23 Mar 2011 10:29:45 -0400
Subject: [Python-Dev] new blog
In-Reply-To: <20110323150319.6ed5fedd@pitrou.net>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
	<20110323150319.6ed5fedd@pitrou.net>
Message-ID: <AANLkTikn0X8ON2sF3i+EmoJtLATDpa7uk-cEGo_frjvF@mail.gmail.com>

On Wed, Mar 23, 2011 at 10:03 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 21 Mar 2011 21:50:53 -0400
> Doug Hellmann <doug.hellmann at gmail.com> wrote:
>> We are nearly ready to launch the new blog for python-dev.
>
> Is any core dev allowed to post on this blog? (how?)
> Or is there an editorial team dedicated to writing posts?
>
> Regards
>
> Antoine.
>

The initial announcement is here antoine:

http://blog.python.org/2011/03/welcome-to-python-insider.html

Doug can expand more on the how: but everyone is welcome.

From ncoghlan at gmail.com  Wed Mar 23 15:31:46 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 24 Mar 2011 00:31:46 +1000
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <1300888356.3495.9.camel@localhost.localdomain>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
Message-ID: <AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>

On Wed, Mar 23, 2011 at 11:52 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Currently even "make quicktest" takes too long to run to be suitable
>> for that task. Leaving out a couple more egregiously slow tests and
>> possibly updating it to use the "-j" switch might make for a usable
>> option.
>
> "-j" will precisely help cover the duration of these long tests. By the
> way, you should use a higher "-j" number than you have CPUs, since some
> tests spend most of their time sleeping and waiting.
>
> "make quicktest" already skips test_io and test_socket, which test
> fundamental parts of Python. I would vote for removing "make quicktest"
> rather than promote such a questionable command.

I'd be fine with that if we change the -j default to something other
than "1" (e.g. as I suggested elsewhere, the number of cores in the
machine).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Wed Mar 23 15:36:37 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 15:36:37 +0100
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>
Message-ID: <1300890997.3495.13.camel@localhost.localdomain>

Le jeudi 24 mars 2011 ? 00:31 +1000, Nick Coghlan a ?crit :
> On Wed, Mar 23, 2011 at 11:52 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >> Currently even "make quicktest" takes too long to run to be suitable
> >> for that task. Leaving out a couple more egregiously slow tests and
> >> possibly updating it to use the "-j" switch might make for a usable
> >> option.
> >
> > "-j" will precisely help cover the duration of these long tests. By the
> > way, you should use a higher "-j" number than you have CPUs, since some
> > tests spend most of their time sleeping and waiting.
> >
> > "make quicktest" already skips test_io and test_socket, which test
> > fundamental parts of Python. I would vote for removing "make quicktest"
> > rather than promote such a questionable command.
> 
> I'd be fine with that if we change the -j default to something other
> than "1" (e.g. as I suggested elsewhere, the number of cores in the
> machine).

You mean in the "-j" option itself or in "make test"?



From barry at python.org  Wed Mar 23 15:44:30 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Mar 2011 10:44:30 -0400
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323150810.38efce46@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
Message-ID: <20110323104430.524ffe2a@limelight.wooz.org>

In IRC Antoine suggested -j5 (note that -j is not compatible with -l so you
have to override TESTOPTS not just EXTRATESTOPTS).  Adding --slow here's what
I get:

$ make TESTOPTS="-j5 --slow" quicktest
...
10 slowest tests:
test_mmap: 221.6s
test_shelve: 184.4s
test_posix: 156.3s
test_largefile: 150.0s
test_concurrent_futures: 105.0s
test_fork1: 12.0s
test_threading: 8.8s
test_signal: 8.4s
test_warnings: 8.0s
test_threaded_import: 6.1s

If I disable down to and including test_concurrent_futures, quicktest runs in
3m20s wall clock.  *That's* what I'm talkin' 'bout!  And the run time is
totally reasonable without halving the test run.  I don't think those 5
slowest tests would be missed in a smoke test.

Any objections to adding those slowest 5 tests to the blacklist, and -j5 to
quicktest for Python 3.3?

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/86d304fa/attachment.pgp>

From kyosohma at gmail.com  Wed Mar 23 15:52:58 2011
From: kyosohma at gmail.com (Mike Driscoll)
Date: Wed, 23 Mar 2011 09:52:58 -0500
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D88F4A5.4060701@voidspace.org.uk>
References: <4D884E08.1020709@skippinet.com.au>
	<4D88F4A5.4060701@voidspace.org.uk>
Message-ID: <AANLkTincgbwBb-RhJSuFssUpM6diNwR-o6mX1HQ_ufzP@mail.gmail.com>

On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 22/03/2011 07:21, Mark Hammond wrote:
>
> Hi all,
> ? I've made some changes to the draft PEP and checked it into the PEP
> repository as PEP397.? The reference implementation is currently being
> tracked at http://bugs.python.org/issue11629.
>
>
> Hey Mark,
>
> One way of supporting alternative implementations (that may not even have a
> standard install directory) is allowing configuration. e.g. config.ini
>
> ??? [paths]
> ??? ironpython = c:\Program Files\IronPython 2.7\ipy.exe
> ??? ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
> ??? jython = c:\Users\foobar\jython2.5\jython.exe
>
> Pythons specified in this way should be recognised in the shebang line using
> any of the formats:
>
> ??? #! ironpython
> ??? #! /usr/bin/ironpython
> ??? #! /usr/bin/env ironpython
>
> This would also permit alternative install locations. (And it would be nice
> if the launcher could use the config file to *automatically* do the right
> thing for the 'w' variants.)
>
> All the best,
>
> Michael
>

Oops...I accidentally sent this off-list:

The main problem I can think of for the config file is that those hard
coded paths probably won't work about 10% of the time. I install my
Python stuff in a different location then the C drive, for example.

- Mike

From solipsis at pitrou.net  Wed Mar 23 15:58:26 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 15:58:26 +0100
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>
Message-ID: <20110323155826.2ab37871@pitrou.net>

On Thu, 24 Mar 2011 00:31:46 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Wed, Mar 23, 2011 at 11:52 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >> Currently even "make quicktest" takes too long to run to be suitable
> >> for that task. Leaving out a couple more egregiously slow tests and
> >> possibly updating it to use the "-j" switch might make for a usable
> >> option.
> >
> > "-j" will precisely help cover the duration of these long tests. By the
> > way, you should use a higher "-j" number than you have CPUs, since some
> > tests spend most of their time sleeping and waiting.
> >
> > "make quicktest" already skips test_io and test_socket, which test
> > fundamental parts of Python. I would vote for removing "make quicktest"
> > rather than promote such a questionable command.
> 
> I'd be fine with that if we change the -j default to something other
> than "1" (e.g. as I suggested elsewhere, the number of cores in the
> machine).

http://bugs.python.org/issue11651

From skip at pobox.com  Wed Mar 23 16:02:57 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 23 Mar 2011 10:02:57 -0500
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323143123.4be80686@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
Message-ID: <19850.2977.894754.352174@montanaro.dyndns.org>


    Antoine> Does anyone use "make quicktest" for something useful?

I don't use it at all.

    Antoine> There is a reason the regression test suite has many tests...
    Antoine> "Blacklisting" some of them sounds like a bad thing to do.

+1.

Eliminating tests based on the time it takes to run them suggests that the
resulting smaller test run may have considerably different overall coverage
quality than you might desire.  Some tests (syntax, basic arithmetic, etc)
probably run blazingly fast and will be fully covered by a "make nanotest",
while some really important stuff (anything which forks or creates sockets)
will have very poor nanotest coverage because many of its tests cases won't
be run.  The odds that someone breaks syntax or basic arithmetic
functionality (or even changes those parts of the system) are pretty low, so
repeatedly running those tests simply because they run fast gives a false
sense of security.

Skip

From ncoghlan at gmail.com  Wed Mar 23 16:09:40 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 24 Mar 2011 01:09:40 +1000
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <1300890997.3495.13.camel@localhost.localdomain>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>
	<1300890997.3495.13.camel@localhost.localdomain>
Message-ID: <AANLkTimq8waQH-VPbxvnXZS-RJNgDk2gFE=_KYRz5v2G@mail.gmail.com>

On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> You mean in the "-j" option itself or in "make test"?

I was actually suggesting that -j be the *default* in regrtest itself,
with an option to turn it off or force a particular number of
processes.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From barry at python.org  Wed Mar 23 16:18:50 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Mar 2011 11:18:50 -0400
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323150810.38efce46@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
Message-ID: <20110323111850.52c10754@neurotica.wooz.org>

On Mar 23, 2011, at 03:08 PM, Antoine Pitrou wrote:

>On Wed, 23 Mar 2011 09:53:37 -0400
>Barry Warsaw <barry at python.org> wrote:
>> OTOH, running
>> some localized test for the feature or bug you're trying to land might be
>> enough.
>
>Might indeed. Quite often, though, some change in a library affects
>another one (especially when we're talking about things like socket
>or threading).
>
>Really, people already don't run the test suite enough before
>committing/pushing (and ironically these same people often don't check
>the buildbots afterwards). I don't think we want to promote more laxism.

This is just the opposite.  I'm not saying people shouldn't run the full(-ish)
test suite before committing, I'm saying we should have a really fast minimal
set of tests as a smoke test when dealing with push-races.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/b2d2ab2f/attachment.pgp>

From barry at python.org  Wed Mar 23 16:21:30 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Mar 2011 11:21:30 -0400
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <AANLkTinTiMNFserBsfzJNnMRCw+A6sKWhH0rWWRebtgx@mail.gmail.com>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
	<AANLkTinTiMNFserBsfzJNnMRCw+A6sKWhH0rWWRebtgx@mail.gmail.com>
Message-ID: <20110323112130.58210437@neurotica.wooz.org>

On Mar 24, 2011, at 12:29 AM, Nick Coghlan wrote:

>Entirely independent of the "make quicktest" question, it would be
>nice if the default behaviour of regrtest was updated to check the
>number of cores a machine has and default to using that many processes
>(leaving people to turn it down if they don't want to dedicate the
>whole machine to the run). I keep forgetting to include the -j4 when I
>run the tests manually, so the tests take nearly 4 times as long as
>they need to (and of course, the test targets in the make file don't
>use it at all, either).

It can't without some refactoring, and you can't set EXTRATESTOPTS=-j4 either
because TESTOPTS includes -l and regrtest complains that -l and -j are
incompatible.

But I agree it would be nice if the test suite automatically took advantage of
more cores where available.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/0b9d202c/attachment.pgp>

From kristjan at ccpgames.com  Wed Mar 23 16:23:54 2011
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Wed, 23 Mar 2011 23:23:54 +0800
Subject: [Python-Dev] __reduce__
Message-ID: <2E034B571A5CE44E949B9FCC3B6D24EE6B1E3D9A@exchcn.ccp.ad.local>

The __reduce__ protocol doesn't provide for keyword arguments to the constructor.
Some constructor arguments are only available as keyword arguments.  Annoying, isn't it?
K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/839f176c/attachment.html>

From barry at python.org  Wed Mar 23 16:26:13 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Mar 2011 11:26:13 -0400
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <1300888356.3495.9.camel@localhost.localdomain>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
Message-ID: <20110323112613.11a4c1e8@neurotica.wooz.org>

On Mar 23, 2011, at 02:52 PM, Antoine Pitrou wrote:

>Then many people will start running the "smoke test" rather than the
>whole suite, which will create new kinds of problems. It's IMO a bad
>idea. Let Barry learn about "-j" :)

Well, that's a social problem, not a technical problem.

(See other messages in the thread regarding -j.)

>> Currently even "make quicktest" takes too long to run to be suitable
>> for that task. Leaving out a couple more egregiously slow tests and
>> possibly updating it to use the "-j" switch might make for a usable
>> option.
>
>"-j" will precisely help cover the duration of these long tests. By the
>way, you should use a higher "-j" number than you have CPUs, since some
>tests spend most of their time sleeping and waiting.
>
>"make quicktest" already skips test_io and test_socket, which test
>fundamental parts of Python. I would vote for removing "make quicktest"
>rather than promote such a questionable command.

Better to rename it than remove it.  If 'quicktest' is misleading people into
running it rather than 'test' (which frankly, I doubt), then rename it
'smoketest' which seems entirely appropriate to its use case and indicates its
value in the spectrum of tests:

http://en.wikipedia.org/wiki/Smoketest

Because this also rebuilds Python if needed, I think it's entirely appropriate
for the push-race use case, where you've already extensively tested your
change with a mostly up-to-date tree and now just need to quickly verify that
Python won't crash and burn after your local merge.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/876c4511/attachment-0001.pgp>

From fuzzyman at voidspace.org.uk  Wed Mar 23 16:26:13 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 23 Mar 2011 15:26:13 +0000
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <AANLkTikk=14XmaZdZxE=Xyg4JzMv5Vbn0EBZ6BP=mZuR@mail.gmail.com>
References: <4D884E08.1020709@skippinet.com.au>	<4D88F4A5.4060701@voidspace.org.uk>
	<AANLkTikk=14XmaZdZxE=Xyg4JzMv5Vbn0EBZ6BP=mZuR@mail.gmail.com>
Message-ID: <4D8A1115.40003@voidspace.org.uk>

On 23/03/2011 14:52, Mike Driscoll wrote:
> On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>> On 22/03/2011 07:21, Mark Hammond wrote:
>>
>> Hi all,
>>    I've made some changes to the draft PEP and checked it into the PEP
>> repository as PEP397.  The reference implementation is currently being
>> tracked athttp://bugs.python.org/issue11629.
>>
>>
>> Hey Mark,
>>
>> One way of supporting alternative implementations (that may not even have a
>> standard install directory) is allowing configuration. e.g. config.ini
>>
>>      [paths]
>>      ironpython = c:\Program Files\IronPython 2.7\ipy.exe
>>      ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
>>      jython = c:\Users\foobar\jython2.5\jython.exe
>>
>> Pythons specified in this way should be recognised in the shebang line using
>> any of the formats:
>>
>>      #! ironpython
>>      #! /usr/bin/ironpython
>>      #! /usr/bin/env ironpython
>>
>> This would also permit alternative install locations. (And it would be nice
>> if the launcher could use the config file to *automatically* do the right
>> thing for the 'w' variants.)
>>
>> All the best,
>>
>> Michael
>>
> The main problem I can think of for the config file is that those hard
> coded paths probably won't work about 10% of the time. I install my
> Python stuff in a different location then the C drive, for example.

The whole point of a config file is that you put the paths in there 
yourself...

To be honest I would be happy with registry entries instead as the 
alternative implementations can then add to their installers (or provide 
a script) to add the right registry entry.

Michael

> - Mike


-- 
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 blessinghttp://www.sqlite.org/different.html


From solipsis at pitrou.net  Wed Mar 23 16:32:45 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 16:32:45 +0100
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
	<20110323104430.524ffe2a@limelight.wooz.org>
Message-ID: <20110323163245.36009338@pitrou.net>

On Wed, 23 Mar 2011 10:44:30 -0400
Barry Warsaw <barry at python.org> wrote:
> In IRC Antoine suggested -j5 (note that -j is not compatible with -l so you
> have to override TESTOPTS not just EXTRATESTOPTS).  Adding --slow here's what
> I get:
> 
> $ make TESTOPTS="-j5 --slow" quicktest
> ...
> 10 slowest tests:
> test_mmap: 221.6s
> test_shelve: 184.4s
> test_posix: 156.3s
> test_largefile: 150.0s
> test_concurrent_futures: 105.0s
> test_fork1: 12.0s
> test_threading: 8.8s
> test_signal: 8.4s
> test_warnings: 8.0s
> test_threaded_import: 6.1s
> 
> If I disable down to and including test_concurrent_futures, quicktest runs in
> 3m20s wall clock.  *That's* what I'm talkin' 'bout!  And the run time is
> totally reasonable without halving the test run.  I don't think those 5
> slowest tests would be missed in a smoke test.
> 
> Any objections to adding those slowest 5 tests to the blacklist, and -j5 to
> quicktest for Python 3.3?

For me, the same objections as to blacklisting any tests at all.
If some tests are too slow, individual issues about them should be
opened.

Also, there may be some issues with your system.
test_mmap, test_shelve, test_posix all take 1-2 seconds each here.
Again, please open issues on the tracker.

Regards

Antoine.



From ethan at stoneleaf.us  Wed Mar 23 16:39:46 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 23 Mar 2011 08:39:46 -0700
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <AANLkTincgbwBb-RhJSuFssUpM6diNwR-o6mX1HQ_ufzP@mail.gmail.com>
References: <4D884E08.1020709@skippinet.com.au>	<4D88F4A5.4060701@voidspace.org.uk>
	<AANLkTincgbwBb-RhJSuFssUpM6diNwR-o6mX1HQ_ufzP@mail.gmail.com>
Message-ID: <4D8A1442.6020305@stoneleaf.us>

Mike Driscoll wrote:
> On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>> On 22/03/2011 07:21, Mark Hammond wrote:
>>
>> Hi all,
>>   I've made some changes to the draft PEP and checked it into the PEP
>> repository as PEP397.  The reference implementation is currently being
>> tracked at http://bugs.python.org/issue11629.
>>
>>
>> Hey Mark,
>>
>> One way of supporting alternative implementations (that may not even have a
>> standard install directory) is allowing configuration. e.g. config.ini
>>
>>     [paths]
>>     ironpython = c:\Program Files\IronPython 2.7\ipy.exe
>>     ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
>>     jython = c:\Users\foobar\jython2.5\jython.exe
>>
>> Pythons specified in this way should be recognised in the shebang line using
>> any of the formats:
>>
>>     #! ironpython
>>     #! /usr/bin/ironpython
>>     #! /usr/bin/env ironpython
>>
>> This would also permit alternative install locations. (And it would be nice
>> if the launcher could use the config file to *automatically* do the right
>> thing for the 'w' variants.)
>>
>> All the best,
>>
>> Michael
>>
> 
> Oops...I accidentally sent this off-list:
> 
> The main problem I can think of for the config file is that those hard
> coded paths probably won't work about 10% of the time. I install my
> Python stuff in a different location then the C drive, for example.

How is that a problem?  Just update your config for your locations.

~Ethan~

From barry at python.org  Wed Mar 23 16:51:56 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Mar 2011 11:51:56 -0400
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <19850.2977.894754.352174@montanaro.dyndns.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
Message-ID: <20110323115156.25bd2845@neurotica.wooz.org>

On Mar 23, 2011, at 10:02 AM, skip at pobox.com wrote:

>Eliminating tests based on the time it takes to run them suggests that the
>resulting smaller test run may have considerably different overall coverage
>quality than you might desire.  Some tests (syntax, basic arithmetic, etc)
>probably run blazingly fast and will be fully covered by a "make nanotest",
>while some really important stuff (anything which forks or creates sockets)
>will have very poor nanotest coverage because many of its tests cases won't
>be run.  The odds that someone breaks syntax or basic arithmetic
>functionality (or even changes those parts of the system) are pretty low, so
>repeatedly running those tests simply because they run fast gives a false
>sense of security.

Not if you keep in mind the appropriate use case for each of the separate make
test targets.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/5fc39bfa/attachment.pgp>

From solipsis at pitrou.net  Wed Mar 23 17:09:22 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 17:09:22 +0100
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
	<20110323111850.52c10754@neurotica.wooz.org>
Message-ID: <20110323170922.330638c8@pitrou.net>

On Wed, 23 Mar 2011 11:18:50 -0400
Barry Warsaw <barry at python.org> wrote:
> 
> This is just the opposite.  I'm not saying people shouldn't run the full(-ish)
> test suite before committing, I'm saying we should have a really fast minimal
> set of tests as a smoke test when dealing with push-races.

That's completely bogus. There's no reason to believe that a push race
would favour certain regressions over certain others. Again, you need
the full test suite to assert that no regressions occured.
(or you might as well run 10 tests at random and call it done)

If you think that some tests are more significant than others (why?)
then perhaps we can devise a limited test suite with these tests.
But these tests should be chosen on the basis of their nature, *not* of
their runtime.

Regards

Antoine.



From skip at pobox.com  Wed Mar 23 17:10:29 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 23 Mar 2011 11:10:29 -0500
Subject: [Python-Dev] python -m test -jN
In-Reply-To: <20110323144859.0145d729@pitrou.net>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<4D8767E7.8020702@cadifra.com>
	<20110321171930.02BBE13F980@kimball.webabinitio.net>
	<20110321135351.20632230@limelight.wooz.org>
	<4D886FA4.7040502@arbash-meinel.com>
	<20110322142529.62c54e22@neurotica.wooz.org>
	<20110323144859.0145d729@pitrou.net>
Message-ID: <19850.7029.808433.474362@montanaro.dyndns.org>


    Antoine> Please take a look at
    Antoine> http://docs.python.org/devguide/runtests.html and learn about
    Antoine> the -j option ;)

I just gave it a try.  Several tests failed:

    test_builtin test_distutils test_imp test_peepholer test_pydoc
    test_unicode test_unittest

OTOH, when I run a simple "make test" only distutils fails.

This is on my Macbook Pro running Leopard.

Skip

From solipsis at pitrou.net  Wed Mar 23 17:16:50 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 17:16:50 +0100
Subject: [Python-Dev] Trimming "make quicktest"
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<20110323112613.11a4c1e8@neurotica.wooz.org>
Message-ID: <20110323171650.3af2b94c@pitrou.net>

On Wed, 23 Mar 2011 11:26:13 -0400
Barry Warsaw <barry at python.org> wrote:
> On Mar 23, 2011, at 02:52 PM, Antoine Pitrou wrote:
> 
> >Then many people will start running the "smoke test" rather than the
> >whole suite, which will create new kinds of problems. It's IMO a bad
> >idea. Let Barry learn about "-j" :)
> 
> Well, that's a social problem, not a technical problem.

Isn't this whole thread about a social problem?
You are complaining that the test suite is too slow, which *is* a
social problem (the buildbots (mostly) don't care about runtime, for
example).

If we start promoting a "quicker" way of running tests, then nobody
will use the normal way. I'm sorry, I'm -1 on that. There are
regressions often enough on the buildbots.

If you insist on that, I suggest that you also vow to take care of
the buildbot fleet and individually track regressions and notify people
who are responsible for them.

Regards

Antoine.



From skip at pobox.com  Wed Mar 23 17:34:46 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 23 Mar 2011 11:34:46 -0500
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323104430.524ffe2a@limelight.wooz.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
	<20110323104430.524ffe2a@limelight.wooz.org>
Message-ID: <19850.8486.209548.680180@montanaro.dyndns.org>


    Barry> If I disable down to and including test_concurrent_futures,
    Barry> quicktest runs in 3m20s wall clock.  *That's* what I'm talkin'
    Barry> 'bout!

How do you know you didn't eliminate the most important tests?  (That is,
the stuff which tests the code which is currently the most flaky.)

    Barry> Any objections to adding those slowest 5 tests to the blacklist,
    Barry> and -j5 to quicktest for Python 3.3?

Convince me that you haven't so horribly skewed the coverage that the result
is no longer meaningful.

Skip

From solipsis at pitrou.net  Wed Mar 23 17:37:42 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 17:37:42 +0100
Subject: [Python-Dev] python -m test -jN
In-Reply-To: <19850.7029.808433.474362@montanaro.dyndns.org>
References: <19844.48323.176151.931392@montanaro.dyndns.org>
	<20110319192128.522235fb@pitrou.net>
	<26C3DC52-A8C3-4F89-B7E5-314909AC1C5C@gmail.com>
	<4D85FAE0.40107@jcea.es> <877hbttywd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<19846.24793.573280.126001@montanaro.dyndns.org>
	<87tyexf4d9.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321065835.664EC16245C@kimball.webabinitio.net>
	<87pqpkg6nn.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20110321134015.B8ED364DAA@kimball.webabinitio.net>
	<4D8767E7.8020702@cadifra.com>
	<20110321171930.02BBE13F980@kimball.webabinitio.net>
	<20110321135351.20632230@limelight.wooz.org>
	<4D886FA4.7040502@arbash-meinel.com>
	<20110322142529.62c54e22@neurotica.wooz.org>
	<20110323144859.0145d729@pitrou.net>
	<19850.7029.808433.474362@montanaro.dyndns.org>
Message-ID: <20110323173742.1278af6a@pitrou.net>

On Wed, 23 Mar 2011 11:10:29 -0500
skip at pobox.com wrote:
> 
>     Antoine> Please take a look at
>     Antoine> http://docs.python.org/devguide/runtests.html and learn about
>     Antoine> the -j option ;)
> 
> I just gave it a try.  Several tests failed:
> 
>     test_builtin test_distutils test_imp test_peepholer test_pydoc
>     test_unicode test_unittest
> 
> OTOH, when I run a simple "make test" only distutils fails.

I would suggest adding the -W option to re-run the failing tests in
verbose mode, and then open individual issues about them.

Regards

Antoine.

From barry at python.org  Wed Mar 23 17:46:14 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Mar 2011 12:46:14 -0400
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <20110323171650.3af2b94c@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<20110323112613.11a4c1e8@neurotica.wooz.org>
	<20110323171650.3af2b94c@pitrou.net>
Message-ID: <20110323124614.5a1f6f16@neurotica.wooz.org>

On Mar 23, 2011, at 05:16 PM, Antoine Pitrou wrote:

>If we start promoting a "quicker" way of running tests, then nobody
>will use the normal way. I'm sorry, I'm -1 on that. There are
>regressions often enough on the buildbots.

I'm not sure it's worth continuing this thread.  I've explained that I'm not
promoting a quicker way of running the tests in lieu of the more thorough test
suite.  I'm looking to fill a very specific use case.

Anyway, there's issue 11651 now too.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/524300fa/attachment.pgp>

From skip at pobox.com  Wed Mar 23 17:52:41 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 23 Mar 2011 11:52:41 -0500
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323115156.25bd2845@neurotica.wooz.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
Message-ID: <19850.9561.366432.287634@montanaro.dyndns.org>


    Barry> Not if you keep in mind the appropriate use case for each of the
    Barry> separate make test targets.

Programmers are lazy.  They will often take the shortest path.  Fix a small
bug in module X which seems innocent enough, fail to recognize that it
breaks module Y.  Run "make smoketest" and see that all the test_X stuff
passes.  Don't notice that key test_Y tests are not even run, push, then
head out to lunch.  Come back to (hopefully) a bunch of red buildbots.
Still, it would have been good to catch that problem before heading out to
Buffalo Wild Wings to watch football players trip over sprinkler heads.

How many of us really and truly can't wait a few minutes for the test suite
to complete?  Especially once Antoine (or whoever) gets -j working properly.
There are plenty of things we can do:

    * Hang out on IRC
    * Update your Facebook status
    * Grab a cup of coffee
    * Read python-dev
    * Try out a few new bass lines you heard on Pinetop Perkins' last album
      (may he RIP).

Skip


From skip at pobox.com  Wed Mar 23 17:54:28 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 23 Mar 2011 11:54:28 -0500
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <20110323171650.3af2b94c@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<20110323112613.11a4c1e8@neurotica.wooz.org>
	<20110323171650.3af2b94c@pitrou.net>
Message-ID: <19850.9668.52358.944323@montanaro.dyndns.org>


    Antoine> If we start promoting a "quicker" way of running tests, then
    Antoine> nobody will use the normal way. I'm sorry, I'm -1 on
    Antoine> that. There are regressions often enough on the buildbots.

It seems I frequently disagree with Antoine about various things, but on
this I am definitely in agreement with him.

Skip

From barry at python.org  Wed Mar 23 18:10:47 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Mar 2011 13:10:47 -0400
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323170922.330638c8@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
	<20110323111850.52c10754@neurotica.wooz.org>
	<20110323170922.330638c8@pitrou.net>
Message-ID: <20110323131047.48056956@neurotica.wooz.org>

On Mar 23, 2011, at 05:09 PM, Antoine Pitrou wrote:

>That's completely bogus. There's no reason to believe that a push race would
>favour certain regressions over certain others. Again, you need the full test
>suite to assert that no regressions occured.  (or you might as well run 10
>tests at random and call it done)

If you promote the full test suite as the thing to run when resolving merge
races, then I predict no one will run them, because doing so increases your
chances of hitting *another* push race.  This whole thread came up in the
context of trying to find a quick test you could run in that case which didn't
increase that race window.  I think the practical effect of not having a
simple, fast smoke test will be to do *less* testing when you hit the merge
race, and just let the buildbots sort it all out.  You'll probably win most of
the time anyway.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/1c33498c/attachment.pgp>

From ethan at stoneleaf.us  Wed Mar 23 18:25:01 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 23 Mar 2011 10:25:01 -0700
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <19850.9561.366432.287634@montanaro.dyndns.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>	<20110323143123.4be80686@pitrou.net>	<19850.2977.894754.352174@montanaro.dyndns.org>	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
Message-ID: <4D8A2CED.7080504@stoneleaf.us>

skip at pobox.com wrote:
>     Barry> Not if you keep in mind the appropriate use case for each of the
>     Barry> separate make test targets.
> 
> Programmers are lazy.  They will often take the shortest path.  Fix a small
> bug in module X which seems innocent enough, fail to recognize that it
> breaks module Y.  Run "make smoketest" and see that all the test_X stuff
> passes.  Don't notice that key test_Y tests are not even run, push, then
> head out to lunch.  Come back to (hopefully) a bunch of red buildbots.
> Still, it would have been good to catch that problem before heading out to
> Buffalo Wild Wings to watch football players trip over sprinkler heads.
> 
> How many of us really and truly can't wait a few minutes for the test suite
> to complete?  Especially once Antoine (or whoever) gets -j working properly.

I think the use-case has been lost.  Think sprints and multiple push 
races.  No one is arguing that the smoke-test should be the default, but 
seriously, are you willing to spend an hour or more re-running the 
complete suite of tests six, eight, or 12 times because of push races in 
a sprint?  I can see losing a good portion of your sprinting day.

Which tests are included in the smoketest definitely needs careful 
reviewing.

Perhaps a better solution for sprints is to clone, have the sprinters 
clone from that clone, have one person responsible for running full 
tests, have the others push to the sub-sub-clone.

~Ethan~

From kyosohma at gmail.com  Wed Mar 23 18:14:41 2011
From: kyosohma at gmail.com (Mike Driscoll)
Date: Wed, 23 Mar 2011 12:14:41 -0500
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D8A1442.6020305@stoneleaf.us>
References: <4D884E08.1020709@skippinet.com.au>
	<4D88F4A5.4060701@voidspace.org.uk>
	<AANLkTincgbwBb-RhJSuFssUpM6diNwR-o6mX1HQ_ufzP@mail.gmail.com>
	<4D8A1442.6020305@stoneleaf.us>
Message-ID: <AANLkTi=63Xj4n+q2v0D520NwvCLSNqEESz5FKrb5t4EW@mail.gmail.com>

On Wed, Mar 23, 2011 at 10:39 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> Mike Driscoll wrote:
>>
>> On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord
>> <fuzzyman at voidspace.org.uk> wrote:
>>>
>>> On 22/03/2011 07:21, Mark Hammond wrote:
>>>
>>> Hi all,
>>> ?I've made some changes to the draft PEP and checked it into the PEP
>>> repository as PEP397. ?The reference implementation is currently being
>>> tracked at http://bugs.python.org/issue11629.
>>>
>>>
>>> Hey Mark,
>>>
>>> One way of supporting alternative implementations (that may not even have
>>> a
>>> standard install directory) is allowing configuration. e.g. config.ini
>>>
>>> ? ?[paths]
>>> ? ?ironpython = c:\Program Files\IronPython 2.7\ipy.exe
>>> ? ?ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
>>> ? ?jython = c:\Users\foobar\jython2.5\jython.exe
>>>
>>> Pythons specified in this way should be recognised in the shebang line
>>> using
>>> any of the formats:
>>>
>>> ? ?#! ironpython
>>> ? ?#! /usr/bin/ironpython
>>> ? ?#! /usr/bin/env ironpython
>>>
>>> This would also permit alternative install locations. (And it would be
>>> nice
>>> if the launcher could use the config file to *automatically* do the right
>>> thing for the 'w' variants.)
>>>
>>> All the best,
>>>
>>> Michael
>>>
>>
>> Oops...I accidentally sent this off-list:
>>
>> The main problem I can think of for the config file is that those hard
>> coded paths probably won't work about 10% of the time. I install my
>> Python stuff in a different location then the C drive, for example.
>
> How is that a problem? ?Just update your config for your locations.
>
> ~Ethan~

Sorry...I thought Foord was implying that they would be defaults or
that the launcher would put them in there. I think I mis-read it.
Nevermind.

- Mike

From doug.hellmann at gmail.com  Wed Mar 23 18:19:34 2011
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Wed, 23 Mar 2011 13:19:34 -0400
Subject: [Python-Dev] new blog
In-Reply-To: <20110323150319.6ed5fedd@pitrou.net>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
	<20110323150319.6ed5fedd@pitrou.net>
Message-ID: <A8AE0BDA-92B0-41D1-903F-44F0D577FC02@gmail.com>


On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote:

> On Mon, 21 Mar 2011 21:50:53 -0400
> Doug Hellmann <doug.hellmann at gmail.com> wrote:
>> We are nearly ready to launch the new blog for python-dev.
> 
> Is any core dev allowed to post on this blog? (how?)
> Or is there an editorial team dedicated to writing posts?

Both!

If you want to write for the blog, just send me your Blogger account name so I can give you authorship permission. There are also a few volunteers who are going to be posting, but we would LOVE to have developers writing their own posts.

Doug

> 
> Regards
> 
> Antoine.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/doug.hellmann%40gmail.com


From solipsis at pitrou.net  Wed Mar 23 18:24:00 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 18:24:00 +0100
Subject: [Python-Dev] sprints and pushes
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
Message-ID: <20110323182400.04ce46cf@pitrou.net>

On Wed, 23 Mar 2011 10:25:01 -0700
Ethan Furman <ethan at stoneleaf.us> wrote:
> 
> I think the use-case has been lost.  Think sprints and multiple push 
> races.  No one is arguing that the smoke-test should be the default, but 
> seriously, are you willing to spend an hour or more re-running the 
> complete suite of tests six, eight, or 12 times because of push races in 
> a sprint?  I can see losing a good portion of your sprinting day.

Well, keep in ming hg is a *distributed* version control system. You
don't have to push your changes right now. You can keep your changesets
for yourself, make several of them (different bug fixes, for example),
and push them (after a single merge) at the end of day.

Regards

Antoine.



From solipsis at pitrou.net  Wed Mar 23 18:26:03 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 18:26:03 +0100
Subject: [Python-Dev] new blog
In-Reply-To: <A8AE0BDA-92B0-41D1-903F-44F0D577FC02@gmail.com>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
	<20110323150319.6ed5fedd@pitrou.net>
	<A8AE0BDA-92B0-41D1-903F-44F0D577FC02@gmail.com>
Message-ID: <1300901163.3495.25.camel@localhost.localdomain>

Le mercredi 23 mars 2011 ? 13:19 -0400, Doug Hellmann a ?crit :
> On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote:
> 
> > On Mon, 21 Mar 2011 21:50:53 -0400
> > Doug Hellmann <doug.hellmann at gmail.com> wrote:
> >> We are nearly ready to launch the new blog for python-dev.
> > 
> > Is any core dev allowed to post on this blog? (how?)
> > Or is there an editorial team dedicated to writing posts?
> 
> Both!
> 
> If you want to write for the blog, just send me your Blogger account
> name so I can give you authorship permission.

I don't know yet if I will write for the blog (I would imagine posting
about new features or interesting fixes), but I definitely don't have a
Blogger account - and would like not to create one.

(or does it work with Google accounts)

Regards

Antoine.



From ethan at stoneleaf.us  Wed Mar 23 18:34:40 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 23 Mar 2011 10:34:40 -0700
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D8A1115.40003@voidspace.org.uk>
References: <4D884E08.1020709@skippinet.com.au>	<4D88F4A5.4060701@voidspace.org.uk>	<AANLkTikk=14XmaZdZxE=Xyg4JzMv5Vbn0EBZ6BP=mZuR@mail.gmail.com>
	<4D8A1115.40003@voidspace.org.uk>
Message-ID: <4D8A2F30.8000601@stoneleaf.us>

Michael Foord wrote:
> To be honest I would be happy with registry entries instead as the 
> alternative implementations can then add to their installers (or provide 
> a script) to add the right registry entry.

I'm partial to the config file method myself.  I have this vague hope 
where this tool could end up being a shebang-script-launching tool for 
other scripting languages as well.

~Ethan~

From fuzzyman at voidspace.org.uk  Wed Mar 23 18:39:01 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 23 Mar 2011 17:39:01 +0000
Subject: [Python-Dev] new blog
In-Reply-To: <1300901163.3495.25.camel@localhost.localdomain>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>	<20110323150319.6ed5fedd@pitrou.net>	<A8AE0BDA-92B0-41D1-903F-44F0D577FC02@gmail.com>
	<1300901163.3495.25.camel@localhost.localdomain>
Message-ID: <4D8A3035.3050204@voidspace.org.uk>

On 23/03/2011 17:26, Antoine Pitrou wrote:
> Le mercredi 23 mars 2011 ? 13:19 -0400, Doug Hellmann a ?crit :
>> On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote:
>>
>>> On Mon, 21 Mar 2011 21:50:53 -0400
>>> Doug Hellmann<doug.hellmann at gmail.com>  wrote:
>>>> We are nearly ready to launch the new blog for python-dev.
>>> Is any core dev allowed to post on this blog? (how?)
>>> Or is there an editorial team dedicated to writing posts?
>> Both!
>>
>> If you want to write for the blog, just send me your Blogger account
>> name so I can give you authorship permission.
> I don't know yet if I will write for the blog (I would imagine posting
> about new features or interesting fixes), but I definitely don't have a
> Blogger account - and would like not to create one.
>
> (or does it work with Google accounts)
>

Yep, a blogger account is a google account (and vice-versa).

Michael

> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From paulo.nuin at gmail.com  Wed Mar 23 18:40:56 2011
From: paulo.nuin at gmail.com (Paulo Nuin)
Date: Wed, 23 Mar 2011 13:40:56 -0400
Subject: [Python-Dev] new blog
In-Reply-To: <1300901163.3495.25.camel@localhost.localdomain>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
	<20110323150319.6ed5fedd@pitrou.net>
	<A8AE0BDA-92B0-41D1-903F-44F0D577FC02@gmail.com>
	<1300901163.3495.25.camel@localhost.localdomain>
Message-ID: <B90146A9-2870-4294-839D-BB4F4BB42683@gmail.com>

Hi Antoine

It does work with your Google account, so no need for a registration with a new service.

Regards
Paulo

PS: I'm a member of the PSF communications team, supervised by Doug. Joined the list in order to follow discussions in the list and be able to report and help with blog postings.

On 2011-03-23, at 1:26 PM, Antoine Pitrou wrote:

> Le mercredi 23 mars 2011 ? 13:19 -0400, Doug Hellmann a ?crit :
>> On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote:
>> 
>>> On Mon, 21 Mar 2011 21:50:53 -0400
>>> Doug Hellmann <doug.hellmann at gmail.com> wrote:
>>>> We are nearly ready to launch the new blog for python-dev.
>>> 
>>> Is any core dev allowed to post on this blog? (how?)
>>> Or is there an editorial team dedicated to writing posts?
>> 
>> Both!
>> 
>> If you want to write for the blog, just send me your Blogger account
>> name so I can give you authorship permission.
> 
> I don't know yet if I will write for the blog (I would imagine posting
> about new features or interesting fixes), but I definitely don't have a
> Blogger account - and would like not to create one.
> 
> (or does it work with Google accounts)
> 
> Regards
> 
> Antoine.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/paulo.nuin%40gmail.com


From fuzzyman at voidspace.org.uk  Wed Mar 23 18:43:39 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 23 Mar 2011 17:43:39 +0000
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D894D49.9060507@skippinet.com.au>
References: <4D884E08.1020709@skippinet.com.au>
	<4D88F4A5.4060701@voidspace.org.uk>
	<4D894D49.9060507@skippinet.com.au>
Message-ID: <4D8A314B.2010609@voidspace.org.uk>

On 23/03/2011 01:30, Mark Hammond wrote:
> On 23/03/2011 6:12 AM, Michael Foord wrote:
>> On 22/03/2011 07:21, Mark Hammond wrote:
>>> Hi all,
>>> I've made some changes to the draft PEP and checked it into the PEP
>>> repository as PEP397. The reference implementation is currently being
>>> tracked at http://bugs.python.org/issue11629.
>>>
>>
>> Hey Mark,
>>
>> One way of supporting alternative implementations (that may not even
>> have a standard install directory) is allowing configuration. e.g.
>> config.ini
>>
>> [paths]
>> ironpython = c:\Program Files\IronPython 2.7\ipy.exe
>> ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
>> jython = c:\Users\foobar\jython2.5\jython.exe
>
> Hi Michael,
>
> I'd have no problem with that in general, but how would you feel about 
> letting the PEP stand as it is without this additional requirement and 
> then treat this as an additional feature to be thrashed out 
> separately?  I intentionally worded the PEP to specifically allow 
> these kinds of features to be added outside the PEP process.
>
> For example, I guess the name of the INI file wouldn't be config.ini, 
> and I guess there might need to be a strategy to allow it to exist in 
> multiple places for when users want this feature but don't have write 
> access to the location of py.exe.  Then people might want it to be in 
> the cwd, or in any parent of the cwd, etc... Further, it might also be 
> possible to support this with simple environment variables which might 
> wind up being just as (or more) reasonable (the concept of per-user 
> environment variables already exist and a UI already exists for 
> editing them, and it would allow different cmd-prompts to have 
> different "rules" with minimal complexity) - not that I am necessarily 
> advocating this - I'd just prefer the PEP to not get bogged down with 
> those kinds of issues.
>

Well... I'd rather see the pep implemented as is than not implemented. 
On the other hand I think it would be a great shame for it to be 
implemented in a way that excludes-until-someone-else-fixes-it the other 
implementations. (i.e. I think built-in support for other 
implementations would be vastly preferable.) It's your PEP though, and 
I'm still +1 on the idea.

I'm not married to it being a config file - registry entries would be 
fine (implementations could modify their installers or ship scripts to 
create the correct entries). I'm not sure about environment variables, I 
suppose it would be ok - but modifying a single environment variable 
with multiple paths / interpreters could get icky.

All the best,

Michael

> 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


From doug.hellmann at gmail.com  Wed Mar 23 18:52:22 2011
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Wed, 23 Mar 2011 13:52:22 -0400
Subject: [Python-Dev] new blog
In-Reply-To: <1300901163.3495.25.camel@localhost.localdomain>
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
	<20110323150319.6ed5fedd@pitrou.net>
	<A8AE0BDA-92B0-41D1-903F-44F0D577FC02@gmail.com>
	<1300901163.3495.25.camel@localhost.localdomain>
Message-ID: <7D1CEC93-1048-4C57-BECF-816218AA34CE@gmail.com>


On Mar 23, 2011, at 1:26 PM, Antoine Pitrou wrote:

> Le mercredi 23 mars 2011 ? 13:19 -0400, Doug Hellmann a ?crit :
>> On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote:
>> 
>>> On Mon, 21 Mar 2011 21:50:53 -0400
>>> Doug Hellmann <doug.hellmann at gmail.com> wrote:
>>>> We are nearly ready to launch the new blog for python-dev.
>>> 
>>> Is any core dev allowed to post on this blog? (how?)
>>> Or is there an editorial team dedicated to writing posts?
>> 
>> Both!
>> 
>> If you want to write for the blog, just send me your Blogger account
>> name so I can give you authorship permission.
> 
> I don't know yet if I will write for the blog (I would imagine posting
> about new features or interesting fixes), but I definitely don't have a
> Blogger account - and would like not to create one.
> 
> (or does it work with Google accounts)

As far as I understand, those are the same thing. If you have a gmail address, you can use it to login to blogger.

Doug


From tseaver at palladion.com  Wed Mar 23 18:58:31 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 23 Mar 2011 13:58:31 -0400
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <20110323182400.04ce46cf@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>	<20110323143123.4be80686@pitrou.net>	<19850.2977.894754.352174@montanaro.dyndns.org>	<20110323115156.25bd2845@neurotica.wooz.org>	<19850.9561.366432.287634@montanaro.dyndns.org>	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net>
Message-ID: <imdcc7$2q4$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/23/2011 01:24 PM, Antoine Pitrou wrote:
> On Wed, 23 Mar 2011 10:25:01 -0700
> Ethan Furman <ethan at stoneleaf.us> wrote:
>>
>> I think the use-case has been lost.  Think sprints and multiple push 
>> races.  No one is arguing that the smoke-test should be the default, but 
>> seriously, are you willing to spend an hour or more re-running the 
>> complete suite of tests six, eight, or 12 times because of push races in 
>> a sprint?  I can see losing a good portion of your sprinting day.
> 
> Well, keep in ming hg is a *distributed* version control system. You
> don't have to push your changes right now. You can keep your changesets
> for yourself, make several of them (different bug fixes, for example),
> and push them (after a single merge) at the end of day.

That doesn't work so well at a sprint, where the point is to maximize
the value of precious face-time to get stuff done *now*.  Long test
latencies and nearly-real-time collaboration are not friendly, as the
agile folks document:

 http://c2.com/cgi/wiki?TestSpeed

Maybe we need to chop the problem up as:

- - Pure documentation changes never require running any test suite
  (this includes true comments in code, as well as docstrings which
  are not used to drive doctests or other tested output).

- - "core" language changes always require running the full test suite.

- - We compute an import-dependency map for the stdlib (maybe during
  build?), and add support for running tests of a named module and its
  dependents. Any non-documentation change to a stdlib module requires
  running this new kind of test against that module.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2KNMcACgkQ+gerLs4ltQ7yCwCfbqhYut0F4L3f92mXwB5SZZ8s
qLUAoNpchNrkPPnjbXkqWDrIqW9NQdWr
=tCRR
-----END PGP SIGNATURE-----


From janssen at parc.com  Wed Mar 23 18:58:37 2011
From: janssen at parc.com (Bill Janssen)
Date: Wed, 23 Mar 2011 10:58:37 PDT
Subject: [Python-Dev] funky buildbot
In-Reply-To: <81942.1299788304@parc.com>
References: <81942.1299788304@parc.com>
Message-ID: <12502.1300903117@parc.com>

My Intel Snow Leopard buildbot failed again last night.

Here's what I see in twistd.log.  Any of this look familiar to some one?
Failed at about 19:58 (PST?).  I don't see any reason for these
failures, but they seem to happen about once a week.  This is the
standard Snow Leopard Python 2.6.1, and whatever version of Twisted
comes with Snow Leopard, and the latest buildslave.  The machine is in a
server room with conditioned power supply and pretty good network
access.  The two other PPC machines next to it have no problems, but
they're running older versions of OS X.

Bill

[...]
2011-03-22 19:44:07-0700 [Broker,client] RunProcess._startCommand
2011-03-22 19:44:07-0700 [Broker,client]  make buildbottest TESTOPTS= TESTPYTHONOPTS=
2011-03-22 19:44:07-0700 [Broker,client]   in dir /Users/buildbot/buildarea/3.x.parc-snowleopard-1/build (timeout 3600 secs)
2011-03-22 19:44:07-0700 [Broker,client]   watching logfiles {}
2011-03-22 19:44:07-0700 [Broker,client]   argv: ['make', 'buildbottest', 'TESTOPTS=', 'TESTPYTHONOPTS=']
2011-03-22 19:44:07-0700 [Broker,client]  environment: {'LANG': 'en_US.UTF-8', 'TERM': 'xterm-color', 'Apple_PubSub_Socket_Render': '/tmp/launch-c3R8Zl/Render', 'TMPDIR': '/var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/', 'VERSIONER_PYTHON_VERSION': '2.6', 'SHLVL': '1', 'VERSIONER_PYTHON_PREFER_32_BIT': 'no', 'SSH_AUTH_SOCK': '/tmp/launch-Nl3TOy/Listeners', '__CF_USER_TEXT_ENCODING': '0x1F6:0:0', 'PWD': '/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build', 'SHELL': '/bin/bash', 'LOGNAME': 'buildbot', 'TERM_PROGRAM_VERSION': '273', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin', 'HOME': '/Users/buildbot', 'TERM_PROGRAM': 'Apple_Terminal', 'COMMAND_MODE': 'unix2003', 'DISPLAY': '/tmp/launch-iaSAFg/org.x:0', '_': '/usr/local/bin/buildslave', 'USER': 'buildbot'}
2011-03-22 19:44:07-0700 [Broker,client]   closing stdin
2011-03-22 19:44:07-0700 [Broker,client]   using PTY: False
2011-03-22 19:46:17-0700 [-] sending app-level keepalive
2011-03-22 19:56:17-0700 [-] sending app-level keepalive
2011-03-22 19:58:33-0700 [Broker,client] SlaveBuilder._ackFailed: SlaveBuilder.sendUpdate
2011-03-22 19:58:33-0700 [Broker,client] Unhandled Error
	Traceback (most recent call last):
	Failure: twisted.spread.pb.PBConnectionLost: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionLost'>: Connection to the other side was lost in a non-clean fashion.
	]
	
2011-03-22 19:58:33-0700 [Broker,client] lost remote
2011-03-22 19:58:33-0700 [Broker,client] lost remote
2011-03-22 19:58:33-0700 [Broker,client] lost remote
2011-03-22 19:58:33-0700 [Broker,client] lost remote
2011-03-22 19:58:33-0700 [Broker,client] lost remote step
2011-03-22 19:58:33-0700 [Broker,client] stopCommand: halting current command <buildslave.commands.shell.SlaveShellCommand instance at 0x102002c68>
2011-03-22 19:58:33-0700 [Broker,client] command interrupted, killing pid 90085
2011-03-22 19:58:33-0700 [Broker,client] trying os.kill(-pid, 9)
2011-03-22 19:58:33-0700 [Broker,client] trying process.signalProcess('KILL')
2011-03-22 19:58:33-0700 [Broker,client]  signal KILL sent successfully
2011-03-22 19:58:33-0700 [Broker,client] Lost connection to dinsdale.python.org:9020
2011-03-22 19:58:33-0700 [Broker,client] <twisted.internet.tcp.Connector instance at 0x101629a70> will retry in 2 seconds
2011-03-22 19:58:33-0700 [Broker,client] Stopping factory <buildslave.bot.BotFactory instance at 0x101629998>
2011-03-22 19:58:33-0700 [-] command finished with signal 9, exit code None, elapsedTime: 865.868813
2011-03-22 19:58:33-0700 [-] SlaveBuilder.commandComplete None
2011-03-22 19:58:35-0700 [-] Starting factory <buildslave.bot.BotFactory instance at 0x101629998>
2011-03-22 19:58:35-0700 [-] Connecting to dinsdale.python.org:9020
2011-03-22 19:58:36-0700 [Uninitialized] Connection to dinsdale.python.org:9020 failed: Connection Refused
2011-03-22 19:58:36-0700 [Uninitialized] <twisted.internet.tcp.Connector instance at 0x101629a70> will retry in 7 seconds
2011-03-22 19:58:36-0700 [Uninitialized] Stopping factory <buildslave.bot.BotFactory instance at 0x101629998>
2011-03-22 19:58:43-0700 [-] Starting factory <buildslave.bot.BotFactory instance at 0x101629998>
2011-03-22 19:58:43-0700 [-] Connecting to dinsdale.python.org:9020

From solipsis at pitrou.net  Wed Mar 23 19:01:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 19:01:25 +0100
Subject: [Python-Dev] new blog
References: <FE263C4C-09FD-41B6-B56F-703632845387@gmail.com>
	<20110323150319.6ed5fedd@pitrou.net>
	<A8AE0BDA-92B0-41D1-903F-44F0D577FC02@gmail.com>
	<1300901163.3495.25.camel@localhost.localdomain>
	<B90146A9-2870-4294-839D-BB4F4BB42683@gmail.com>
Message-ID: <20110323190125.67b0d004@pitrou.net>


Thank you, Michael and Brian (on IRC) for your answers.

Regards

Antoine.


On Wed, 23 Mar 2011 13:40:56 -0400
Paulo Nuin <paulo.nuin at gmail.com> wrote:

> Hi Antoine
> 
> It does work with your Google account, so no need for a registration with a new service.
> 
> Regards
> Paulo
> 


From solipsis at pitrou.net  Wed Mar 23 19:13:54 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 19:13:54 +0100
Subject: [Python-Dev] sprints and pushes
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net> <imdcc7$2q4$1@dough.gmane.org>
Message-ID: <20110323191354.6e31247f@pitrou.net>

On Wed, 23 Mar 2011 13:58:31 -0400
Tres Seaver <tseaver at palladion.com> wrote:
> 
> That doesn't work so well at a sprint, where the point is to maximize
> the value of precious face-time to get stuff done *now*.  Long test
> latencies and nearly-real-time collaboration are not friendly, as the
> agile folks document:
> 
>  http://c2.com/cgi/wiki?TestSpeed
> 
> Maybe we need to chop the problem up as:
> 
> - - Pure documentation changes never require running any test suite
>   (this includes true comments in code, as well as docstrings which
>   are not used to drive doctests or other tested output).
> 
> - - "core" language changes always require running the full test suite.
> 
> - - We compute an import-dependency map for the stdlib (maybe during
>   build?), and add support for running tests of a named module and its
>   dependents. Any non-documentation change to a stdlib module requires
>   running this new kind of test against that module.

I agree that finding ways to speedup running tests *without* reducing
the necessary coverage is the right way to go.
Part of that is obviously about optimizing the tests themselves
(something which I and others have been doing repeatedly, including the
addition of the "-j" switch).
The dependency map is another idea.

All this needs work and is therefore more difficult than blacklisting
some "slow" tests, but is much more productive in the long run.

Regards

Antoine.



From db3l.net at gmail.com  Wed Mar 23 19:29:22 2011
From: db3l.net at gmail.com (David Bolen)
Date: Wed, 23 Mar 2011 14:29:22 -0400
Subject: [Python-Dev] Trimming "make quicktest"
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>
	<1300890997.3495.13.camel@localhost.localdomain>
	<AANLkTimq8waQH-VPbxvnXZS-RJNgDk2gFE=_KYRz5v2G@mail.gmail.com>
Message-ID: <m2mxklu1vh.fsf@valheru.db3l.homeip.net>

Nick Coghlan <ncoghlan at gmail.com> writes:

> On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> You mean in the "-j" option itself or in "make test"?
>
> I was actually suggesting that -j be the *default* in regrtest itself,
> with an option to turn it off or force a particular number of
> processes.

Just one request - if there are changes in this direction (e.g.,
trying to make regrtest use all cores by default), please include the
ability to configure/override this for individual builders (or at
least slaves) since otherwise I won't be able to disable it.

I, for example, have cases where I may not automatically want all
cores that regrtest happens to "see" get used, as the slave is doing
other things too.  Command line options to regrtest won't help since
that's not something I, as a slave owner, can override for test
builds.

-- David


From solipsis at pitrou.net  Wed Mar 23 19:42:01 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 19:42:01 +0100
Subject: [Python-Dev] Trimming "make quicktest"
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>
	<1300890997.3495.13.camel@localhost.localdomain>
	<AANLkTimq8waQH-VPbxvnXZS-RJNgDk2gFE=_KYRz5v2G@mail.gmail.com>
	<m2mxklu1vh.fsf@valheru.db3l.homeip.net>
Message-ID: <20110323194201.17d01670@pitrou.net>

On Wed, 23 Mar 2011 14:29:22 -0400
David Bolen <db3l.net at gmail.com> wrote:
> Nick Coghlan <ncoghlan at gmail.com> writes:
> 
> > On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >> You mean in the "-j" option itself or in "make test"?
> >
> > I was actually suggesting that -j be the *default* in regrtest itself,
> > with an option to turn it off or force a particular number of
> > processes.
> 
> Just one request - if there are changes in this direction (e.g.,
> trying to make regrtest use all cores by default), please include the
> ability to configure/override this for individual builders (or at
> least slaves) since otherwise I won't be able to disable it.

I think "-j" should remain a manual setting. I've posted a patch to
enable it automatically in "make test" for convenience, but it would
be enabled for neither "-m test" nor "make buildbottest".

Regards

Antoine.



From xiscu at email.de  Wed Mar 23 19:43:01 2011
From: xiscu at email.de (xiscu)
Date: Wed, 23 Mar 2011 19:43:01 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D87D2B2.5060901@v.loewis.de>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<im5akg$ptc$1@dough.gmane.org>	<20110321122015.3add347b@limelight.wooz.org>	<20110321180740.27947057@pitrou.net>	<20110321142954.4e301fb2@limelight.wooz.org>	<20110321193818.66fee202@pitrou.net>	<20110321163331.4277ffd0@limelight.wooz.org>	<20110321215326.0767c775@pitrou.net>	<20110321172505.33b3d507@neurotica.wooz.org>	<20110321223153.1a0128ed@pitrou.net>	<AANLkTi=qqeDb4+JLTFx9Lo4RRLqjp4P-YLoC7+LHuZkt@mail.gmail.com>	<4D87CCA7.40002@v.loewis.de>	<1300745738.3516.13.camel@localhost.localdomain>
	<4D87D2B2.5060901@v.loewis.de>
Message-ID: <4D8A3F35.6010300@email.de>

On 03/21/2011 11:35 PM, "Martin v. L?wis" wrote:
>
> If people then complain about too much fine-grainedness, we could
> tighten it again.
>    

Hi to all for the first time,

I'm new to this list. First of all I would like to thank all you for the 
great software and ideas you produce.

I found this thread of discussion interesting and well, it's just an idea:

Why not to TAG the final feature ? May be in a ?parsable?, standard form ?

Ej:

 >> hg tag -m ?Feature : Templates for code generation, status: Done?

So If one doesn't want to see the ?in between?, a tag filter can be 
applied, or something similar ?

Of course there are 2 types of info here: ?private? and ?public? and 
well, like in python, use some kind of ?underline? for private names 
here (def _do_my_thing(self): pass)

May be can be somehow automated ?

Cheers / Saludos

francis



From fuzzyman at voidspace.org.uk  Wed Mar 23 19:51:20 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 23 Mar 2011 18:51:20 +0000
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <20110323194201.17d01670@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>	<20110323143123.4be80686@pitrou.net>	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>	<1300888356.3495.9.camel@localhost.localdomain>	<AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>	<1300890997.3495.13.camel@localhost.localdomain>	<AANLkTimq8waQH-VPbxvnXZS-RJNgDk2gFE=_KYRz5v2G@mail.gmail.com>	<m2mxklu1vh.fsf@valheru.db3l.homeip.net>
	<20110323194201.17d01670@pitrou.net>
Message-ID: <4D8A4128.2050206@voidspace.org.uk>

On 23/03/2011 18:42, Antoine Pitrou wrote:
> On Wed, 23 Mar 2011 14:29:22 -0400
> David Bolen<db3l.net at gmail.com>  wrote:
>> Nick Coghlan<ncoghlan at gmail.com>  writes:
>>
>>> On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou<solipsis at pitrou.net>  wrote:
>>>> You mean in the "-j" option itself or in "make test"?
>>> I was actually suggesting that -j be the *default* in regrtest itself,
>>> with an option to turn it off or force a particular number of
>>> processes.
>> Just one request - if there are changes in this direction (e.g.,
>> trying to make regrtest use all cores by default), please include the
>> ability to configure/override this for individual builders (or at
>> least slaves) since otherwise I won't be able to disable it.
> I think "-j" should remain a manual setting. I've posted a patch to
> enable it automatically in "make test" for convenience, but it would
> be enabled for neither "-m test" nor "make buildbottest".

-j doesn't pass on several of the flags to its subprocesses (e.g. 
warning settings I believe), so it shouldn't be the default. It's still 
very useful though.

All the best,

Michael
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From solipsis at pitrou.net  Wed Mar 23 19:56:16 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Mar 2011 19:56:16 +0100
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <4D8A4128.2050206@voidspace.org.uk>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>
	<1300890997.3495.13.camel@localhost.localdomain>
	<AANLkTimq8waQH-VPbxvnXZS-RJNgDk2gFE=_KYRz5v2G@mail.gmail.com>
	<m2mxklu1vh.fsf@valheru.db3l.homeip.net>
	<20110323194201.17d01670@pitrou.net>
	<4D8A4128.2050206@voidspace.org.uk>
Message-ID: <1300906576.3495.29.camel@localhost.localdomain>

Le mercredi 23 mars 2011 ? 18:51 +0000, Michael Foord a ?crit :
> On 23/03/2011 18:42, Antoine Pitrou wrote:
> > On Wed, 23 Mar 2011 14:29:22 -0400
> > David Bolen<db3l.net at gmail.com>  wrote:
> >> Nick Coghlan<ncoghlan at gmail.com>  writes:
> >>
> >>> On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou<solipsis at pitrou.net>  wrote:
> >>>> You mean in the "-j" option itself or in "make test"?
> >>> I was actually suggesting that -j be the *default* in regrtest itself,
> >>> with an option to turn it off or force a particular number of
> >>> processes.
> >> Just one request - if there are changes in this direction (e.g.,
> >> trying to make regrtest use all cores by default), please include the
> >> ability to configure/override this for individual builders (or at
> >> least slaves) since otherwise I won't be able to disable it.
> > I think "-j" should remain a manual setting. I've posted a patch to
> > enable it automatically in "make test" for convenience, but it would
> > be enabled for neither "-m test" nor "make buildbottest".
> 
> -j doesn't pass on several of the flags to its subprocesses (e.g. 
> warning settings I believe)

It does (should):
http://hg.python.org/cpython/file/2f4865834695/Lib/test/support.py#l1375



From g.brandl at gmx.net  Wed Mar 23 20:56:09 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 23 Mar 2011 20:56:09 +0100
Subject: [Python-Dev] Python 3.3 release schedule posted
Message-ID: <imdj8n$dq0$1@dough.gmane.org>

I've posted a very preliminary Python 3.3 release schedule as PEP 398.
The final release is set to be about 18 months after 3.2 final, which
is in August 2012.

For 3.3, I'd like to revive the tradition of listing planned large-scale
changes in the PEP.  Please let me know if you plan any such changes,
at any time.  (If they aren't codified in PEP form, we should think about
whether they should be.)

The "Candidate PEPs" I listed are those open PEPs that in my opinion have
the highest chance to be accepted and implemented for 3.3.  It is by no
means binding.

cheers,
Georg


From tjreedy at udel.edu  Wed Mar 23 20:57:15 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 23 Mar 2011 15:57:15 -0400
Subject: [Python-Dev] __reduce__
In-Reply-To: <2E034B571A5CE44E949B9FCC3B6D24EE6B1E3D9A@exchcn.ccp.ad.local>
References: <2E034B571A5CE44E949B9FCC3B6D24EE6B1E3D9A@exchcn.ccp.ad.local>
Message-ID: <imdjao$caj$1@dough.gmane.org>

On 3/23/2011 11:23 AM, Kristj?n Valur J?nsson wrote:
> The __reduce__ protocol doesn?t provide for keyword arguments to the
> constructor.
>
> Some constructor arguments are only available as keyword arguments.
> Annoying, isn?t it?

I suspect it is ;-).
If you think this could be changed and are ready to pursue it, open a 
feature request on the tracker. This is a rather busy time on pydev for 
new threads to get much attention.

-- 
Terry Jan Reedy



From carl at oddbird.net  Wed Mar 23 21:02:01 2011
From: carl at oddbird.net (Carl Meyer)
Date: Wed, 23 Mar 2011 16:02:01 -0400
Subject: [Python-Dev] Python 3.3 release schedule posted
In-Reply-To: <imdj8n$dq0$1@dough.gmane.org>
References: <imdj8n$dq0$1@dough.gmane.org>
Message-ID: <4D8A51B9.7000403@oddbird.net>

Hi Georg,

On 03/23/2011 03:56 PM, Georg Brandl wrote:
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP.  Please let me know if you plan any such changes,
> at any time.  (If they aren't codified in PEP form, we should think about
> whether they should be.)

Over in distutils-sig there's been extensive discussion at and since
PyCon of a built-in Python virtual-environment tool, similar to
virtualenv, targeted hopefully for 3.3. This is something that's seen
some discussion on python-dev previously; I now have a working prototype
and am working on a PEP. When the PEP is ready I'll bring it up for
discussion on python-ideas and then python-dev; anyone interested in
checking it out sooner can go read the discussions at distutils-sig.

Carl

From tjreedy at udel.edu  Wed Mar 23 21:13:54 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 23 Mar 2011 16:13:54 -0400
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
	first experience)
In-Reply-To: <AANLkTi=z0TxiaNRqj-t3XyLmJeLXp1fJLuMP88amF-hH@mail.gmail.com>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
	<AANLkTi=z0TxiaNRqj-t3XyLmJeLXp1fJLuMP88amF-hH@mail.gmail.com>
Message-ID: <imdka0$ka4$1@dough.gmane.org>

On 3/23/2011 8:58 AM, Nick Coghlan wrote:
> On Tue, Mar 22, 2011 at 9:57 PM, anatoly techtonik<techtonik at gmail.com>  wrote:

> Python 3 actually chose *cross-platform consistency* over user
> convenience when switching away from the platform IO implementations.

Given that print acted differently on *nix and Windows, there were *two* 
choices, not just one, for consistency: the *nix way and the Windows 
way. In this case, I think the Windows way was/is better and that the 
wrong choice was made. We could and I hope can have *both* convenience 
and consistency.

The *nix choice introduced an new within-platform inconsistency, at 
least on Windows. When a program is run from an IDLE editor window, 
print to screen remaims unbuffered. (This is true on Windows, at least. 
I have no idea about *nix, and hope someone will test the code below). 
That means that I can develop a program like this:

import time

for c in 'Similated 10 cps teletype output':
     print(c,end='')
     time.sleep(.1)

print()

run it, see that it works, and ship it. But apparently, is will not work 
even for Windows users who run it 'normally'.

I would prefer that IDLE not be degraded and am not sure it could be.

>Users may *say* they prefer
> convenience over speed, but that's only true until the lack of speed
> becomes intolerably slow.

Could speed ever really be an issue for print to screen?

-- 
Terry Jan Reedy


From g.brandl at gmx.net  Wed Mar 23 22:07:21 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 23 Mar 2011 22:07:21 +0100
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323131047.48056956@neurotica.wooz.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
	<20110323111850.52c10754@neurotica.wooz.org>
	<20110323170922.330638c8@pitrou.net>
	<20110323131047.48056956@neurotica.wooz.org>
Message-ID: <imdne2$2dc$1@dough.gmane.org>

On 23.03.2011 18:10, Barry Warsaw wrote:
> On Mar 23, 2011, at 05:09 PM, Antoine Pitrou wrote:
> 
>>That's completely bogus. There's no reason to believe that a push race would
>>favour certain regressions over certain others. Again, you need the full test
>>suite to assert that no regressions occured.  (or you might as well run 10
>>tests at random and call it done)
> 
> If you promote the full test suite as the thing to run when resolving merge
> races, then I predict no one will run them, because doing so increases your
> chances of hitting *another* push race.  This whole thread came up in the
> context of trying to find a quick test you could run in that case which didn't
> increase that race window.  I think the practical effect of not having a
> simple, fast smoke test will be to do *less* testing when you hit the merge
> race, and just let the buildbots sort it all out.  You'll probably win most of
> the time anyway.

FWIW, +1 to this.

Georg


From hodgestar+pythondev at gmail.com  Wed Mar 23 22:27:49 2011
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Wed, 23 Mar 2011 23:27:49 +0200
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <20110323182400.04ce46cf@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net>
Message-ID: <AANLkTim7snnOOrsbxJrU9mFr4S8S+xwZaY9iCCQKVMDZ@mail.gmail.com>

On Wed, Mar 23, 2011 at 7:24 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 23 Mar 2011 10:25:01 -0700
> Ethan Furman <ethan at stoneleaf.us> wrote:
>>
>> I think the use-case has been lost. ?Think sprints and multiple push
>> races. ?No one is arguing that the smoke-test should be the default, but
>> seriously, are you willing to spend an hour or more re-running the
>> complete suite of tests six, eight, or 12 times because of push races in
>> a sprint? ?I can see losing a good portion of your sprinting day.

Our sprint model has been to set up a throw-away sprint repository
somewhere accessible (github, bitbucket, wherever) and have everyone
commit madly to it however they want. Afterwards a few brace souls
take the result and commit it to the master repository in a more
orderly fashion.

From skip at pobox.com  Wed Mar 23 22:40:51 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 23 Mar 2011 16:40:51 -0500
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <imdcc7$2q4$1@dough.gmane.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us> <20110323182400.04ce46cf@pitrou.net>
	<imdcc7$2q4$1@dough.gmane.org>
Message-ID: <19850.26851.812637.185223@montanaro.dyndns.org>


    >>> I think the use-case has been lost.  Think sprints and multiple push
    >>> races.

    Tres> That doesn't work so well at a sprint, where the point is to
    Tres> maximize the value of precious face-time to get stuff done *now*.

How about everybody pushes (without testing, or with, at most, Barry's smoke
test) to a sprint-specific local repository?  One or more buildbots (or
similar) can just churn away running unit tests from that repository.  When
a problem is encountered, the people resposible are going to be right there.
They don't have to slow down their mad hacking until there is a problem.
Since there will be a fair amount of communication between sprinters, the
odds of something bad and horribly hard to fix should be low.  Pushes to the
global repository from that sprint repository can happen at a more leisurely
pace and be coordinated manually.  Say, everybody breaks for {morning snack,
lunch, dinner}.  When they return from the break if the local buildbots are
green you push out to cpython, then everyone starts banging on their
keyboards again.

Skip

From regebro at gmail.com  Wed Mar 23 22:45:15 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 23 Mar 2011 22:45:15 +0100
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <4D89E124.3000204@pearwood.info>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
	<4D8910BB.8090307@pearwood.info>
	<AANLkTikieVGwEkvKG9gRbRCmeaD=yJFhjELMkkOrtRfH@mail.gmail.com>
	<4D89E124.3000204@pearwood.info>
Message-ID: <AANLkTi=VTXRBCB4m_P_3=e1Gcm2nB6Sg_4uq9aMfjCC0@mail.gmail.com>

On Wed, Mar 23, 2011 at 13:01, Steven D'Aprano <steve at pearwood.info> wrote:
> But the improvement is exactly what Anatoly is talking about: it's an
> improvement in speed over user convenience. If all you are doing is
> iterating over a moderately-sized dictionary, you probably don't care
> whether items() etc. returns a list or an iterator. But if you want to take
> those items away and do something with them, you need a list, and that's
> ever-so-slightly less convenient now than it was.

But how often are you doing things with the results from items() and
values() that doesn't involve iterating over them? Sure, you can take
a slice, but there is no point in slicing a list that comes from a
dictionary because it's not ordered, so you won't know which item you
get. You could sort them of course, but sorted() takes an iterable and
returns a list anyway.

And in what way is it more convenient to default to what you usually
don't want? In most cases you do *not* want a list. So now, you in
most cases do not get a list. Before, if  you didn't want a lite you
used d.iteritems(). Now if you want a list you use list(d.items()).

So I don't agree that this is speed over convenience. It's speed *and*
convenience. Python 3 is *more* convenient here, because the most
common usecases are the most convenient. In Python 2 it was the other
way around. It just feels inconvenient because we were used to it
being the other way around.

> Lennart, please be a little more careful with your attributions.

Sorry!

//Lennart

From ncoghlan at gmail.com  Thu Mar 24 00:12:29 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 24 Mar 2011 09:12:29 +1000
Subject: [Python-Dev] Python 3.3 release schedule posted
In-Reply-To: <imdj8n$dq0$1@dough.gmane.org>
References: <imdj8n$dq0$1@dough.gmane.org>
Message-ID: <AANLkTi=9bedAp40CPHQG-fkPTHwqrkzJ6q9Dr6X7p_f7@mail.gmail.com>

On Thu, Mar 24, 2011 at 5:56 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP. ?Please let me know if you plan any such changes,
> at any time. ?(If they aren't codified in PEP form, we should think about
> whether they should be.)

I would add a note about a "standardised event loop interface" -
that's a PEP idea that came up at the language summit, and LvH plans
to write it with support from the Twisted crew and others.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From thomas at python.org  Thu Mar 24 00:18:15 2011
From: thomas at python.org (Thomas Wouters)
Date: Thu, 24 Mar 2011 00:18:15 +0100
Subject: [Python-Dev] Python 3.3 release schedule posted
In-Reply-To: <AANLkTi=9bedAp40CPHQG-fkPTHwqrkzJ6q9Dr6X7p_f7@mail.gmail.com>
References: <imdj8n$dq0$1@dough.gmane.org>
	<AANLkTi=9bedAp40CPHQG-fkPTHwqrkzJ6q9Dr6X7p_f7@mail.gmail.com>
Message-ID: <AANLkTikt+PUE41h576o5oo+foT5o61RW=p=oEBF5qkzC@mail.gmail.com>

On Thu, Mar 24, 2011 at 00:12, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Thu, Mar 24, 2011 at 5:56 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> > For 3.3, I'd like to revive the tradition of listing planned large-scale
> > changes in the PEP.  Please let me know if you plan any such changes,
> > at any time.  (If they aren't codified in PEP form, we should think about
> > whether they should be.)
>
> I would add a note about a "standardised event loop interface" -
> that's a PEP idea that came up at the language summit, and LvH plans
> to write it with support from the Twisted crew and others.
>

It ended up that Jim Fulton is actually writing the PEP (with input from
Twisted people and others.)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/dcb3d296/attachment.html>

From ncoghlan at gmail.com  Thu Mar 24 00:18:56 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 24 Mar 2011 09:18:56 +1000
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <imdne2$2dc$1@dough.gmane.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
	<20110323111850.52c10754@neurotica.wooz.org>
	<20110323170922.330638c8@pitrou.net>
	<20110323131047.48056956@neurotica.wooz.org>
	<imdne2$2dc$1@dough.gmane.org>
Message-ID: <AANLkTimNL3hu6TEpPPyzPAc3=A-DsaT6-i9yNvnXmNt9@mail.gmail.com>

On Thu, Mar 24, 2011 at 7:07 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> On 23.03.2011 18:10, Barry Warsaw wrote:
>> On Mar 23, 2011, at 05:09 PM, Antoine Pitrou wrote:
>>
>>>That's completely bogus. There's no reason to believe that a push race would
>>>favour certain regressions over certain others. Again, you need the full test
>>>suite to assert that no regressions occured. ?(or you might as well run 10
>>>tests at random and call it done)
>>
>> If you promote the full test suite as the thing to run when resolving merge
>> races, then I predict no one will run them, because doing so increases your
>> chances of hitting *another* push race. ?This whole thread came up in the
>> context of trying to find a quick test you could run in that case which didn't
>> increase that race window. ?I think the practical effect of not having a
>> simple, fast smoke test will be to do *less* testing when you hit the merge
>> race, and just let the buildbots sort it all out. ?You'll probably win most of
>> the time anyway.
>
> FWIW, +1 to this.

To make it clear as to the use case Barry and I are trying to cover
here, when you get into a full push race for a bug fix, the current
work flow (in practice) is to just merge/commit/push. When you
multiply it by 3 branches, a useful smoke test needs to be *damn* fast
(i.e. less than a minute) because you're going to be running it three
times in quick succession (perhaps 3 if it applies to 2.7 as well).

The alternative is *not* a full test run, but at best simply running
the specific tests for whatever I'm fixing (or, more likely, not
running any tests at all).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Thu Mar 24 00:21:59 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 24 Mar 2011 09:21:59 +1000
Subject: [Python-Dev] Python3: speed efficiency vs user friendliness (my
 first experience)
In-Reply-To: <imdka0$ka4$1@dough.gmane.org>
References: <AANLkTi=a15rXR=hp51YK8M6popboa5rk4ok2RbM2vMRD@mail.gmail.com>
	<AANLkTi=z0TxiaNRqj-t3XyLmJeLXp1fJLuMP88amF-hH@mail.gmail.com>
	<imdka0$ka4$1@dough.gmane.org>
Message-ID: <AANLkTimRFtHFqDiH+hyubokQk4ZFz3-DD_rjAfgXZ=dt@mail.gmail.com>

On Thu, Mar 24, 2011 at 6:13 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> Could speed ever really be an issue for print to screen?

Definitely, especially on Windows. Just minimising the console window
can speed up a Windows console app enormously.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From fuzzyman at voidspace.org.uk  Thu Mar 24 00:33:53 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 23 Mar 2011 23:33:53 +0000
Subject: [Python-Dev] Python 3.3 release schedule posted
In-Reply-To: <imdj8n$dq0$1@dough.gmane.org>
References: <imdj8n$dq0$1@dough.gmane.org>
Message-ID: <4D8A8361.3050105@voidspace.org.uk>

On 23/03/2011 19:56, Georg Brandl wrote:
> I've posted a very preliminary Python 3.3 release schedule as PEP 398.
> The final release is set to be about 18 months after 3.2 final, which
> is in August 2012.
>
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP.  Please let me know if you plan any such changes,
> at any time.  (If they aren't codified in PEP form, we should think about
> whether they should be.)
>
> The "Candidate PEPs" I listed are those open PEPs that in my opinion have
> the highest chance to be accepted and implemented for 3.3.  It is by no
> means binding.

During the language summit we also discussed formalising in a pep the 
rule that all modules that have a pure python form and a C accelerator 
must keep the pure python and C form precisely in sync and the same 
tests must be run against both. Brett said he would write the pep after 
he has switched import to use importlib...

There was also the "compatibility warning", probably enabled by a 
command line flag, that would warn on the use of CPython specific 
implementation details (for example using non-string keys in class 
dicts). There is no owner for this as a PEP.

They're both mentioned in Nick Coghlan's summary:

http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html

Another item discussed at the language summit was moving the standard 
library into its own repository. Jesse Noller started working on a PEP 
but it stalled waiting for the transition to mercurial and I don't know 
if he is volunteering to pick up the PEP again now that has happened.

All the best,

Michael Foord

> cheers,
> Georg
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From victor.stinner at haypocalc.com  Thu Mar 24 00:49:09 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 24 Mar 2011 00:49:09 +0100
Subject: [Python-Dev] I plan to push faulthandler into Python 3.3 in one week
Message-ID: <1300924149.1028.15.camel@marge>

Hi,

If nobody complains, I plan to push my faulthandler module into Python
3.3 in one week. It's a module to display the Python backtrace on a
segfault, on a user signal or after a timeout.

I opened an issue (#11393) for that, 3 weeks ago, and I already got some
interesting comments. I fixed some bugs and changed the API (function
names).

Even if faulthandler is very specific to CPython, I would like to keep
its original name: faulthandler (and not _faulthandler). I also plan to
maintain the module outside CPython for Python 2.5-3.2.

What is the procedure to add a new module? Just add the code into
Modules and patch setup.py? The module is distributed under the BSD
(2-clause) license.

---

faulthandler API is simple and small.

Fatal errors:

 * enable()
 * disable()
 * is_enabled()

Dump the traceback after a timeout:

 * dump_traceback_later(delay, repeat=False, 
                        file=sys.stderr, all_threads=False)
 * cancel_dump_traceback_later()

Dump the traceback on a user signal:

 * register(signum, file=sys.stderr, all_threads=False)
 * unregister(signum)

Explicit call to dump the traceback:

 * dump_traceback(file=sys.stderr, all_threads=False)

Read the README file for more information.

I don't know if I chose the best function names :-)

---

https://github.com/haypo/faulthandler/
http://bugs.python.org/issue11393
(see also my previous thread on python-dev, "Integrate the faulthandler
module into Python 3.3?")

Victor


From martin at v.loewis.de  Thu Mar 24 01:05:19 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Mar 2011 01:05:19 +0100
Subject: [Python-Dev] I plan to push faulthandler into Python 3.3 in one
 week
In-Reply-To: <1300924149.1028.15.camel@marge>
References: <1300924149.1028.15.camel@marge>
Message-ID: <4D8A8ABF.6060800@v.loewis.de>

> What is the procedure to add a new module? Just add the code into
> Modules and patch setup.py? The module is distributed under the BSD
> (2-clause) license.

Also add it to the Visual Studio build process. It either needs to go
into pythonXY.dll (i.e. pythoncore.vcproj), or into a separate project,
to be referenced from pcbuild.sln.

Contributions under the BSD license are not acceptable. You did provide
a contributor agreement, right? If so, you need to submit it under the
terms of that agreement, which means that the code will be licensed
under the PSF license (subject to PSF changes to the license). If you
accepted contributions of others into the code, make sure they also
filed a contributor agreement.

Regards,
Martin

From fuzzyman at voidspace.org.uk  Thu Mar 24 01:08:46 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 24 Mar 2011 00:08:46 +0000
Subject: [Python-Dev] I plan to push faulthandler into Python 3.3 in one
 week
In-Reply-To: <4D8A8ABF.6060800@v.loewis.de>
References: <1300924149.1028.15.camel@marge> <4D8A8ABF.6060800@v.loewis.de>
Message-ID: <4D8A8B8E.4080508@voidspace.org.uk>

On 24/03/2011 00:05, "Martin v. L?wis" wrote:
>> What is the procedure to add a new module? Just add the code into
>> Modules and patch setup.py? The module is distributed under the BSD
>> (2-clause) license.
> Also add it to the Visual Studio build process. It either needs to go
> into pythonXY.dll (i.e. pythoncore.vcproj), or into a separate project,
> to be referenced from pcbuild.sln.
>
> Contributions under the BSD license are not acceptable. You did provide
> a contributor agreement, right? If so, you need to submit it under the
> terms of that agreement, which means that the code will be licensed
> under the PSF license (subject to PSF changes to the license). If you
> accepted contributions of others into the code, make sure they also
> filed a contributor agreement.

Although note you are still free to distribute it under whatever license 
you want as an external project (you retain copyright). If you have 
already signed a contributor agreement then there is no need for further 
discussion of how your contributions are licensed for inclusion in 
Python, that is already dealt with.

All the best,

Michael Foord
> Regards,
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From mhammond at skippinet.com.au  Thu Mar 24 01:14:40 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Thu, 24 Mar 2011 11:14:40 +1100
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D8A2F30.8000601@stoneleaf.us>
References: <4D884E08.1020709@skippinet.com.au>	<4D88F4A5.4060701@voidspace.org.uk>	<AANLkTikk=14XmaZdZxE=Xyg4JzMv5Vbn0EBZ6BP=mZuR@mail.gmail.com>	<4D8A1115.40003@voidspace.org.uk>
	<4D8A2F30.8000601@stoneleaf.us>
Message-ID: <4D8A8CF0.2060806@skippinet.com.au>

On 24/03/2011 4:34 AM, Ethan Furman wrote:
> Michael Foord wrote:
>> To be honest I would be happy with registry entries instead as the
>> alternative implementations can then add to their installers (or
>> provide a script) to add the right registry entry.
>
> I'm partial to the config file method myself. I have this vague hope
> where this tool could end up being a shebang-script-launching tool for
> other scripting languages as well.

That is an explicit non-goal for the launcher - but if it happens to be 
able to work that way for you, that's great :)

If you guys (or anyone) would like to agree on some precise rules for 
both the location of the config file and its contents and express this 
as a patch to the PEP text, I have no problem supporting it in the 
implementations.  I'd like to insist that the format of the config file 
was such that the GetPrivateProfileString() Windows function could be 
used to extract the data (eg, only '=' can be used to separate the 
name/value pair, case-insensitive and no support for string 
interpolation) as I have no interest in writing my own config file 
parser in C :)

Cheers,

Mark

From victor.stinner at haypocalc.com  Thu Mar 24 01:36:31 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 24 Mar 2011 01:36:31 +0100
Subject: [Python-Dev] I plan to push faulthandler into Python 3.3 in one
 week
In-Reply-To: <4D8A8ABF.6060800@v.loewis.de>
References: <1300924149.1028.15.camel@marge>  <4D8A8ABF.6060800@v.loewis.de>
Message-ID: <1300926991.1028.26.camel@marge>

Le jeudi 24 mars 2011 ? 01:05 +0100, "Martin v. L?wis" a ?crit :
> > What is the procedure to add a new module? Just add the code into
> > Modules and patch setup.py? The module is distributed under the BSD
> > (2-clause) license.
> 
> Also add it to the Visual Studio build process. It either needs to go
> into pythonXY.dll (i.e. pythoncore.vcproj), or into a separate project,
> to be referenced from pcbuild.sln.

Antoine would like to enable faulthandler by default on fatal error. I
suppose that it would be more easy to do that if the module is a builtin
module, especially if we want to dump the traceback on fatal errors at
*startup* (during Py_InitializeEx).

But we can make it optional, and use a command line option (eg. python
-x faulthandler) or an environment variable to enable it
(PYTHONFAULTHANDLER=1). I am not sure that it is really useful to enable
it *by default*, and some people don't want it enabled by default
because it writes into file descriptor 2 (sys.stderr.fileno()) which may
have been replaced by something else.

Because the module is still a little bit experimental (well, it's stable
but it is not tested by enough people), I would prefer to disable it by
default and have it has an extension (use a dynamic module). But it
doesn't really matter to me :-)

(ok, I will also patch the Visual Studio project)

> Contributions under the BSD license are not acceptable. You did provide
> a contributor agreement, right?

If it is a paper thing, I don't think so. I only sent a paper to the
PSF, but I think that it is different. When I got my commit access one
year ago, I was only asked for a SSH public key. It looks like I will
need to sign this agreement :-)

I can distribute the module under two licenses, I am the only author (I
got two minor contributors).

Victor


From victor.stinner at haypocalc.com  Thu Mar 24 01:41:18 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 24 Mar 2011 01:41:18 +0100
Subject: [Python-Dev] Python 3.3 release schedule posted
In-Reply-To: <imdj8n$dq0$1@dough.gmane.org>
References: <imdj8n$dq0$1@dough.gmane.org>
Message-ID: <1300927278.1028.29.camel@marge>

Le mercredi 23 mars 2011 ? 20:56 +0100, Georg Brandl a ?crit :
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP.  Please let me know if you plan any such changes,
> at any time.  (If they aren't codified in PEP form, we should think about
> whether they should be.)

I am still working on the import machinery to fix last bugs related to
Unicode. So it will be possible to do an useless "import caf?" in Python
3.3, on any platform. But it is not really an huge change (for the user,
but an huge change in the code ;-)).

I will probably add my faulthandler module into 3.3.

Victor


From digitalxero at gmail.com  Thu Mar 24 01:44:23 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Wed, 23 Mar 2011 20:44:23 -0400
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D8A8CF0.2060806@skippinet.com.au>
References: <4D884E08.1020709@skippinet.com.au>
	<4D88F4A5.4060701@voidspace.org.uk>
	<AANLkTikk=14XmaZdZxE=Xyg4JzMv5Vbn0EBZ6BP=mZuR@mail.gmail.com>
	<4D8A1115.40003@voidspace.org.uk> <4D8A2F30.8000601@stoneleaf.us>
	<4D8A8CF0.2060806@skippinet.com.au>
Message-ID: <AANLkTimUZrX=ajQCMSBaQCP2kGQrUsAHXgu=_eDXF33D@mail.gmail.com>

On Wed, Mar 23, 2011 at 8:14 PM, Mark Hammond <mhammond at skippinet.com.au> wrote:
> If you guys (or anyone) would like to agree on some precise rules for both
> the location of the config file and its contents and express this as a patch
> to the PEP text, I have no problem supporting it in the implementations.
> ?I'd like to insist that the format of the config file was such that the
> GetPrivateProfileString() Windows function could be used to extract the data
> (eg, only '=' can be used to separate the name/value pair, case-insensitive
> and no support for string interpolation) as I have no interest in writing my
> own config file parser in C :)

In the user directory much like TortoiseHG adds a murcurial.ini file
to the users directory for basic globa config the launch could look
for a python.ini there and use to to add known paths or version
overrides on a user by user basis.

From turnbull at sk.tsukuba.ac.jp  Thu Mar 24 02:36:06 2011
From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Thu, 24 Mar 2011 10:36:06 +0900
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <imdcc7$2q4$1@dough.gmane.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net> <imdcc7$2q4$1@dough.gmane.org>
Message-ID: <87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>

Tres Seaver writes:

 > On 03/23/2011 01:24 PM, Antoine Pitrou wrote:
 > > On Wed, 23 Mar 2011 10:25:01 -0700
 > > Ethan Furman <ethan at stoneleaf.us> wrote:
 > >>
 > >> I think the use-case has been lost.  Think sprints and multiple push 
 > >> races.

I do, can't speak for others.  So what? *sigh* ... read on.

 > > Well, keep in ming hg is a *distributed* version control system. You
 > > don't have to push your changes right now.

s/push your changes right now/push your changes to the public repo/

 > That doesn't work so well at a sprint, where the point is to maximize
 > the value of precious face-time to get stuff done *now*.

That's where the D in DVCS comes in.  It's a new world, friends.  All
you need to do is bring a $50 wireless router to the sprint, and have
some volunteer set up a shared repo for the sprinters.  Then some
volunteer *later* runs the tests and pilots the patches into the
public repo.  Where's the latency?

N.B.  The repo admin and test-running volunteers can be non-coders.
In fact, the tests can be running concurrently (gives those non-coders
an excuse to attend sprints!), but nobody need wait for the results.

 > Maybe we need to chop the problem up as:

"Violence is the last refuge of the incompetent." ObRef Asimov.<wink>

From jcea at jcea.es  Thu Mar 24 03:06:06 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 24 Mar 2011 03:06:06 +0100
Subject: [Python-Dev] Python 3.3 release schedule posted
In-Reply-To: <imdj8n$dq0$1@dough.gmane.org>
References: <imdj8n$dq0$1@dough.gmane.org>
Message-ID: <4D8AA70E.90304@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/03/11 20:56, Georg Brandl wrote:
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP.

I want to integrate dependence injection in the stdlib, specially in
libs creating sockets. This would be an optional feature.

The idea would be, for instance, that smtplib could call an optional
constructor to create a socket-like object, if some is provided.

That would break the implicit dependency with sockets, reduce
monkey-patching need, and ease testing the libs.

I proposed this on the list like a year ago. Somebody else said he was
planning a PEP... not done yet, I guess.

Digging the archive:
<http://mail.python.org/pipermail/python-dev/2010-April/099237.html>

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYqnDplgi5GaxT1NAQJTxQP/U9dk4x9r9Fbwm7zEzEMydzxqqiY/FF6z
PA52YDRPUgyeiDnhmZwk1f9PqnwYWkgf2qmDi+v0eXLZJYqs/rBEcaY36yP1sgP+
+RrFp4aTpf6oqp7HSwrJMoOS2BmRZxLmzShfKecX+3q33Ix1C1EvcF8F8Yg4P4s6
Pd+jRaGvJRs=
=Ec5o
-----END PGP SIGNATURE-----

From jcea at jcea.es  Thu Mar 24 03:15:39 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 24 Mar 2011 03:15:39 +0100
Subject: [Python-Dev] Workflow proposal
In-Reply-To: <AANLkTi=fKPgGDR4_RJRi4swbzinM1+f_QZsy9HXUS8PR@mail.gmail.com>
References: <4D88DE84.8050209@jcea.es>
	<AANLkTi=fKPgGDR4_RJRi4swbzinM1+f_QZsy9HXUS8PR@mail.gmail.com>
Message-ID: <4D8AA94B.7000204@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/03/11 22:20, Nick Coghlan wrote:
> There's a third option (which is what I've been doing):
> 
> 6. Pull
> 7. Merge the heads on the oldest branch that now has multiple heads
> 8. Merge that branch to the next branch in line as usual.
> 9. Repeat 7-8 until all branches, up to and including default have been merged
> 10. Push.

Then you are merging to the newer branches, commits done by some other
developer that, maybe, doesn't want to merge yet for whatever reason.
For instance, because she is waiting for a buildbot cycle.

Also, you have to deal with whatever problem you have during the merge
yourself (for instance, the API changed and the merge is not trivial),
when this work should be done by the original committer.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYqpS5lgi5GaxT1NAQK/6gP8C6lcTUqnvLE9+szJVLAWzjkwqt8lDCOq
a2Zqi9geOnvUfTYTJgChAL54MZXofzp9Xc/m6bHQV7H9KUuUngcttUkr30De2e4c
410+h9RJFjDBxgpVut+r2jptuH2aOtxaTVt7VLEluO9q8YXmPH1uQV241vtfe3HN
TXopfow/CXA=
=M1WJ
-----END PGP SIGNATURE-----

From fuzzyman at voidspace.org.uk  Thu Mar 24 03:16:26 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 24 Mar 2011 02:16:26 +0000
Subject: [Python-Dev] dependency injection for testing [was Python 3.3
 release schedule posted]
In-Reply-To: <4D8AA70E.90304@jcea.es>
References: <imdj8n$dq0$1@dough.gmane.org> <4D8AA70E.90304@jcea.es>
Message-ID: <4D8AA97A.60601@voidspace.org.uk>

On 24/03/2011 02:06, Jesus Cea wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 23/03/11 20:56, Georg Brandl wrote:
>> For 3.3, I'd like to revive the tradition of listing planned large-scale
>> changes in the PEP.
> I want to integrate dependence injection in the stdlib, specially in
> libs creating sockets. This would be an optional feature.
>
> The idea would be, for instance, that smtplib could call an optional
> constructor to create a socket-like object, if some is provided.
>
> That would break the implicit dependency with sockets, reduce
> monkey-patching need, and ease testing the libs.
>

In general I dislike dependency injection if it's only done for 
testability. With monkey patching (if done right) you can safely test 
Python code without messing with your public interfaces just to make 
code testable.

A clean solution that does monkey patching correctly for us, for use 
within our own tests would be a better solution in my opinion.

All the best,

Michael Foord

> I proposed this on the list like a year ago. Somebody else said he was
> planning a PEP... not done yet, I guess.
>
> Digging the archive:
> <http://mail.python.org/pipermail/python-dev/2010-April/099237.html>
>
> - -- 
> Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
> jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
> jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
> .                              _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQCVAwUBTYqnDplgi5GaxT1NAQJTxQP/U9dk4x9r9Fbwm7zEzEMydzxqqiY/FF6z
> PA52YDRPUgyeiDnhmZwk1f9PqnwYWkgf2qmDi+v0eXLZJYqs/rBEcaY36yP1sgP+
> +RrFp4aTpf6oqp7HSwrJMoOS2BmRZxLmzShfKecX+3q33Ix1C1EvcF8F8Yg4P4s6
> Pd+jRaGvJRs=
> =Ec5o
> -----END PGP SIGNATURE-----
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From fuzzyman at voidspace.org.uk  Thu Mar 24 03:19:03 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 24 Mar 2011 02:19:03 +0000
Subject: [Python-Dev] Python 3.3 release schedule posted
In-Reply-To: <4D8AA70E.90304@jcea.es>
References: <imdj8n$dq0$1@dough.gmane.org> <4D8AA70E.90304@jcea.es>
Message-ID: <4D8AAA17.8070708@voidspace.org.uk>

On 24/03/2011 02:06, Jesus Cea wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 23/03/11 20:56, Georg Brandl wrote:
>> For 3.3, I'd like to revive the tradition of listing planned large-scale
>> changes in the PEP.
> I want to integrate dependence injection in the stdlib, specially in
> libs creating sockets. This would be an optional feature.
>
> The idea would be, for instance, that smtplib could call an optional
> constructor to create a socket-like object, if some is provided.
>
> That would break the implicit dependency with sockets, reduce
> monkey-patching need, and ease testing the libs.
>
> I proposed this on the list like a year ago. Somebody else said he was
> planning a PEP... not done yet, I guess.
>
> Digging the archive:
> <http://mail.python.org/pipermail/python-dev/2010-April/099237.html>

Although from this email it seems like it is for much more than just 
testability, in which case go ahead. :-)

Michael

> - -- 
> Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
> jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
> jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
> .                              _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQCVAwUBTYqnDplgi5GaxT1NAQJTxQP/U9dk4x9r9Fbwm7zEzEMydzxqqiY/FF6z
> PA52YDRPUgyeiDnhmZwk1f9PqnwYWkgf2qmDi+v0eXLZJYqs/rBEcaY36yP1sgP+
> +RrFp4aTpf6oqp7HSwrJMoOS2BmRZxLmzShfKecX+3q33Ix1C1EvcF8F8Yg4P4s6
> Pd+jRaGvJRs=
> =Ec5o
> -----END PGP SIGNATURE-----
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From fuzzyman at voidspace.org.uk  Thu Mar 24 03:20:30 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 24 Mar 2011 02:20:30 +0000
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <AANLkTimUZrX=ajQCMSBaQCP2kGQrUsAHXgu=_eDXF33D@mail.gmail.com>
References: <4D884E08.1020709@skippinet.com.au>	<4D88F4A5.4060701@voidspace.org.uk>	<AANLkTikk=14XmaZdZxE=Xyg4JzMv5Vbn0EBZ6BP=mZuR@mail.gmail.com>	<4D8A1115.40003@voidspace.org.uk>
	<4D8A2F30.8000601@stoneleaf.us>	<4D8A8CF0.2060806@skippinet.com.au>
	<AANLkTimUZrX=ajQCMSBaQCP2kGQrUsAHXgu=_eDXF33D@mail.gmail.com>
Message-ID: <4D8AAA6E.3020002@voidspace.org.uk>

On 24/03/2011 00:44, Dj Gilcrease wrote:
> On Wed, Mar 23, 2011 at 8:14 PM, Mark Hammond<mhammond at skippinet.com.au>  wrote:
>> If you guys (or anyone) would like to agree on some precise rules for both
>> the location of the config file and its contents and express this as a patch
>> to the PEP text, I have no problem supporting it in the implementations.
>>   I'd like to insist that the format of the config file was such that the
>> GetPrivateProfileString() Windows function could be used to extract the data
>> (eg, only '=' can be used to separate the name/value pair, case-insensitive
>> and no support for string interpolation) as I have no interest in writing my
>> own config file parser in C :)
> In the user directory much like TortoiseHG adds a murcurial.ini file
> to the users directory for basic globa config the launch could look
> for a python.ini there and use to to add known paths or version
> overrides on a user by user basis.

A single global location (for shared installs) or a single per-user 
location for per-user installs would seem to be sensible if the config 
file route is chosen.

All the best,

Michael Foord

> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From stephen at xemacs.org  Thu Mar 24 03:40:31 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 24 Mar 2011 11:40:31 +0900
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <AANLkTimNL3hu6TEpPPyzPAc3=A-DsaT6-i9yNvnXmNt9@mail.gmail.com>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
	<20110323150810.38efce46@pitrou.net>
	<20110323111850.52c10754@neurotica.wooz.org>
	<20110323170922.330638c8@pitrou.net>
	<20110323131047.48056956@neurotica.wooz.org>
	<imdne2$2dc$1@dough.gmane.org>
	<AANLkTimNL3hu6TEpPPyzPAc3=A-DsaT6-i9yNvnXmNt9@mail.gmail.com>
Message-ID: <87oc518cm8.fsf@uwakimon.sk.tsukuba.ac.jp>

Nick Coghlan writes:

 > (i.e. less than a minute) because you're going to be running it three
 > times in quick succession (perhaps 3 if it applies to 2.7 as well).

Nobody says it's got to be *you* that runs the tests, just that they
need to be run before pushing to public repo.

Here's a simple way to deal with this: have two repo URLs,
"pull-source" and "push-target".  Under (currently) normal commit
pace, "pull-source" and "push-target" resolve to the same physical
repo, the other repo(s) sync(s) to that one in the background (or they
could be cloned at need, in advance of the sprint).  Sprinters clone
from "push-target", non-sprinters from "pull-source".

When sprinting, change "pull-source" to resolve to a mirror, and close
it to commits, protecting the non-sprinters from instability.  Let
the sprinters have at it, and start a test process walking the commits
in "push-target", testing each one.  As each commit is validated,
merge it to a third repo "validated" (could be a named branch, but I
suspect named branches would suck for this purpose, because eventually
you want these commits on the default branch or the appropriate named
branch).

So far, so good.  Sprinters don't need to reconfigure their
workspaces, they don't need to run the full test suite before merging.
The main issue remaining is what if the tests fail?  Now you have to
fix the commit and do a merge dance.  I'm not sure what the best way
to do this is.

My thinking if merges are used is that you *need* to

1. rewind the workspace to the busted commit or just before it (ie,
   keeping the changes for the busted commit)
2. fix it
3. commit, creating a new head
4. rebase children of the busted commit on the new head (*without*
   destroying the original branch
5. merge the original branch into the rebased branch
6. point the test process at the new tip

Rationale:

1. The test process has not tested children of the busted commit, you
   can't just commit the fix on top -- it will most likely fail the
   same way for each child until reaching the fix.
3. See 1.
4. See 1 for "rebase".  You want to keep the original branch because
   other sprinters' workspace configs know about it, and will get very
   confused if it disappears from the push-target repo.
5. This forces other sprinters to update before pushing, thus
   incorporating the fix in their work, and getting them back on the
   same page as the test process.
6. Commits don't know their children, so you'll have to reinitialize
   the test process to walk the branch backward.

I think the process 1-6 is excessively complex for most contributors,
and the rebase itself risks conflicts.  So I'm not entirely happy with
this.

Another possibility would be to cherrypick commits into the
"validated" repo.  This might be best as the test process could do it
automatically, and simply delete anything that causes a test failure
or merge conflict.  Sprinters whose commits don't make it will have to
come back and fix them later.  The test bot could tag the busted
commits "FAILED".  This has the disadvantage that commits could fall
on the floor if sprinters are inattentive.  It also loses branch
structure, and if (say) the 3rd commit in a series is busted, you
want to back out 1 and 2 as well.  (It's not always necessary, but I
don't see how the 'bot can know which is which.)

And of course, step 7: when all the problems are resolved, reset both
push-target and pull-source to resolve to the validated repo.
Sprinters will have to re-clone.

Step 8: convert the old push-target repo to hex as ASCII armor, and
mail it to Barry Warsaw and Ben Finney because they might want to look
at branch history.<wink>

I suspect this is more or less what the Bazaar project's PQM does.


From tjreedy at udel.edu  Thu Mar 24 03:54:09 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 23 Mar 2011 22:54:09 -0400
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>	<20110323143123.4be80686@pitrou.net>	<19850.2977.894754.352174@montanaro.dyndns.org>	<20110323115156.25bd2845@neurotica.wooz.org>	<19850.9561.366432.287634@montanaro.dyndns.org>	<4D8A2CED.7080504@stoneleaf.us>	<20110323182400.04ce46cf@pitrou.net>
	<imdcc7$2q4$1@dough.gmane.org>
	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <imebog$e6i$1@dough.gmane.org>

On 3/23/2011 9:36 PM, Stephen J. Turnbull wrote:

> That's where the D in DVCS comes in.  It's a new world, friends.  All
> you need to do is bring a $50 wireless router to the sprint, and have
> some volunteer set up a shared repo for the sprinters.  Then some
> volunteer *later* runs the tests and pilots the patches into the
> public repo.  Where's the latency?
>
> N.B.  The repo admin and test-running volunteers can be non-coders.
> In fact, the tests can be running concurrently (gives those non-coders
> an excuse to attend sprints!), but nobody need wait for the results.

If the push-target is a clone at, for instance, hg.python, the tester 
does not even need to be at the sprint site. Skype can be used for 
occasional feedback to authors.

-- 
Terry Jan Reedy


From mhammond at skippinet.com.au  Thu Mar 24 04:02:04 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Thu, 24 Mar 2011 14:02:04 +1100
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D8AAA6E.3020002@voidspace.org.uk>
References: <4D884E08.1020709@skippinet.com.au>	<4D88F4A5.4060701@voidspace.org.uk>	<AANLkTikk=14XmaZdZxE=Xyg4JzMv5Vbn0EBZ6BP=mZuR@mail.gmail.com>	<4D8A1115.40003@voidspace.org.uk>
	<4D8A2F30.8000601@stoneleaf.us>	<4D8A8CF0.2060806@skippinet.com.au>
	<AANLkTimUZrX=ajQCMSBaQCP2kGQrUsAHXgu=_eDXF33D@mail.gmail.com>
	<4D8AAA6E.3020002@voidspace.org.uk>
Message-ID: <4D8AB42C.9000904@skippinet.com.au>

On 24/03/2011 1:20 PM, Michael Foord wrote:
> On 24/03/2011 00:44, Dj Gilcrease wrote:
>> On Wed, Mar 23, 2011 at 8:14 PM, Mark
>> Hammond<mhammond at skippinet.com.au> wrote:
>>> If you guys (or anyone) would like to agree on some precise rules for
>>> both
>>> the location of the config file and its contents and express this as
>>> a patch
>>> to the PEP text, I have no problem supporting it in the implementations.
>>> I'd like to insist that the format of the config file was such that the
>>> GetPrivateProfileString() Windows function could be used to extract
>>> the data
>>> (eg, only '=' can be used to separate the name/value pair,
>>> case-insensitive
>>> and no support for string interpolation) as I have no interest in
>>> writing my
>>> own config file parser in C :)
>> In the user directory much like TortoiseHG adds a murcurial.ini file
>> to the users directory for basic globa config the launch could look
>> for a python.ini there and use to to add known paths or version
>> overrides on a user by user basis.
>
> A single global location (for shared installs) or a single per-user
> location for per-user installs would seem to be sensible if the config
> file route is chosen.

My concern with that would be that an administrator may install Python, 
but the user may not have write access to that global location, leaving 
that user unable to customize the launcher.  OTOH, that is how things 
work on Unix today - such users could not change what /usr/bin/python 
points to).  Always using a per-user location would mean there is no 
opportunity to have global settings, but it is unclear which is the 
lesser of 2 evils.  Supporting both might even be reasonable if the 
rules are very straightforward.

I'd still very much like to see the change to the wording of the PEP to 
describe this feature though, otherwise I fear different people will 
have different assumptions about exactly what it does and how it does it...

Cheers,

Mark

From jcea at jcea.es  Thu Mar 24 04:19:58 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 24 Mar 2011 04:19:58 +0100
Subject: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I
 am now lost - committed, pulled, merged, what is "collapse"?)
In-Reply-To: <20110323095337.26d9ddb2@neurotica.wooz.org>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>	<20110323143123.4be80686@pitrou.net>
	<20110323095337.26d9ddb2@neurotica.wooz.org>
Message-ID: <4D8AB85E.2050007@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/03/11 14:53, Barry Warsaw wrote:
> If 'make quicktest' were actually quick - say could run in 1/10 the current
> time, it could be used as a smoke test for merge-dance cases.  OTOH, running
> some localized test for the feature or bug you're trying to land might be
> enough.

Would be amazing if the test system could detect which files were
changed and only do the tests that cover them. Not a 100% safety net,
provided by the full test suite, but not a bad start...

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYq4Xplgi5GaxT1NAQL+EwP/bcaTceSpUB8xg4mRTixb9Ym1VFGG0lRK
VqgAXQ3Otl2/MnxS7r79aPrC5QNv8tcgMSN1cQ1Em7ulbJvgAXZoI58sR/IUZeD5
uWiH6mYS++3jnw/J5pZsktwQxnLUELnQtEYbCB3ZaAf+9oF4/tQukIpUFivYDez3
mrUw9td7qVA=
=WCso
-----END PGP SIGNATURE-----

From brian.curtin at gmail.com  Thu Mar 24 05:35:49 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Wed, 23 Mar 2011 23:35:49 -0500
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <AANLkTim7snnOOrsbxJrU9mFr4S8S+xwZaY9iCCQKVMDZ@mail.gmail.com>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net>
	<AANLkTim7snnOOrsbxJrU9mFr4S8S+xwZaY9iCCQKVMDZ@mail.gmail.com>
Message-ID: <AANLkTik2-_7fwiEdBoWvtdZWVkv06+JBjd7Oz8jYV5SV@mail.gmail.com>

On Wed, Mar 23, 2011 at 16:27, Simon Cross <hodgestar+pythondev at gmail.com>wrote:

> On Wed, Mar 23, 2011 at 7:24 PM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> > On Wed, 23 Mar 2011 10:25:01 -0700
> > Ethan Furman <ethan at stoneleaf.us> wrote:
> >>
> >> I think the use-case has been lost.  Think sprints and multiple push
> >> races.  No one is arguing that the smoke-test should be the default, but
> >> seriously, are you willing to spend an hour or more re-running the
> >> complete suite of tests six, eight, or 12 times because of push races in
> >> a sprint?  I can see losing a good portion of your sprinting day.
>
> Our sprint model has been to set up a throw-away sprint repository
> somewhere accessible (github, bitbucket, wherever) and have everyone
> commit madly to it however they want. Afterwards a few brace souls
> take the result and commit it to the master repository in a more
> orderly fashion.


While we're talking about sprints, I just wanted to put out a reminder that
the PSF wants to support more of them. See www.pythonsprints.com and/or
email sprints at python.org

(sorry for the OT)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/cfefee3c/attachment.html>

From ericsnowcurrently at gmail.com  Thu Mar 24 05:38:48 2011
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Wed, 23 Mar 2011 22:38:48 -0600
Subject: [Python-Dev] [Python-checkins] r88796 - in
 sandbox/trunk/pep362: pep362.py setup.py test_pep362.py tests
In-Reply-To: <3Pw46Y065Fz7Lln@mail.python.org>
References: <3Pw46Y065Fz7Lln@mail.python.org>
Message-ID: <AANLkTikdPnhHn70usyYxAM+WmefL+Ko3MZmn_jaAZPNi@mail.gmail.com>

Shouldn't the Signature class also support building from args and not just a
function object? Then I could use a Signature object when building a
function object, or vice versa.  Having the ability to validate args/kwargs
against a Signature object, sort of like provided by the bind method, will
be helpful, particularly with the decorator use case.  What does the tuple
form of Parameter.name represent?  Did you come to any conclusion on the
open issues in the PEP?

With the exec_closure stuff I have been looking pretty closely at
function-related C-API capability that might be worth exposing better in
python, and Signature objects would help facilitate in a much clearer way.
 Not only that, but even though CPython won't use Signature objects behind
the scenes, they can help to make the internal operations of Python more
clear by exposing the underlying mechanisms in pure python.  For example,
with a validate method you could express how args and kwargs are mapped onto
the different parts of the code object which correspond to the parts of the
Signature object.

I am looking forward to the inclusion of the function signature stuff in
3.3.

-eric


On Wed, Mar 23, 2011 at 3:39 PM, brett.cannon <python-checkins at python.org>wrote:

> Author: brett.cannon
> Date: Wed Mar 23 22:39:32 2011
> New Revision: 88796
>
> Log:
> Update code for future inclusion in Python 3.3 (when I get around to it).
>
> Added:
>   sandbox/trunk/pep362/test_pep362.py
>      - copied, changed from r88415,
> /sandbox/trunk/pep362/tests/test_pep362.py
> Removed:
>   sandbox/trunk/pep362/setup.py
>   sandbox/trunk/pep362/tests/
> Modified:
>   sandbox/trunk/pep362/   (props changed)
>   sandbox/trunk/pep362/pep362.py
>
> Modified: sandbox/trunk/pep362/pep362.py
>
> ==============================================================================
> --- sandbox/trunk/pep362/pep362.py      (original)
> +++ sandbox/trunk/pep362/pep362.py      Wed Mar 23 22:39:32 2011
> @@ -8,7 +8,7 @@
>     pass
>
>
> -class Parameter(object):
> +class Parameter:
>
>     """Represent a parameter in a function signature.
>
> @@ -31,8 +31,9 @@
>
>     """
>
> -    def __init__(self, name, position, has_default=False,
> default_value=None,
> -                 keyword_only=False, has_annotation=False,
> annotation=None):
> +    def __init__(self, name, position, *, has_default=False,
> +                 default=None, keyword_only=False, has_annotation=False,
> +                 annotation=None):
>         """Initialize a Parameter instance.
>
>         For has_* arguments, if they are False then the corresponding *
> @@ -42,13 +43,13 @@
>         self.name = name
>         self.position = position
>         if has_default:
> -            self.default_value = default_value
> +            self.default = default
>         self.keyword_only = keyword_only
>         if has_annotation:
>             self.annotation = annotation
>
>
> -class Signature(object):
> +class Signature:
>
>     """Object to represent the signature of a function/method.
>
> @@ -74,39 +75,19 @@
>
>     def __init__(self, func):
>         """Initialize from a function or method object."""
> -        if hasattr(func, 'im_func'):
> -            func = func.im_func
> -        try:
> -            func_code = func.__code__
> -        except AttributeError:
> -            # Compatibility for versions < 2.6.
> -            func_code = func.func_code
> -
> +        func_code = func.__code__
>         self.name = func.__name__
> -
> -        try:
> -            # Unneeded once 2.x support is removed; can easily get info
> the
> -            #  "hard" way.
> -            argspec = inspect.getfullargspec(func)[:4]
> -        except AttributeError:
> -            # Needed only for tuple parameters.
> -            argspec = inspect.getargspec(func)
> +        # XXX replace with own implementation
> +        argspec = inspect.getfullargspec(func)[:4]
>         parameters = {}
>
>         # Parameter information.
>         pos_count = func_code.co_argcount
> -        if hasattr(func_code, 'co_kwonlyargcount'):
> -            keyword_only_count = func_code.co_kwonlyargcount
> -        else:
> -            keyword_only_count = 0
> +        keyword_only_count = func_code.co_kwonlyargcount
>         positional = argspec[0]
>         keyword_only = func_code.co_varnames[pos_count:
>
> pos_count+keyword_only_count]
> -        try:
> -            fxn_defaults = func.__defaults__
> -        except AttributeError:
> -            # Deal with old names prior to 2.6.
> -            fxn_defaults = func.func_defaults
> +        fxn_defaults = func.__defaults__
>         if fxn_defaults:
>             pos_default_count = len(fxn_defaults)
>         else:
> @@ -126,7 +107,7 @@
>             has_annotation, annotation = self._find_annotation(func, name)
>             default_value = fxn_defaults[offset]
>             param = Parameter(name, offset+non_default_count,
> -                                has_default=True,
> default_value=default_value,
> +                                has_default=True, default=default_value,
>                                 has_annotation=has_annotation,
>                                 annotation=annotation)
>             parameters[name] = param
> @@ -134,16 +115,14 @@
>         for offset, name in enumerate(keyword_only):
>             has_annotation, annotation = self._find_annotation(func, name)
>             has_default, default_value = False, None
> -            # hasattr check only needed for versions < 2.6.
> -            if (hasattr(func, '__kwdefaults__') and func.__kwdefaults__
> and
> -                    name in func.__kwdefaults__):
> +            if func.__kwdefaults__ and name in func.__kwdefaults__:
>                 has_default = True
>                 default_value = func.__kwdefaults__[name]
>             param = Parameter(name, offset+pos_count, keyword_only=True,
> -                                has_default=has_default,
> -                                default_value=default_value,
> -                                has_annotation=has_annotation,
> -                                annotation=annotation)
> +                              has_default=has_default,
> +                              default=default_value,
> +                              has_annotation=has_annotation,
> +                              annotation=annotation)
>             parameters[name] = param
>         # Variable parameters.
>         index = pos_count + keyword_only_count
> @@ -172,9 +151,8 @@
>         self._parameters = parameters
>
>         # Return annotation.
> -        if hasattr(func, '__annotations__'):
> -            if 'return' in func.__annotations__:
> -                self.return_annotation = func.__annotations__['return']
> +        if 'return' in func.__annotations__:
> +            self.return_annotation = func.__annotations__['return']
>
>     def __getitem__(self, key):
>         return self._parameters[key]
> @@ -186,10 +164,9 @@
>         """Return True if an annotation exists for the named parameter
> along
>         with its annotation, else return False and None."""
>         has_annotation, annotation = False, None
> -        if hasattr(func, '__annotations__'):
> -            if name in func.__annotations__:
> -                has_annotation = True
> -                annotation = func.__annotations__[name]
> +        if name in func.__annotations__:
> +            has_annotation = True
> +            annotation = func.__annotations__[name]
>         return has_annotation, annotation
>
>     def _convert_name(self, name):
> @@ -234,7 +211,7 @@
>                     break
>                 else:
>                     raise BindError("too many positional arguments")
> -            self._tuple_bind(bindings, param.name, position_arg)
> +            bindings[param.name] = position_arg
>             args = args[1:]
>         # Keyword arguments & default values.
>         else:
> @@ -247,9 +224,8 @@
>                     except KeyError:
>                         raise BindError("%r unbound" % param_name)
>                 else:
> -                    if hasattr(positional_param, 'default_value'):
> -                        self._tuple_bind(bindings, param_name,
> -
>  positional_param.default_value)
> +                    if hasattr(positional_param, 'default'):
> +                        bindings[param_name] = positional_param.default
>                     else:
>                         raise BindError("%r parameter lacking default
> value" %
>                                         param_name)
> @@ -276,39 +252,14 @@
>         # Keyword-only default values.
>         else:
>             for name, param in keyword_only.items():
> -                if hasattr(param, 'default_value'):
> -                    bindings[name] = param.default_value
> +                if hasattr(param, 'default'):
> +                    bindings[name] = param.default
>                 else:
>                     raise BindError("%s parameter lacking a default value"
> %
>                                     name)
>
>         return bindings
>
> -    def _tuple_bind(self, bindings, possible_tuple, value):
> -        """Where a tuple could be a parameter, handle binding the values
> to the
> -        tuple and storing into the bindings mapping."""
> -        if not isinstance(possible_tuple, tuple):
> -            bindings[possible_tuple] = value
> -        else:
> -            # Need to make sure that value is as long as the parameter,
> but not
> -            # vice-versa.
> -            error_msg = "not enough values to unpack for %r"
> -            tuple_iter = iter(possible_tuple)
> -            try:
> -                value_iter = iter(value)
> -            except TypeError:
> -                raise BindError(error_msg % possible_tuple)
> -            while True:
> -                try:
> -                    sub_param = tuple_iter.next()
> -                except StopIteration:
> -                    break
> -                try:
> -                    sub_value = value_iter.next()
> -                except StopIteration:
> -                    raise BindError(error_msg % possible_tuple)
> -                self._tuple_bind(bindings, sub_param, sub_value)
> -
>
>  def signature(func):
>     """Return a Signature object for the function or method.
> @@ -318,15 +269,9 @@
>     attribute if possible (but is not required).
>
>     """
> -    if hasattr(func, 'im_func'):
> -        func = func.im_func
> -    sig = Signature(func)
> -    if not hasattr(func, '__signature__'):
> -        try:
> -            func.__signature__ = sig
> -        except AttributeError:
> -            pass
> -    else:
> -        sig = func.__signature__
> -
> -    return sig
> +    try:
> +        return func.__signature__
> +    except AttributeError:
> +        sig = Signature(func)
> +        func.__signature__ = sig
> +        return sig
>
> Deleted: sandbox/trunk/pep362/setup.py
>
> ==============================================================================
> --- sandbox/trunk/pep362/setup.py       Wed Mar 23 22:39:32 2011
> +++ (empty file)
> @@ -1,25 +0,0 @@
> -from distutils.core import setup
> -
> -setup(
> -        # Package metadata.
> -        name='pep362',
> -        version='0.6.2',
> -        description='Implementation of PEP 362 (Function Signature
> objects)',
> -        author='Brett Cannon',
> -        author_email='brett at python.org',
> -        url='http://svn.python.org/view/sandbox/trunk/pep362/',
> -        # Files.
> -        py_modules=['pep362', 'examples'],
> -        packages=['tests'],
> -        data_files=['README'],
> -        classifiers=[
> -            'Programming Language :: Python :: 2',
> -            'Programming Language :: Python :: 2.5',
> -            'Programming Language :: Python :: 2.6',
> -            'Programming Language :: Python :: 2.7',
> -            'Programming Language :: Python :: 3',
> -            'Programming Language :: Python :: 3.0',
> -            'Programming Language :: Python :: 3.1',
> -            'Programming Language :: Python :: 3.2',
> -        ]
> -    )
>
> Copied: sandbox/trunk/pep362/test_pep362.py (from r88415,
> /sandbox/trunk/pep362/tests/test_pep362.py)
>
> ==============================================================================
> --- /sandbox/trunk/pep362/tests/test_pep362.py  (original)
> +++ sandbox/trunk/pep362/test_pep362.py Wed Mar 23 22:39:32 2011
> @@ -1,23 +1,49 @@
>  import pep362
>
>  import unittest
> -from tests import pep362_fodder
> -try:
> -    from tests import pep362_py2_fodder
> -    from test import test_support
> -except SyntaxError:
> -    from tests import pep362_py3k_fodder
> -    from test import support as test_support
> +from test import support as test_support
>  from sys import version_info
>
>
> -def version_specific(major_number):
> -    def inner(fxn):
> -        if version_info[0] == major_number:
> -            return fxn
> -        else:
> -            return lambda self: self
> -    return inner
> +def no_args():
> +    pass
> +
> +def var_args(*args):
> +    pass
> +
> +def var_kw_args(**kwargs):
> +    pass
> +
> +def no_default_args(a):
> +    pass
> +
> +def default_args(a=42):
> +    pass
> +
> +def keyword_only(*, a):
> +    pass
> +
> +def keyword_only_default(*, a=42):
> +    pass
> +
> +def arg_annotation(a:int):
> +    pass
> +
> +def arg_annotation_default(a:int=42):
> +    pass
> +
> +def arg_annotation_var(*args:int, **kwargs:str):
> +    pass
> +
> +def arg_annotation_keyword_only(*, a:int):
> +    pass
> +
> +def return_annotation() -> int:
> +    pass
> +
> +def all_args(a:int, d=0, *args:int,
> +                g:int, h:int=8, **kwargs:int) -> int:
> +    return a, d, g, h, args, kwargs
>
>
>  class ParameterObjectTests(unittest.TestCase):
> @@ -41,13 +67,14 @@
>         self.assertEqual(param.position, pos)
>
>     def test_default_values(self):
> -        # Testing that 'default_value' is not set is handled in the
> testing of
> +        # Testing that 'default' is not set is handled in the testing of
>         # that attribute.
>         default_value = 42
> -        param = pep362.Parameter('_', 0, True, default_value)
> -        self.assertEqual(param.default_value, default_value)
> -        param = pep362.Parameter('_', 0, False)
> -        self.assertTrue(not hasattr(param, 'default_value'))
> +        param = pep362.Parameter('_', 0, has_default=True,
> +                                 default=default_value)
> +        self.assertEqual(param.default, default_value)
> +        param = pep362.Parameter('_', 0, has_default=False)
> +        self.assertTrue(not hasattr(param, 'default'))
>
>     def test_keyword_only(self):
>         # Setting the value for keyword_only should create an attribute.
> @@ -70,21 +97,21 @@
>     def test_getitem(self):
>         # __getitem__() should return the Parameter object for the name
>         # parameter.
> -        sig = pep362.Signature(pep362_fodder.default_args)
> +        sig = pep362.Signature(default_args)
>         self.assertTrue(sig['a'])
>         param = sig['a']
>         self.assertTrue(param.name, 'a')
>
>     def test_iter(self):
>         # The iterator should return all Parameter objects in the proper
> order.
> -        sig = pep362.Signature(pep362_fodder.default_args)
> +        sig = pep362.Signature(default_args)
>         params = list(sig)
>         self.assertEqual(len(params), 1)
>         self.assertEqual(params[0].name, 'a')
>
>     def test_no_args(self):
>         # Test a function with no arguments.
> -        sig = pep362.Signature(pep362_fodder.no_args)
> +        sig = pep362.Signature(no_args)
>         self.assertEqual('no_args', sig.name)
>         self.assertTrue(not sig.var_args)
>         self.assertTrue(not sig.var_kw_args)
> @@ -92,115 +119,87 @@
>
>     def test_var_args(self):
>         # Test the var_args attribute.
> -        sig = pep362.Signature(pep362_fodder.var_args)
> +        sig = pep362.Signature(var_args)
>         self.assertEqual('args', sig.var_args)
>         self.assertEqual(0, len(list(sig)))
> -        sig = pep362.Signature(pep362_fodder.no_args)
> +        sig = pep362.Signature(no_args)
>         self.assertEqual('', sig.var_args)
>
>     def test_var_kw_args(self):
>         # Test the var_kw_args attribute and annotations.
> -        sig = pep362.Signature(pep362_fodder.var_kw_args)
> +        sig = pep362.Signature(var_kw_args)
>         self.assertEqual('var_kw_args', sig.name)
>         self.assertEqual('kwargs', sig.var_kw_args)
>         self.assertEqual(0, len(list(sig)))
> -        sig = pep362.Signature(pep362_fodder.no_args)
> +        sig = pep362.Signature(no_args)
>         self.assertEqual('', sig.var_kw_args)
>
>     def test_parameter_positional(self):
>         # A function with positional arguments should work.
> -        sig = pep362.Signature(pep362_fodder.no_default_args)
> +        sig = pep362.Signature(no_default_args)
>         self.assertEqual('no_default_args', sig.name)
>         param = sig['a']
>         self.assertEqual('a', param.name)
>         self.assertEqual(0, param.position)
> -        self.assertTrue(not hasattr(param, 'default_value'))
> +        self.assertTrue(not hasattr(param, 'default'))
>
>     def test_parameter_default(self):
>         # Default parameters for a function should work.
> -        sig = pep362.Signature(pep362_fodder.default_args)
> +        sig = pep362.Signature(default_args)
>         self.assertEqual('default_args', sig.name)
>         param = sig['a']
>         self.assertEqual('a', param.name)
>         self.assertEqual(0, param.position)
> -        self.assertEqual(42, param.default_value)
> -
> -    @version_specific(2)
> -    def test_parameter_tuple(self):
> -        # A function with a tuple as a parameter should work.
> -        sig = pep362.Signature(pep362_py2_fodder.tuple_args)
> -        self.assertEqual('tuple_args', sig.name)
> -        param = list(sig)[0]
> -        self.assertTrue(isinstance(param.name, tuple))
> -        self.assertEqual(('a', ('b',)), param.name)
> -        self.assertEqual(0, param.position)
> -        self.assertTrue(not hasattr(param, 'default_value'))
> +        self.assertEqual(42, param.default)
>
> -    @version_specific(2)
> -    def test_parameter_tuple_default(self):
> -        # A default argument for a tuple parameter needs to work.
> -        sig = pep362.Signature(pep362_py2_fodder.default_tuple_args)
> -        self.assertEqual('default_tuple_args', sig.name)
> -        param = list(sig)[0]
> -        self.assertEqual(('a', ('b',)), param.name)
> -        self.assertEqual(0, param.position)
> -        self.assertEqual((1, (2,)), param.default_value)
> -
> -    @version_specific(3)
>     def test_keyword_only(self):
>         # Is a function containing keyword-only parameters handled
> properly?
> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only)
> +        sig = pep362.Signature(keyword_only)
>         param = sig['a']
>         self.assertEqual(param.name, 'a')
>         self.assertTrue(param.keyword_only)
>         self.assertEqual(param.position, 0)
>
> -    @version_specific(3)
>     def test_keyword_only_default(self):
>         # Default arguments can work for keyword-only parameters.
> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only_default)
> +        sig = pep362.Signature(keyword_only_default)
>         param = sig['a']
>         self.assertEqual(param.name, 'a')
>         self.assertTrue(param.keyword_only)
>         self.assertEqual(param.position, 0)
> -        self.assertEqual(param.default_value, 42)
> +        self.assertEqual(param.default, 42)
>
> -    @version_specific(3)
>     def test_annotations(self):
>         # Make sure the proper annotation is found.
> -        sig = pep362.Signature(pep362_py3k_fodder.arg_annotation)
> +        sig = pep362.Signature(arg_annotation)
>         param = sig['a']
>         self.assertEqual(param.name, 'a')
>         self.assertEqual(param.annotation, int)
>
> -    @version_specific(3)
>     def test_annotations_default(self):
>         # Annotations with a default value should work.
> -        sig = pep362.Signature(pep362_py3k_fodder.arg_annotation_default)
> +        sig = pep362.Signature(arg_annotation_default)
>         param = sig['a']
>         self.assertEqual(param.name, 'a')
>         self.assertEqual(param.annotation, int)
> -        self.assertEqual(param.default_value, 42)
> +        self.assertEqual(param.default, 42)
>
> -    @version_specific(3)
>     def test_annotation_keyword_only(self):
>         # Keyword-only parameters can have an annotation.
> -        sig =
> pep362.Signature(pep362_py3k_fodder.arg_annotation_keyword_only)
> +        sig = pep362.Signature(arg_annotation_keyword_only)
>         param = sig['a']
>         self.assertEqual(param.name, 'a')
>         self.assertEqual(param.annotation, int)
>         self.assertTrue(param.keyword_only)
>
> -    @version_specific(3)
>     def test_return_annotation(self):
>         # The return value annotation.
> -        sig = pep362.Signature(pep362_py3k_fodder.return_annotation)
> +        sig = pep362.Signature(return_annotation)
>         self.assertEqual(sig.return_annotation, int)
>
> -    @version_specific(3)
>     def test_var_annotations(self):
>         # Annotation on variable arguments (*args & **kwargs).
> -        sig = pep362.Signature(pep362_py3k_fodder.arg_annotation_var)
> +        sig = pep362.Signature(arg_annotation_var)
>         self.assertEqual(sig.var_annotations[sig.var_args], int)
>         self.assertEqual(sig.var_annotations[sig.var_kw_args], str)
>
> @@ -224,14 +223,14 @@
>     """Test Signature.bind()."""
>
>     def test_no_parameters(self):
> -        sig = pep362.Signature(pep362_fodder.no_args)
> +        sig = pep362.Signature(no_args)
>         binding = sig.bind()
>         self.assertEqual({}, binding)
>         self.assertRaises(pep362.BindError, sig.bind, 42)
>         self.assertRaises(pep362.BindError, sig.bind, a=0)
>
>     def test_var_parameters(self):
> -        sig = pep362.Signature(pep362_fodder.var_args)
> +        sig = pep362.Signature(var_args)
>         binding = sig.bind(0, 1, 2)
>         self.assertEqual({'args':(0, 1, 2)}, binding)
>         binding = sig.bind()
> @@ -239,7 +238,7 @@
>         self.assertRaises(pep362.BindError, sig.bind, a=0)
>
>     def test_var_kw_parameters(self):
> -        sig = pep362.Signature(pep362_fodder.var_kw_args)
> +        sig = pep362.Signature(var_kw_args)
>         binding = sig.bind(a=0)
>         self.assertEqual({'kwargs':{'a':0}}, binding)
>         binding = sig.bind()
> @@ -247,7 +246,7 @@
>         self.assertRaises(pep362.BindError, sig.bind, 42)
>
>     def test_positional_parameters(self):
> -        sig = pep362.Signature(pep362_fodder.no_default_args)
> +        sig = pep362.Signature(no_default_args)
>         binding = sig.bind(42)
>         self.assertEqual({'a':42}, binding)
>         binding = sig.bind(a=42)
> @@ -257,7 +256,7 @@
>         self.assertRaises(pep362.BindError, sig.bind, b=0)
>
>     def test_keyword_parameters(self):
> -        sig = pep362.Signature(pep362_fodder.default_args)
> +        sig = pep362.Signature(default_args)
>         binding = sig.bind()
>         self.assertEqual({'a':42}, binding)
>         binding = sig.bind(0)
> @@ -268,73 +267,24 @@
>         self.assertRaises(pep362.BindError, sig.bind, a=0, b=1)
>         self.assertRaises(pep362.BindError, sig.bind, b=1)
>
> -    @version_specific(2)
> -    def test_tuple_parameter(self):
> -        sig = pep362.Signature(pep362_py2_fodder.tuple_args)
> -        arg = (1, ((2,),))
> -        binding = sig.bind(arg)
> -        self.assertEqual({'a':1, 'b':(2,)}, binding)
> -        self.assertRaises(pep362.BindError, sig.bind, (1,2,3))
> -        self.assertRaises(pep362.BindError, sig.bind, (1, 2))
> -
> -    @version_specific(2)
> -    def test_default_tuple_parameter(self):
> -        sig = pep362.Signature(pep362_py2_fodder.default_tuple_args)
> -        binding = sig.bind()
> -        self.assertEqual({'a':1, 'b':2}, binding)
> -        arg = (0, (1,))
> -        binding = sig.bind(arg)
> -        self.assertEqual({'a':0, 'b':1}, binding)
> -
> -    @version_specific(2)
> -    def test_py2_all_args(self):
> -        sig = pep362.Signature(pep362_py2_fodder.all_args)
> -        # a, (b, (c,)), d=0, (e, (f,))=(4, (5,)), *g, **h
> -        # name, position, has_default, default value
> -        expect = (('a', 0, False, None),
> -                    (('b', ('c',)), 1, False, None),
> -                    ('d', 2, True, 0),
> -                    (('e', ('f',)), 3, True, (4, (5,))))
> -        self.assertEqual(len(list(sig)), len(expect))
> -        for param, check in zip(list(sig), expect):
> -            name, pos, has_default, default_value = check
> -            self.assertEqual(param.name, name)
> -            self.assertEqual(param.position, pos)
> -            if has_default:
> -                self.assertEqual(param.default_value, default_value)
> -            else:
> -                self.assertTrue(not hasattr(param, 'default_value'))
> -            self.assertTrue(not param.keyword_only)
> -            self.assertTrue(not hasattr(param, 'annotation'))
> -        self.assertEqual(sig.var_args, 'g')
> -        self.assertEqual(sig.var_kw_args, 'h')
> -        self.assertEqual(len(sig.var_annotations), 0)
> -        binding = sig.bind(0, (1, (2,)), d=3, i=7)
> -        expected = {'a':0, 'b':1, 'c':2, 'd':3, 'e':4, 'f':5, 'g':tuple(),
> -                    'h':{'i':7}}
> -        self.assertEqual(expected, binding)
> -
> -    @version_specific(3)
>     def test_keyword_only(self):
> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only)
> +        sig = pep362.Signature(keyword_only)
>         binding = sig.bind(a=42)
>         self.assertEqual(binding, {'a':42})
>         self.assertRaises(pep362.BindError, sig.bind)
>         self.assertRaises(pep362.BindError, sig.bind, 42)
>
> -    @version_specific(3)
>     def test_keyword_only_default(self):
> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only_default)
> +        sig = pep362.Signature(keyword_only_default)
>         binding = sig.bind()
>         self.assertEqual(binding, {'a':42})
>         binding = sig.bind(a=1)
>         self.assertEqual(binding, {'a':1})
>         self.assertRaises(pep362.BindError, sig.bind, 1)
>
> -    @version_specific(3)
>     def test_all_py3k_args(self):
>         # a:int, d=0, *args:int, g:int, h:int=8, **kwargs:int) -> int
> -        sig = pep362.Signature(pep362_py3k_fodder.all_args)
> +        sig = pep362.Signature(all_args)
>         # name, position, kw only, has_default, default, has anno, anno
>         expected = (('a', 0, False, False, None, True, int),
>                     ('d', 1, False, True, 0, False, None),
> @@ -353,9 +303,9 @@
>             else:
>                 self.assertTrue(not param.keyword_only)
>             if has_default:
> -                self.assertEqual(param.default_value, default)
> +                self.assertEqual(param.default, default)
>             else:
> -                self.assertTrue(not hasattr(param, 'default_value'))
> +                self.assertTrue(not hasattr(param, 'default'))
>             if has_anno:
>                 self.assertEqual(param.annotation, anno)
>             else:
> @@ -373,7 +323,7 @@
>
>     def test_too_many_arguments(self):
>         # Only one argument should pair up with a parameter.
> -        sig = pep362.Signature(pep362_fodder.no_default_args)
> +        sig = pep362.Signature(no_default_args)
>         self.assertRaises(pep362.BindError, sig.bind, 1, a=1)
>
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110323/f592ec74/attachment-0001.html>

From bruce.bushby at gmail.com  Thu Mar 24 09:06:35 2011
From: bruce.bushby at gmail.com (bruce bushby)
Date: Thu, 24 Mar 2011 08:06:35 +0000
Subject: [Python-Dev] Embedded Python startup is slow
Message-ID: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>

Hi

I have previously asked this question in python-list, however I think it
belongs here.

I'm running python 2.7.1 on an embedded Linux board and noticed it takes 1.8
seconds to execute the most simple "Hello World" script.

Platform:
cpu: 200Mhz ARM (ARM926EJ-)
kernel: 2.6.38
uClibc: 0.92.1-rc2


Using strace I found that python is attempting to open 168 non-existent
files during startup, see trace:
http://www.veritrack.co.uk/static/images/strace-hello-py.txt

I think this is normal behavior but more noticeable due to the embedded
environment.


1. Is there anything I can do at compile time to tell Python these files
don't exist and avoid trying to open them?
2. Is it possible to make python first try and open the ".pyc" and only then
look for ".py" ?



[root at vx-200 /]# cat hello.py
#!/usr/bin/python

print "Hello World!!"
[root at vx-200 /]#


[root at vx-200 /]# time ./hello.py
Hello World!!

real    0m1.781s
user    0m1.530s
sys     0m0.230s



Thanks
Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/27c8ec57/attachment.html>

From glyph at twistedmatrix.com  Thu Mar 24 10:19:02 2011
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Thu, 24 Mar 2011 05:19:02 -0400
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
Message-ID: <9A9A037B-9A15-4B39-A2F9-C95341269495@twistedmatrix.com>

On Mar 24, 2011, at 4:06 AM, bruce bushby wrote:

> I have previously asked this question in python-list, however I think it belongs here.

As the saying goes, this list is for development of python, not with python.  So it would be appropriate to make a suggestion as to some direction for Python's development that would improve your situation.

That said, at one point I had similar issues, and I also thought that Python should have had some kind of "embedded mode" compilation options, and I never found anything.

> I'm running python 2.7.1 on an embedded Linux board and noticed it takes 1.8 seconds to execute the most simple "Hello World" script.

You will notice that very, very early on in the process (not quite the first thing, but almost), there is a stat for python27.zip.  You want to put absolutely everything in the standard library into that archive, and to put your shared objects into /usr/lib/python2.7/ with names like 'foo.so' (not 'foomodule.so', as that's statted second).

When I was working with embedded python, that was pretty much the whole story: 2 zip files (one for the stdlib, one for everything else in my application), one directory for extension modules.  Finally, I hacked site.py to set sys.path to just those three entries, so that even failed imports would not stat too many non-existent files.

I think it would be a great idea to have a configure flag that instructed python to be pre-built this way, but I don't work with embedded pythons these days, so I'm not likely to do it :).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/89559f9d/attachment.html>

From flub at devork.be  Thu Mar 24 10:29:31 2011
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 24 Mar 2011 09:29:31 +0000
Subject: [Python-Dev] dependency injection for testing [was Python 3.3
 release schedule posted]
In-Reply-To: <4D8AA97A.60601@voidspace.org.uk>
References: <imdj8n$dq0$1@dough.gmane.org> <4D8AA70E.90304@jcea.es>
	<4D8AA97A.60601@voidspace.org.uk>
Message-ID: <AANLkTinbakdepTPohP11HC7TiMm6F9zbxbmqcbVJJVkf@mail.gmail.com>

On 24 March 2011 02:16, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 24/03/2011 02:06, Jesus Cea wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 23/03/11 20:56, Georg Brandl wrote:
>>>
>>> For 3.3, I'd like to revive the tradition of listing planned large-scale
>>> changes in the PEP.
>>
>> I want to integrate dependence injection in the stdlib, specially in
>> libs creating sockets. This would be an optional feature.
>>
>> The idea would be, for instance, that smtplib could call an optional
>> constructor to create a socket-like object, if some is provided.
>>
>> That would break the implicit dependency with sockets, reduce
>> monkey-patching need, and ease testing the libs.
>
> In general I dislike dependency injection if it's only done for testability.
> With monkey patching (if done right) you can safely test Python code without
> messing with your public interfaces just to make code testable.

Though in this case this sounds interesting to me as it would allow
using stdlib modules with e.g. "green" sockets from eventlet or gevent
without having to revert to monkey patching (which I don't mind for
testing but dislike for production).  In a way I'm always a little
disappointed when a library uses sockets out of my reach, ideally
you'd be able to use a library abstracted away from this so you can
plug in into async frameworks and other things the author didn't
foresee.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From martin at v.loewis.de  Thu Mar 24 12:18:18 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Mar 2011 12:18:18 +0100
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
Message-ID: <4D8B287A.2090002@v.loewis.de>

> 1. Is there anything I can do at compile time to tell Python these files
> don't exist and avoid trying to open them?

If you disable dynamic loading of extension modules, the number of stat
calls will go down significantly.

> 2. Is it possible to make python first try and open the ".pyc" and only
> then look for ".py" ?

If you then further reduce sys.path, and zip up the standard library
.pyc files, you get further reductions.

Regards,
Martin

From jameson.quinn at gmail.com  Thu Mar 24 12:40:54 2011
From: jameson.quinn at gmail.com (Jameson Quinn)
Date: Thu, 24 Mar 2011 05:40:54 -0600
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
Message-ID: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>

"class attrdict" is a perennial dead-end for intermediate pythonistas who
want to save 3 characters/5 keystrokes for item access. Other languages such
as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so
why not python? Well, there are a number of reasons why not, beginning with
all the magic method names in python.

But saving keystrokes is still a reasonable goal.

So what about a compromise? Allow "somedict..foo", with two dots, to take
that place. It still saves 2 characters (often 4 keystrokes; and I find even
', "[", or "]" harder to type than ".").

The "foo" part would of course have to obey attribute/identifier naming
rules. So there would be no shortcut for "somedict['$#!%']". But for any
identifier-legal foo, the interpreter would just read ..foo as ['foo'].

I would not be surprised if I'm not the first person to suggest this. If so,
and there's already well-known reasons why this is a bad idea, I apologize.
But if the only reason not to is "we never did it that way before" or "it
would be too addictive, and so people would never want to use older python
versions" or "headache for tools like pylint", I think we should do it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/4032b62f/attachment.html>

From dirkjan at ochtman.nl  Thu Mar 24 12:43:41 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Thu, 24 Mar 2011 12:43:41 +0100
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
Message-ID: <AANLkTi=UnFtfafShV5ZVR099=GngOuiYUcVP6TfkAjUp@mail.gmail.com>

On Thu, Mar 24, 2011 at 12:40, Jameson Quinn <jameson.quinn at gmail.com> wrote:
> "class attrdict" is a perennial dead-end for intermediate pythonistas who
> want to save 3 characters/5 keystrokes for item access. Other languages such
> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so
> why not python? Well, there are a number of reasons why not, beginning with
> all the magic method names in python.

This should go on python-ideas.

Cheers,

Dirkjan

From victor.stinner at haypocalc.com  Thu Mar 24 12:45:58 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 24 Mar 2011 12:45:58 +0100
Subject: [Python-Dev] Replace useless %.100s by %s in PyErr_Format()
Message-ID: <1300967158.17607.16.camel@marge>

Hi,

I plan to replace all %.100s (or any other size, %\.[0-9]+s regex) by %s
in the whole source code, in all calls to PyErr_Format(). And I would
like your opinion.

When Guido added the function PyErr_Format(), 13 years ago, the function
was implemented using a buffer of 500 bytes (allocated on the stack).
The developer was responsible to limit the argument fit into a total of
500 bytes. But 3 years later (2000), PyErr_Format() was patched to use a
dynamic buffer (allocated on the heap). But since this change,
PyErr_Format() doesn't support %.100s anymore (the 100 bytes limitation
is just ignored), and it becomes useless and so no, it's no more (since
10 years) a "protection" against segmentation fault.

But I would like to know if I have to do in all branches (3.1-3.3, or
worse: 2.5-3.3), or just in 3.3? Because it may make merge harder (like
any change only done in default).

I would like to replace %.100s because there are no more reason to
truncate strings to an arbitrary length.

=> http://bugs.python.org/issue10833

---

... at the same time, Ray Allen wrote a patch to implement %.100s in
PyUnicode_FromFormatV() (so PyErr_Format() will support it too). I would
like to replace %.100s in PyErr_Format(), and then commit its patch.

http://bugs.python.org/issue7330

Victor


From mal at egenix.com  Thu Mar 24 13:22:47 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 24 Mar 2011 13:22:47 +0100
Subject: [Python-Dev] Replace useless %.100s by %s in PyErr_Format()
In-Reply-To: <1300967158.17607.16.camel@marge>
References: <1300967158.17607.16.camel@marge>
Message-ID: <4D8B3797.7070500@egenix.com>

Victor Stinner wrote:
> Hi,
> 
> I plan to replace all %.100s (or any other size, %\.[0-9]+s regex) by %s
> in the whole source code, in all calls to PyErr_Format(). And I would
> like your opinion.
> 
> When Guido added the function PyErr_Format(), 13 years ago, the function
> was implemented using a buffer of 500 bytes (allocated on the stack).
> The developer was responsible to limit the argument fit into a total of
> 500 bytes. But 3 years later (2000), PyErr_Format() was patched to use a
> dynamic buffer (allocated on the heap). But since this change,
> PyErr_Format() doesn't support %.100s anymore (the 100 bytes limitation
> is just ignored), and it becomes useless and so no, it's no more (since
> 10 years) a "protection" against segmentation fault.
> 
> But I would like to know if I have to do in all branches (3.1-3.3, or
> worse: 2.5-3.3), or just in 3.3? Because it may make merge harder (like
> any change only done in default).
> 
> I would like to replace %.100s because there are no more reason to
> truncate strings to an arbitrary length.
> 
> => http://bugs.python.org/issue10833
> 
> ---
> 
> ... at the same time, Ray Allen wrote a patch to implement %.100s in
> PyUnicode_FromFormatV() (so PyErr_Format() will support it too). I would
> like to replace %.100s in PyErr_Format(), and then commit its patch.
> 
> http://bugs.python.org/issue7330

I think it's better to add the #7330 fix and leave the
length limitations in place.

Note that the length limitation did not only protect against
segfaults at the time when PyErr_Format() was using a fixed
size buffer and later on against miscalculations in creating
the variable sized buffer, it also protects against making the
error message text too long to be of any use or cause problems
further down the line in error processing.

BTW: Why do you think that %.100s is not supported in
PyErr_Format() in Python 2.x ? PyString_FromFormatV()
does support this. The change to use Unicode error strings
introduced the problem, since PyUnicode_FromFormatV() for
some reason ignores the precision (which is shouldn't).

That said, it's a good idea to add the #7330 fix
to at least Python 2.7 as well, since ignoring the precision
is definitely a bug. It may even be security relevant, since
it could be used for DOS attacks on servers (e.g. causing them
to write huge strings to log files instead of just a few
hundreds bytes per message), so may even need to go into Python 2.6.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 24 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From tseaver at palladion.com  Thu Mar 24 13:46:37 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 24 Mar 2011 08:46:37 -0400
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>	<20110323143123.4be80686@pitrou.net>	<19850.2977.894754.352174@montanaro.dyndns.org>	<20110323115156.25bd2845@neurotica.wooz.org>	<19850.9561.366432.287634@montanaro.dyndns.org>	<4D8A2CED.7080504@stoneleaf.us>	<20110323182400.04ce46cf@pitrou.net>
	<imdcc7$2q4$1@dough.gmane.org>
	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D8B3D2D.7000200@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/23/2011 09:36 PM, Stephen J. Turnbull wrote:
> Tres Seaver writes:
> 
>  > On 03/23/2011 01:24 PM, Antoine Pitrou wrote:
>  > > On Wed, 23 Mar 2011 10:25:01 -0700
>  > > Ethan Furman <ethan at stoneleaf.us> wrote:
>  > >>
>  > >> I think the use-case has been lost.  Think sprints and multiple push 
>  > >> races.
> 
> I do, can't speak for others.  So what? *sigh* ... read on.
> 
>  > > Well, keep in ming hg is a *distributed* version control system. You
>  > > don't have to push your changes right now.
> 
> s/push your changes right now/push your changes to the public repo/
> 
>  > That doesn't work so well at a sprint, where the point is to maximize
>  > the value of precious face-time to get stuff done *now*.
> 
> That's where the D in DVCS comes in.  It's a new world, friends.  All
> you need to do is bring a $50 wireless router to the sprint, and have
> some volunteer set up a shared repo for the sprinters.  Then some
> volunteer *later* runs the tests and pilots the patches into the
> public repo.  Where's the latency?

The current full test suite is punishingly expensive to run, sprint or
not.  Because of that fact, people will defer running it, and sometimes
forget.  Trying to require that people run it repeatedly during a push
race is just Canute lashing the waves.

> N.B.  The repo admin and test-running volunteers can be non-coders.
> In fact, the tests can be running concurrently (gives those non-coders
> an excuse to attend sprints!), but nobody need wait for the results.

The rhythm is still broken if devlopers don't run the tests and see them
pass.  Async is an enemy to the process here, because it encourages poor
practices.

>  > Maybe we need to chop the problem up as:
> 
> "Violence is the last refuge of the incompetent." ObRef Asimov.<wink>

Hmm, that hardly seems appropriate, even with the wink.  "Chopping"
isn't violence in any normal sense of the word when applied to
non-persons:  Chopping up a problem is no more violent than chopping
wood or onions (i.e., not at all).


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2LPS0ACgkQ+gerLs4ltQ5GmACeKvwnwzbOX4jRzokwnm+B0yD3
X/AAoK3kQ9e1yq1LbUcg9ERj8LquAEHg
=FEvh
-----END PGP SIGNATURE-----


From brian.curtin at gmail.com  Thu Mar 24 15:16:38 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Thu, 24 Mar 2011 09:16:38 -0500
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
Message-ID: <AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>

On Thu, Mar 24, 2011 at 06:40, Jameson Quinn <jameson.quinn at gmail.com>wrote:

> "class attrdict" is a perennial dead-end for intermediate pythonistas who
> want to save 3 characters/5 keystrokes for item access. Other languages such
> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so
> why not python? Well, there are a number of reasons why not, beginning with
> all the magic method names in python.
>
> But saving keystrokes is still a reasonable goal.
>

Code is read far more often than it is written, so readability tends to
count more than most other metrics.

So what about a compromise? Allow "somedict..foo", with two dots, to take
> that place. It still saves 2 characters (often 4 keystrokes; and I find even
> ', "[", or "]" harder to type than ".").
>

I don't see the benefit, but maybe it'll save a few bytes in file size.
Anyone reviewing your code now has to think "does this need one or two
dots?"

Anyways, why not just do something like this:

class AttrDict(dict):
    def __getattr__(self, attr):
        return super(AttrDict, self).__getitem__(attr)

>>> d = AttrDict()
>>> d["a"] = 1
>>> d.a
1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/56f044d7/attachment.html>

From fuzzyman at voidspace.org.uk  Thu Mar 24 15:21:48 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 24 Mar 2011 14:21:48 +0000
Subject: [Python-Dev] Second draft: PEP397: Python launcher for Windows
In-Reply-To: <4D8AB42C.9000904@skippinet.com.au>
References: <4D884E08.1020709@skippinet.com.au>	<4D88F4A5.4060701@voidspace.org.uk>	<AANLkTikk=14XmaZdZxE=Xyg4JzMv5Vbn0EBZ6BP=mZuR@mail.gmail.com>	<4D8A1115.40003@voidspace.org.uk>
	<4D8A2F30.8000601@stoneleaf.us>	<4D8A8CF0.2060806@skippinet.com.au>
	<AANLkTimUZrX=ajQCMSBaQCP2kGQrUsAHXgu=_eDXF33D@mail.gmail.com>
	<4D8AAA6E.3020002@voidspace.org.uk>
	<4D8AB42C.9000904@skippinet.com.au>
Message-ID: <4D8B537C.3030105@voidspace.org.uk>

On 24/03/2011 03:02, Mark Hammond wrote:
> On 24/03/2011 1:20 PM, Michael Foord wrote:
>> On 24/03/2011 00:44, Dj Gilcrease wrote:
>>> On Wed, Mar 23, 2011 at 8:14 PM, Mark
>>> Hammond<mhammond at skippinet.com.au> wrote:
>>>> If you guys (or anyone) would like to agree on some precise rules for
>>>> both
>>>> the location of the config file and its contents and express this as
>>>> a patch
>>>> to the PEP text, I have no problem supporting it in the 
>>>> implementations.
>>>> I'd like to insist that the format of the config file was such that 
>>>> the
>>>> GetPrivateProfileString() Windows function could be used to extract
>>>> the data
>>>> (eg, only '=' can be used to separate the name/value pair,
>>>> case-insensitive
>>>> and no support for string interpolation) as I have no interest in
>>>> writing my
>>>> own config file parser in C :)
>>> In the user directory much like TortoiseHG adds a murcurial.ini file
>>> to the users directory for basic globa config the launch could look
>>> for a python.ini there and use to to add known paths or version
>>> overrides on a user by user basis.
>>
>> A single global location (for shared installs) or a single per-user
>> location for per-user installs would seem to be sensible if the config
>> file route is chosen.
>
> My concern with that would be that an administrator may install 
> Python, but the user may not have write access to that global 
> location, leaving that user unable to customize the launcher.  OTOH, 
> that is how things work on Unix today - such users could not change 
> what /usr/bin/python points to).  Always using a per-user location 
> would mean there is no opportunity to have global settings, but it is 
> unclear which is the lesser of 2 evils.  Supporting both might even be 
> reasonable if the rules are very straightforward.
>

I would look first for a local config and fallback to a global config. 
That way you can choose your evil... With a single config location for 
each it should be simple enough.

> I'd still very much like to see the change to the wording of the PEP 
> to describe this feature though, otherwise I fear different people 
> will have different assumptions about exactly what it does and how it 
> does it...
>

I can provide a suggested pep wording if you like.

Michael

> 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


From rndblnch at gmail.com  Thu Mar 24 15:31:16 2011
From: rndblnch at gmail.com (rndblnch)
Date: Thu, 24 Mar 2011 14:31:16 +0000 (UTC)
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
	<4D6AB409.40001@canterbury.ac.nz>
	<loom.20110322T000609-760@post.gmane.org>
	<AANLkTik6CZbJj2cPO+807vcp85S3qTfC-w5fMjmdzkuj@mail.gmail.com>
	<AANLkTimpM8ysUzJL1idHoKXuFCpbYgAjzaGb2DFsVF=u@mail.gmail.com>
	<loom.20110322T125508-35@post.gmane.org>
Message-ID: <loom.20110324T151333-689@post.gmane.org>

rndblnch <rndblnch <at> gmail.com> writes:
> > Anyone without push rights for hg.python.org may want to fork the
> > mirror the bitbucket folks set up during the PyCon sprints to avoid
> > having to push the whole repository up to a separate hosting site:
> > https://bitbucket.org/mirror/cpython
> 
> Done here:
> <https://bitbucket.org/rndblnch/cpython-pep380/>

Now that I have figured out how to use patch queues with bitbucket, I will
maintain greg's pep380 implementation as a patch on top of cpython here:
<https://bitbucket.org/rndblnch/cpython-pep380/>

Testing it should be as simple as:
% hg qclone https://bitbucket.org/rndblnch/cpython-pep380
% cd cpython-pep380
% hg qpush pep380

and then the usual ./configure etc.


To test on an already existing clone of <http://hg.python.org/cpython>...
% hg clone http://hg.python.org/cpython
% cd cpython
% hg update -C default

you should enable mq extension...
% hg init --mq

get the pep380 patch and apply it...
% pushd .hg/patches/
% hg pull https://bitbucket.org/rndblnch/cpython-pep380/.hg/patches
% hg update
% popd
% hg qpush pep380

and then the usual ./configure etc.


The patch is now visible here:
<https://bitbucket.org/rndblnch/cpython-pep380/qseries?apply=t&qs_apply=pep380>

Hope this helps,

renaud



From solipsis at pitrou.net  Thu Mar 24 15:33:34 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 24 Mar 2011 15:33:34 +0100
Subject: [Python-Dev] sprints and pushes
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net> <imdcc7$2q4$1@dough.gmane.org>
	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D8B3D2D.7000200@palladion.com>
Message-ID: <20110324153334.1e0625a1@pitrou.net>

On Thu, 24 Mar 2011 08:46:37 -0400
Tres Seaver <tseaver at palladion.com> wrote:
> > 
> >  > That doesn't work so well at a sprint, where the point is to maximize
> >  > the value of precious face-time to get stuff done *now*.
> > 
> > That's where the D in DVCS comes in.  It's a new world, friends.  All
> > you need to do is bring a $50 wireless router to the sprint, and have
> > some volunteer set up a shared repo for the sprinters.  Then some
> > volunteer *later* runs the tests and pilots the patches into the
> > public repo.  Where's the latency?
> 
> The current full test suite is punishingly expensive to run, sprint or
> not.  Because of that fact, people will defer running it, and sometimes
> forget.  Trying to require that people run it repeatedly during a push
> race is just Canute lashing the waves.

Punishingly expensive?
You have to remember that Python is an entire programming language with
its standard library, used by millions of people. That its test suite
can run on 4 minutes on a modern computer actually makes it rather
"fast" IMO (and, perhaps, incomplete...).

If you have a "push race", then after merging you could just re-run the
tests that are affected by your changes (of course, if you did a change
in the interpreter core, you probably should run the whole suite again).
That's both faster and better focussed than a hypothetical "smoke test".

(that assumes you did run the test suite before doing the original
commit, of course)

Regards

Antoine.



From jameson.quinn at gmail.com  Thu Mar 24 16:20:36 2011
From: jameson.quinn at gmail.com (Jameson Quinn)
Date: Thu, 24 Mar 2011 09:20:36 -0600
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
Message-ID: <AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>

2011/3/24 Brian Curtin <brian.curtin at gmail.com>

> On Thu, Mar 24, 2011 at 06:40, Jameson Quinn <jameson.quinn at gmail.com>wrote:
>
>> "class attrdict" is a perennial dead-end for intermediate pythonistas who
>> want to save 3 characters/5 keystrokes for item access. Other languages such
>> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so
>> why not python? Well, there are a number of reasons why not, beginning with
>> all the magic method names in python.
>>
>> But saving keystrokes is still a reasonable goal.
>>
>
> Code is read far more often than it is written, so readability tends to
> count more than most other metrics.
>
> So what about a compromise? Allow "somedict..foo", with two dots, to take
>> that place. It still saves 2 characters (often 4 keystrokes; and I find even
>> ', "[", or "]" harder to type than ".").
>>
>
> I don't see the benefit, but maybe it'll save a few bytes in file size.
> Anyone reviewing your code now has to think "does this need one or two
> dots?"
>
>  Anyways, why not just do something like this:
>
> class AttrDict(dict):
>     def __getattr__(self, attr):
>         return super(AttrDict, self).__getitem__(attr)
>
> >>> d = AttrDict()
> >>> d["a"] = 1
> >>> d.a
> 1
>

There are a few reasons not to do it your way. For one, you could easily
forget about one of the built-in dict methods (e.g. d.get != d["get"]). For
another, if you look on the web, you'll find at least 15 different recipes
for that thing you just made, several of which have more-or-less subtle
errors waiting to get you. Furthermore, the whole point is to have this
available for built-in dicts. Say you get a dict as json - you can either
subclass your own json decoder, with all the pitfalls, or you can explicitly
pass the decoded dict to AttrDict, causing an extra object to be created and
obfuscating your code. And finally, who wants to copy that AttrDict code for
the 137th time?

As for the question of "one or two dots", it's exactly the same question you
face now with "dot or bracket", so I don't see the problem.

It's not merely a matter of saving keystrokes. To me, it would be actually
easier to read code in this style. When I'm doing things like accessing my
json data, that is essentially attribute access; why should my syntax
colorer color it the same as my UI strings?

In sum:
-Saves keystrokes
-saves bugs from miscooked recipes
-faster and less memory than any such recipe
-more-readable code
-very low-risk for old code

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/bcab6003/attachment-0001.html>

From theller at ctypes.org  Thu Mar 24 16:23:29 2011
From: theller at ctypes.org (Thomas Heller)
Date: Thu, 24 Mar 2011 16:23:29 +0100
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <4D8B287A.2090002@v.loewis.de>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
	<4D8B287A.2090002@v.loewis.de>
Message-ID: <4D8B61F1.2010904@ctypes.org>

Am 24.03.2011 12:18, schrieb "Martin v. L?wis":
>> 1. Is there anything I can do at compile time to tell Python these files
>> don't exist and avoid trying to open them?
>
> If you disable dynamic loading of extension modules, the number of stat
> calls will go down significantly.
>
>> 2. Is it possible to make python first try and open the ".pyc" and only
>> then look for ".py" ?
>
> If you then further reduce sys.path, and zip up the standard library
> .pyc files, you get further reductions.

On my embedded ARM system (400MHz ARM926EJ-S, linux 2.6.38) Python
starts up even slower when the standard library is in a zip-file.
The effect is worse when the zip-file is compressed, but the slow-down
is still there if the zip-file is not compressed.

Thomas

From jameson.quinn at gmail.com  Thu Mar 24 16:51:59 2011
From: jameson.quinn at gmail.com (Jameson Quinn)
Date: Thu, 24 Mar 2011 09:51:59 -0600
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
Message-ID: <AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>

Consider:

def fun1(argument):
    print argument1

fun1(argument="spam")

def fun2(**kw):
    print kw["argument"]

Why should I need quotes around "argument" in just one of those places? What
if I left them off, and there happened to be a global variable named
"argument"? Why shouldn't I be able to say:

def fun2(**kw):
    print kw..argument

(in real life, there would be a try... except block in case there was no
argument, I'm just showing the simplest case here.)

Jameson

2011/3/24 Jameson Quinn <jameson.quinn at gmail.com>

>
>
> 2011/3/24 Brian Curtin <brian.curtin at gmail.com>
>
>> On Thu, Mar 24, 2011 at 06:40, Jameson Quinn <jameson.quinn at gmail.com>wrote:
>>
>>> "class attrdict" is a perennial dead-end for intermediate pythonistas who
>>> want to save 3 characters/5 keystrokes for item access. Other languages such
>>> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so
>>> why not python? Well, there are a number of reasons why not, beginning with
>>> all the magic method names in python.
>>>
>>> But saving keystrokes is still a reasonable goal.
>>>
>>
>> Code is read far more often than it is written, so readability tends to
>> count more than most other metrics.
>>
>> So what about a compromise? Allow "somedict..foo", with two dots, to take
>>> that place. It still saves 2 characters (often 4 keystrokes; and I find even
>>> ', "[", or "]" harder to type than ".").
>>>
>>
>> I don't see the benefit, but maybe it'll save a few bytes in file size.
>> Anyone reviewing your code now has to think "does this need one or two
>> dots?"
>>
>>  Anyways, why not just do something like this:
>>
>> class AttrDict(dict):
>>     def __getattr__(self, attr):
>>         return super(AttrDict, self).__getitem__(attr)
>>
>> >>> d = AttrDict()
>> >>> d["a"] = 1
>> >>> d.a
>> 1
>>
>
> There are a few reasons not to do it your way. For one, you could easily
> forget about one of the built-in dict methods (e.g. d.get != d["get"]). For
> another, if you look on the web, you'll find at least 15 different recipes
> for that thing you just made, several of which have more-or-less subtle
> errors waiting to get you. Furthermore, the whole point is to have this
> available for built-in dicts. Say you get a dict as json - you can either
> subclass your own json decoder, with all the pitfalls, or you can explicitly
> pass the decoded dict to AttrDict, causing an extra object to be created and
> obfuscating your code. And finally, who wants to copy that AttrDict code for
> the 137th time?
>
> As for the question of "one or two dots", it's exactly the same question
> you face now with "dot or bracket", so I don't see the problem.
>
> It's not merely a matter of saving keystrokes. To me, it would be actually
> easier to read code in this style. When I'm doing things like accessing my
> json data, that is essentially attribute access; why should my syntax
> colorer color it the same as my UI strings?
>
> In sum:
> -Saves keystrokes
> -saves bugs from miscooked recipes
> -faster and less memory than any such recipe
> -more-readable code
> -very low-risk for old code
>
> Jameson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/89deaf21/attachment.html>

From solipsis at pitrou.net  Thu Mar 24 16:57:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 24 Mar 2011 16:57:25 +0100
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
Message-ID: <20110324165725.0068e8e5@pitrou.net>


Can this discussion be moved to python-ideas? Thank you.



On Thu, 24 Mar 2011 09:51:59 -0600
Jameson Quinn <jameson.quinn at gmail.com> wrote:

> Consider:
> 
> def fun1(argument):
>     print argument1
> 
> fun1(argument="spam")
> 
> def fun2(**kw):
>     print kw["argument"]
> 
> Why should I need quotes around "argument" in just one of those places? What
> if I left them off, and there happened to be a global variable named
> "argument"? Why shouldn't I be able to say:
> 
> def fun2(**kw):
>     print kw..argument
> 
> (in real life, there would be a try... except block in case there was no
> argument, I'm just showing the simplest case here.)
> 
> Jameson
> 
> 2011/3/24 Jameson Quinn <jameson.quinn at gmail.com>
> 
> >
> >
> > 2011/3/24 Brian Curtin <brian.curtin at gmail.com>
> >
> >> On Thu, Mar 24, 2011 at 06:40, Jameson Quinn <jameson.quinn at gmail.com>wrote:
> >>
> >>> "class attrdict" is a perennial dead-end for intermediate pythonistas who
> >>> want to save 3 characters/5 keystrokes for item access. Other languages such
> >>> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so
> >>> why not python? Well, there are a number of reasons why not, beginning with
> >>> all the magic method names in python.
> >>>
> >>> But saving keystrokes is still a reasonable goal.
> >>>
> >>
> >> Code is read far more often than it is written, so readability tends to
> >> count more than most other metrics.
> >>
> >> So what about a compromise? Allow "somedict..foo", with two dots, to take
> >>> that place. It still saves 2 characters (often 4 keystrokes; and I find even
> >>> ', "[", or "]" harder to type than ".").
> >>>
> >>
> >> I don't see the benefit, but maybe it'll save a few bytes in file size.
> >> Anyone reviewing your code now has to think "does this need one or two
> >> dots?"
> >>
> >>  Anyways, why not just do something like this:
> >>
> >> class AttrDict(dict):
> >>     def __getattr__(self, attr):
> >>         return super(AttrDict, self).__getitem__(attr)
> >>
> >> >>> d = AttrDict()
> >> >>> d["a"] = 1
> >> >>> d.a
> >> 1
> >>
> >
> > There are a few reasons not to do it your way. For one, you could easily
> > forget about one of the built-in dict methods (e.g. d.get != d["get"]). For
> > another, if you look on the web, you'll find at least 15 different recipes
> > for that thing you just made, several of which have more-or-less subtle
> > errors waiting to get you. Furthermore, the whole point is to have this
> > available for built-in dicts. Say you get a dict as json - you can either
> > subclass your own json decoder, with all the pitfalls, or you can explicitly
> > pass the decoded dict to AttrDict, causing an extra object to be created and
> > obfuscating your code. And finally, who wants to copy that AttrDict code for
> > the 137th time?
> >
> > As for the question of "one or two dots", it's exactly the same question
> > you face now with "dot or bracket", so I don't see the problem.
> >
> > It's not merely a matter of saving keystrokes. To me, it would be actually
> > easier to read code in this style. When I'm doing things like accessing my
> > json data, that is essentially attribute access; why should my syntax
> > colorer color it the same as my UI strings?
> >
> > In sum:
> > -Saves keystrokes
> > -saves bugs from miscooked recipes
> > -faster and less memory than any such recipe
> > -more-readable code
> > -very low-risk for old code
> >
> > Jameson
> >
> 



From bruce.bushby at gmail.com  Thu Mar 24 16:58:20 2011
From: bruce.bushby at gmail.com (bruce bushby)
Date: Thu, 24 Mar 2011 15:58:20 +0000
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <4D8B61F1.2010904@ctypes.org>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
	<4D8B287A.2090002@v.loewis.de> <4D8B61F1.2010904@ctypes.org>
Message-ID: <AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>

My main concern was that a freshly compiled Python attempts to open 168
non-existent files before starting.

I understand that an interpreted language is probably not the best choice
for an embedded device (although it's very nice for prototyping) , Python
really should know what exists after it's just been compiled....ie before
any corrupting modules or other nonsense has been added.

It appears it is hard coded to open these files regardless of any
"configure" options.

On my desktop pc, when I run the most simple "Hello World" .... 78% of the
overall execution time is spent opening files....most of which don't exist.

Some form of "cache" would help the startup time on the "second go" .....
but arguably just a "band aid" covering a deeper problem.


Bruce





On Thu, Mar 24, 2011 at 3:23 PM, Thomas Heller <theller at ctypes.org> wrote:

> Am 24.03.2011 12:18, schrieb "Martin v. L?wis":
>
>  1. Is there anything I can do at compile time to tell Python these files
>>> don't exist and avoid trying to open them?
>>>
>>
>> If you disable dynamic loading of extension modules, the number of stat
>> calls will go down significantly.
>>
>>  2. Is it possible to make python first try and open the ".pyc" and only
>>> then look for ".py" ?
>>>
>>
>> If you then further reduce sys.path, and zip up the standard library
>> .pyc files, you get further reductions.
>>
>
> On my embedded ARM system (400MHz ARM926EJ-S, linux 2.6.38) Python
> starts up even slower when the standard library is in a zip-file.
> The effect is worse when the zip-file is compressed, but the slow-down
> is still there if the zip-file is not compressed.
>
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/a801a40b/attachment.html>

From theller at ctypes.org  Thu Mar 24 17:16:17 2011
From: theller at ctypes.org (Thomas Heller)
Date: Thu, 24 Mar 2011 17:16:17 +0100
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>	<4D8B287A.2090002@v.loewis.de>
	<4D8B61F1.2010904@ctypes.org>
	<AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
Message-ID: <4D8B6E51.1070405@ctypes.org>

Am 24.03.2011 16:58, schrieb bruce bushby:
>
> My main concern was that a freshly compiled Python attempts to open 168
> non-existent files before starting.
>
> I understand that an interpreted language is probably not the best
> choice for an embedded device (although it's very nice for prototyping)
> , Python really should know what exists after it's just been
> compiled....ie before any corrupting modules or other nonsense has been
> added.
>
> It appears it is hard coded to open these files regardless of any
> "configure" options.
>
> On my desktop pc, when I run the most simple "Hello World" .... 78% of
> the overall execution time is spent opening files....most of which don't
> exist.
>
> Some form of "cache" would help the startup time on the "second go"
> ..... but arguably just a "band aid" covering a deeper problem.

So maybe you should try to come up with a patch, to find out
if the cache helps?

From brian.curtin at gmail.com  Thu Mar 24 17:15:46 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Thu, 24 Mar 2011 11:15:46 -0500
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
Message-ID: <AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>

On Thu, Mar 24, 2011 at 10:51, Jameson Quinn <jameson.quinn at gmail.com>wrote:

> Consider:
>
> def fun1(argument):
>     print argument1
>
> fun1(argument="spam")
>
> def fun2(**kw):
>     print kw["argument"]
>
> Why should I need quotes around "argument" in just one of those places?
> What if I left them off, and there happened to be a global variable named
> "argument"? Why shouldn't I be able to say:
>
> def fun2(**kw):
>     print kw..argument
>
> (in real life, there would be a try... except block in case there was no
> argument, I'm just showing the simplest case here.)
>

I can certainly see use cases for this, but none generic enough for the
standard library.

Let's take the configparser module for example: in 3.2 ConfigParser objects
can now be accessed like dictionaries. Looking at the examples in the
documentation [0], an immediate problem comes to mind:

    print(config..bitbucket.org..user)
    *boom*

If you're going to be doing attribute access, it's likely that you know the
name of the attribute -- you wrote the code knowing what to expect in the
first place. If you know the names of the attributes you're going to be
dealing with, why not just store them in a class, or even a class with
__slots__ defined for each attribute?

The double-dot notation will only work when you already know the key. When
iterating over keys, you're going to resort back to dict[key] or
getattr(dict, key) to get the value.

In the end, it's syntactic sugar for a limited set of applicable cases.



[0] http://docs.python.org/release/3.2/library/configparser
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/7f724df3/attachment.html>

From eliben at gmail.com  Thu Mar 24 17:36:15 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Thu, 24 Mar 2011 18:36:15 +0200
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <20110324153334.1e0625a1@pitrou.net>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us> <20110323182400.04ce46cf@pitrou.net>
	<imdcc7$2q4$1@dough.gmane.org>
	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D8B3D2D.7000200@palladion.com> <20110324153334.1e0625a1@pitrou.net>
Message-ID: <AANLkTi=5DR7zqBKX5rKLjSrVgJ1f4Gsgvcp1_T8Zt9gi@mail.gmail.com>

On Thu, Mar 24, 2011 at 16:33, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Thu, 24 Mar 2011 08:46:37 -0400
> Tres Seaver <tseaver at palladion.com> wrote:
> > >
> > >  > That doesn't work so well at a sprint, where the point is to
> maximize
> > >  > the value of precious face-time to get stuff done *now*.
> > >
> > > That's where the D in DVCS comes in.  It's a new world, friends.  All
> > > you need to do is bring a $50 wireless router to the sprint, and have
> > > some volunteer set up a shared repo for the sprinters.  Then some
> > > volunteer *later* runs the tests and pilots the patches into the
> > > public repo.  Where's the latency?
> >
> > The current full test suite is punishingly expensive to run, sprint or
> > not.  Because of that fact, people will defer running it, and sometimes
> > forget.  Trying to require that people run it repeatedly during a push
> > race is just Canute lashing the waves.
>
> Punishingly expensive?
> You have to remember that Python is an entire programming language with
> its standard library, used by millions of people. That its test suite
> can run on 4 minutes on a modern computer actually makes it rather
> "fast" IMO (and, perhaps, incomplete...).
>

+1
Having experience running [= suffering from] multiple-hour (and sometimes
weekend-long) tests for some systems, Python's test suite feels slender.
Even surprisingly so. I often wonder how such a relatively short set of
tests can exercise a project as big and full of functionality as Python with
its whole standard library.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/cf9b994b/attachment.html>

From jcea at jcea.es  Thu Mar 24 17:40:18 2011
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 24 Mar 2011 17:40:18 +0100
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
Message-ID: <4D8B73F2.50700@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, everybody.

I want to test the dev community interest in modifying the stdlib to
ease dependence injection.

The seminal idea was in
<http://mail.python.org/pipermail/python-dev/2010-April/099237.html>.

A lot of stdlib modules use, deep inside, other modules to do their
work. The most obvious case would be the socket library, used by ANY
module involving the network.

This internal usage, deep inside, prevents programmers to "mess" with
the networking layer in an easy way. Some examples: transparent
encryption/compression, using alternative network implementations like
shared buffers if the traffic is local, integrating the socket in a
async event loop/greenlet/etc, network logging/sniffing, testing
(simulating a server, with no real network connection), etc. Testing
gets very easy if we can "mock" the internal socket, for instance.

So I propose to add an additional OPTIONAL parameter to quite a few
libraries. If the parameter is not present (compatible with client
current code), the library would instantiate a internal socket, just
like now. But if the parameter is present, it would inject a constructor
for the library to use instead of "socket".

Traditionally this "features" can be used in Python code using monkey
patching, but this approach is fragile (can break when upgrading), not
obvious for newbies and difficult to combine (for instance, trying to
apply multiple "monkey patches" over the socket module).

What do you think?. Should I write a PEP? (I don't think so, but your
opinion matters). I care, for instance, about how to garantee the API
coverage actually needed for the new "socket-like" object. The idea is
that your object should be "socket-like", but how much "socket-like" in
the API sense?. Do you need to implement "getpeername()" for injecting
in smtplib?.

If you agree that this is a nice idea, what other libs do you think that
could benefice of being "injected", beside "socket"?.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYtz8plgi5GaxT1NAQJCzwQAkvtCwvKDh1QcQ+Qfbhe0qrKcQdI4wMfB
g4jpCmCX3UCkTvAjU1AsnxGGwVjvYZWdL2QVZS5+sJOP5GOmMzm96PBYjWZjVovk
YHIP+HFXU0BtbXlRJMV2+bjrwZf1g8CQFngyxqkQ69WdU+FMyxmDhFbcQ7y667HT
ldkINMLSuTk=
=rrkE
-----END PGP SIGNATURE-----

From benjamin at python.org  Thu Mar 24 17:46:42 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 24 Mar 2011 11:46:42 -0500
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <4D8B73F2.50700@jcea.es>
References: <4D8B73F2.50700@jcea.es>
Message-ID: <AANLkTi=tyeEY6KU+P=J=jruEF1z-O0njfNt_Bs=k_mWZ@mail.gmail.com>

2011/3/24 Jesus Cea <jcea at jcea.es>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, everybody.
>
> I want to test the dev community interest in modifying the stdlib to
> ease dependence injection.

I, for one, am -1. Code shouldn't be uglified for the purposes of
testing. It's also a slippery slope. Maybe we should add parameters
for open() and io functions? What about sys and os? Those often need
to be mocked.



-- 
Regards,
Benjamin

From benjamin at python.org  Thu Mar 24 17:51:46 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 24 Mar 2011 11:51:46 -0500
Subject: [Python-Dev] [Python-checkins] cpython: Isolate the
	test_source() test in test_collections
In-Reply-To: <E1Q2nfW-0006MV-Rs@dinsdale.python.org>
References: <E1Q2nfW-0006MV-Rs@dinsdale.python.org>
Message-ID: <AANLkTi=pG3zZ2y9TYqja2MimzCVDFc7JKsF0Kd5eEGZd@mail.gmail.com>

2011/3/24 raymond.hettinger <python-checkins at python.org>:
> http://hg.python.org/cpython/rev/4f1cd92fe835
> changeset: ? 68901:4f1cd92fe835
> user: ? ? ? ?Raymond Hettinger <python at rcn.com>
> date: ? ? ? ?Thu Mar 24 09:45:43 2011 -0700
> summary:
> ?Isolate the test_source() test in test_collections
>
> files:
> ?Lib/test/test_collections.py | ?13 ++++++++-----
> ?1 files changed, 8 insertions(+), 5 deletions(-)
>
>
> diff --git a/Lib/test/test_collections.py b/Lib/test/test_collections.py
> --- a/Lib/test/test_collections.py
> +++ b/Lib/test/test_collections.py
> @@ -330,13 +330,16 @@
>
> ? ? def test_source(self):
> ? ? ? ? # verify that _source can be run through exec()
> - ? ? ? ?tmp = namedtuple('Color', 'red green blue')
> - ? ? ? ?self.assertNotIn('Color', globals())
> + ? ? ? ?tmp = namedtuple('NTColor', 'red green blue')
> + ? ? ? ?globals().pop('NTColor', None) ? ? ? ? ?# remove artifacts from other tests
> + ? ? ? ?self.assertNotIn('NTColor', globals())

Shouldn't these other tests cleanup after themselves?



-- 
Regards,
Benjamin

From bruce.bushby at gmail.com  Thu Mar 24 17:52:26 2011
From: bruce.bushby at gmail.com (bruce bushby)
Date: Thu, 24 Mar 2011 16:52:26 +0000
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <EF8F0025-8849-4029-AA10-EDCB5C88FD61@fuhm.net>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
	<4D8B287A.2090002@v.loewis.de> <4D8B61F1.2010904@ctypes.org>
	<AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
	<EF8F0025-8849-4029-AA10-EDCB5C88FD61@fuhm.net>
Message-ID: <AANLkTimEj=Tsnf=bec95cnAfWq88f-jKBgjg+TND1u6x@mail.gmail.com>

".....your Desktop PC being that MS-Windows..."  aaaaww sis man, it's all
Linux :))))

I wanted to make sure I've not missed some compile trick for this sort of
thing.

".....So maybe you should try to come up with a patch, to find out if the
cache helps?"
Yes, now that I know I've not ignored some obvious "everybody knows not to
do that" trick I'll look into some form of cache.....although off the top of
my head I imagine it''ll be difficult to precede every open with a cache
lookup....perhaps this is something better suited for the underlying
"uClibc" framework....but then who refreshes the cache.

Thanks for the thoughts and idea, if I find a nice solution I'll be sure to
post an update.


Bruce






On Thu, Mar 24, 2011 at 4:18 PM, James Y Knight <foom at fuhm.net> wrote:

> On Mar 24, 2011, at 11:58 AM, bruce bushby wrote:
> > My main concern was that a freshly compiled Python attempts to open 168
> non-existent files before starting.
> >
> > I understand that an interpreted language is probably not the best choice
> for an embedded device (although it's very nice for prototyping) , Python
> really should know what exists after it's just been compiled....ie before
> any corrupting modules or other nonsense has been added.
> >
> > It appears it is hard coded to open these files regardless of any
> "configure" options.
> >
> > On my desktop pc, when I run the most simple "Hello World" .... 78% of
> the overall execution time is spent opening files....most of which don't
> exist.
> >
> > Some form of "cache" would help the startup time on the "second go" .....
> but arguably just a "band aid" covering a deeper problem.
>
> The deeper problem on your Desktop PC being that MS-Windows' file system
> calls are horrifically expensive for no good reason? :)
>
> James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/a35da8d0/attachment.html>

From foom at fuhm.net  Thu Mar 24 17:52:50 2011
From: foom at fuhm.net (James Y Knight)
Date: Thu, 24 Mar 2011 12:52:50 -0400
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <4D8B73F2.50700@jcea.es>
References: <4D8B73F2.50700@jcea.es>
Message-ID: <7001D8B5-C6B5-4F99-8F23-CCF9E9B8C52B@fuhm.net>

On Mar 24, 2011, at 12:40 PM, Jesus Cea wrote:
> I want to test the dev community interest in modifying the stdlib to
> ease dependence injection.
> 
> The seminal idea was in
> <http://mail.python.org/pipermail/python-dev/2010-April/099237.html>.
> 
> A lot of stdlib modules use, deep inside, other modules to do their
> work. The most obvious case would be the socket library, used by ANY
> module involving the network.

Do you know about exocet (described by the last few blog entries on http://washort.twistedmatrix.com/search/label/exocet), a newly developed tool for doing dependency injection on arbitrary modules? It seems like it would be very well suited for the kinds of things you want to do.

James

From foom at fuhm.net  Thu Mar 24 17:18:29 2011
From: foom at fuhm.net (James Y Knight)
Date: Thu, 24 Mar 2011 12:18:29 -0400
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
	<4D8B287A.2090002@v.loewis.de> <4D8B61F1.2010904@ctypes.org>
	<AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
Message-ID: <EF8F0025-8849-4029-AA10-EDCB5C88FD61@fuhm.net>

On Mar 24, 2011, at 11:58 AM, bruce bushby wrote:
> My main concern was that a freshly compiled Python attempts to open 168 non-existent files before starting. 
> 
> I understand that an interpreted language is probably not the best choice for an embedded device (although it's very nice for prototyping) , Python really should know what exists after it's just been compiled....ie before any corrupting modules or other nonsense has been added.
> 
> It appears it is hard coded to open these files regardless of any "configure" options.
> 
> On my desktop pc, when I run the most simple "Hello World" .... 78% of the overall execution time is spent opening files....most of which don't exist. 
> 
> Some form of "cache" would help the startup time on the "second go" ..... but arguably just a "band aid" covering a deeper problem.

The deeper problem on your Desktop PC being that MS-Windows' file system calls are horrifically expensive for no good reason? :)

James

From solipsis at pitrou.net  Thu Mar 24 17:57:58 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 24 Mar 2011 17:57:58 +0100
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
References: <4D8B73F2.50700@jcea.es>
	<AANLkTi=tyeEY6KU+P=J=jruEF1z-O0njfNt_Bs=k_mWZ@mail.gmail.com>
Message-ID: <20110324175758.4681705e@pitrou.net>

On Thu, 24 Mar 2011 11:46:42 -0500
Benjamin Peterson <benjamin at python.org> wrote:

> 2011/3/24 Jesus Cea <jcea at jcea.es>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi, everybody.
> >
> > I want to test the dev community interest in modifying the stdlib to
> > ease dependence injection.
> 
> I, for one, am -1. Code shouldn't be uglified for the purposes of
> testing. It's also a slippery slope. Maybe we should add parameters
> for open() and io functions? What about sys and os? Those often need
> to be mocked.

A non-ugly way of doing "dependency injection" is to rely on
class/instance attributes instead. e.g.:

class FTP:
    socket_factory = socket.create_connection

    def open(self, host, port):
        self.sock = self.socket_factory(host, port)
        ...


Regards

Antoine.



From brett at python.org  Thu Mar 24 17:58:28 2011
From: brett at python.org (Brett Cannon)
Date: Thu, 24 Mar 2011 09:58:28 -0700
Subject: [Python-Dev] Trimming "make quicktest"
In-Reply-To: <1300906576.3495.29.camel@localhost.localdomain>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<AANLkTik8dPfMSdnn=YnUmc4YB4cjS-W3frEz_DYR6pZc@mail.gmail.com>
	<1300888356.3495.9.camel@localhost.localdomain>
	<AANLkTi==bn5LwUdbCnN7xeKw_ub35CcaOr2D7GNmTnq4@mail.gmail.com>
	<1300890997.3495.13.camel@localhost.localdomain>
	<AANLkTimq8waQH-VPbxvnXZS-RJNgDk2gFE=_KYRz5v2G@mail.gmail.com>
	<m2mxklu1vh.fsf@valheru.db3l.homeip.net>
	<20110323194201.17d01670@pitrou.net>
	<4D8A4128.2050206@voidspace.org.uk>
	<1300906576.3495.29.camel@localhost.localdomain>
Message-ID: <AANLkTik63qxCnGoVVuGmH7uu97LCsC2sEO=iG-rwPL8R@mail.gmail.com>

On Wed, Mar 23, 2011 at 11:56, Antoine Pitrou <solipsis at pitrou.net> wrote:

> Le mercredi 23 mars 2011 ? 18:51 +0000, Michael Foord a ?crit :
> > On 23/03/2011 18:42, Antoine Pitrou wrote:
> > > On Wed, 23 Mar 2011 14:29:22 -0400
> > > David Bolen<db3l.net at gmail.com>  wrote:
> > >> Nick Coghlan<ncoghlan at gmail.com>  writes:
> > >>
> > >>> On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou<solipsis at pitrou.net>
>  wrote:
> > >>>> You mean in the "-j" option itself or in "make test"?
> > >>> I was actually suggesting that -j be the *default* in regrtest
> itself,
> > >>> with an option to turn it off or force a particular number of
> > >>> processes.
> > >> Just one request - if there are changes in this direction (e.g.,
> > >> trying to make regrtest use all cores by default), please include the
> > >> ability to configure/override this for individual builders (or at
> > >> least slaves) since otherwise I won't be able to disable it.
> > > I think "-j" should remain a manual setting. I've posted a patch to
> > > enable it automatically in "make test" for convenience, but it would
> > > be enabled for neither "-m test" nor "make buildbottest".
> >
> > -j doesn't pass on several of the flags to its subprocesses (e.g.
> > warning settings I believe)
>
> It does (should):
> http://hg.python.org/cpython/file/2f4865834695/Lib/test/support.py#l1375
>

I fixed that at the sprints so yes, it works as expected (at least for the
flags one will care about).

-Brett



>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/c52a5d2b/attachment.html>

From stefan_ml at behnel.de  Thu Mar 24 18:05:59 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 24 Mar 2011 18:05:59 +0100
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>	<4D8B287A.2090002@v.loewis.de>
	<4D8B61F1.2010904@ctypes.org>
	<AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
Message-ID: <imftlo$upj$1@dough.gmane.org>

bruce bushby, 24.03.2011 16:58:
> My main concern was that a freshly compiled Python attempts to open 168
> non-existent files before starting.
>
> I understand that an interpreted language is probably not the best choice
> for an embedded device

Well, "hello world" isn't exactly the benchmark I'd use for an embedded system.


> On my desktop pc, when I run the most simple "Hello World" .... 78% of the
> overall execution time is spent opening files....most of which don't exist.

How did you measure that?

I'd expect that after the first startup, most of the relevant parts of the 
file system are cached by the OS, so a subsequent run should be quick as 
all file existence tests will run from memory. Sure, it's a bit of overhead 
to call into the OS, and I don't know how expensive that is on ARM-Linux, 
but given that you also claim it to be expensive on your desktop, I must 
say that I'm a bit surprised about your above claim.

Stefan


From brett at python.org  Thu Mar 24 17:57:00 2011
From: brett at python.org (Brett Cannon)
Date: Thu, 24 Mar 2011 09:57:00 -0700
Subject: [Python-Dev] [Python-checkins] r88796 - in
 sandbox/trunk/pep362: pep362.py setup.py test_pep362.py tests
In-Reply-To: <AANLkTikdPnhHn70usyYxAM+WmefL+Ko3MZmn_jaAZPNi@mail.gmail.com>
References: <3Pw46Y065Fz7Lln@mail.python.org>
	<AANLkTikdPnhHn70usyYxAM+WmefL+Ko3MZmn_jaAZPNi@mail.gmail.com>
Message-ID: <AANLkTik8Qm-n+1prQPw2bRzsrwTJdpkzEhxdYk5A0B63@mail.gmail.com>

On Wed, Mar 23, 2011 at 21:38, Eric Snow <ericsnowcurrently at gmail.com>wrote:

> Shouldn't the Signature class also support building from args and not just
> a function object? Then I could use a Signature object when building a
> function object, or vice versa.  Having the ability to validate args/kwargs
> against a Signature object, sort of like provided by the bind method, will
> be helpful, particularly with the decorator use case.


I will probably try to add that functionality, but one thing at a time. =)



>  What does the tuple form of Parameter.name represent?


What tuple form? If you mean tuple parameters those no longer exist.


>  Did you come to any conclusion on the open issues in the PEP?


Nope. You are getting ahead of me. =)

-Brett


>
> With the exec_closure stuff I have been looking pretty closely at
> function-related C-API capability that might be worth exposing better in
> python, and Signature objects would help facilitate in a much clearer way.
>  Not only that, but even though CPython won't use Signature objects behind
> the scenes, they can help to make the internal operations of Python more
> clear by exposing the underlying mechanisms in pure python.  For example,
> with a validate method you could express how args and kwargs are mapped onto
> the different parts of the code object which correspond to the parts of the
> Signature object.
>
> I am looking forward to the inclusion of the function signature stuff in
> 3.3.
>
> -eric
>
>
> On Wed, Mar 23, 2011 at 3:39 PM, brett.cannon <python-checkins at python.org>wrote:
>
>> Author: brett.cannon
>> Date: Wed Mar 23 22:39:32 2011
>> New Revision: 88796
>>
>> Log:
>> Update code for future inclusion in Python 3.3 (when I get around to it).
>>
>> Added:
>>   sandbox/trunk/pep362/test_pep362.py
>>      - copied, changed from r88415,
>> /sandbox/trunk/pep362/tests/test_pep362.py
>> Removed:
>>   sandbox/trunk/pep362/setup.py
>>   sandbox/trunk/pep362/tests/
>> Modified:
>>   sandbox/trunk/pep362/   (props changed)
>>   sandbox/trunk/pep362/pep362.py
>>
>> Modified: sandbox/trunk/pep362/pep362.py
>>
>> ==============================================================================
>> --- sandbox/trunk/pep362/pep362.py      (original)
>> +++ sandbox/trunk/pep362/pep362.py      Wed Mar 23 22:39:32 2011
>> @@ -8,7 +8,7 @@
>>     pass
>>
>>
>> -class Parameter(object):
>> +class Parameter:
>>
>>     """Represent a parameter in a function signature.
>>
>> @@ -31,8 +31,9 @@
>>
>>     """
>>
>> -    def __init__(self, name, position, has_default=False,
>> default_value=None,
>> -                 keyword_only=False, has_annotation=False,
>> annotation=None):
>> +    def __init__(self, name, position, *, has_default=False,
>> +                 default=None, keyword_only=False, has_annotation=False,
>> +                 annotation=None):
>>         """Initialize a Parameter instance.
>>
>>         For has_* arguments, if they are False then the corresponding *
>> @@ -42,13 +43,13 @@
>>         self.name = name
>>         self.position = position
>>         if has_default:
>> -            self.default_value = default_value
>> +            self.default = default
>>         self.keyword_only = keyword_only
>>         if has_annotation:
>>             self.annotation = annotation
>>
>>
>> -class Signature(object):
>> +class Signature:
>>
>>     """Object to represent the signature of a function/method.
>>
>> @@ -74,39 +75,19 @@
>>
>>     def __init__(self, func):
>>         """Initialize from a function or method object."""
>> -        if hasattr(func, 'im_func'):
>> -            func = func.im_func
>> -        try:
>> -            func_code = func.__code__
>> -        except AttributeError:
>> -            # Compatibility for versions < 2.6.
>> -            func_code = func.func_code
>> -
>> +        func_code = func.__code__
>>         self.name = func.__name__
>> -
>> -        try:
>> -            # Unneeded once 2.x support is removed; can easily get info
>> the
>> -            #  "hard" way.
>> -            argspec = inspect.getfullargspec(func)[:4]
>> -        except AttributeError:
>> -            # Needed only for tuple parameters.
>> -            argspec = inspect.getargspec(func)
>> +        # XXX replace with own implementation
>> +        argspec = inspect.getfullargspec(func)[:4]
>>         parameters = {}
>>
>>         # Parameter information.
>>         pos_count = func_code.co_argcount
>> -        if hasattr(func_code, 'co_kwonlyargcount'):
>> -            keyword_only_count = func_code.co_kwonlyargcount
>> -        else:
>> -            keyword_only_count = 0
>> +        keyword_only_count = func_code.co_kwonlyargcount
>>         positional = argspec[0]
>>         keyword_only = func_code.co_varnames[pos_count:
>>
>> pos_count+keyword_only_count]
>> -        try:
>> -            fxn_defaults = func.__defaults__
>> -        except AttributeError:
>> -            # Deal with old names prior to 2.6.
>> -            fxn_defaults = func.func_defaults
>> +        fxn_defaults = func.__defaults__
>>         if fxn_defaults:
>>             pos_default_count = len(fxn_defaults)
>>         else:
>> @@ -126,7 +107,7 @@
>>             has_annotation, annotation = self._find_annotation(func, name)
>>             default_value = fxn_defaults[offset]
>>             param = Parameter(name, offset+non_default_count,
>> -                                has_default=True,
>> default_value=default_value,
>> +                                has_default=True, default=default_value,
>>                                 has_annotation=has_annotation,
>>                                 annotation=annotation)
>>             parameters[name] = param
>> @@ -134,16 +115,14 @@
>>         for offset, name in enumerate(keyword_only):
>>             has_annotation, annotation = self._find_annotation(func, name)
>>             has_default, default_value = False, None
>> -            # hasattr check only needed for versions < 2.6.
>> -            if (hasattr(func, '__kwdefaults__') and func.__kwdefaults__
>> and
>> -                    name in func.__kwdefaults__):
>> +            if func.__kwdefaults__ and name in func.__kwdefaults__:
>>                 has_default = True
>>                 default_value = func.__kwdefaults__[name]
>>             param = Parameter(name, offset+pos_count, keyword_only=True,
>> -                                has_default=has_default,
>> -                                default_value=default_value,
>> -                                has_annotation=has_annotation,
>> -                                annotation=annotation)
>> +                              has_default=has_default,
>> +                              default=default_value,
>> +                              has_annotation=has_annotation,
>> +                              annotation=annotation)
>>             parameters[name] = param
>>         # Variable parameters.
>>         index = pos_count + keyword_only_count
>> @@ -172,9 +151,8 @@
>>         self._parameters = parameters
>>
>>         # Return annotation.
>> -        if hasattr(func, '__annotations__'):
>> -            if 'return' in func.__annotations__:
>> -                self.return_annotation = func.__annotations__['return']
>> +        if 'return' in func.__annotations__:
>> +            self.return_annotation = func.__annotations__['return']
>>
>>     def __getitem__(self, key):
>>         return self._parameters[key]
>> @@ -186,10 +164,9 @@
>>         """Return True if an annotation exists for the named parameter
>> along
>>         with its annotation, else return False and None."""
>>         has_annotation, annotation = False, None
>> -        if hasattr(func, '__annotations__'):
>> -            if name in func.__annotations__:
>> -                has_annotation = True
>> -                annotation = func.__annotations__[name]
>> +        if name in func.__annotations__:
>> +            has_annotation = True
>> +            annotation = func.__annotations__[name]
>>         return has_annotation, annotation
>>
>>     def _convert_name(self, name):
>> @@ -234,7 +211,7 @@
>>                     break
>>                 else:
>>                     raise BindError("too many positional arguments")
>> -            self._tuple_bind(bindings, param.name, position_arg)
>> +            bindings[param.name] = position_arg
>>             args = args[1:]
>>         # Keyword arguments & default values.
>>         else:
>> @@ -247,9 +224,8 @@
>>                     except KeyError:
>>                         raise BindError("%r unbound" % param_name)
>>                 else:
>> -                    if hasattr(positional_param, 'default_value'):
>> -                        self._tuple_bind(bindings, param_name,
>> -
>>  positional_param.default_value)
>> +                    if hasattr(positional_param, 'default'):
>> +                        bindings[param_name] = positional_param.default
>>                     else:
>>                         raise BindError("%r parameter lacking default
>> value" %
>>                                         param_name)
>> @@ -276,39 +252,14 @@
>>         # Keyword-only default values.
>>         else:
>>             for name, param in keyword_only.items():
>> -                if hasattr(param, 'default_value'):
>> -                    bindings[name] = param.default_value
>> +                if hasattr(param, 'default'):
>> +                    bindings[name] = param.default
>>                 else:
>>                     raise BindError("%s parameter lacking a default value"
>> %
>>                                     name)
>>
>>         return bindings
>>
>> -    def _tuple_bind(self, bindings, possible_tuple, value):
>> -        """Where a tuple could be a parameter, handle binding the values
>> to the
>> -        tuple and storing into the bindings mapping."""
>> -        if not isinstance(possible_tuple, tuple):
>> -            bindings[possible_tuple] = value
>> -        else:
>> -            # Need to make sure that value is as long as the parameter,
>> but not
>> -            # vice-versa.
>> -            error_msg = "not enough values to unpack for %r"
>> -            tuple_iter = iter(possible_tuple)
>> -            try:
>> -                value_iter = iter(value)
>> -            except TypeError:
>> -                raise BindError(error_msg % possible_tuple)
>> -            while True:
>> -                try:
>> -                    sub_param = tuple_iter.next()
>> -                except StopIteration:
>> -                    break
>> -                try:
>> -                    sub_value = value_iter.next()
>> -                except StopIteration:
>> -                    raise BindError(error_msg % possible_tuple)
>> -                self._tuple_bind(bindings, sub_param, sub_value)
>> -
>>
>>  def signature(func):
>>     """Return a Signature object for the function or method.
>> @@ -318,15 +269,9 @@
>>     attribute if possible (but is not required).
>>
>>     """
>> -    if hasattr(func, 'im_func'):
>> -        func = func.im_func
>> -    sig = Signature(func)
>> -    if not hasattr(func, '__signature__'):
>> -        try:
>> -            func.__signature__ = sig
>> -        except AttributeError:
>> -            pass
>> -    else:
>> -        sig = func.__signature__
>> -
>> -    return sig
>> +    try:
>> +        return func.__signature__
>> +    except AttributeError:
>> +        sig = Signature(func)
>> +        func.__signature__ = sig
>> +        return sig
>>
>> Deleted: sandbox/trunk/pep362/setup.py
>>
>> ==============================================================================
>> --- sandbox/trunk/pep362/setup.py       Wed Mar 23 22:39:32 2011
>> +++ (empty file)
>> @@ -1,25 +0,0 @@
>> -from distutils.core import setup
>> -
>> -setup(
>> -        # Package metadata.
>> -        name='pep362',
>> -        version='0.6.2',
>> -        description='Implementation of PEP 362 (Function Signature
>> objects)',
>> -        author='Brett Cannon',
>> -        author_email='brett at python.org',
>> -        url='http://svn.python.org/view/sandbox/trunk/pep362/',
>> -        # Files.
>> -        py_modules=['pep362', 'examples'],
>> -        packages=['tests'],
>> -        data_files=['README'],
>> -        classifiers=[
>> -            'Programming Language :: Python :: 2',
>> -            'Programming Language :: Python :: 2.5',
>> -            'Programming Language :: Python :: 2.6',
>> -            'Programming Language :: Python :: 2.7',
>> -            'Programming Language :: Python :: 3',
>> -            'Programming Language :: Python :: 3.0',
>> -            'Programming Language :: Python :: 3.1',
>> -            'Programming Language :: Python :: 3.2',
>> -        ]
>> -    )
>>
>> Copied: sandbox/trunk/pep362/test_pep362.py (from r88415,
>> /sandbox/trunk/pep362/tests/test_pep362.py)
>>
>> ==============================================================================
>> --- /sandbox/trunk/pep362/tests/test_pep362.py  (original)
>> +++ sandbox/trunk/pep362/test_pep362.py Wed Mar 23 22:39:32 2011
>> @@ -1,23 +1,49 @@
>>  import pep362
>>
>>  import unittest
>> -from tests import pep362_fodder
>> -try:
>> -    from tests import pep362_py2_fodder
>> -    from test import test_support
>> -except SyntaxError:
>> -    from tests import pep362_py3k_fodder
>> -    from test import support as test_support
>> +from test import support as test_support
>>  from sys import version_info
>>
>>
>> -def version_specific(major_number):
>> -    def inner(fxn):
>> -        if version_info[0] == major_number:
>> -            return fxn
>> -        else:
>> -            return lambda self: self
>> -    return inner
>> +def no_args():
>> +    pass
>> +
>> +def var_args(*args):
>> +    pass
>> +
>> +def var_kw_args(**kwargs):
>> +    pass
>> +
>> +def no_default_args(a):
>> +    pass
>> +
>> +def default_args(a=42):
>> +    pass
>> +
>> +def keyword_only(*, a):
>> +    pass
>> +
>> +def keyword_only_default(*, a=42):
>> +    pass
>> +
>> +def arg_annotation(a:int):
>> +    pass
>> +
>> +def arg_annotation_default(a:int=42):
>> +    pass
>> +
>> +def arg_annotation_var(*args:int, **kwargs:str):
>> +    pass
>> +
>> +def arg_annotation_keyword_only(*, a:int):
>> +    pass
>> +
>> +def return_annotation() -> int:
>> +    pass
>> +
>> +def all_args(a:int, d=0, *args:int,
>> +                g:int, h:int=8, **kwargs:int) -> int:
>> +    return a, d, g, h, args, kwargs
>>
>>
>>  class ParameterObjectTests(unittest.TestCase):
>> @@ -41,13 +67,14 @@
>>         self.assertEqual(param.position, pos)
>>
>>     def test_default_values(self):
>> -        # Testing that 'default_value' is not set is handled in the
>> testing of
>> +        # Testing that 'default' is not set is handled in the testing of
>>         # that attribute.
>>         default_value = 42
>> -        param = pep362.Parameter('_', 0, True, default_value)
>> -        self.assertEqual(param.default_value, default_value)
>> -        param = pep362.Parameter('_', 0, False)
>> -        self.assertTrue(not hasattr(param, 'default_value'))
>> +        param = pep362.Parameter('_', 0, has_default=True,
>> +                                 default=default_value)
>> +        self.assertEqual(param.default, default_value)
>> +        param = pep362.Parameter('_', 0, has_default=False)
>> +        self.assertTrue(not hasattr(param, 'default'))
>>
>>     def test_keyword_only(self):
>>         # Setting the value for keyword_only should create an attribute.
>> @@ -70,21 +97,21 @@
>>     def test_getitem(self):
>>         # __getitem__() should return the Parameter object for the name
>>         # parameter.
>> -        sig = pep362.Signature(pep362_fodder.default_args)
>> +        sig = pep362.Signature(default_args)
>>         self.assertTrue(sig['a'])
>>         param = sig['a']
>>         self.assertTrue(param.name, 'a')
>>
>>     def test_iter(self):
>>         # The iterator should return all Parameter objects in the proper
>> order.
>> -        sig = pep362.Signature(pep362_fodder.default_args)
>> +        sig = pep362.Signature(default_args)
>>         params = list(sig)
>>         self.assertEqual(len(params), 1)
>>         self.assertEqual(params[0].name, 'a')
>>
>>     def test_no_args(self):
>>         # Test a function with no arguments.
>> -        sig = pep362.Signature(pep362_fodder.no_args)
>> +        sig = pep362.Signature(no_args)
>>         self.assertEqual('no_args', sig.name)
>>         self.assertTrue(not sig.var_args)
>>         self.assertTrue(not sig.var_kw_args)
>> @@ -92,115 +119,87 @@
>>
>>     def test_var_args(self):
>>         # Test the var_args attribute.
>> -        sig = pep362.Signature(pep362_fodder.var_args)
>> +        sig = pep362.Signature(var_args)
>>         self.assertEqual('args', sig.var_args)
>>         self.assertEqual(0, len(list(sig)))
>> -        sig = pep362.Signature(pep362_fodder.no_args)
>> +        sig = pep362.Signature(no_args)
>>         self.assertEqual('', sig.var_args)
>>
>>     def test_var_kw_args(self):
>>         # Test the var_kw_args attribute and annotations.
>> -        sig = pep362.Signature(pep362_fodder.var_kw_args)
>> +        sig = pep362.Signature(var_kw_args)
>>         self.assertEqual('var_kw_args', sig.name)
>>         self.assertEqual('kwargs', sig.var_kw_args)
>>         self.assertEqual(0, len(list(sig)))
>> -        sig = pep362.Signature(pep362_fodder.no_args)
>> +        sig = pep362.Signature(no_args)
>>         self.assertEqual('', sig.var_kw_args)
>>
>>     def test_parameter_positional(self):
>>         # A function with positional arguments should work.
>> -        sig = pep362.Signature(pep362_fodder.no_default_args)
>> +        sig = pep362.Signature(no_default_args)
>>         self.assertEqual('no_default_args', sig.name)
>>         param = sig['a']
>>         self.assertEqual('a', param.name)
>>         self.assertEqual(0, param.position)
>> -        self.assertTrue(not hasattr(param, 'default_value'))
>> +        self.assertTrue(not hasattr(param, 'default'))
>>
>>     def test_parameter_default(self):
>>         # Default parameters for a function should work.
>> -        sig = pep362.Signature(pep362_fodder.default_args)
>> +        sig = pep362.Signature(default_args)
>>         self.assertEqual('default_args', sig.name)
>>         param = sig['a']
>>         self.assertEqual('a', param.name)
>>         self.assertEqual(0, param.position)
>> -        self.assertEqual(42, param.default_value)
>> -
>> -    @version_specific(2)
>> -    def test_parameter_tuple(self):
>> -        # A function with a tuple as a parameter should work.
>> -        sig = pep362.Signature(pep362_py2_fodder.tuple_args)
>> -        self.assertEqual('tuple_args', sig.name)
>> -        param = list(sig)[0]
>> -        self.assertTrue(isinstance(param.name, tuple))
>> -        self.assertEqual(('a', ('b',)), param.name)
>> -        self.assertEqual(0, param.position)
>> -        self.assertTrue(not hasattr(param, 'default_value'))
>> +        self.assertEqual(42, param.default)
>>
>> -    @version_specific(2)
>> -    def test_parameter_tuple_default(self):
>> -        # A default argument for a tuple parameter needs to work.
>> -        sig = pep362.Signature(pep362_py2_fodder.default_tuple_args)
>> -        self.assertEqual('default_tuple_args', sig.name)
>> -        param = list(sig)[0]
>> -        self.assertEqual(('a', ('b',)), param.name)
>> -        self.assertEqual(0, param.position)
>> -        self.assertEqual((1, (2,)), param.default_value)
>> -
>> -    @version_specific(3)
>>     def test_keyword_only(self):
>>         # Is a function containing keyword-only parameters handled
>> properly?
>> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only)
>> +        sig = pep362.Signature(keyword_only)
>>         param = sig['a']
>>         self.assertEqual(param.name, 'a')
>>         self.assertTrue(param.keyword_only)
>>         self.assertEqual(param.position, 0)
>>
>> -    @version_specific(3)
>>     def test_keyword_only_default(self):
>>         # Default arguments can work for keyword-only parameters.
>> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only_default)
>> +        sig = pep362.Signature(keyword_only_default)
>>         param = sig['a']
>>         self.assertEqual(param.name, 'a')
>>         self.assertTrue(param.keyword_only)
>>         self.assertEqual(param.position, 0)
>> -        self.assertEqual(param.default_value, 42)
>> +        self.assertEqual(param.default, 42)
>>
>> -    @version_specific(3)
>>     def test_annotations(self):
>>         # Make sure the proper annotation is found.
>> -        sig = pep362.Signature(pep362_py3k_fodder.arg_annotation)
>> +        sig = pep362.Signature(arg_annotation)
>>         param = sig['a']
>>         self.assertEqual(param.name, 'a')
>>         self.assertEqual(param.annotation, int)
>>
>> -    @version_specific(3)
>>     def test_annotations_default(self):
>>         # Annotations with a default value should work.
>> -        sig = pep362.Signature(pep362_py3k_fodder.arg_annotation_default)
>> +        sig = pep362.Signature(arg_annotation_default)
>>         param = sig['a']
>>         self.assertEqual(param.name, 'a')
>>         self.assertEqual(param.annotation, int)
>> -        self.assertEqual(param.default_value, 42)
>> +        self.assertEqual(param.default, 42)
>>
>> -    @version_specific(3)
>>     def test_annotation_keyword_only(self):
>>         # Keyword-only parameters can have an annotation.
>> -        sig =
>> pep362.Signature(pep362_py3k_fodder.arg_annotation_keyword_only)
>> +        sig = pep362.Signature(arg_annotation_keyword_only)
>>         param = sig['a']
>>         self.assertEqual(param.name, 'a')
>>         self.assertEqual(param.annotation, int)
>>         self.assertTrue(param.keyword_only)
>>
>> -    @version_specific(3)
>>     def test_return_annotation(self):
>>         # The return value annotation.
>> -        sig = pep362.Signature(pep362_py3k_fodder.return_annotation)
>> +        sig = pep362.Signature(return_annotation)
>>         self.assertEqual(sig.return_annotation, int)
>>
>> -    @version_specific(3)
>>     def test_var_annotations(self):
>>         # Annotation on variable arguments (*args & **kwargs).
>> -        sig = pep362.Signature(pep362_py3k_fodder.arg_annotation_var)
>> +        sig = pep362.Signature(arg_annotation_var)
>>         self.assertEqual(sig.var_annotations[sig.var_args], int)
>>         self.assertEqual(sig.var_annotations[sig.var_kw_args], str)
>>
>> @@ -224,14 +223,14 @@
>>     """Test Signature.bind()."""
>>
>>     def test_no_parameters(self):
>> -        sig = pep362.Signature(pep362_fodder.no_args)
>> +        sig = pep362.Signature(no_args)
>>         binding = sig.bind()
>>         self.assertEqual({}, binding)
>>         self.assertRaises(pep362.BindError, sig.bind, 42)
>>         self.assertRaises(pep362.BindError, sig.bind, a=0)
>>
>>     def test_var_parameters(self):
>> -        sig = pep362.Signature(pep362_fodder.var_args)
>> +        sig = pep362.Signature(var_args)
>>         binding = sig.bind(0, 1, 2)
>>         self.assertEqual({'args':(0, 1, 2)}, binding)
>>         binding = sig.bind()
>> @@ -239,7 +238,7 @@
>>         self.assertRaises(pep362.BindError, sig.bind, a=0)
>>
>>     def test_var_kw_parameters(self):
>> -        sig = pep362.Signature(pep362_fodder.var_kw_args)
>> +        sig = pep362.Signature(var_kw_args)
>>         binding = sig.bind(a=0)
>>         self.assertEqual({'kwargs':{'a':0}}, binding)
>>         binding = sig.bind()
>> @@ -247,7 +246,7 @@
>>         self.assertRaises(pep362.BindError, sig.bind, 42)
>>
>>     def test_positional_parameters(self):
>> -        sig = pep362.Signature(pep362_fodder.no_default_args)
>> +        sig = pep362.Signature(no_default_args)
>>         binding = sig.bind(42)
>>         self.assertEqual({'a':42}, binding)
>>         binding = sig.bind(a=42)
>> @@ -257,7 +256,7 @@
>>         self.assertRaises(pep362.BindError, sig.bind, b=0)
>>
>>     def test_keyword_parameters(self):
>> -        sig = pep362.Signature(pep362_fodder.default_args)
>> +        sig = pep362.Signature(default_args)
>>         binding = sig.bind()
>>         self.assertEqual({'a':42}, binding)
>>         binding = sig.bind(0)
>> @@ -268,73 +267,24 @@
>>         self.assertRaises(pep362.BindError, sig.bind, a=0, b=1)
>>         self.assertRaises(pep362.BindError, sig.bind, b=1)
>>
>> -    @version_specific(2)
>> -    def test_tuple_parameter(self):
>> -        sig = pep362.Signature(pep362_py2_fodder.tuple_args)
>> -        arg = (1, ((2,),))
>> -        binding = sig.bind(arg)
>> -        self.assertEqual({'a':1, 'b':(2,)}, binding)
>> -        self.assertRaises(pep362.BindError, sig.bind, (1,2,3))
>> -        self.assertRaises(pep362.BindError, sig.bind, (1, 2))
>> -
>> -    @version_specific(2)
>> -    def test_default_tuple_parameter(self):
>> -        sig = pep362.Signature(pep362_py2_fodder.default_tuple_args)
>> -        binding = sig.bind()
>> -        self.assertEqual({'a':1, 'b':2}, binding)
>> -        arg = (0, (1,))
>> -        binding = sig.bind(arg)
>> -        self.assertEqual({'a':0, 'b':1}, binding)
>> -
>> -    @version_specific(2)
>> -    def test_py2_all_args(self):
>> -        sig = pep362.Signature(pep362_py2_fodder.all_args)
>> -        # a, (b, (c,)), d=0, (e, (f,))=(4, (5,)), *g, **h
>> -        # name, position, has_default, default value
>> -        expect = (('a', 0, False, None),
>> -                    (('b', ('c',)), 1, False, None),
>> -                    ('d', 2, True, 0),
>> -                    (('e', ('f',)), 3, True, (4, (5,))))
>> -        self.assertEqual(len(list(sig)), len(expect))
>> -        for param, check in zip(list(sig), expect):
>> -            name, pos, has_default, default_value = check
>> -            self.assertEqual(param.name, name)
>> -            self.assertEqual(param.position, pos)
>> -            if has_default:
>> -                self.assertEqual(param.default_value, default_value)
>> -            else:
>> -                self.assertTrue(not hasattr(param, 'default_value'))
>> -            self.assertTrue(not param.keyword_only)
>> -            self.assertTrue(not hasattr(param, 'annotation'))
>> -        self.assertEqual(sig.var_args, 'g')
>> -        self.assertEqual(sig.var_kw_args, 'h')
>> -        self.assertEqual(len(sig.var_annotations), 0)
>> -        binding = sig.bind(0, (1, (2,)), d=3, i=7)
>> -        expected = {'a':0, 'b':1, 'c':2, 'd':3, 'e':4, 'f':5,
>> 'g':tuple(),
>> -                    'h':{'i':7}}
>> -        self.assertEqual(expected, binding)
>> -
>> -    @version_specific(3)
>>     def test_keyword_only(self):
>> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only)
>> +        sig = pep362.Signature(keyword_only)
>>         binding = sig.bind(a=42)
>>         self.assertEqual(binding, {'a':42})
>>         self.assertRaises(pep362.BindError, sig.bind)
>>         self.assertRaises(pep362.BindError, sig.bind, 42)
>>
>> -    @version_specific(3)
>>     def test_keyword_only_default(self):
>> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only_default)
>> +        sig = pep362.Signature(keyword_only_default)
>>         binding = sig.bind()
>>         self.assertEqual(binding, {'a':42})
>>         binding = sig.bind(a=1)
>>         self.assertEqual(binding, {'a':1})
>>         self.assertRaises(pep362.BindError, sig.bind, 1)
>>
>> -    @version_specific(3)
>>     def test_all_py3k_args(self):
>>         # a:int, d=0, *args:int, g:int, h:int=8, **kwargs:int) -> int
>> -        sig = pep362.Signature(pep362_py3k_fodder.all_args)
>> +        sig = pep362.Signature(all_args)
>>         # name, position, kw only, has_default, default, has anno, anno
>>         expected = (('a', 0, False, False, None, True, int),
>>                     ('d', 1, False, True, 0, False, None),
>> @@ -353,9 +303,9 @@
>>             else:
>>                 self.assertTrue(not param.keyword_only)
>>             if has_default:
>> -                self.assertEqual(param.default_value, default)
>> +                self.assertEqual(param.default, default)
>>             else:
>> -                self.assertTrue(not hasattr(param, 'default_value'))
>> +                self.assertTrue(not hasattr(param, 'default'))
>>             if has_anno:
>>                 self.assertEqual(param.annotation, anno)
>>             else:
>> @@ -373,7 +323,7 @@
>>
>>     def test_too_many_arguments(self):
>>         # Only one argument should pair up with a parameter.
>> -        sig = pep362.Signature(pep362_fodder.no_default_args)
>> +        sig = pep362.Signature(no_default_args)
>>         self.assertRaises(pep362.BindError, sig.bind, 1, a=1)
>>
>>
>> _______________________________________________
>> Python-checkins mailing list
>> Python-checkins at python.org
>> http://mail.python.org/mailman/listinfo/python-checkins
>>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/b3a1d328/attachment-0001.html>

From guido at python.org  Thu Mar 24 18:12:18 2011
From: guido at python.org (Guido van Rossum)
Date: Thu, 24 Mar 2011 10:12:18 -0700
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <AANLkTi=tyeEY6KU+P=J=jruEF1z-O0njfNt_Bs=k_mWZ@mail.gmail.com>
References: <4D8B73F2.50700@jcea.es>
	<AANLkTi=tyeEY6KU+P=J=jruEF1z-O0njfNt_Bs=k_mWZ@mail.gmail.com>
Message-ID: <AANLkTimtwo3U73KvgBksurTKRP2B2MN-1h2iW=N-SA3X@mail.gmail.com>

On Thu, Mar 24, 2011 at 9:46 AM, Benjamin Peterson <benjamin at python.org> wrote:
>> I want to test the dev community interest in modifying the stdlib to
>> ease dependence injection.
>
> I, for one, am -1. Code shouldn't be uglified for the purposes of
> testing.

Well, the philosophy of dependency injection requires exactly that.
Personally I am on the fence; I've seen is used effectively but I've
also seen code, indeed, uglified with little benefits. (Same for other
extreme testing practices like TDD.)

> It's also a slippery slope. Maybe we should add parameters
> for open() and io functions? What about sys and os? Those often need
> to be mocked.

There are existing solutions that work pretty well, so I'm thinking
there is no big problem that this solved.

But my main concern is about anything that proposed to make sweeping
changes to a large number of stdlib modules. This has almost always
resulted in reduced quality.

-- 
--Guido van Rossum (python.org/~guido)

From ericsnowcurrently at gmail.com  Thu Mar 24 18:25:35 2011
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Thu, 24 Mar 2011 11:25:35 -0600
Subject: [Python-Dev] [Python-checkins] r88796 - in
 sandbox/trunk/pep362: pep362.py setup.py test_pep362.py tests
In-Reply-To: <AANLkTik8Qm-n+1prQPw2bRzsrwTJdpkzEhxdYk5A0B63@mail.gmail.com>
References: <3Pw46Y065Fz7Lln@mail.python.org>
	<AANLkTikdPnhHn70usyYxAM+WmefL+Ko3MZmn_jaAZPNi@mail.gmail.com>
	<AANLkTik8Qm-n+1prQPw2bRzsrwTJdpkzEhxdYk5A0B63@mail.gmail.com>
Message-ID: <AANLkTi=P0MjUjKd5rowDFb=JmKoL390e5oMMscHzmSV8@mail.gmail.com>

Take your time, but hurry up ;)

On Thu, Mar 24, 2011 at 10:57 AM, Brett Cannon <brett at python.org> wrote:

>
>
> On Wed, Mar 23, 2011 at 21:38, Eric Snow <ericsnowcurrently at gmail.com>wrote:
>
>> Shouldn't the Signature class also support building from args and not just
>> a function object? Then I could use a Signature object when building a
>> function object, or vice versa.  Having the ability to validate args/kwargs
>> against a Signature object, sort of like provided by the bind method, will
>> be helpful, particularly with the decorator use case.
>
>
> I will probably try to add that functionality, but one thing at a time. =)
>
>
>
>>  What does the tuple form of Parameter.name represent?
>
>
> What tuple form? If you mean tuple parameters those no longer exist.
>
>
>>  Did you come to any conclusion on the open issues in the PEP?
>
>
> Nope. You are getting ahead of me. =)
>
> -Brett
>
>
>>
>> With the exec_closure stuff I have been looking pretty closely at
>> function-related C-API capability that might be worth exposing better in
>> python, and Signature objects would help facilitate in a much clearer way.
>>  Not only that, but even though CPython won't use Signature objects behind
>> the scenes, they can help to make the internal operations of Python more
>> clear by exposing the underlying mechanisms in pure python.  For example,
>> with a validate method you could express how args and kwargs are mapped onto
>> the different parts of the code object which correspond to the parts of the
>> Signature object.
>>
>> I am looking forward to the inclusion of the function signature stuff in
>> 3.3.
>>
>> -eric
>>
>>
>> On Wed, Mar 23, 2011 at 3:39 PM, brett.cannon <python-checkins at python.org
>> > wrote:
>>
>>> Author: brett.cannon
>>> Date: Wed Mar 23 22:39:32 2011
>>> New Revision: 88796
>>>
>>> Log:
>>> Update code for future inclusion in Python 3.3 (when I get around to it).
>>>
>>> Added:
>>>   sandbox/trunk/pep362/test_pep362.py
>>>      - copied, changed from r88415,
>>> /sandbox/trunk/pep362/tests/test_pep362.py
>>> Removed:
>>>   sandbox/trunk/pep362/setup.py
>>>   sandbox/trunk/pep362/tests/
>>> Modified:
>>>   sandbox/trunk/pep362/   (props changed)
>>>   sandbox/trunk/pep362/pep362.py
>>>
>>> Modified: sandbox/trunk/pep362/pep362.py
>>>
>>> ==============================================================================
>>> --- sandbox/trunk/pep362/pep362.py      (original)
>>> +++ sandbox/trunk/pep362/pep362.py      Wed Mar 23 22:39:32 2011
>>> @@ -8,7 +8,7 @@
>>>     pass
>>>
>>>
>>> -class Parameter(object):
>>> +class Parameter:
>>>
>>>     """Represent a parameter in a function signature.
>>>
>>> @@ -31,8 +31,9 @@
>>>
>>>     """
>>>
>>> -    def __init__(self, name, position, has_default=False,
>>> default_value=None,
>>> -                 keyword_only=False, has_annotation=False,
>>> annotation=None):
>>> +    def __init__(self, name, position, *, has_default=False,
>>> +                 default=None, keyword_only=False, has_annotation=False,
>>> +                 annotation=None):
>>>         """Initialize a Parameter instance.
>>>
>>>         For has_* arguments, if they are False then the corresponding *
>>> @@ -42,13 +43,13 @@
>>>         self.name = name
>>>         self.position = position
>>>         if has_default:
>>> -            self.default_value = default_value
>>> +            self.default = default
>>>         self.keyword_only = keyword_only
>>>         if has_annotation:
>>>             self.annotation = annotation
>>>
>>>
>>> -class Signature(object):
>>> +class Signature:
>>>
>>>     """Object to represent the signature of a function/method.
>>>
>>> @@ -74,39 +75,19 @@
>>>
>>>     def __init__(self, func):
>>>         """Initialize from a function or method object."""
>>> -        if hasattr(func, 'im_func'):
>>> -            func = func.im_func
>>> -        try:
>>> -            func_code = func.__code__
>>> -        except AttributeError:
>>> -            # Compatibility for versions < 2.6.
>>> -            func_code = func.func_code
>>> -
>>> +        func_code = func.__code__
>>>         self.name = func.__name__
>>> -
>>> -        try:
>>> -            # Unneeded once 2.x support is removed; can easily get info
>>> the
>>> -            #  "hard" way.
>>> -            argspec = inspect.getfullargspec(func)[:4]
>>> -        except AttributeError:
>>> -            # Needed only for tuple parameters.
>>> -            argspec = inspect.getargspec(func)
>>> +        # XXX replace with own implementation
>>> +        argspec = inspect.getfullargspec(func)[:4]
>>>         parameters = {}
>>>
>>>         # Parameter information.
>>>         pos_count = func_code.co_argcount
>>> -        if hasattr(func_code, 'co_kwonlyargcount'):
>>> -            keyword_only_count = func_code.co_kwonlyargcount
>>> -        else:
>>> -            keyword_only_count = 0
>>> +        keyword_only_count = func_code.co_kwonlyargcount
>>>         positional = argspec[0]
>>>         keyword_only = func_code.co_varnames[pos_count:
>>>
>>> pos_count+keyword_only_count]
>>> -        try:
>>> -            fxn_defaults = func.__defaults__
>>> -        except AttributeError:
>>> -            # Deal with old names prior to 2.6.
>>> -            fxn_defaults = func.func_defaults
>>> +        fxn_defaults = func.__defaults__
>>>         if fxn_defaults:
>>>             pos_default_count = len(fxn_defaults)
>>>         else:
>>> @@ -126,7 +107,7 @@
>>>             has_annotation, annotation = self._find_annotation(func,
>>> name)
>>>             default_value = fxn_defaults[offset]
>>>             param = Parameter(name, offset+non_default_count,
>>> -                                has_default=True,
>>> default_value=default_value,
>>> +                                has_default=True, default=default_value,
>>>                                 has_annotation=has_annotation,
>>>                                 annotation=annotation)
>>>             parameters[name] = param
>>> @@ -134,16 +115,14 @@
>>>         for offset, name in enumerate(keyword_only):
>>>             has_annotation, annotation = self._find_annotation(func,
>>> name)
>>>             has_default, default_value = False, None
>>> -            # hasattr check only needed for versions < 2.6.
>>> -            if (hasattr(func, '__kwdefaults__') and func.__kwdefaults__
>>> and
>>> -                    name in func.__kwdefaults__):
>>> +            if func.__kwdefaults__ and name in func.__kwdefaults__:
>>>                 has_default = True
>>>                 default_value = func.__kwdefaults__[name]
>>>             param = Parameter(name, offset+pos_count, keyword_only=True,
>>> -                                has_default=has_default,
>>> -                                default_value=default_value,
>>> -                                has_annotation=has_annotation,
>>> -                                annotation=annotation)
>>> +                              has_default=has_default,
>>> +                              default=default_value,
>>> +                              has_annotation=has_annotation,
>>> +                              annotation=annotation)
>>>             parameters[name] = param
>>>         # Variable parameters.
>>>         index = pos_count + keyword_only_count
>>> @@ -172,9 +151,8 @@
>>>         self._parameters = parameters
>>>
>>>         # Return annotation.
>>> -        if hasattr(func, '__annotations__'):
>>> -            if 'return' in func.__annotations__:
>>> -                self.return_annotation = func.__annotations__['return']
>>> +        if 'return' in func.__annotations__:
>>> +            self.return_annotation = func.__annotations__['return']
>>>
>>>     def __getitem__(self, key):
>>>         return self._parameters[key]
>>> @@ -186,10 +164,9 @@
>>>         """Return True if an annotation exists for the named parameter
>>> along
>>>         with its annotation, else return False and None."""
>>>         has_annotation, annotation = False, None
>>> -        if hasattr(func, '__annotations__'):
>>> -            if name in func.__annotations__:
>>> -                has_annotation = True
>>> -                annotation = func.__annotations__[name]
>>> +        if name in func.__annotations__:
>>> +            has_annotation = True
>>> +            annotation = func.__annotations__[name]
>>>         return has_annotation, annotation
>>>
>>>     def _convert_name(self, name):
>>> @@ -234,7 +211,7 @@
>>>                     break
>>>                 else:
>>>                     raise BindError("too many positional arguments")
>>> -            self._tuple_bind(bindings, param.name, position_arg)
>>> +            bindings[param.name] = position_arg
>>>             args = args[1:]
>>>         # Keyword arguments & default values.
>>>         else:
>>> @@ -247,9 +224,8 @@
>>>                     except KeyError:
>>>                         raise BindError("%r unbound" % param_name)
>>>                 else:
>>> -                    if hasattr(positional_param, 'default_value'):
>>> -                        self._tuple_bind(bindings, param_name,
>>> -
>>>  positional_param.default_value)
>>> +                    if hasattr(positional_param, 'default'):
>>> +                        bindings[param_name] = positional_param.default
>>>                     else:
>>>                         raise BindError("%r parameter lacking default
>>> value" %
>>>                                         param_name)
>>> @@ -276,39 +252,14 @@
>>>         # Keyword-only default values.
>>>         else:
>>>             for name, param in keyword_only.items():
>>> -                if hasattr(param, 'default_value'):
>>> -                    bindings[name] = param.default_value
>>> +                if hasattr(param, 'default'):
>>> +                    bindings[name] = param.default
>>>                 else:
>>>                     raise BindError("%s parameter lacking a default
>>> value" %
>>>                                     name)
>>>
>>>         return bindings
>>>
>>> -    def _tuple_bind(self, bindings, possible_tuple, value):
>>> -        """Where a tuple could be a parameter, handle binding the values
>>> to the
>>> -        tuple and storing into the bindings mapping."""
>>> -        if not isinstance(possible_tuple, tuple):
>>> -            bindings[possible_tuple] = value
>>> -        else:
>>> -            # Need to make sure that value is as long as the parameter,
>>> but not
>>> -            # vice-versa.
>>> -            error_msg = "not enough values to unpack for %r"
>>> -            tuple_iter = iter(possible_tuple)
>>> -            try:
>>> -                value_iter = iter(value)
>>> -            except TypeError:
>>> -                raise BindError(error_msg % possible_tuple)
>>> -            while True:
>>> -                try:
>>> -                    sub_param = tuple_iter.next()
>>> -                except StopIteration:
>>> -                    break
>>> -                try:
>>> -                    sub_value = value_iter.next()
>>> -                except StopIteration:
>>> -                    raise BindError(error_msg % possible_tuple)
>>> -                self._tuple_bind(bindings, sub_param, sub_value)
>>> -
>>>
>>>  def signature(func):
>>>     """Return a Signature object for the function or method.
>>> @@ -318,15 +269,9 @@
>>>     attribute if possible (but is not required).
>>>
>>>     """
>>> -    if hasattr(func, 'im_func'):
>>> -        func = func.im_func
>>> -    sig = Signature(func)
>>> -    if not hasattr(func, '__signature__'):
>>> -        try:
>>> -            func.__signature__ = sig
>>> -        except AttributeError:
>>> -            pass
>>> -    else:
>>> -        sig = func.__signature__
>>> -
>>> -    return sig
>>> +    try:
>>> +        return func.__signature__
>>> +    except AttributeError:
>>> +        sig = Signature(func)
>>> +        func.__signature__ = sig
>>> +        return sig
>>>
>>> Deleted: sandbox/trunk/pep362/setup.py
>>>
>>> ==============================================================================
>>> --- sandbox/trunk/pep362/setup.py       Wed Mar 23 22:39:32 2011
>>> +++ (empty file)
>>> @@ -1,25 +0,0 @@
>>> -from distutils.core import setup
>>> -
>>> -setup(
>>> -        # Package metadata.
>>> -        name='pep362',
>>> -        version='0.6.2',
>>> -        description='Implementation of PEP 362 (Function Signature
>>> objects)',
>>> -        author='Brett Cannon',
>>> -        author_email='brett at python.org',
>>> -        url='http://svn.python.org/view/sandbox/trunk/pep362/',
>>> -        # Files.
>>> -        py_modules=['pep362', 'examples'],
>>> -        packages=['tests'],
>>> -        data_files=['README'],
>>> -        classifiers=[
>>> -            'Programming Language :: Python :: 2',
>>> -            'Programming Language :: Python :: 2.5',
>>> -            'Programming Language :: Python :: 2.6',
>>> -            'Programming Language :: Python :: 2.7',
>>> -            'Programming Language :: Python :: 3',
>>> -            'Programming Language :: Python :: 3.0',
>>> -            'Programming Language :: Python :: 3.1',
>>> -            'Programming Language :: Python :: 3.2',
>>> -        ]
>>> -    )
>>>
>>> Copied: sandbox/trunk/pep362/test_pep362.py (from r88415,
>>> /sandbox/trunk/pep362/tests/test_pep362.py)
>>>
>>> ==============================================================================
>>> --- /sandbox/trunk/pep362/tests/test_pep362.py  (original)
>>> +++ sandbox/trunk/pep362/test_pep362.py Wed Mar 23 22:39:32 2011
>>> @@ -1,23 +1,49 @@
>>>  import pep362
>>>
>>>  import unittest
>>> -from tests import pep362_fodder
>>> -try:
>>> -    from tests import pep362_py2_fodder
>>> -    from test import test_support
>>> -except SyntaxError:
>>> -    from tests import pep362_py3k_fodder
>>> -    from test import support as test_support
>>> +from test import support as test_support
>>>  from sys import version_info
>>>
>>>
>>> -def version_specific(major_number):
>>> -    def inner(fxn):
>>> -        if version_info[0] == major_number:
>>> -            return fxn
>>> -        else:
>>> -            return lambda self: self
>>> -    return inner
>>> +def no_args():
>>> +    pass
>>> +
>>> +def var_args(*args):
>>> +    pass
>>> +
>>> +def var_kw_args(**kwargs):
>>> +    pass
>>> +
>>> +def no_default_args(a):
>>> +    pass
>>> +
>>> +def default_args(a=42):
>>> +    pass
>>> +
>>> +def keyword_only(*, a):
>>> +    pass
>>> +
>>> +def keyword_only_default(*, a=42):
>>> +    pass
>>> +
>>> +def arg_annotation(a:int):
>>> +    pass
>>> +
>>> +def arg_annotation_default(a:int=42):
>>> +    pass
>>> +
>>> +def arg_annotation_var(*args:int, **kwargs:str):
>>> +    pass
>>> +
>>> +def arg_annotation_keyword_only(*, a:int):
>>> +    pass
>>> +
>>> +def return_annotation() -> int:
>>> +    pass
>>> +
>>> +def all_args(a:int, d=0, *args:int,
>>> +                g:int, h:int=8, **kwargs:int) -> int:
>>> +    return a, d, g, h, args, kwargs
>>>
>>>
>>>  class ParameterObjectTests(unittest.TestCase):
>>> @@ -41,13 +67,14 @@
>>>         self.assertEqual(param.position, pos)
>>>
>>>     def test_default_values(self):
>>> -        # Testing that 'default_value' is not set is handled in the
>>> testing of
>>> +        # Testing that 'default' is not set is handled in the testing of
>>>         # that attribute.
>>>         default_value = 42
>>> -        param = pep362.Parameter('_', 0, True, default_value)
>>> -        self.assertEqual(param.default_value, default_value)
>>> -        param = pep362.Parameter('_', 0, False)
>>> -        self.assertTrue(not hasattr(param, 'default_value'))
>>> +        param = pep362.Parameter('_', 0, has_default=True,
>>> +                                 default=default_value)
>>> +        self.assertEqual(param.default, default_value)
>>> +        param = pep362.Parameter('_', 0, has_default=False)
>>> +        self.assertTrue(not hasattr(param, 'default'))
>>>
>>>     def test_keyword_only(self):
>>>         # Setting the value for keyword_only should create an attribute.
>>> @@ -70,21 +97,21 @@
>>>     def test_getitem(self):
>>>         # __getitem__() should return the Parameter object for the name
>>>         # parameter.
>>> -        sig = pep362.Signature(pep362_fodder.default_args)
>>> +        sig = pep362.Signature(default_args)
>>>         self.assertTrue(sig['a'])
>>>         param = sig['a']
>>>         self.assertTrue(param.name, 'a')
>>>
>>>     def test_iter(self):
>>>         # The iterator should return all Parameter objects in the proper
>>> order.
>>> -        sig = pep362.Signature(pep362_fodder.default_args)
>>> +        sig = pep362.Signature(default_args)
>>>         params = list(sig)
>>>         self.assertEqual(len(params), 1)
>>>         self.assertEqual(params[0].name, 'a')
>>>
>>>     def test_no_args(self):
>>>         # Test a function with no arguments.
>>> -        sig = pep362.Signature(pep362_fodder.no_args)
>>> +        sig = pep362.Signature(no_args)
>>>         self.assertEqual('no_args', sig.name)
>>>         self.assertTrue(not sig.var_args)
>>>         self.assertTrue(not sig.var_kw_args)
>>> @@ -92,115 +119,87 @@
>>>
>>>     def test_var_args(self):
>>>         # Test the var_args attribute.
>>> -        sig = pep362.Signature(pep362_fodder.var_args)
>>> +        sig = pep362.Signature(var_args)
>>>         self.assertEqual('args', sig.var_args)
>>>         self.assertEqual(0, len(list(sig)))
>>> -        sig = pep362.Signature(pep362_fodder.no_args)
>>> +        sig = pep362.Signature(no_args)
>>>         self.assertEqual('', sig.var_args)
>>>
>>>     def test_var_kw_args(self):
>>>         # Test the var_kw_args attribute and annotations.
>>> -        sig = pep362.Signature(pep362_fodder.var_kw_args)
>>> +        sig = pep362.Signature(var_kw_args)
>>>         self.assertEqual('var_kw_args', sig.name)
>>>         self.assertEqual('kwargs', sig.var_kw_args)
>>>         self.assertEqual(0, len(list(sig)))
>>> -        sig = pep362.Signature(pep362_fodder.no_args)
>>> +        sig = pep362.Signature(no_args)
>>>         self.assertEqual('', sig.var_kw_args)
>>>
>>>     def test_parameter_positional(self):
>>>         # A function with positional arguments should work.
>>> -        sig = pep362.Signature(pep362_fodder.no_default_args)
>>> +        sig = pep362.Signature(no_default_args)
>>>         self.assertEqual('no_default_args', sig.name)
>>>         param = sig['a']
>>>         self.assertEqual('a', param.name)
>>>         self.assertEqual(0, param.position)
>>> -        self.assertTrue(not hasattr(param, 'default_value'))
>>> +        self.assertTrue(not hasattr(param, 'default'))
>>>
>>>     def test_parameter_default(self):
>>>         # Default parameters for a function should work.
>>> -        sig = pep362.Signature(pep362_fodder.default_args)
>>> +        sig = pep362.Signature(default_args)
>>>         self.assertEqual('default_args', sig.name)
>>>         param = sig['a']
>>>         self.assertEqual('a', param.name)
>>>         self.assertEqual(0, param.position)
>>> -        self.assertEqual(42, param.default_value)
>>> -
>>> -    @version_specific(2)
>>> -    def test_parameter_tuple(self):
>>> -        # A function with a tuple as a parameter should work.
>>> -        sig = pep362.Signature(pep362_py2_fodder.tuple_args)
>>> -        self.assertEqual('tuple_args', sig.name)
>>> -        param = list(sig)[0]
>>> -        self.assertTrue(isinstance(param.name, tuple))
>>> -        self.assertEqual(('a', ('b',)), param.name)
>>> -        self.assertEqual(0, param.position)
>>> -        self.assertTrue(not hasattr(param, 'default_value'))
>>> +        self.assertEqual(42, param.default)
>>>
>>> -    @version_specific(2)
>>> -    def test_parameter_tuple_default(self):
>>> -        # A default argument for a tuple parameter needs to work.
>>> -        sig = pep362.Signature(pep362_py2_fodder.default_tuple_args)
>>> -        self.assertEqual('default_tuple_args', sig.name)
>>> -        param = list(sig)[0]
>>> -        self.assertEqual(('a', ('b',)), param.name)
>>> -        self.assertEqual(0, param.position)
>>> -        self.assertEqual((1, (2,)), param.default_value)
>>> -
>>> -    @version_specific(3)
>>>     def test_keyword_only(self):
>>>         # Is a function containing keyword-only parameters handled
>>> properly?
>>> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only)
>>> +        sig = pep362.Signature(keyword_only)
>>>         param = sig['a']
>>>         self.assertEqual(param.name, 'a')
>>>         self.assertTrue(param.keyword_only)
>>>         self.assertEqual(param.position, 0)
>>>
>>> -    @version_specific(3)
>>>     def test_keyword_only_default(self):
>>>         # Default arguments can work for keyword-only parameters.
>>> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only_default)
>>> +        sig = pep362.Signature(keyword_only_default)
>>>         param = sig['a']
>>>         self.assertEqual(param.name, 'a')
>>>         self.assertTrue(param.keyword_only)
>>>         self.assertEqual(param.position, 0)
>>> -        self.assertEqual(param.default_value, 42)
>>> +        self.assertEqual(param.default, 42)
>>>
>>> -    @version_specific(3)
>>>     def test_annotations(self):
>>>         # Make sure the proper annotation is found.
>>> -        sig = pep362.Signature(pep362_py3k_fodder.arg_annotation)
>>> +        sig = pep362.Signature(arg_annotation)
>>>         param = sig['a']
>>>         self.assertEqual(param.name, 'a')
>>>         self.assertEqual(param.annotation, int)
>>>
>>> -    @version_specific(3)
>>>     def test_annotations_default(self):
>>>         # Annotations with a default value should work.
>>> -        sig =
>>> pep362.Signature(pep362_py3k_fodder.arg_annotation_default)
>>> +        sig = pep362.Signature(arg_annotation_default)
>>>         param = sig['a']
>>>         self.assertEqual(param.name, 'a')
>>>         self.assertEqual(param.annotation, int)
>>> -        self.assertEqual(param.default_value, 42)
>>> +        self.assertEqual(param.default, 42)
>>>
>>> -    @version_specific(3)
>>>     def test_annotation_keyword_only(self):
>>>         # Keyword-only parameters can have an annotation.
>>> -        sig =
>>> pep362.Signature(pep362_py3k_fodder.arg_annotation_keyword_only)
>>> +        sig = pep362.Signature(arg_annotation_keyword_only)
>>>         param = sig['a']
>>>         self.assertEqual(param.name, 'a')
>>>         self.assertEqual(param.annotation, int)
>>>         self.assertTrue(param.keyword_only)
>>>
>>> -    @version_specific(3)
>>>     def test_return_annotation(self):
>>>         # The return value annotation.
>>> -        sig = pep362.Signature(pep362_py3k_fodder.return_annotation)
>>> +        sig = pep362.Signature(return_annotation)
>>>         self.assertEqual(sig.return_annotation, int)
>>>
>>> -    @version_specific(3)
>>>     def test_var_annotations(self):
>>>         # Annotation on variable arguments (*args & **kwargs).
>>> -        sig = pep362.Signature(pep362_py3k_fodder.arg_annotation_var)
>>> +        sig = pep362.Signature(arg_annotation_var)
>>>         self.assertEqual(sig.var_annotations[sig.var_args], int)
>>>         self.assertEqual(sig.var_annotations[sig.var_kw_args], str)
>>>
>>> @@ -224,14 +223,14 @@
>>>     """Test Signature.bind()."""
>>>
>>>     def test_no_parameters(self):
>>> -        sig = pep362.Signature(pep362_fodder.no_args)
>>> +        sig = pep362.Signature(no_args)
>>>         binding = sig.bind()
>>>         self.assertEqual({}, binding)
>>>         self.assertRaises(pep362.BindError, sig.bind, 42)
>>>         self.assertRaises(pep362.BindError, sig.bind, a=0)
>>>
>>>     def test_var_parameters(self):
>>> -        sig = pep362.Signature(pep362_fodder.var_args)
>>> +        sig = pep362.Signature(var_args)
>>>         binding = sig.bind(0, 1, 2)
>>>         self.assertEqual({'args':(0, 1, 2)}, binding)
>>>         binding = sig.bind()
>>> @@ -239,7 +238,7 @@
>>>         self.assertRaises(pep362.BindError, sig.bind, a=0)
>>>
>>>     def test_var_kw_parameters(self):
>>> -        sig = pep362.Signature(pep362_fodder.var_kw_args)
>>> +        sig = pep362.Signature(var_kw_args)
>>>         binding = sig.bind(a=0)
>>>         self.assertEqual({'kwargs':{'a':0}}, binding)
>>>         binding = sig.bind()
>>> @@ -247,7 +246,7 @@
>>>         self.assertRaises(pep362.BindError, sig.bind, 42)
>>>
>>>     def test_positional_parameters(self):
>>> -        sig = pep362.Signature(pep362_fodder.no_default_args)
>>> +        sig = pep362.Signature(no_default_args)
>>>         binding = sig.bind(42)
>>>         self.assertEqual({'a':42}, binding)
>>>         binding = sig.bind(a=42)
>>> @@ -257,7 +256,7 @@
>>>         self.assertRaises(pep362.BindError, sig.bind, b=0)
>>>
>>>     def test_keyword_parameters(self):
>>> -        sig = pep362.Signature(pep362_fodder.default_args)
>>> +        sig = pep362.Signature(default_args)
>>>         binding = sig.bind()
>>>         self.assertEqual({'a':42}, binding)
>>>         binding = sig.bind(0)
>>> @@ -268,73 +267,24 @@
>>>         self.assertRaises(pep362.BindError, sig.bind, a=0, b=1)
>>>         self.assertRaises(pep362.BindError, sig.bind, b=1)
>>>
>>> -    @version_specific(2)
>>> -    def test_tuple_parameter(self):
>>> -        sig = pep362.Signature(pep362_py2_fodder.tuple_args)
>>> -        arg = (1, ((2,),))
>>> -        binding = sig.bind(arg)
>>> -        self.assertEqual({'a':1, 'b':(2,)}, binding)
>>> -        self.assertRaises(pep362.BindError, sig.bind, (1,2,3))
>>> -        self.assertRaises(pep362.BindError, sig.bind, (1, 2))
>>> -
>>> -    @version_specific(2)
>>> -    def test_default_tuple_parameter(self):
>>> -        sig = pep362.Signature(pep362_py2_fodder.default_tuple_args)
>>> -        binding = sig.bind()
>>> -        self.assertEqual({'a':1, 'b':2}, binding)
>>> -        arg = (0, (1,))
>>> -        binding = sig.bind(arg)
>>> -        self.assertEqual({'a':0, 'b':1}, binding)
>>> -
>>> -    @version_specific(2)
>>> -    def test_py2_all_args(self):
>>> -        sig = pep362.Signature(pep362_py2_fodder.all_args)
>>> -        # a, (b, (c,)), d=0, (e, (f,))=(4, (5,)), *g, **h
>>> -        # name, position, has_default, default value
>>> -        expect = (('a', 0, False, None),
>>> -                    (('b', ('c',)), 1, False, None),
>>> -                    ('d', 2, True, 0),
>>> -                    (('e', ('f',)), 3, True, (4, (5,))))
>>> -        self.assertEqual(len(list(sig)), len(expect))
>>> -        for param, check in zip(list(sig), expect):
>>> -            name, pos, has_default, default_value = check
>>> -            self.assertEqual(param.name, name)
>>> -            self.assertEqual(param.position, pos)
>>> -            if has_default:
>>> -                self.assertEqual(param.default_value, default_value)
>>> -            else:
>>> -                self.assertTrue(not hasattr(param, 'default_value'))
>>> -            self.assertTrue(not param.keyword_only)
>>> -            self.assertTrue(not hasattr(param, 'annotation'))
>>> -        self.assertEqual(sig.var_args, 'g')
>>> -        self.assertEqual(sig.var_kw_args, 'h')
>>> -        self.assertEqual(len(sig.var_annotations), 0)
>>> -        binding = sig.bind(0, (1, (2,)), d=3, i=7)
>>> -        expected = {'a':0, 'b':1, 'c':2, 'd':3, 'e':4, 'f':5,
>>> 'g':tuple(),
>>> -                    'h':{'i':7}}
>>> -        self.assertEqual(expected, binding)
>>> -
>>> -    @version_specific(3)
>>>     def test_keyword_only(self):
>>> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only)
>>> +        sig = pep362.Signature(keyword_only)
>>>         binding = sig.bind(a=42)
>>>         self.assertEqual(binding, {'a':42})
>>>         self.assertRaises(pep362.BindError, sig.bind)
>>>         self.assertRaises(pep362.BindError, sig.bind, 42)
>>>
>>> -    @version_specific(3)
>>>     def test_keyword_only_default(self):
>>> -        sig = pep362.Signature(pep362_py3k_fodder.keyword_only_default)
>>> +        sig = pep362.Signature(keyword_only_default)
>>>         binding = sig.bind()
>>>         self.assertEqual(binding, {'a':42})
>>>         binding = sig.bind(a=1)
>>>         self.assertEqual(binding, {'a':1})
>>>         self.assertRaises(pep362.BindError, sig.bind, 1)
>>>
>>> -    @version_specific(3)
>>>     def test_all_py3k_args(self):
>>>         # a:int, d=0, *args:int, g:int, h:int=8, **kwargs:int) -> int
>>> -        sig = pep362.Signature(pep362_py3k_fodder.all_args)
>>> +        sig = pep362.Signature(all_args)
>>>         # name, position, kw only, has_default, default, has anno, anno
>>>         expected = (('a', 0, False, False, None, True, int),
>>>                     ('d', 1, False, True, 0, False, None),
>>> @@ -353,9 +303,9 @@
>>>             else:
>>>                 self.assertTrue(not param.keyword_only)
>>>             if has_default:
>>> -                self.assertEqual(param.default_value, default)
>>> +                self.assertEqual(param.default, default)
>>>             else:
>>> -                self.assertTrue(not hasattr(param, 'default_value'))
>>> +                self.assertTrue(not hasattr(param, 'default'))
>>>             if has_anno:
>>>                 self.assertEqual(param.annotation, anno)
>>>             else:
>>> @@ -373,7 +323,7 @@
>>>
>>>     def test_too_many_arguments(self):
>>>         # Only one argument should pair up with a parameter.
>>> -        sig = pep362.Signature(pep362_fodder.no_default_args)
>>> +        sig = pep362.Signature(no_default_args)
>>>         self.assertRaises(pep362.BindError, sig.bind, 1, a=1)
>>>
>>>
>>> _______________________________________________
>>> Python-checkins mailing list
>>> Python-checkins at python.org
>>> http://mail.python.org/mailman/listinfo/python-checkins
>>>
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/4db3ab25/attachment-0001.html>

From jameson.quinn at gmail.com  Thu Mar 24 18:37:37 2011
From: jameson.quinn at gmail.com (Jameson Quinn)
Date: Thu, 24 Mar 2011 11:37:37 -0600
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
Message-ID: <AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>

OK, fair enough. People don't like this. So let me back up a step.

Clearly this is intended for using with things that you get as a dictionary,
but which really should be namespaces. The top two cases of that are parsed
json objects and **kw arguments.

I suppose that, if I cared to, I could write a decorator that passed a
wrapped object in kw arguments. Also, the whole point of **kw is that you
don't know ahead of time exactly what's in there, so the usefulness is
limited.

But definitely, it looks wrong to me to be putting the attribute names of my
json in quotes. Again, I could make a wrapper, and tinker with my json
parser (subclass it or whatever) so that it passed back by default. But I
think that this use case is common enough with json (often, you know exactly
what should be in there) that it should be built into the standard json
library.

So, what about a method on (certain?) dict objects to return the
attr-wrapped version of the dict. That is:

class AttrDict(object):
   def __init__(self, dict):
     self.__dict__ = dict

class WithAttrDict(dict):
    @cached_property #what it sounds like - implementation not shown
    def att(self):
        return AttrDict(self)

I'd like all the dicts and sub-dicts which come from the standard json
library to be WithAttrDicts, so I can write:

parsedjson.att.spam.att.eggs #I'd love to avoid the second "att."
   #but I don't want to complicate this proposal further.

instead of

parsedjson["spam"]["eggs"].

I'd love it if there were a one-or-two-letter property name to use instead
of ".att" (".s", by analogy with english apostrophe-s?). And I'd even love
it if the built-in dictionary object had such a property, even if it had a
long name ("{'spam':'eggs'}.as_attributes.spam == 'eggs' "). That latter
thing could, in theory, break working code... but only if you're using the
same attribute name to duck-type a dictionary subclass, which I'd bet heavy
odds has not been done for the given attribute name or any reasonable
substitute.

Jameson

2011/3/24 Brian Curtin <brian.curtin at gmail.com>

> On Thu, Mar 24, 2011 at 10:51, Jameson Quinn <jameson.quinn at gmail.com>wrote:
>
>> Consider:
>>
>> def fun1(argument):
>>     print argument1
>>
>> fun1(argument="spam")
>>
>> def fun2(**kw):
>>     print kw["argument"]
>>
>> Why should I need quotes around "argument" in just one of those places?
>> What if I left them off, and there happened to be a global variable named
>> "argument"? Why shouldn't I be able to say:
>>
>> def fun2(**kw):
>>     print kw..argument
>>
>> (in real life, there would be a try... except block in case there was no
>> argument, I'm just showing the simplest case here.)
>>
>
> I can certainly see use cases for this, but none generic enough for the
> standard library.
>
> Let's take the configparser module for example: in 3.2 ConfigParser objects
> can now be accessed like dictionaries. Looking at the examples in the
> documentation [0], an immediate problem comes to mind:
>
>     print(config..bitbucket.org..user)
>     *boom*
>
> If you're going to be doing attribute access, it's likely that you know the
> name of the attribute -- you wrote the code knowing what to expect in the
> first place. If you know the names of the attributes you're going to be
> dealing with, why not just store them in a class, or even a class with
> __slots__ defined for each attribute?
>
> The double-dot notation will only work when you already know the key. When
> iterating over keys, you're going to resort back to dict[key] or
> getattr(dict, key) to get the value.
>
> In the end, it's syntactic sugar for a limited set of applicable cases.
>
>
>
> [0] http://docs.python.org/release/3.2/library/configparser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/4cb71e6e/attachment.html>

From bruce.bushby at gmail.com  Thu Mar 24 18:39:52 2011
From: bruce.bushby at gmail.com (bruce bushby)
Date: Thu, 24 Mar 2011 17:39:52 +0000
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <imftlo$upj$1@dough.gmane.org>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
	<4D8B287A.2090002@v.loewis.de> <4D8B61F1.2010904@ctypes.org>
	<AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
	<imftlo$upj$1@dough.gmane.org>
Message-ID: <AANLkTinSbWFnhyu_Wo_vw5a=g5VteWv8oFhwufSV35fm@mail.gmail.com>

I used the most simple "Hello World" program as a benchmark for "bare bones"
Python __initialization__...nothing more.

On my pc, the "Hello World" script obviously executes very quickly....so
trying to open 160 odd files that don't exist is negligible, but it still
happens.

 "...How did you measure that?..."
I used "strace -c hello.py"

This is not a dig at Python, I love Python....I was asking if I had missed a
compile option or implementation trick.


Bruce





On Thu, Mar 24, 2011 at 5:05 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:

> bruce bushby, 24.03.2011 16:58:
>
>  My main concern was that a freshly compiled Python attempts to open 168
>> non-existent files before starting.
>>
>> I understand that an interpreted language is probably not the best choice
>> for an embedded device
>>
>
> Well, "hello world" isn't exactly the benchmark I'd use for an embedded
> system.
>
>
>
>  On my desktop pc, when I run the most simple "Hello World" .... 78% of the
>> overall execution time is spent opening files....most of which don't
>> exist.
>>
>
> How did you measure that?
>
> I'd expect that after the first startup, most of the relevant parts of the
> file system are cached by the OS, so a subsequent run should be quick as all
> file existence tests will run from memory. Sure, it's a bit of overhead to
> call into the OS, and I don't know how expensive that is on ARM-Linux, but
> given that you also claim it to be expensive on your desktop, I must say
> that I'm a bit surprised about your above claim.
>
> Stefan
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/bruce.bushby%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/1fc4430f/attachment.html>

From guido at python.org  Thu Mar 24 18:50:51 2011
From: guido at python.org (Guido van Rossum)
Date: Thu, 24 Mar 2011 10:50:51 -0700
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
Message-ID: <AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>

On Thu, Mar 24, 2011 at 10:37 AM, Jameson Quinn <jameson.quinn at gmail.com> wrote:
> OK, fair enough. People don't like this. So let me back up a step.

> Clearly this is intended for using with things that you get as a dictionary,
> but which really should be namespaces. The top two cases of that are parsed
> json objects and **kw arguments.

If you need this for **kw arguments maybe you're not using them right;
why not name your arguments if you're going to reference them by name?

The JSON use case seems to be driven because this is the way
JavaScript does things -- they don't distinguish between dicts and
objects. I personally think that's a poor language feature: it blurs a
line that should be clear, between data (dict keys) and program
variables (attributes).

-- 
--Guido van Rossum (python.org/~guido)

From stefan_ml at behnel.de  Thu Mar 24 19:03:39 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 24 Mar 2011 19:03:39 +0100
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <AANLkTinSbWFnhyu_Wo_vw5a=g5VteWv8oFhwufSV35fm@mail.gmail.com>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>	<4D8B287A.2090002@v.loewis.de>
	<4D8B61F1.2010904@ctypes.org>	<AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>	<imftlo$upj$1@dough.gmane.org>
	<AANLkTinSbWFnhyu_Wo_vw5a=g5VteWv8oFhwufSV35fm@mail.gmail.com>
Message-ID: <img11r$ksk$1@dough.gmane.org>

bruce bushby, 24.03.2011 18:39:
> On Thu, Mar 24, 2011 at 5:05 PM, Stefan Behnel wrote:
>> bruce bushby, 24.03.2011 16:58:
>>   On my desktop pc, when I run the most simple "Hello World" .... 78% of the
>>> overall execution time is spent opening files....most of which don't
>>> exist.
>>
>> How did you measure that?
>
> I used "strace -c hello.py"

Ok, I tried that as well, using a self-compiled CPython 3.2. On the first 
run, "open()" was at the top, on the subsequent runs, "read()" was. So it 
looks like a non-problem to me.

First run:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000026           0       677       581 open
   0.00    0.000000           0       145           read
   0.00    0.000000           0         1           write
    ...

Second run:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000016           0       145           read
   0.00    0.000000           0         1           write
   0.00    0.000000           0       677       581 open
    ...

The exact timings are likely bogus as the numbers are way too low to be 
measured accurately. The higher number of calls is partly due to the ABI 
version specific .so files that CPython 3.2 uses.


>> I'd expect that after the first startup, most of the relevant parts of the
>> file system are cached by the OS, so a subsequent run should be quick as all
>> file existence tests will run from memory. Sure, it's a bit of overhead to
>> call into the OS, and I don't know how expensive that is on ARM-Linux, but
>> given that you also claim it to be expensive on your desktop, I must say
>> that I'm a bit surprised about your above claim.
>
> On my pc, the "Hello World" script obviously executes very quickly....so
> trying to open 160 odd files that don't exist is negligible, but it still
> happens.

That brings us to the question why your processes are so short-running that 
the startup time starts to matter. And, if they are so short-running, what 
prevents the disk cache (or whatever kind of storage system you use) from 
speeding up the open() requests. However, that's the right kind of question 
to discuss on python-list, not python-devel.

Stefan


From amcnabb at mcnabbs.org  Thu Mar 24 18:46:42 2011
From: amcnabb at mcnabbs.org (Andrew McNabb)
Date: Thu, 24 Mar 2011 11:46:42 -0600
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <AANLkTimtwo3U73KvgBksurTKRP2B2MN-1h2iW=N-SA3X@mail.gmail.com>
References: <4D8B73F2.50700@jcea.es>
	<AANLkTi=tyeEY6KU+P=J=jruEF1z-O0njfNt_Bs=k_mWZ@mail.gmail.com>
	<AANLkTimtwo3U73KvgBksurTKRP2B2MN-1h2iW=N-SA3X@mail.gmail.com>
Message-ID: <20110324174642.GC8684@mcnabbs.org>

On Thu, Mar 24, 2011 at 10:12:18AM -0700, Guido van Rossum wrote:
> On Thu, Mar 24, 2011 at 9:46 AM, Benjamin Peterson <benjamin at python.org> wrote:
> >> I want to test the dev community interest in modifying the stdlib to
> >> ease dependence injection.
> >
> > I, for one, am -1. Code shouldn't be uglified for the purposes of
> > testing.
> 
> Well, the philosophy of dependency injection requires exactly that.
> Personally I am on the fence; I've seen is used effectively but I've
> also seen code, indeed, uglified with little benefits. (Same for other
> extreme testing practices like TDD.)

I agree with the comments about uglification, but testing was only one
of the use cases that Jesus provided.  He also mentioned using
alternative network implementations, integrating with event loops, etc.
Another use case that I've run into before is setting socket options.

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868

From fijall at gmail.com  Thu Mar 24 19:08:12 2011
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 24 Mar 2011 12:08:12 -0600
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
Message-ID: <AANLkTi=m-TcFa+UM5F-w26xjrDvV=gHLs73488DKeH9t@mail.gmail.com>

On Thu, Mar 24, 2011 at 11:50 AM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Mar 24, 2011 at 10:37 AM, Jameson Quinn <jameson.quinn at gmail.com> wrote:
>> OK, fair enough. People don't like this. So let me back up a step.
>
>> Clearly this is intended for using with things that you get as a dictionary,
>> but which really should be namespaces. The top two cases of that are parsed
>> json objects and **kw arguments.
>
> If you need this for **kw arguments maybe you're not using them right;
> why not name your arguments if you're going to reference them by name?
>
> The JSON use case seems to be driven because this is the way
> JavaScript does things -- they don't distinguish between dicts and
> objects. I personally think that's a poor language feature: it blurs a
> line that should be clear, between data (dict keys) and program
> variables (attributes).

As an almost completely unrelated note, it also makes writing fast
interpreter for JavaScript harder, because you don't know usage
patterns, while in Python it's clear when you meant objects and when
you meant dicts.

>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

From phd at phdru.name  Thu Mar 24 19:26:18 2011
From: phd at phdru.name (Oleg Broytman)
Date: Thu, 24 Mar 2011 21:26:18 +0300
Subject: [Python-Dev] Attributes access with dict
In-Reply-To: <AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
Message-ID: <20110324182618.GA23187@iskra.aviel.ru>

On Thu, Mar 24, 2011 at 10:50:51AM -0700, Guido van Rossum wrote:
> The JSON use case seems to be driven because this is the way
> JavaScript does things -- they don't distinguish between dicts and
> objects.

   That's particular feature has a cure (or poison - for thos who don't
want to mix getattr and getitem): json.load/loads have object_hook
parameter that's used instead of dict. Pass DictRecord (or whatever you
call that) - and voila!

> I personally think that's a poor language feature: it blurs a
> line that should be clear, between data (dict keys) and program
> variables (attributes).

   Me too.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From jameson.quinn at gmail.com  Thu Mar 24 19:46:33 2011
From: jameson.quinn at gmail.com (Jameson Quinn)
Date: Thu, 24 Mar 2011 12:46:33 -0600
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
Message-ID: <AANLkTi=RjQK4F-97KOnTcHvfiqfaOV+ff22xZgu0x_aU@mail.gmail.com>

>
>
> If you need this for **kw arguments maybe you're not using them right;
> why not name your arguments if you're going to reference them by name?
>

Good point.

>
> The JSON use case seems to be driven because this is the way
> JavaScript does things -- they don't distinguish between dicts and
> objects. I personally think that's a poor language feature: it blurs a
> line that should be clear, between data (dict keys) and program
> variables (attributes).
>
> OK. So if this is a json-only issue, it can be done using a wrapper and
object_hook in the json library. I believe that, since all the magic
functions are pulled from the class, not the instance, you should even be
able to use  "if 'a' in wrapped_dict:" and "for a in wrapped_dict:" if your
wrapper class delegates __contains__ and __iter__ to the underlying dict.
Anyway, you can use hasattr for the former.

So my overarching proposal has shrunk to a suggestion that I should go and
make a attrlyjson module which does this by default. I certainly think that
I can get it right, and I know that there are several easy ways to get it
wrong, so it's worth saving people the headache.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/4dab1b40/attachment-0001.html>

From bob at redivi.com  Thu Mar 24 19:53:20 2011
From: bob at redivi.com (Bob Ippolito)
Date: Thu, 24 Mar 2011 11:53:20 -0700
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTi=RjQK4F-97KOnTcHvfiqfaOV+ff22xZgu0x_aU@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
	<AANLkTi=RjQK4F-97KOnTcHvfiqfaOV+ff22xZgu0x_aU@mail.gmail.com>
Message-ID: <AANLkTinK4ee58jpRrGnD-gjCD8b3LsjEdLAHdmJw+M1a@mail.gmail.com>

On Thu, Mar 24, 2011 at 11:46 AM, Jameson Quinn <jameson.quinn at gmail.com> wrote:
>>
>> If you need this for **kw arguments maybe you're not using them right;
>> why not name your arguments if you're going to reference them by name?
>
> Good point.
>>
>> The JSON use case seems to be driven because this is the way
>> JavaScript does things -- they don't distinguish between dicts and
>> objects. I personally think that's a poor language feature: it blurs a
>> line that should be clear, between data (dict keys) and program
>> variables (attributes).
>>
> OK. So if this is a json-only issue, it can be done using a wrapper and
> object_hook in the json library. I believe that, since all the magic
> functions are pulled from the class, not the instance,?you should even be
> able to use??"if 'a' in wrapped_dict:" and "for a in wrapped_dict:" if your
> wrapper class delegates __contains__ and __iter__ to the underlying dict.
> Anyway, you can use hasattr for the former.
> So my overarching proposal has shrunk to a suggestion that I should go and
> make a attrlyjson module which does this by default. I certainly think that
> I can get it right, and I know that there are several easy ways to get it
> wrong, so it's worth saving people the headache.

You're correct, this is trivial with object_hook.

>>> class AttrDict(dict):
...     def __getattr__(self, attr):
...         try:
...             return self[attr]
...         except KeyError:
...             raise AttributeError(attr)
...
>>> import json
>>> obj = json.loads('{"foo": {"bar": "baz"}}', object_hook=AttrDict)
{u'foo': {u'bar': u'baz'}}
>>> obj.foo.bar
u'baz'

-bob

From fuzzyman at voidspace.org.uk  Thu Mar 24 20:04:21 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 24 Mar 2011 19:04:21 +0000
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <20110324174642.GC8684@mcnabbs.org>
References: <4D8B73F2.50700@jcea.es>	<AANLkTi=tyeEY6KU+P=J=jruEF1z-O0njfNt_Bs=k_mWZ@mail.gmail.com>	<AANLkTimtwo3U73KvgBksurTKRP2B2MN-1h2iW=N-SA3X@mail.gmail.com>
	<20110324174642.GC8684@mcnabbs.org>
Message-ID: <4D8B95B5.1030705@voidspace.org.uk>

On 24/03/2011 17:46, Andrew McNabb wrote:
> On Thu, Mar 24, 2011 at 10:12:18AM -0700, Guido van Rossum wrote:
>> On Thu, Mar 24, 2011 at 9:46 AM, Benjamin Peterson<benjamin at python.org>  wrote:
>>>> I want to test the dev community interest in modifying the stdlib to
>>>> ease dependence injection.
>>> I, for one, am -1. Code shouldn't be uglified for the purposes of
>>> testing.
>> Well, the philosophy of dependency injection requires exactly that.
>> Personally I am on the fence; I've seen is used effectively but I've
>> also seen code, indeed, uglified with little benefits. (Same for other
>> extreme testing practices like TDD.)
> I agree with the comments about uglification, but testing was only one
> of the use cases that Jesus provided.  He also mentioned using
> alternative network implementations, integrating with event loops, etc.
> Another use case that I've run into before is setting socket options.

And some of the use cases for this seemed pretty good from the email 
thread he linked to.

Michael

> --
> Andrew McNabb
> http://www.mcnabbs.org/andrew/
> PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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


From eric at trueblade.com  Thu Mar 24 20:18:09 2011
From: eric at trueblade.com (Eric Smith)
Date: Thu, 24 Mar 2011 15:18:09 -0400 (EDT)
Subject: [Python-Dev] Attributes access with dict
In-Reply-To: <20110324182618.GA23187@iskra.aviel.ru>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
	<20110324182618.GA23187@iskra.aviel.ru>
Message-ID: <6e68ece5018c542a2e9e9d4303793f79.squirrel@mail.trueblade.com>

> On Thu, Mar 24, 2011 at 10:50:51AM -0700, Guido van Rossum wrote:
>> The JSON use case seems to be driven because this is the way
>> JavaScript does things -- they don't distinguish between dicts and
>> objects.
>
>    That's particular feature has a cure (or poison - for thos who don't
> want to mix getattr and getitem): json.load/loads have object_hook
> parameter that's used instead of dict. Pass DictRecord (or whatever you
> call that) - and voila!
>
>> I personally think that's a poor language feature: it blurs a
>> line that should be clear, between data (dict keys) and program
>> variables (attributes).
>
>    Me too.

Although we do something similar with namedtuple (instead of using a
dict), so it's not like we have a strict distinction.

Eric.


From greg.ewing at canterbury.ac.nz  Thu Mar 24 21:38:53 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 25 Mar 2011 09:38:53 +1300
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
Message-ID: <4D8BABDD.1000000@canterbury.ac.nz>

Jameson Quinn wrote:
> "class attrdict" is a perennial dead-end for intermediate pythonistas 
> who want to save 3 characters/5 keystrokes for item access. Other 
> languages such as javascript allow "somedict.foo" to mean the same as 
> "somedict['foo']", so why not python?

I think the main reason this is a dead end is these
intermediate pythonistas eventually come to realise that,
if you program pythonically, it's actually extremely
rare that you need to index a dictionary with a constant.

Either you have a mostly-fixed set of field names, in
which case you should be using a custom class instead of
a dict, or the set of keys is dynamic, in which case
you're mostly indexing with computed values. Lots of
somedict['foo'] appearing is a code smell.

So there wouldn't be enough use for a somedict..foo syntax
to justify its existence.

-- 
Greg

From skip at pobox.com  Thu Mar 24 21:50:28 2011
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 24 Mar 2011 15:50:28 -0500
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <4D8BABDD.1000000@canterbury.ac.nz>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<4D8BABDD.1000000@canterbury.ac.nz>
Message-ID: <19851.44692.892951.66326@montanaro.dyndns.org>


    Greg> Either you have a mostly-fixed set of field names, in which case
    Greg> you should be using a custom class instead of a dict, or the set
    Greg> of keys is dynamic, in which case you're mostly indexing with
    Greg> computed values. Lots of somedict['foo'] appearing is a code
    Greg> smell.

Unless, as I suspect, given the first message in the thread, the dict is
arriving via JSON.  Doesn't that only support the most basic builtin scalar
and container types?  You couldn't transfer class instances over JSON could
you?  As with XML-RPC I suspect your best fallback is a dictionary.

Skip

From santoso.wijaya at gmail.com  Thu Mar 24 21:59:51 2011
From: santoso.wijaya at gmail.com (Santoso Wijaya)
Date: Thu, 24 Mar 2011 13:59:51 -0700
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
Message-ID: <AANLkTin2WSFF7pDbGvwdY7Q2h1ocd0doxeokio3ZO5i7@mail.gmail.com>

I just want to chip in that, as far as syntactic sugar go, `somedict:foo`
looks better than `somedict..foo`.

2c...

~/santa


On Thu, Mar 24, 2011 at 4:40 AM, Jameson Quinn <jameson.quinn at gmail.com>wrote:

> "class attrdict" is a perennial dead-end for intermediate pythonistas who
> want to save 3 characters/5 keystrokes for item access. Other languages such
> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so
> why not python? Well, there are a number of reasons why not, beginning with
> all the magic method names in python.
>
> But saving keystrokes is still a reasonable goal.
>
> So what about a compromise? Allow "somedict..foo", with two dots, to take
> that place. It still saves 2 characters (often 4 keystrokes; and I find even
> ', "[", or "]" harder to type than ".").
>
> The "foo" part would of course have to obey attribute/identifier naming
> rules. So there would be no shortcut for "somedict['$#!%']". But for any
> identifier-legal foo, the interpreter would just read ..foo as ['foo'].
>
> I would not be surprised if I'm not the first person to suggest this. If
> so, and there's already well-known reasons why this is a bad idea, I
> apologize. But if the only reason not to is "we never did it that way
> before" or "it would be too addictive, and so people would never want to use
> older python versions" or "headache for tools like pylint", I think we
> should do it.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/7925ea8f/attachment.html>

From greg.ewing at canterbury.ac.nz  Thu Mar 24 22:00:49 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 25 Mar 2011 10:00:49 +1300
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
Message-ID: <4D8BB101.5070007@canterbury.ac.nz>

Jameson Quinn wrote:

> def fun2(**kw):
>     print kw["argument"]

Since this function effectively has a compulsory argument
called 'argument', it would be better written

   def fun2(argument, **kw):
     print argument

or, if the recently-added keyword-only feature is available,

   def fun2(*, argument, **kw):
     print argument

-- 
Greg

From santoso.wijaya at gmail.com  Thu Mar 24 22:07:50 2011
From: santoso.wijaya at gmail.com (Santoso Wijaya)
Date: Thu, 24 Mar 2011 14:07:50 -0700
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <EF8F0025-8849-4029-AA10-EDCB5C88FD61@fuhm.net>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>
	<4D8B287A.2090002@v.loewis.de> <4D8B61F1.2010904@ctypes.org>
	<AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
	<EF8F0025-8849-4029-AA10-EDCB5C88FD61@fuhm.net>
Message-ID: <AANLkTi=b_v2KO0RC=a7Ow36-cj2orM542EfpB7bC8C=H@mail.gmail.com>

On Thu, Mar 24, 2011 at 9:18 AM, James Y Knight <foom at fuhm.net> wrote:

> On Mar 24, 2011, at 11:58 AM, bruce bushby wrote:
> > My main concern was that a freshly compiled Python attempts to open 168
> non-existent files before starting.
> >
> > I understand that an interpreted language is probably not the best choice
> for an embedded device (although it's very nice for prototyping) , Python
> really should know what exists after it's just been compiled....ie before
> any corrupting modules or other nonsense has been added.
> >
> > It appears it is hard coded to open these files regardless of any
> "configure" options.
> >
> > On my desktop pc, when I run the most simple "Hello World" .... 78% of
> the overall execution time is spent opening files....most of which don't
> exist.
> >
> > Some form of "cache" would help the startup time on the "second go" .....
> but arguably just a "band aid" covering a deeper problem.
>
> The deeper problem on your Desktop PC being that MS-Windows' file system
> calls are horrifically expensive for no good reason? :)
>
>
Be that as it may, Windows is a major platform Python runs on and is
supported for. Limitations and quirky behaviors of each platform should be
taken into account, IMHO. And if expensive system calls are some of them, we
should take them into consideration.

~/santa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/61bb0d90/attachment.html>

From greg.ewing at canterbury.ac.nz  Thu Mar 24 22:19:00 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 25 Mar 2011 10:19:00 +1300
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTin2WSFF7pDbGvwdY7Q2h1ocd0doxeokio3ZO5i7@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTin2WSFF7pDbGvwdY7Q2h1ocd0doxeokio3ZO5i7@mail.gmail.com>
Message-ID: <4D8BB544.7060404@canterbury.ac.nz>

Santoso Wijaya wrote:

> `somedict:foo` looks better than `somedict..foo`.

Parsing ambiguity:

   if foo:bar:baz

Is that

   if (foo:bar): baz

or

   if foo: (bar:baz)

?

-- 
Greg

From jameson.quinn at gmail.com  Thu Mar 24 23:14:09 2011
From: jameson.quinn at gmail.com (Jameson Quinn)
Date: Thu, 24 Mar 2011 16:14:09 -0600
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTinK4ee58jpRrGnD-gjCD8b3LsjEdLAHdmJw+M1a@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
	<AANLkTi=RjQK4F-97KOnTcHvfiqfaOV+ff22xZgu0x_aU@mail.gmail.com>
	<AANLkTinK4ee58jpRrGnD-gjCD8b3LsjEdLAHdmJw+M1a@mail.gmail.com>
Message-ID: <AANLkTin+X_xoqOYe3jMsHtTR3A6v1BDMHYpcRmdcsCQx@mail.gmail.com>

>
>
> You're correct, this is trivial with object_hook.
>
> >>> class AttrDict(dict):
> ...     def __getattr__(self, attr):
> ...         try:
> ...             return self[attr]
> ...         except KeyError:
> ...             raise AttributeError(attr)
> ...
> >>> import json
> >>> obj = json.loads('{"foo": {"bar": "baz"}}', object_hook=AttrDict)
> {u'foo': {u'bar': u'baz'}}
> >>> obj.foo.bar
> u'baz'
>
> -bob
>

That's pretty good, but it does clone the dict unnecessarily. I prefer:

class AttrDict(object):
  def __init__(self, adict):
    self.__dict__ = adict #a reference, not a copy
  def __getattr__(self, attr):
    if hasattr(dict, attr): #built-in methods of dict...
      return getattr(self.__dict__, attr) #...are bound directly to the dict
    else:
      try:
        return self.__dict__[attr]
      except KeyError:
        raise AttributeError(attr)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/6efdc0bf/attachment.html>

From martin at v.loewis.de  Thu Mar 24 23:51:31 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Mar 2011 23:51:31 +0100
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
References: <AANLkTi=QiQq1VYFRGBGNsyrJkzj-vcspr8h20rcCYCmE@mail.gmail.com>	<4D8B287A.2090002@v.loewis.de>
	<4D8B61F1.2010904@ctypes.org>
	<AANLkTimShxvywoh-553HT0T8vC_sVjJMg572etGaQL_1@mail.gmail.com>
Message-ID: <4D8BCAF3.6070005@v.loewis.de>

> My main concern was that a freshly compiled Python attempts to open 168
> non-existent files before starting. 

Please consider my proposals then.

Regards,
Martin

From martin at v.loewis.de  Thu Mar 24 23:57:38 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Mar 2011 23:57:38 +0100
Subject: [Python-Dev] Replace useless %.100s by %s in PyErr_Format()
In-Reply-To: <1300967158.17607.16.camel@marge>
References: <1300967158.17607.16.camel@marge>
Message-ID: <4D8BCC62.8040504@v.loewis.de>

> I would like to replace %.100s because there are no more reason to
> truncate strings to an arbitrary length.

I agree with MAL. It protects against cases with ridiculously long
parameters - say, you have a string with 1GB. You *want* to truncate
bogus text.

Regards,
Martin

From victor.stinner at haypocalc.com  Fri Mar 25 00:21:25 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 25 Mar 2011 00:21:25 +0100
Subject: [Python-Dev] Replace useless %.100s by %s in PyErr_Format()
In-Reply-To: <4D8B3797.7070500@egenix.com>
References: <1300967158.17607.16.camel@marge>  <4D8B3797.7070500@egenix.com>
Message-ID: <1301008885.25217.5.camel@marge>

Le jeudi 24 mars 2011 ? 13:22 +0100, M.-A. Lemburg a ?crit :
> BTW: Why do you think that %.100s is not supported in
> PyErr_Format() in Python 2.x ? PyString_FromFormatV()
> does support this. The change to use Unicode error strings
> introduced the problem, since PyUnicode_FromFormatV() for
> some reason ignores the precision (which is shouldn't).

Oh... You are right, it is a regression in Python 3. We started to write
unit tests for PyBytes_FromFormat() and PyUnicode_FromFormat(), I hope
that they will improve the situation.

> That said, it's a good idea to add the #7330 fix
> to at least Python 2.7 as well, since ignoring the precision
> is definitely a bug. It may even be security relevant, since
> it could be used for DOS attacks on servers (e.g. causing them
> to write huge strings to log files instead of just a few
> hundreds bytes per message), so may even need to go into Python 2.6.

Python 2 is not affected because PyErr_Format() uses
PyString_FromFormatV() which supports precision for %s format (e.g.
%.100s truncate the string to 100 bytes).

Do you think that Python 3.1-3.3 should be fixed?

Let's begin by closing #10833 as invalid.

Victor


From ncoghlan at gmail.com  Fri Mar 25 00:25:59 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 09:25:59 +1000
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <4D8B73F2.50700@jcea.es>
References: <4D8B73F2.50700@jcea.es>
Message-ID: <AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>

On Fri, Mar 25, 2011 at 2:40 AM, Jesus Cea <jcea at jcea.es> wrote:
> What do you think?. Should I write a PEP? (I don't think so, but your
> opinion matters). I care, for instance, about how to garantee the API
> coverage actually needed for the new "socket-like" object. The idea is
> that your object should be "socket-like", but how much "socket-like" in
> the API sense?. Do you need to implement "getpeername()" for injecting
> in smtplib?.
>
> If you agree that this is a nice idea, what other libs do you think that
> could benefice of being "injected", beside "socket"?.

1. A PEP is definitely needed to thrash out how this API should work
in practice, as well as whether or not it should even be done at all

2. The level at which the dependency injection works (function
arguments, class attributes, module globals) needs to be decided

3. Alternative designs (such as standardised tools for thread-safe
monkey patching or other customisation of affected libraries) should
be considered

As an example of the last point, perhaps rather than modifying all the
*clients* of the socket module, it may make more sense to have tools
in the socket module itself to temporarily customise the socket
creation process in the current thread. The advantage of such an
approach is that it would then work for 3rd party libraries that
create sockets, without requiring any further modification.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From eltoder at gmail.com  Fri Mar 25 01:10:45 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Thu, 24 Mar 2011 20:10:45 -0400
Subject: [Python-Dev] Attributes access with dict
In-Reply-To: <6e68ece5018c542a2e9e9d4303793f79.squirrel@mail.trueblade.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
	<20110324182618.GA23187@iskra.aviel.ru>
	<6e68ece5018c542a2e9e9d4303793f79.squirrel@mail.trueblade.com>
Message-ID: <AANLkTinjmatXm+LT8wXMHUNurE19CK8J6ydY4xmua=AB@mail.gmail.com>

> Although we do something similar with namedtuple (instead of using a
> dict), so it's not like we have a strict distinction.

Named tuple is a convenience to avoid creating boilerplate classes (or
resorting to use dict with well-known keys). Names in named tuple are
not data, only values. In dict, names are data too.

Eugene

From paul at boddie.org.uk  Fri Mar 25 01:20:34 2011
From: paul at boddie.org.uk (Paul Boddie)
Date: Fri, 25 Mar 2011 01:20:34 +0100
Subject: [Python-Dev] Embedded Python startup is slow
Message-ID: <201103250120.35062.paul@boddie.org.uk>

bruce bushby wrote:
>
> My main concern was that a freshly compiled Python attempts to open 168
> non-existent files before starting.

This has been a longstanding problem with CPython and, despite assertions to 
the contrary, a significant factor on some embedded systems.

> I understand that an interpreted language is probably not the best choice
> for an embedded device (although it's very nice for prototyping) , Python
> really should know what exists after it's just been compiled....ie before
> any corrupting modules or other nonsense has been added.
>
> It appears it is hard coded to open these files regardless of any
> "configure" options.

You might want to look at the following Wiki page:

http://wiki.python.org/moin/EmbeddedPython

Since this topic has come up a few times before, I thought it might be time to 
collect references to it as well as to other topics that people doing 
embedded work might be interested in, along with the recurring problems that 
seem to get solved, probably all too frequently from scratch, outside the 
CPython development scene. (Just looking at an average cross-compilation 
issue in the tracker is likely to fill you with despair if you're waiting for 
a resolution in the official releases, unfortunately.)

Paul

From arfrever.fta at gmail.com  Fri Mar 25 01:21:34 2011
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 25 Mar 2011 01:21:34 +0100
Subject: [Python-Dev] API deprecations in Python 3,
	from a Python 2 perspective
In-Reply-To: <AANLkTinPNhwaBdzOEX4cetn+xQVE-d01YBXm=qj5x0z_@mail.gmail.com>
References: <AANLkTikw-moRs8A8-QiLePFeSdwpZUBr+qHvMMx0zNrv@mail.gmail.com>
	<AANLkTinPNhwaBdzOEX4cetn+xQVE-d01YBXm=qj5x0z_@mail.gmail.com>
Message-ID: <201103250122.04405.Arfrever.FTA@gmail.com>

2011-03-19 03:42:54 Nick Coghlan napisa?(a):
> 4. Anyone testing C extensions against the 3.2 alpha and beta releases
> must have either not used the PyCObject API in the first place, or
> else had already ported their code to use the PyCapsule API as
> necessary.

Gentoo Python maintainer had noticed build failures related to PyCObject, but
he wasn't treating these problems as a bug in Python.
https://bugs.gentoo.org/buglist.cgi?short_desc=Python%203.2%20PyCObject;short_desc_type=allwordssubstr;order=bug_id

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110325/b3c65606/attachment.pgp>

From eric at trueblade.com  Fri Mar 25 02:29:02 2011
From: eric at trueblade.com (Eric Smith)
Date: Thu, 24 Mar 2011 21:29:02 -0400
Subject: [Python-Dev] Attributes access with dict
In-Reply-To: <AANLkTinjmatXm+LT8wXMHUNurE19CK8J6ydY4xmua=AB@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>	<20110324182618.GA23187@iskra.aviel.ru>	<6e68ece5018c542a2e9e9d4303793f79.squirrel@mail.trueblade.com>
	<AANLkTinjmatXm+LT8wXMHUNurE19CK8J6ydY4xmua=AB@mail.gmail.com>
Message-ID: <4D8BEFDE.7070708@trueblade.com>

On 3/24/2011 8:10 PM, Eugene Toder wrote:
>> Although we do something similar with namedtuple (instead of using a
>> dict), so it's not like we have a strict distinction.
>
> Named tuple is a convenience to avoid creating boilerplate classes (or
> resorting to use dict with well-known keys).

My point is that I don't see the distinction between avoiding using 
dicts with well-known keys and wanting to access a dict with attribute 
access (which is where this started). Seems the same to me.

Not that it matters much to me either way.

Eric.

From orsenthil at gmail.com  Fri Mar 25 02:32:12 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Fri, 25 Mar 2011 09:32:12 +0800
Subject: [Python-Dev] Suggestion on back-porting - a getpass issue.
Message-ID: <20110325013212.GA2477@kevin>

The issue is this:

http://bugs.python.org/issue11236
getpass.getpass does not respond to ctrl-c or ctrl-z


Python 2.5 had a behavior when a user pressed CTRL-C at the getpass
prompt, it would raise a KeyBoardInterrupt and CTRL-Z would background
it.

Python 2.6 onwards this behavior got changed and KeyBoardInterrupt
Exception is not raised and nor is CTRL-Z backgrounding behavior
observed.

Users have complained about this change in behavior and want the old
behavior back. Their reasoning for wanting 2.5 behavior seems fine.

The tracker link gives the details to the discussion.

Now, if we fix it in 3.3 (and document the change), should  it be
back-ported to other versions (3.2,3.1,2.7)?

We may end up in a state where only 2.6 has a unique behavior with
respect handling CTRL-C and CTRL-Z on getpass call.

If you have any strong opinion that it should not be back-ported,
please share.

-- 
Senthil

From eltoder at gmail.com  Fri Mar 25 02:44:05 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Thu, 24 Mar 2011 21:44:05 -0400
Subject: [Python-Dev] Attributes access with dict
In-Reply-To: <4D8BEFDE.7070708@trueblade.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
	<20110324182618.GA23187@iskra.aviel.ru>
	<6e68ece5018c542a2e9e9d4303793f79.squirrel@mail.trueblade.com>
	<AANLkTinjmatXm+LT8wXMHUNurE19CK8J6ydY4xmua=AB@mail.gmail.com>
	<4D8BEFDE.7070708@trueblade.com>
Message-ID: <AANLkTimhtTh2F6uOXb9qE4LtXWdJ3qDo7KrEvBADAGQ+@mail.gmail.com>

> My point is that I don't see the distinction between avoiding using dicts
> with well-known keys and wanting to access a dict with attribute access
> (which is where this started). Seems the same to me.

I think using dict with well-known keys is what makes people want dict
with attribute access.
My point is that this is not a very good use of dict -- normally dict
keys are also data. If they are not, something more specific should be
used, though before namedtuple (and still in many other scripting
languages) there were no good alternatives.

Eugene

From eltoder at gmail.com  Fri Mar 25 02:56:26 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Thu, 24 Mar 2011 21:56:26 -0400
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
References: <4D8B73F2.50700@jcea.es>
	<AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
Message-ID: <AANLkTinLsZoCF=Ga975oAas6y5wFuJMGp=tijJi7SwFc@mail.gmail.com>

> 2. The level at which the dependency injection works (function
> arguments, class attributes, module globals) needs to be decided

+1. The scope of parameter needs to be specified. If the scope is
global, this can be achieved pretty easily -- declare some of the
imports in particular modules to be a part of the public APIs of that
modules. Being part of the public API means allowing to replace that
module with another one with compatible implementations. In other
words, bless monkey-patching of those imports.
The advantages of this is simplicity and no uglification of the code
(no changes even). However, this should really not be used for more
than just testing. For other purposes the scope should be smaller
(e.g. class) and Antoine's approach looks like the right thing.

Eugene

From victor.stinner at haypocalc.com  Fri Mar 25 03:03:40 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 25 Mar 2011 03:03:40 +0100
Subject: [Python-Dev] Unload a module written in C
Message-ID: <1301018620.25217.18.camel@marge>

Hi,

I am trying to understand why I am unable to unload my faulthandler
module (implemented in C). Antoine pointed me
_PyImport_FixupExtensionObject() comment which gave me a first clue:

   Modules which do support multiple initialization set their m_size
   field to a non-negative number (indicating the size of the
   module-specific state). They are still recorded in the extensions
   dictionary, to avoid loading shared libraries twice.

Ok, so I changed the size from -1 to 0, and so the m_free callback was
called at exit. Nice. This is thanks to PyImport_Cleanup() which clears
my module attributes.

--

But if I do

  import faulthandler
  del sys.modules['faulthandler']
  del faulthandler

the module is never unloaded. There is another secret reference in the
interpreter state: state->modules_by_index. This list is cleared at exit
(by PyInterpreterState_Clear), but not my module attributes, and some of
them are functions pointing to the module.

My module attribute are not cleared at exit because PyImport_Cleanup()
clears only modules from sys.modules, and my module is no more
referenced in sys.modules.

The workaround to unload the module is to explicitly clear its
attributes:

  import faulthandler
  del sys.modules['faulthandler']
  faulthandler.__dict__.clear()
  del faulthandler

--

Is there a bug somewhere, or do I misunderstood something important?

Note: I implemented m_traversal, but it is not revelant here (you can
consider that my module only contains functions).

Victor


From v+python at g.nevcal.com  Fri Mar 25 03:22:14 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Thu, 24 Mar 2011 19:22:14 -0700
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
References: <4D8B73F2.50700@jcea.es>
	<AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
Message-ID: <4D8BFC56.1080203@g.nevcal.com>

On 3/24/2011 4:25 PM, Nick Coghlan wrote:
> As an example of the last point, perhaps rather than modifying all the
> *clients*  of the socket module, it may make more sense to have tools
> in the socket module itself to temporarily customise the socket
> creation process in the current thread. The advantage of such an
> approach is that it would then work for 3rd party libraries that
> create sockets, without requiring any further modification.

Would be easier to implement that way, not requiring changes to every 
client of the socket library, but in some circles that would be called 
"action at a distance", and harder to understand.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/279ef8cd/attachment.html>

From rdmurray at bitdance.com  Fri Mar 25 03:40:40 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 24 Mar 2011 22:40:40 -0400
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <201103250120.35062.paul@boddie.org.uk>
References: <201103250120.35062.paul@boddie.org.uk>
Message-ID: <20110325024041.255EFED7B1@kimball.webabinitio.net>

On Fri, 25 Mar 2011 01:20:34 +0100, Paul Boddie <paul at boddie.org.uk> wrote:
> Since this topic has come up a few times before, I thought it might be time to 
> collect references to it as well as to other topics that people doing 
> embedded work might be interested in, along with the recurring problems that 
> seem to get solved, probably all too frequently from scratch, outside the 
> CPython development scene. (Just looking at an average cross-compilation 
> issue in the tracker is likely to fill you with despair if you're waiting for 
> a resolution in the official releases, unfortunately.)

Personally I think it would be a good thing for CPython to better support
both embedded systems and cross compilation in general.  I think that
many improvements that would make it better for embedded use would
also make it better for general use (such as improved startup time).
I also think we have a dearth of active core committers with experience
in cross compilation.

Paul, if this is a particular itch/knowledge area for you, maybe you
could do some spade work on the relevant issues, and see if we can get
some movement on them?  If we can get some good patches accepted from
one or more people with interest in this area, maybe we can get some
people with relevant knowledge onto the development team.

--
R. David Murray           http://www.bitdance.com

From stephen at xemacs.org  Fri Mar 25 03:51:11 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 25 Mar 2011 11:51:11 +0900
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <4D8B3D2D.7000200@palladion.com>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net> <imdcc7$2q4$1@dough.gmane.org>
	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D8B3D2D.7000200@palladion.com>
Message-ID: <87oc4zrjz4.fsf@uwakimon.sk.tsukuba.ac.jp>

Tres Seaver writes:

 > >  > > Well, keep in ming hg is a *distributed* version control system. You
 > >  > > don't have to push your changes right now.

 > >  > That doesn't work so well at a sprint, where the point is to maximize
 > >  > the value of precious face-time to get stuff done *now*.
 > > 
 > > That's where the D in DVCS comes in.  It's a new world, friends.  All
 > > you need to do is bring a $50 wireless router to the sprint, and have
 > > some volunteer set up a shared repo for the sprinters.  Then some
 > > volunteer *later* runs the tests and pilots the patches into the
 > > public repo.  Where's the latency?
 > 
 > The current full test suite is punishingly expensive to run, sprint
 > or not.  Because of that fact, people will defer running it, and
 > sometimes forget.  Trying to require that people run it repeatedly
 > during a push race is just Canute lashing the waves.

"Defer" is precisely the point of the proposal you are apparently
responding to, and "people forget" is why I propose a volunteer (or if
possible an automatic process, see my other post and Jesus Cea's) to
run the deferred tests.  I don't understand your point, unless it is
this:

 > The rhythm is still broken if developers don't run the tests and see them
 > pass.  Async is an enemy to the process here, because it encourages poor
 > practices.

Yes, but you can't have it both ways.  Either "the" tests (in fact, I
think people are referring to several different sets of tests by the
phrase "the tests", sometimes even in the same sentence) are valuable
and it's desirable that they always be run (I'm deliberately ignoring
cost here), or they're not, in which case they should never be run.
Now costs come back in: if the tests are valuable but too costly to
run during sprints, better late than never, IMO.  What am I missing?

Also, there's nothing here that says that developers can't run the
tests they think are relevant themselves.  But shouldn't that be their
choice if we are going to relax the requirement from the full test
suite to some subset?  After all, they're the ones closest to the
problem, they should be in the best position to decide which tests are
relevant.

 > >  > Maybe we need to chop the problem up as:
 > > 
 > > "Violence is the last refuge of the incompetent." ObRef Asimov.<wink>
 > 
 > Hmm, that hardly seems appropriate, even with the wink.  "Chopping"
 > isn't violence in any normal sense of the word when applied to
 > non-persons:  Chopping up a problem is no more violent than chopping
 > wood or onions (i.e., not at all).

Well, the referent of "violence" is the global nature of the proposal.
I don't think that one size fits all, here.  If you are going to argue
for running some tests but not others after making changes, shouldn't
there be a notion of relevance involved?  IMO "the" tests for modules
with dependents should include the tests for their dependents, for
example.  Modules that are leaves in the dependency tree presumably
can be unit tested and leave it at that.

Eg, much as I normally respect Barry's intuitions, his proposal (to
remove costly tests, without reference to the possibility of missing
something important) is IMHO absolutely the wrong criterion.  I don't
really know about Python's test suite, but in XEmacs the time-
expensive tests are mostly the ones that involve timeouts and lots of
system calls because they interact with the OS -- and those are
precisely the finicky areas where a small change can occasion an
unexpected bug.  For XEmacs, those bugs also are more likely than
average to be showstoppers for dependents, in the sense that until
they're fixed, the dependents can't be tested at all.  So the cost of
*not* running those tests is relatively high, too.

OTOH, there are a couple of expensive "sledgehammer" tests, eg, the
M17N tests that iterate over *all* the characters XEmacs knows
about.  (Seriously, once you've seen one of the 11,000 precomposed
Hangul, you've seen them all, and it's almost that bad for the 21,000
kanji.)  These could easily be omitted without harming anything else.

Yes, it would be a fair amount of work to do this kind of analysis.
That's why I propose some sort of deferred testing as an alternative
to a cost-based smoke test.

Another alternative would be to require unit testing of changed
modules only, which should be a pretty accurate heuristic for
relevance, except for modules with lots of dependencies.

From greg.ewing at canterbury.ac.nz  Fri Mar 25 05:02:07 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 25 Mar 2011 17:02:07 +1300
Subject: [Python-Dev] Suggestion on back-porting - a getpass issue.
In-Reply-To: <20110325013212.GA2477@kevin>
References: <20110325013212.GA2477@kevin>
Message-ID: <4D8C13BF.6040602@canterbury.ac.nz>

Senthil Kumaran wrote:

> http://bugs.python.org/issue11236
> getpass.getpass does not respond to ctrl-c or ctrl-z

Could this have been deliberate so that people can
put control characters in their passwords?

-- 
Greg

From orsenthil at gmail.com  Fri Mar 25 05:40:24 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Fri, 25 Mar 2011 12:40:24 +0800
Subject: [Python-Dev] Suggestion on back-porting - a getpass issue.
In-Reply-To: <4D8C13BF.6040602@canterbury.ac.nz>
References: <20110325013212.GA2477@kevin> <4D8C13BF.6040602@canterbury.ac.nz>
Message-ID: <20110325044024.GB5497@kevin>

Greg Ewing wrote:
> 
> >http://bugs.python.org/issue11236
> >getpass.getpass does not respond to ctrl-c or ctrl-z
> 
> Could this have been deliberate so that people can
> put control characters in their passwords?

I don't think so. There are discussions in the internet which don't
favor use of control character in password. And anyway, it was not
intention to introduce control characters in password, for the change
in 2.6.

-- 
Senthil

From martin at v.loewis.de  Fri Mar 25 07:59:11 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 25 Mar 2011 07:59:11 +0100
Subject: [Python-Dev] Unload a module written in C
In-Reply-To: <1301018620.25217.18.camel@marge>
References: <1301018620.25217.18.camel@marge>
Message-ID: <4D8C3D3F.4000409@v.loewis.de>

> Is there a bug somewhere, or do I misunderstood something important?

Module unloading is simply not implemented, and would be very difficult
to implement.

Regards,
Martin

From hodgestar+pythondev at gmail.com  Fri Mar 25 10:22:08 2011
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Fri, 25 Mar 2011 11:22:08 +0200
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
References: <4D8B73F2.50700@jcea.es>
	<AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
Message-ID: <AANLkTimOAUpDzrxk0rMfA+yDvJFESotpraOixh5__91L@mail.gmail.com>

On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> As an example of the last point, perhaps rather than modifying all the
> *clients* of the socket module, it may make more sense to have tools
> in the socket module itself to temporarily customise the socket
> creation process in the current thread. The advantage of such an
> approach is that it would then work for 3rd party libraries that
> create sockets, without requiring any further modification.

-2.  That wouldn't allow one to use normal sockets in one 3rd party
library and special sockets in another 3rd party library.

Schiavo
Simon

From stefan_ml at behnel.de  Fri Mar 25 10:24:20 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 25 Mar 2011 10:24:20 +0100
Subject: [Python-Dev] Unload a module written in C
In-Reply-To: <4D8C3D3F.4000409@v.loewis.de>
References: <1301018620.25217.18.camel@marge> <4D8C3D3F.4000409@v.loewis.de>
Message-ID: <imhn04$u62$1@dough.gmane.org>

"Martin v. L?wis", 25.03.2011 07:59:
>> Is there a bug somewhere, or do I misunderstood something important?
>
> Module unloading is simply not implemented, and would be very difficult
> to implement.

Are you saying that because objects instantiated from a module do not 
normally keep a reference to it to keep it alive?

Stefan


From stefan at bytereef.org  Fri Mar 25 10:36:19 2011
From: stefan at bytereef.org (Stefan Krah)
Date: Fri, 25 Mar 2011 10:36:19 +0100
Subject: [Python-Dev] CRLF line endings
Message-ID: <20110325093619.GA11011@sleipnir.bytereef.org>

Hi,

A commit hook prevented pushing changes to the cdecimal repository:

pushing to ssh://hg at hg.python.org/features/cdecimal
searching for changes
8 changesets found
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 8 changesets with 117 changes to 117 files
remote: error: pretxnchangegroup.eol hook failed: Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not have CRLF line endings
remote: transaction abort!
remote: rollback completed
remote: abort: Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not have CRLF line endings


However, dnloop.patch is correct and must have CRLF line endings. How
can I disable the commit hook?


Stefan Krah


From victor.stinner at haypocalc.com  Fri Mar 25 10:46:06 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 25 Mar 2011 10:46:06 +0100
Subject: [Python-Dev] Unload a module written in C
In-Reply-To: <imhn04$u62$1@dough.gmane.org>
References: <1301018620.25217.18.camel@marge> <4D8C3D3F.4000409@v.loewis.de>
	<imhn04$u62$1@dough.gmane.org>
Message-ID: <1301046366.9096.2.camel@marge>

Le vendredi 25 mars 2011 ? 10:24 +0100, Stefan Behnel a ?crit :
> "Martin v. L?wis", 25.03.2011 07:59:
> >> Is there a bug somewhere, or do I misunderstood something important?
> >
> > Module unloading is simply not implemented, and would be very difficult
> > to implement.
> 
> Are you saying that because objects instantiated from a module do not 
> normally keep a reference to it to keep it alive?

If you are right, I can understand that it is not possible to unload
safely a module.  In my case, faulthandler module doesn't create an
object, and it has a function to unload itself safely.

Victor


From techtonik at gmail.com  Fri Mar 25 10:47:30 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 25 Mar 2011 11:47:30 +0200
Subject: [Python-Dev] 2to3 status, repositories and HACKING guide
In-Reply-To: <AANLkTi=Uh7f56LdZ_kgvwQVF7t_FYNgqpfH34DdgppNG@mail.gmail.com>
References: <AANLkTi=Uh7f56LdZ_kgvwQVF7t_FYNgqpfH34DdgppNG@mail.gmail.com>
Message-ID: <AANLkTingP4ZwRv=ta6RC_C59nbS6gN-hkzVm15Xdd-2Y@mail.gmail.com>

Hi, Benjamin,

Is your repository for 2to3 is still actual?
http://svn.python.org/view/sandbox/trunk/2to3/

Which should I use to start hacking on 2to3?

--
anatoly t.



On Wed, Mar 23, 2011 at 9:01 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> Hi,
>
> Currently 2to3 page at http://wiki.python.org/moin/2to3 lists
> http://svn.python.org/view/sandbox/trunk/2to3 as a repository for 2to3
> tool. There is also an outdated repository at http://hg.python.org/
> and the page says that the code is finally integrated into CPython 2.6
> - you can see it at
> http://hg.python.org/cpython/file/default/Lib/lib2to3. So, what
> version is more up-to-date?
>
> In svn repository there is a HACKING guide advising to use
> find_pattern.py script for writing new fixer. However, there is no
> find_pattern.py in CPython repository, no HACKING guide, no any
> documentation about how to write fixers or description of PATTERN
> format. Did I miss something?
> --
> anatoly t.
>

From victor.stinner at haypocalc.com  Fri Mar 25 11:14:16 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 25 Mar 2011 11:14:16 +0100
Subject: [Python-Dev] Unload a module written in C
In-Reply-To: <4D8C3D3F.4000409@v.loewis.de>
References: <1301018620.25217.18.camel@marge> <4D8C3D3F.4000409@v.loewis.de>
Message-ID: <1301048056.9096.8.camel@marge>

Le vendredi 25 mars 2011 ? 07:59 +0100, "Martin v. L?wis" a ?crit :
> > Is there a bug somewhere, or do I misunderstood something important?
> 
> Module unloading is simply not implemented, and would be very difficult
> to implement.

My problem is that if Python is embeded, my module will still be active
after Py_FinalizeEx(). For example, if it installed an handler for the
SIGSEGV signal: a segmentation fault will call the handler which will
try to get the interpreter state, but there is no more interpreter. I
don't know if it is a problem or not, but I would prefer to cleanup my
module on Py_FinalizeEx().

I can try to ensure that Python does restore all signals installed by
faulthandler and cancel the current alarm() (used by
dump_traceback_later()). Or I can hardcode something to unload
faulthandler in Py_FinalizeEx() (or somewhere else).

Victor


From victor.stinner at haypocalc.com  Fri Mar 25 11:48:16 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 25 Mar 2011 11:48:16 +0100
Subject: [Python-Dev] Embedded Python startup is slow
In-Reply-To: <20110325024041.255EFED7B1@kimball.webabinitio.net>
References: <201103250120.35062.paul@boddie.org.uk>
	<20110325024041.255EFED7B1@kimball.webabinitio.net>
Message-ID: <1301050096.9096.15.camel@marge>

Le jeudi 24 mars 2011 ? 22:40 -0400, R. David Murray a ?crit :
> On Fri, 25 Mar 2011 01:20:34 +0100, Paul Boddie <paul at boddie.org.uk> wrote:
> > Since this topic has come up a few times before, I thought it might be time to 
> > collect references to it as well as to other topics that people doing 
> > embedded work might be interested in, along with the recurring problems that 
> > seem to get solved, probably all too frequently from scratch, outside the 
> > CPython development scene. (Just looking at an average cross-compilation 
> > issue in the tracker is likely to fill you with despair if you're waiting for 
> > a resolution in the official releases, unfortunately.)
> 
> Personally I think it would be a good thing for CPython to better support
> both embedded systems and cross compilation in general.  I think that
> many improvements that would make it better for embedded use would
> also make it better for general use (such as improved startup time).
> I also think we have a dearth of active core committers with experience
> in cross compilation.

I proposed to integrate Buildroot patches which are 12 patches to
improve cross-compilation and remove/disable some Python features:
http://bugs.python.org/issue11365

Roumen Petrov wrote "All is duplicate on already posted patches . It is
not work to review limited functionality posted here." But I don't know
the number of the issues cited by Roumen.

Victor



From ncoghlan at gmail.com  Fri Mar 25 12:00:25 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 21:00:25 +1000
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <87oc4zrjz4.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net> <imdcc7$2q4$1@dough.gmane.org>
	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D8B3D2D.7000200@palladion.com>
	<87oc4zrjz4.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTik7qQZPs0SXyo4BpaHTX=KvoeVZfWjF827Z29G1@mail.gmail.com>

On Fri, Mar 25, 2011 at 12:51 PM, Stephen J. Turnbull
<stephen at xemacs.org> wrote:
> Eg, much as I normally respect Barry's intuitions, his proposal (to
> remove costly tests, without reference to the possibility of missing
> something important) is IMHO absolutely the wrong criterion. ?I don't
> really know about Python's test suite, but in XEmacs the time-
> expensive tests are mostly the ones that involve timeouts and lots of
> system calls because they interact with the OS -- and those are
> precisely the finicky areas where a small change can occasion an
> unexpected bug. ?For XEmacs, those bugs also are more likely than
> average to be showstoppers for dependents, in the sense that until
> they're fixed, the dependents can't be tested at all. ?So the cost of
> *not* running those tests is relatively high, too.

For Python, our most expensive, slow tests are generally process
related or IO related (over time the threading related ones have been
largely fixed to use Event based signalling rather than relying on
timeouts, so they're significantly faster than they once were).

These slow tests are *also* typically the most platform dependent
tests, so a "green light" from a local test run is generally pretty
inconclusive - you don't really find out whether you borked something
until you get green lights on the buildbots for platforms other than
those the patch was developed on.

So I still see value in having a standard "smoke test" that runs
through the platform independent stuff, to reduce the number of minor
errors that needlessly cause the buildbots to go red.

The idea would be to create a tiered test suite along the following lines:

1. The buildbots: run the entire (-uall) test suite across a variety
of platforms. Performed for every commit pushed to
hg.python.org/cpython.
2. Complete local test: run the entire (-uall) test suite on a local
working copy. Recommended before first committing a fix or change to a
branch.
3. Basic local test: run the test suite with no additional resources
enabled on a local working copy. Current closest equivalent to a
"smoke test"
4. Proposed "smoke test": quick test of platform independent code for
use when merging heads after a push race
5. Specific tests: run specified tests for modules being worked on.
Used during development to check fix validity and feature degree of
completion.

With the volume of platform dependent code we have in CPython and the
standard library, the only way we're ever likely to achieve
consistently green buildbots is to move to a "staging repo" model,
where commits only get made to the central repo after they have
already passed muster on the buildbots at least once. I think that's
actually a good way for us to go in the long run, but I also think
separating out a fast set of platform independent is a decent idea.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar 25 12:04:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 21:04:17 +1000
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <AANLkTimOAUpDzrxk0rMfA+yDvJFESotpraOixh5__91L@mail.gmail.com>
References: <4D8B73F2.50700@jcea.es>
	<AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
	<AANLkTimOAUpDzrxk0rMfA+yDvJFESotpraOixh5__91L@mail.gmail.com>
Message-ID: <AANLkTin23KPuqUbUXN+BC_OWnu2fGxieTWPQZ9qm42=+@mail.gmail.com>

On Fri, Mar 25, 2011 at 7:22 PM, Simon Cross
<hodgestar+pythondev at gmail.com> wrote:
> On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> As an example of the last point, perhaps rather than modifying all the
>> *clients* of the socket module, it may make more sense to have tools
>> in the socket module itself to temporarily customise the socket
>> creation process in the current thread. The advantage of such an
>> approach is that it would then work for 3rd party libraries that
>> create sockets, without requiring any further modification.
>
> -2. ?That wouldn't allow one to use normal sockets in one 3rd party
> library and special sockets in another 3rd party library.

Uh, yes it would. One possible implementation is to use exactly the
same techniques that are used to implement contexts in the decimal
module.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From python-dev at masklinn.net  Fri Mar 25 12:07:50 2011
From: python-dev at masklinn.net (Xavier Morel)
Date: Fri, 25 Mar 2011 12:07:50 +0100
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <AANLkTimOAUpDzrxk0rMfA+yDvJFESotpraOixh5__91L@mail.gmail.com>
References: <4D8B73F2.50700@jcea.es>
	<AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
	<AANLkTimOAUpDzrxk0rMfA+yDvJFESotpraOixh5__91L@mail.gmail.com>
Message-ID: <A780E8D4-C85C-48C7-A970-CA78763D8A31@masklinn.net>

On 2011-03-25, at 10:22 , Simon Cross wrote:
> On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> As an example of the last point, perhaps rather than modifying all the
>> *clients* of the socket module, it may make more sense to have tools
>> in the socket module itself to temporarily customise the socket
>> creation process in the current thread. The advantage of such an
>> approach is that it would then work for 3rd party libraries that
>> create sockets, without requiring any further modification.
> 
> -2.  That wouldn't allow one to use normal sockets in one 3rd party
> library and special sockets in another 3rd party library.
> 
> Schiavo
> Simon

Or even in "first-party" code (in the stdlib) to set different timeouts on different APIs (say, an xmlrpclib.ServerProxy and an IMAP4 client).

For instance, currently as far as I can tell setting a socket timeout on an xmlrpclib.ServerProxy without setting a global timeout involves:

* subclassing all of xmlrpclib.Serverproxy, xmlrpclib.Transport, httplib.HTTP and httplib.HTTPConnection
* overloading __init__ on the ServerProxy subclass (and on Transport if the timeout is to be a parameter)
* overloading make_connection on the Transport subclass (in order to use the HTTP subclass and propagate the timeout)
* overloading _connection_class on the HTTP subclass
* overloading connect on the HTTPConnection class

This *could* be solved by wrapping a socket-related thread-local context manager around each call resulting in the creation of a socket, but these call sites may not even be under control.

From ncoghlan at gmail.com  Fri Mar 25 12:10:08 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 21:10:08 +1000
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <4D8BFC56.1080203@g.nevcal.com>
References: <4D8B73F2.50700@jcea.es>
	<AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
	<4D8BFC56.1080203@g.nevcal.com>
Message-ID: <AANLkTikgmses_8UH+o9WJsPXBSY+FA6PxJDBC39m3jf+@mail.gmail.com>

On Fri, Mar 25, 2011 at 12:22 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> On 3/24/2011 4:25 PM, Nick Coghlan wrote:
>
> As an example of the last point, perhaps rather than modifying all the
> *clients* of the socket module, it may make more sense to have tools
> in the socket module itself to temporarily customise the socket
> creation process in the current thread. The advantage of such an
> approach is that it would then work for 3rd party libraries that
> create sockets, without requiring any further modification.
>
> Would be easier to implement that way, not requiring changes to every client
> of the socket library, but in some circles that would be called "action at a
> distance", and harder to understand.

Oh, it is definitely action at a distance, and quite deliberately so.

My model for the suggestion is the context objects in the decimal
module. They offer a constrained way to affect the way the entire
decimal module goes about its business, and through judicious use of
thread local storage and context managers, allow this to be done
without distorting the public API of the decimal objects themselves.

There's no reason a solution along those lines wouldn't work for the
socket module, or any other API that would similarly benefit from
providing a mechanism for applications to indirectly control library
behaviour without resorting to monkey-patching.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar 25 12:12:19 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 21:12:19 +1000
Subject: [Python-Dev] CRLF line endings
In-Reply-To: <20110325093619.GA11011@sleipnir.bytereef.org>
References: <20110325093619.GA11011@sleipnir.bytereef.org>
Message-ID: <AANLkTinWp3vOGymzS2bnrp8S3aRgOXL26FXSDY2nhxtC@mail.gmail.com>

On Fri, Mar 25, 2011 at 7:36 PM, Stefan Krah <stefan at bytereef.org> wrote:
> Hi,
>
> A commit hook prevented pushing changes to the cdecimal repository:
>
> pushing to ssh://hg at hg.python.org/features/cdecimal
> searching for changes
> 8 changesets found
> remote: adding changesets
> remote: adding manifests
> remote: adding file changes
> remote: added 8 changesets with 117 changes to 117 files
> remote: error: pretxnchangegroup.eol hook failed: Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not have CRLF line endings
> remote: transaction abort!
> remote: rollback completed
> remote: abort: Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not have CRLF line endings
>
>
> However, dnloop.patch is correct and must have CRLF line endings. How
> can I disable the commit hook?

Don't disable the commit hook, update .hgeol to flag that file as
requiring CRLF line endings.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar 25 12:14:59 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 21:14:59 +1000
Subject: [Python-Dev] Unload a module written in C
In-Reply-To: <1301048056.9096.8.camel@marge>
References: <1301018620.25217.18.camel@marge> <4D8C3D3F.4000409@v.loewis.de>
	<1301048056.9096.8.camel@marge>
Message-ID: <AANLkTimM-g3mgTiKNvj-koT6rdM0-MOqgk9a3jO6XJnP@mail.gmail.com>

On Fri, Mar 25, 2011 at 8:14 PM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> Le vendredi 25 mars 2011 ? 07:59 +0100, "Martin v. L?wis" a ?crit :
>> > Is there a bug somewhere, or do I misunderstood something important?
>>
>> Module unloading is simply not implemented, and would be very difficult
>> to implement.
>
> My problem is that if Python is embeded, my module will still be active
> after Py_FinalizeEx(). For example, if it installed an handler for the
> SIGSEGV signal: a segmentation fault will call the handler which will
> try to get the interpreter state, but there is no more interpreter. I
> don't know if it is a problem or not, but I would prefer to cleanup my
> module on Py_FinalizeEx().

And registering your cleanup function with atexit() isn't enough? Or
does that remove the handler too early?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From victor.stinner at haypocalc.com  Fri Mar 25 12:36:01 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 25 Mar 2011 12:36:01 +0100
Subject: [Python-Dev] Unload a module written in C
In-Reply-To: <AANLkTimM-g3mgTiKNvj-koT6rdM0-MOqgk9a3jO6XJnP@mail.gmail.com>
References: <1301018620.25217.18.camel@marge> <4D8C3D3F.4000409@v.loewis.de>
	<1301048056.9096.8.camel@marge>
	<AANLkTimM-g3mgTiKNvj-koT6rdM0-MOqgk9a3jO6XJnP@mail.gmail.com>
Message-ID: <1301052961.11097.3.camel@marge>

Le vendredi 25 mars 2011 ? 21:14 +1000, Nick Coghlan a ?crit :
> On Fri, Mar 25, 2011 at 8:14 PM, Victor Stinner
> <victor.stinner at haypocalc.com> wrote:
> > Le vendredi 25 mars 2011 ? 07:59 +0100, "Martin v. L?wis" a ?crit :
> >> > Is there a bug somewhere, or do I misunderstood something important?
> >>
> >> Module unloading is simply not implemented, and would be very difficult
> >> to implement.
> >
> > My problem is that if Python is embeded, my module will still be active
> > after Py_FinalizeEx(). For example, if it installed an handler for the
> > SIGSEGV signal: a segmentation fault will call the handler which will
> > try to get the interpreter state, but there is no more interpreter. I
> > don't know if it is a problem or not, but I would prefer to cleanup my
> > module on Py_FinalizeEx().
> 
> And registering your cleanup function with atexit() isn't enough? Or
> does that remove the handler too early?

atexit() is too late: when Python is embeded, Py_Finalize() may be
called a long time before the program does really finish.

Well, I never embeded Python in another program, but it looks like some
people do initialize/finalize Python more than once:

http://bugs.python.org/issue11321
"9th import of module _pickle always crashes"

In this issue, Python is initialized/finalized 20 times.

Victor


From ncoghlan at gmail.com  Fri Mar 25 12:37:09 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 21:37:09 +1000
Subject: [Python-Dev] [Python-checkins] cpython: Remove
 test_importable(). Couldn't see how to make this reliable across all
In-Reply-To: <E1Q2ogw-0003rz-Fe@dinsdale.python.org>
References: <E1Q2ogw-0003rz-Fe@dinsdale.python.org>
Message-ID: <AANLkTikXNhrsmAnPXCY1A+NdFLYGzGzdLoDHaWfPxi1d@mail.gmail.com>

On Fri, Mar 25, 2011 at 3:51 AM, raymond.hettinger
<python-checkins at python.org> wrote:
> http://hg.python.org/cpython/rev/5adddc6be3c1
> changeset: ? 68902:5adddc6be3c1
> user: ? ? ? ?Raymond Hettinger <python at rcn.com>
> date: ? ? ? ?Thu Mar 24 10:51:06 2011 -0700
> summary:
> ?Remove test_importable(). ?Couldn't see how to make this reliable across all platforms.

For this particular use case, a temporary directory added to sys,path,
then some subsequent cleanup of sys.modules, sys.path and
sys.path_importer_cache would likely do the trick.

I've actually never been a fan of using TESTFN in tests - the tempfile
module always struck me as being significantly more useful. It also
makes tidying up the files afterwards really easy - the temporary
directory context manager will blow everything away for you.

Then again, quite a few of the tests I've written involved convoluted
module hierarchies, so I'm likely a little biased by my typical use
cases :)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar 25 12:47:16 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 21:47:16 +1000
Subject: [Python-Dev] Unload a module written in C
In-Reply-To: <1301052961.11097.3.camel@marge>
References: <1301018620.25217.18.camel@marge> <4D8C3D3F.4000409@v.loewis.de>
	<1301048056.9096.8.camel@marge>
	<AANLkTimM-g3mgTiKNvj-koT6rdM0-MOqgk9a3jO6XJnP@mail.gmail.com>
	<1301052961.11097.3.camel@marge>
Message-ID: <AANLkTik0ORWLnCn7WAi9miP97eGuVunNeEA0H8K3DmEX@mail.gmail.com>

On Fri, Mar 25, 2011 at 9:36 PM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
>> And registering your cleanup function with atexit() isn't enough? Or
>> does that remove the handler too early?
>
> atexit() is too late: when Python is embeded, Py_Finalize() may be
> called a long time before the program does really finish.

I'm talking about the Python "atexit" module - any callbacks
registered there are invoked by Py_Finalize(), not by process
termination.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From jnoller at gmail.com  Fri Mar 25 13:03:43 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Mar 2011 08:03:43 -0400
Subject: [Python-Dev] Python Core Mentorship program
Message-ID: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>

Hello everyone:

I wanted to take a moment to outline another idea which came out of
PyCon 2011 this year from numerous sources - a Python Core Mentorship
Program predicated on the idea that Python-Core, and Python as a whole
would be served by further lowering the barrier to entry of
contribution, and to provide a program to connect new programmers,
students, women, and others to experienced Python-Core developers
(Mentors).

Brett's revamp of the Dev guide was part one of "secret plan to get
more people involved in python-core" - this is another part, but I'm
not sure of the numbering scheme.

The mission of the Python Core Mentor Program is to provide an open
and welcoming place to connect students, programmers - and anyone
interested in contributing to the Python-Core development. This
project is based on the idea that the best way to welcome new people
into any project is a venue which connects them to mentors who can
assist in guiding them through the contribution process, including
discussions on lists such as python-dev, and python-ideas, the bug
tracker, mercurial, code reviews, etc.

Additionally, mentors will assist in something incredibly critical to
maintain contributor interest: getting patches through the process and
actually *committed*. We all know - not everyone who is mentor will
have all the answers, so mentors also act as conduits to others who
will have the answer.

The project itself will (hopefully) be low in time-spent, and largely
self-managing. We will start simple with a mailing list
(core-mentorship at python.org) where mentors, and those who wish to be
mentored or ask questions may do so. This mailing list will have a
code of conduct which will help prevent flame wars, or other
counterproductive discussions - a code of conduct also makes it clear
to mentors what they''re agreeing to when they decide to participate.

The new list will also have a closed, members-only archive. After
consulting with other core developers, we believe it's easier to ask
questions when you don't have to worry about Google picking up your
words from a public archive.

We want to make this list a resource for people to be able to get
started, ask "silly" questions, and so on - our goal is to turn anyone
who wishes to be into an active, sustainable committer to Python.

Mentors will be asked to answer questions - but also assist people in
need of help with discussions on the mailing lists and bug tracker
(conversations on which could have become contentious or stressful)
and generally to be advocates for the people being mentored. For
example - if a person submits a patch to the tracker, the mentor list
may help them through initial code reviews, or discussions with other
core developers. The job is to act as an experienced proxy for them.

The first step to this project is to ask for volunteer mentors -
people who are willing to help answer questions on the list, and
generally guide people as needed being as friendly and courteous and
welcoming as possible.

If you are interested in being a mentor - or have feedback about this
plan in general, please feel free to reach out to me
(jnoller at gmail.com) directly. My goal, once this is setup, is to have
the project largely self-managing, with the PSF helping to market it
to the community as a whole.

Jesse

From stefan at bytereef.org  Fri Mar 25 13:59:32 2011
From: stefan at bytereef.org (Stefan Krah)
Date: Fri, 25 Mar 2011 13:59:32 +0100
Subject: [Python-Dev] CRLF line endings
In-Reply-To: <AANLkTinWp3vOGymzS2bnrp8S3aRgOXL26FXSDY2nhxtC@mail.gmail.com>
References: <20110325093619.GA11011@sleipnir.bytereef.org>
	<AANLkTinWp3vOGymzS2bnrp8S3aRgOXL26FXSDY2nhxtC@mail.gmail.com>
Message-ID: <20110325125932.GA13028@sleipnir.bytereef.org>

Nick Coghlan <ncoghlan at gmail.com> wrote:
> > However, dnloop.patch is correct and must have CRLF line endings. How
> > can I disable the commit hook?
> 
> Don't disable the commit hook, update .hgeol to flag that file as
> requiring CRLF line endings.

Thanks, that works well.


Stefan Krah



From jnoller at gmail.com  Fri Mar 25 14:06:48 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Mar 2011 09:06:48 -0400
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
Message-ID: <AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK@mail.gmail.com>

On Fri, Mar 25, 2011 at 9:04 AM,  <exarkun at twistedmatrix.com> wrote:
> On 12:03 pm, jnoller at gmail.com wrote:
>>
>> Hello everyone:
>>
>>
>> The new list will also have a closed, members-only archive. After
>> consulting with other core developers, we believe it's easier to ask
>> questions when you don't have to worry about Google picking up your
>> words from a public archive.
>
> Boggle.
>
> Jean-Paul
>

I assume that means your in, or you hate that idea?

From skip at pobox.com  Fri Mar 25 14:12:32 2011
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 25 Mar 2011 08:12:32 -0500
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK@mail.gmail.com>
Message-ID: <19852.38080.246431.344709@montanaro.dyndns.org>


    >> Boggle.

    Jesse> I assume that means your in, or you hate that idea?

Or that he just really likes to play Boggle. :-)

S

From rdmurray at bitdance.com  Fri Mar 25 14:12:53 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 25 Mar 2011 09:12:53 -0400
Subject: [Python-Dev] CRLF line endings
In-Reply-To: <AANLkTinWp3vOGymzS2bnrp8S3aRgOXL26FXSDY2nhxtC@mail.gmail.com>
References: <20110325093619.GA11011@sleipnir.bytereef.org>
	<AANLkTinWp3vOGymzS2bnrp8S3aRgOXL26FXSDY2nhxtC@mail.gmail.com>
Message-ID: <20110325131253.5E5E163919@kimball.webabinitio.net>

On Fri, 25 Mar 2011 21:12:19 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Don't disable the commit hook, update .hgeol to flag that file as
> requiring CRLF line endings.

Note however that we discovered that the server side hook looks at the
.hgeol file in the *server's checkout*.  I don't know if Georg or Antoine
have fixed this or not (it's a standard Mercurial plugin, so probably
not).

So, I think that once you check in the .hgeol, you have to get a server
admin to update the repo checkout on the server.  Maybe we should
set up a cron job.

But, yeah, updating .hgeol is the correct solution, otherwise you'll
just run in to the trouble when you try to merge the branch into default.

--
R. David Murray           http://www.bitdance.com

From ncoghlan at gmail.com  Fri Mar 25 14:21:56 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 23:21:56 +1000
Subject: [Python-Dev] CRLF line endings
In-Reply-To: <20110325131253.5E5E163919@kimball.webabinitio.net>
References: <20110325093619.GA11011@sleipnir.bytereef.org>
	<AANLkTinWp3vOGymzS2bnrp8S3aRgOXL26FXSDY2nhxtC@mail.gmail.com>
	<20110325131253.5E5E163919@kimball.webabinitio.net>
Message-ID: <AANLkTi=kLW24gXcWjDbf5VBjZnABt+Q6WwZGo+rjd7yQ@mail.gmail.com>

On Fri, Mar 25, 2011 at 11:12 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Fri, 25 Mar 2011 21:12:19 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Don't disable the commit hook, update .hgeol to flag that file as
>> requiring CRLF line endings.
>
> Note however that we discovered that the server side hook looks at the
> .hgeol file in the *server's checkout*. ?I don't know if Georg or Antoine
> have fixed this or not (it's a standard Mercurial plugin, so probably
> not).

Not that I noticed - to get my sandbox updated after you moved all the
email test files, I just had to one do push to get the .hgeol file
updated, then the second push with all the subsequent changes went
through without any trouble.

The one thing you can't do is push an updated .hgeol *and* files that
depend on the updated ruleset in one operation - the server will
process the whole transaction using the *old* version of the .hgeol
file and it will fail as a result. But "hg log .hgeol" will tell you
which version last changed it, then a "hg push -r <rev>" will get the
server's version updated.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Fri Mar 25 14:26:03 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 23:26:03 +1000
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK@mail.gmail.com>
Message-ID: <AANLkTikDwTzfA0854BEfL--3d+-nwEGWgcYQw0bOk9my@mail.gmail.com>

On Fri, Mar 25, 2011 at 11:06 PM, Jesse Noller <jnoller at gmail.com> wrote:
> On Fri, Mar 25, 2011 at 9:04 AM, ?<exarkun at twistedmatrix.com> wrote:
>> On 12:03 pm, jnoller at gmail.com wrote:
>>>
>>> Hello everyone:
>>>
>>>
>>> The new list will also have a closed, members-only archive. After
>>> consulting with other core developers, we believe it's easier to ask
>>> questions when you don't have to worry about Google picking up your
>>> words from a public archive.
>>
>> Boggle.
>
> I assume that means your in, or you hate that idea?

I'll note that one thing the mentors on that list will be doing is
using the questions received as an indication of areas where the
devguide and FAQ may need possible tweaks.

One other thing I would hope to be able to do with the list is to try
to stay in touch with new contributors that participate in sprints.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Fri Mar 25 14:29:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Mar 2011 14:29:25 +0100
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
References: <4D8B73F2.50700@jcea.es>
	<AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
	<4D8BFC56.1080203@g.nevcal.com>
	<AANLkTikgmses_8UH+o9WJsPXBSY+FA6PxJDBC39m3jf+@mail.gmail.com>
Message-ID: <20110325142925.5b2c3a87@pitrou.net>

On Fri, 25 Mar 2011 21:10:08 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Mar 25, 2011 at 12:22 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> > On 3/24/2011 4:25 PM, Nick Coghlan wrote:
> >
> > As an example of the last point, perhaps rather than modifying all the
> > *clients* of the socket module, it may make more sense to have tools
> > in the socket module itself to temporarily customise the socket
> > creation process in the current thread. The advantage of such an
> > approach is that it would then work for 3rd party libraries that
> > create sockets, without requiring any further modification.
> >
> > Would be easier to implement that way, not requiring changes to every client
> > of the socket library, but in some circles that would be called "action at a
> > distance", and harder to understand.
> 
> Oh, it is definitely action at a distance, and quite deliberately so.
> 
> My model for the suggestion is the context objects in the decimal
> module. They offer a constrained way to affect the way the entire
> decimal module goes about its business, and through judicious use of
> thread local storage and context managers, allow this to be done
> without distorting the public API of the decimal objects themselves.

Making an API TLS-based means your code breaks mysteriously if you
start offloading tasks to separate threads (which is quite common with
network-related tasks).

Regards

Antoine.



From jnoller at gmail.com  Fri Mar 25 14:30:47 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Mar 2011 09:30:47 -0400
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTikDwTzfA0854BEfL--3d+-nwEGWgcYQw0bOk9my@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK@mail.gmail.com>
	<AANLkTikDwTzfA0854BEfL--3d+-nwEGWgcYQw0bOk9my@mail.gmail.com>
Message-ID: <AANLkTi=XcdkG8o6PmLOjC5_WVaL9Qw53nPGerSbrK30c@mail.gmail.com>

On Fri, Mar 25, 2011 at 9:26 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Mar 25, 2011 at 11:06 PM, Jesse Noller <jnoller at gmail.com> wrote:
>> On Fri, Mar 25, 2011 at 9:04 AM, ?<exarkun at twistedmatrix.com> wrote:
>>> On 12:03 pm, jnoller at gmail.com wrote:
>>>>
>>>> Hello everyone:
>>>>
>>>>
>>>> The new list will also have a closed, members-only archive. After
>>>> consulting with other core developers, we believe it's easier to ask
>>>> questions when you don't have to worry about Google picking up your
>>>> words from a public archive.
>>>
>>> Boggle.
>>
>> I assume that means your in, or you hate that idea?
>
> I'll note that one thing the mentors on that list will be doing is
> using the questions received as an indication of areas where the
> devguide and FAQ may need possible tweaks.
>
> One other thing I would hope to be able to do with the list is to try
> to stay in touch with new contributors that participate in sprints.
>
> Cheers,
> Nick.

Violently agreed on both counts.

jesse

From solipsis at pitrou.net  Fri Mar 25 14:32:23 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Mar 2011 14:32:23 +0100
Subject: [Python-Dev] CRLF line endings
References: <20110325093619.GA11011@sleipnir.bytereef.org>
	<AANLkTinWp3vOGymzS2bnrp8S3aRgOXL26FXSDY2nhxtC@mail.gmail.com>
	<20110325131253.5E5E163919@kimball.webabinitio.net>
Message-ID: <20110325143223.73c17758@pitrou.net>

On Fri, 25 Mar 2011 09:12:53 -0400
"R. David Murray" <rdmurray at bitdance.com> wrote:
> On Fri, 25 Mar 2011 21:12:19 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Don't disable the commit hook, update .hgeol to flag that file as
> > requiring CRLF line endings.
> 
> Note however that we discovered that the server side hook looks at the
> .hgeol file in the *server's checkout*.  I don't know if Georg or Antoine
> have fixed this or not (it's a standard Mercurial plugin, so probably
> not).

We have "fixed" it by nulling the server's checkout (updating to it to
changeset 0000000000, that is). Unless someone logs in and manually
does "hg up" in that directory, it shouldn't happen again.

(but, yes, it's probably a bug or misfeature in hgeol)

Regards

Antoine.



From tseaver at palladion.com  Fri Mar 25 14:51:04 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 25 Mar 2011 09:51:04 -0400
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <87oc4zrjz4.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>	<20110323143123.4be80686@pitrou.net>	<19850.2977.894754.352174@montanaro.dyndns.org>	<20110323115156.25bd2845@neurotica.wooz.org>	<19850.9561.366432.287634@montanaro.dyndns.org>	<4D8A2CED.7080504@stoneleaf.us>	<20110323182400.04ce46cf@pitrou.net>	<imdcc7$2q4$1@dough.gmane.org>	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D8B3D2D.7000200@palladion.com>
	<87oc4zrjz4.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D8C9DC8.6030701@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/24/2011 10:51 PM, Stephen J. Turnbull wrote:

> If you are going to argue
> for running some tests but not others after making changes, shouldn't
> there be a notion of relevance involved?  IMO "the" tests for modules
> with dependents should include the tests for their dependents, for
> example.  Modules that are leaves in the dependency tree presumably
> can be unit tested and leave it at that.

That was precisely my proposal:  when trying to check in changes to a
stdlib module, we required that developers ensure that the module's
tests, *and* those of its dependents, pass.  We would need to add new
testing infrastructure to support this expectation by computing (and
saving) the dependency graph of the stdlib.  I originally suggested
build time for this, but now think that it would better be built during
an intial full run of the suite.



Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2MncgACgkQ+gerLs4ltQ5WWwCfZVNtfIsPZWx6o5fC08Dh+JHV
EKsAn19jQ//9TGLhMs0yCiY5zDBXNEoD
=VVCq
-----END PGP SIGNATURE-----


From jnoller at gmail.com  Fri Mar 25 14:51:15 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Mar 2011 09:51:15 -0400
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
Message-ID: <AANLkTimd6CjO5VU99f8LVg6hx59NeLpHQPRbTZimXHsV@mail.gmail.com>

On Fri, Mar 25, 2011 at 8:03 AM, Jesse Noller <jnoller at gmail.com> wrote:
> Hello everyone:
>
> I wanted to take a moment to outline another idea which came out of
> PyCon 2011 this year from numerous sources - a Python Core Mentorship
> Program predicated on the idea that Python-Core, and Python as a whole
> would be served by further lowering the barrier to entry of
> contribution, and to provide a program to connect new programmers,
> students, women, and others to experienced Python-Core developers
> (Mentors).
>
> Brett's revamp of the Dev guide was part one of "secret plan to get
> more people involved in python-core" - this is another part, but I'm
> not sure of the numbering scheme.
>
> The mission of the Python Core Mentor Program is to provide an open
> and welcoming place to connect students, programmers - and anyone
> interested in contributing to the Python-Core development. This
> project is based on the idea that the best way to welcome new people
> into any project is a venue which connects them to mentors who can
> assist in guiding them through the contribution process, including
> discussions on lists such as python-dev, and python-ideas, the bug
> tracker, mercurial, code reviews, etc.
>
> Additionally, mentors will assist in something incredibly critical to
> maintain contributor interest: getting patches through the process and
> actually *committed*. We all know - not everyone who is mentor will
> have all the answers, so mentors also act as conduits to others who
> will have the answer.
>
> The project itself will (hopefully) be low in time-spent, and largely
> self-managing. We will start simple with a mailing list
> (core-mentorship at python.org) where mentors, and those who wish to be
> mentored or ask questions may do so. This mailing list will have a
> code of conduct which will help prevent flame wars, or other
> counterproductive discussions - a code of conduct also makes it clear
> to mentors what they''re agreeing to when they decide to participate.
>
> The new list will also have a closed, members-only archive. After
> consulting with other core developers, we believe it's easier to ask
> questions when you don't have to worry about Google picking up your
> words from a public archive.
>
> We want to make this list a resource for people to be able to get
> started, ask "silly" questions, and so on - our goal is to turn anyone
> who wishes to be into an active, sustainable committer to Python.
>
> Mentors will be asked to answer questions - but also assist people in
> need of help with discussions on the mailing lists and bug tracker
> (conversations on which could have become contentious or stressful)
> and generally to be advocates for the people being mentored. For
> example - if a person submits a patch to the tracker, the mentor list
> may help them through initial code reviews, or discussions with other
> core developers. The job is to act as an experienced proxy for them.
>
> The first step to this project is to ask for volunteer mentors -
> people who are willing to help answer questions on the list, and
> generally guide people as needed being as friendly and courteous and
> welcoming as possible.
>
> If you are interested in being a mentor - or have feedback about this
> plan in general, please feel free to reach out to me
> (jnoller at gmail.com) directly. My goal, once this is setup, is to have
> the project largely self-managing, with the PSF helping to market it
> to the community as a whole.
>
> Jesse
>

And the mailing list is up and running for those of you interested in helping:

http://mail.python.org/mailman/listinfo/core-mentorship

jesse

From exarkun at twistedmatrix.com  Fri Mar 25 14:04:18 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Fri, 25 Mar 2011 13:04:18 -0000
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
Message-ID: <20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>

On 12:03 pm, jnoller at gmail.com wrote:
>Hello everyone:
>
>
>The new list will also have a closed, members-only archive. After
>consulting with other core developers, we believe it's easier to ask
>questions when you don't have to worry about Google picking up your
>words from a public archive.

Boggle.

Jean-Paul

From brian.curtin at gmail.com  Fri Mar 25 14:54:49 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Fri, 25 Mar 2011 08:54:49 -0500
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTikDwTzfA0854BEfL--3d+-nwEGWgcYQw0bOk9my@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK@mail.gmail.com>
	<AANLkTikDwTzfA0854BEfL--3d+-nwEGWgcYQw0bOk9my@mail.gmail.com>
Message-ID: <AANLkTik-Jw6AS4pTxAO4YE=uuc51DpH-nSatG4DMUtZ+@mail.gmail.com>

On Fri, Mar 25, 2011 at 08:26, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> One other thing I would hope to be able to do with the list is to try
> to stay in touch with new contributors that participate in sprints.
>
> Cheers,
> Nick.


This was exactly my thought. We were there in person to get ~10 PyCon
sprinters through through the initial hurdles, but what can we do moving
forward? This list answers that question.

A lot have suggested that we follow-up with the people who came out, and an
introduction/invite to this mailing-list seems like a good first contact.
I'll keep them in mind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110325/608fbe9f/attachment.html>

From ncoghlan at gmail.com  Fri Mar 25 14:59:20 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Mar 2011 23:59:20 +1000
Subject: [Python-Dev] Proposal for Python 3.3: dependence injection
In-Reply-To: <20110325142925.5b2c3a87@pitrou.net>
References: <4D8B73F2.50700@jcea.es>
	<AANLkTimHd3PwwXDYXdwfWvc8bOzpEo753-j8cAFk8yQ3@mail.gmail.com>
	<4D8BFC56.1080203@g.nevcal.com>
	<AANLkTikgmses_8UH+o9WJsPXBSY+FA6PxJDBC39m3jf+@mail.gmail.com>
	<20110325142925.5b2c3a87@pitrou.net>
Message-ID: <AANLkTinLQWM_4z1MHCbrUxHnDWth2WKeG4NdT=tH89rf@mail.gmail.com>

On Fri, Mar 25, 2011 at 11:29 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> My model for the suggestion is the context objects in the decimal
>> module. They offer a constrained way to affect the way the entire
>> decimal module goes about its business, and through judicious use of
>> thread local storage and context managers, allow this to be done
>> without distorting the public API of the decimal objects themselves.
>
> Making an API TLS-based means your code breaks mysteriously if you
> start offloading tasks to separate threads (which is quite common with
> network-related tasks).

Ah, true - and, as you say, libraries are far more likely to farm
networking operations out to threads than they are decimal
calculations. Such situations also cause problems for any approaches
based on temporary monkey-patching.

Still, exploring such ideas and their downsides would be one of the
purposes of writing a PEP on this topic. Sprinkling factory function
pixie dust everywhere may turn out to be the right thing to do, but
the various options should be explored before settling specifically on
that one.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ziade.tarek at gmail.com  Fri Mar 25 15:07:39 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 25 Mar 2011 15:07:39 +0100
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <19852.38080.246431.344709@montanaro.dyndns.org>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK@mail.gmail.com>
	<19852.38080.246431.344709@montanaro.dyndns.org>
Message-ID: <AANLkTin_LWqkcOUDEWtxHgc6oYSB+AEgQLJFjdCgz-pk@mail.gmail.com>

On Fri, Mar 25, 2011 at 2:12 PM,  <skip at pobox.com> wrote:
>
> ? ?>> Boggle.
>
> ? ?Jesse> I assume that means your in, or you hate that idea?
>
> Or that he just really likes to play Boggle. :-)
>

Or that he's confused ?
https://secure.wikimedia.org/wiktionary/en/wiki/mindboggling

> S
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>



-- 
Tarek Ziad? | http://ziade.org

From stefan at bytereef.org  Fri Mar 25 15:30:37 2011
From: stefan at bytereef.org (Stefan Krah)
Date: Fri, 25 Mar 2011 15:30:37 +0100
Subject: [Python-Dev] Buildbots and feature branches
Message-ID: <20110325143037.GA13709@sleipnir.bytereef.org>

Hi,

I'm unable to figure out how to trigger a build of a feature branch, see:

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/3424


I saw this:

'Branch to build' is relative to http://svn.python.org/projects/python.



But if I leave out the branch, nothing happens at all.



Stefan Krah



From merwok at netwok.org  Fri Mar 25 15:31:55 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 25 Mar 2011 15:31:55 +0100
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
Message-ID: <4D8CA75B.8000403@netwok.org>

Hi,

Sounds like an excellent initiative!  Kudos to the PSF and the
individuals involved.  I don?t have time to take part right now, but I
wish a good start to the program.

Cheers

From solipsis at pitrou.net  Fri Mar 25 15:34:56 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Mar 2011 15:34:56 +0100
Subject: [Python-Dev] Buildbots and feature branches
References: <20110325143037.GA13709@sleipnir.bytereef.org>
Message-ID: <20110325153456.0081ce52@pitrou.net>

On Fri, 25 Mar 2011 15:30:37 +0100
Stefan Krah <stefan at bytereef.org> wrote:
> Hi,
> 
> I'm unable to figure out how to trigger a build of a feature branch, see:

You cannot do that yet.

Regards

Antoine.



From stefan at bytereef.org  Fri Mar 25 15:58:20 2011
From: stefan at bytereef.org (Stefan Krah)
Date: Fri, 25 Mar 2011 15:58:20 +0100
Subject: [Python-Dev] Buildbots and feature branches
In-Reply-To: <20110325153456.0081ce52@pitrou.net>
References: <20110325143037.GA13709@sleipnir.bytereef.org>
	<20110325153456.0081ce52@pitrou.net>
Message-ID: <20110325145820.GA14047@sleipnir.bytereef.org>

Antoine Pitrou <solipsis at pitrou.net> wrote:
> > I'm unable to figure out how to trigger a build of a feature branch, see:
> 
> You cannot do that yet.

Ok, thanks.


Incidentally, I noticed that push messages with an issue number get
redirected to bugs.python.org. See the recent commit for #2650 here:

http://hg.python.org/cpython/ 


Is this really what everyone wants? I think there's way too much
information on the tracker if you just want to see what actually
got committed.



Stefan Krah




From merwok at netwok.org  Fri Mar 25 16:11:16 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 25 Mar 2011 16:11:16 +0100
Subject: [Python-Dev] Buildbots and feature branches
In-Reply-To: <20110325145820.GA14047@sleipnir.bytereef.org>
References: <20110325143037.GA13709@sleipnir.bytereef.org>	<20110325153456.0081ce52@pitrou.net>
	<20110325145820.GA14047@sleipnir.bytereef.org>
Message-ID: <4D8CB094.5070306@netwok.org>

Le 25/03/2011 15:58, Stefan Krah a ?crit :
> Incidentally, I noticed that push messages with an issue number get
> redirected to bugs.python.org. See the recent commit for #2650 here:
> 
> http://hg.python.org/cpython/ 
> 
> 
> Is this really what everyone wants?

Having issues linked from commit messages on changeset pages (like
http://hg.python.org/cpython/rev/d52b1faa7b11) is very useful IMO;
however, having those links disable the usual links to the changeset
pages on the main log page (http://hg.python.org/cpython/) is a bug.  If
nobody can fix it quickly, I?ll try to make a patch in a week or two.

Regards

From solipsis at pitrou.net  Fri Mar 25 16:28:53 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Mar 2011 16:28:53 +0100
Subject: [Python-Dev] Buildbots and feature branches
References: <20110325143037.GA13709@sleipnir.bytereef.org>
	<20110325153456.0081ce52@pitrou.net>
	<20110325145820.GA14047@sleipnir.bytereef.org>
	<4D8CB094.5070306@netwok.org>
Message-ID: <20110325162853.08a9ac16@pitrou.net>

On Fri, 25 Mar 2011 16:11:16 +0100
?ric Araujo <merwok at netwok.org> wrote:
> Le 25/03/2011 15:58, Stefan Krah a ?crit :
> > Incidentally, I noticed that push messages with an issue number get
> > redirected to bugs.python.org. See the recent commit for #2650 here:
> > 
> > http://hg.python.org/cpython/ 
> > 
> > 
> > Is this really what everyone wants?
> 
> Having issues linked from commit messages on changeset pages (like
> http://hg.python.org/cpython/rev/d52b1faa7b11) is very useful IMO;
> however, having those links disable the usual links to the changeset
> pages on the main log page (http://hg.python.org/cpython/) is a bug.  If
> nobody can fix it quickly, I?ll try to make a patch in a week or two.

See http://mercurial.selenic.com/bts/issue698 for a related issue
(the patch there may be reusable in order to disable these links in the
log view).

Regards

Antoine.



From merwok at netwok.org  Fri Mar 25 16:46:51 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 25 Mar 2011 16:46:51 +0100
Subject: [Python-Dev] A myriad of cross-compile patches (Was: Re: Embedded
 Python startup is slow)
In-Reply-To: <1301050096.9096.15.camel@marge>
References: <201103250120.35062.paul@boddie.org.uk>	<20110325024041.255EFED7B1@kimball.webabinitio.net>
	<1301050096.9096.15.camel@marge>
Message-ID: <4D8CB8EB.1080508@netwok.org>

Le 25/03/2011 11:48, Victor Stinner a ?crit :
> I proposed to integrate Buildroot patches which are 12 patches to
> improve cross-compilation and remove/disable some Python features:
> http://bugs.python.org/issue11365
> 
> Roumen Petrov wrote "All is duplicate on already posted patches . It is
> not work to review limited functionality posted here." But I don't know
> the number of the issues cited by Roumen.

Courtesy of Roundup?s search:

Open issues
===========

http://bugs.python.org/issue3754
  cross-compilation support for python build

http://bugs.python.org/issue1006238
  cross compile patch

http://bugs.python.org/issue1597850
  Cross compiling patches for MINGW (superseder of
  http://bugs.python.org/issue1339673, cross compile and mingw support)

http://bugs.python.org/issue3871
  cross and native build of python for mingw32 with distutils

http://bugs.python.org/issue3718
  environment variable MACHDEP and python build system

http://bugs.python.org/issue10782
  Not possible to cross-compile due to poor detection of %lld support
  in printf

Solved issues
=============

http://bugs.python.org/issue433537
  better cross-compilation support

http://bugs.python.org/issue2513
  64bit cross compilation on windows

http://bugs.python.org/issue1115
  Minor Change For Better cross compile

Those overlapping bugs encompass 10 to 15 users interested in
cross-compilation, but not always in understanding CPython policy (i.e.
targeting 3.3 and packaging, not distutils in 2.6) or politeness <wink>.
 See also http://kegel.com/crosstool/python.html and
http://mail.python.org/pipermail/distutils-sig/2004-October/004209.html
Some patches modify the configure script, other the Windows project
thing files, and the more pervasive make changes in distutils.

The most experienced core dev about those matters is Martin von L?wis;
other core devs who make reviews are Roumen Petrov and Gregory P. Smith
(who?s recently been removing his name from nosy fields).  Mark Hammond,
Thomas Heller and Trent Nelson have knowledge on cross-compilation on
Windows.

Hope this helps.

Regards

From jameson.quinn at gmail.com  Fri Mar 25 17:00:43 2011
From: jameson.quinn at gmail.com (Jameson Quinn)
Date: Fri, 25 Mar 2011 10:00:43 -0600
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTin+X_xoqOYe3jMsHtTR3A6v1BDMHYpcRmdcsCQx@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>
	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>
	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>
	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>
	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>
	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>
	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>
	<AANLkTi=RjQK4F-97KOnTcHvfiqfaOV+ff22xZgu0x_aU@mail.gmail.com>
	<AANLkTinK4ee58jpRrGnD-gjCD8b3LsjEdLAHdmJw+M1a@mail.gmail.com>
	<AANLkTin+X_xoqOYe3jMsHtTR3A6v1BDMHYpcRmdcsCQx@mail.gmail.com>
Message-ID: <AANLkTim+sJ+p1sKWSTERtt6fcAg51WSLgONSeeWSKtbY@mail.gmail.com>

I realized that python already has a way to access the string-based members
of a dict without using quotes:

def expect_a_chair(chair, **kw):
  print "Thanks. That chair is %s." % chair
  if kw:
    for key, val in kw.iteritems():
      print "I wasn't expecting the (%s) %s!" % (val, key)

d = json.loads('{"chair":"comfy","inquisition":"Spanish"}')
expect_a_chair(**d)
try:
  expect_a_chair({})
except TypeError:
  print "No chair."

The ** operator does this. Notice that nowhere in that python code (not
counting the json) do I have to put "chair" in quotes.

Honestly, this solves my current use case. I can use functions like
expect_a_chair for everything I need right now.

But perhaps, if there were a quote-free way to access string-based dict
items, it should be based on this. The problem is, this ** operator is a
unary operator, and the non-unary ** is already taken.

So, I don't have a perfect name for my proposed quoteless synonym for
'["..."]'. My best option is '*.'. Note that this could also be used for
unpacking, and with defaults:
d*.(x,y,z) #=== (d["x"], d["y"], d['z'])
e=d*.(e=None) #like 'e=d.get("e", None)'.

Does this sound worth-it to anyone?

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110325/a2a8cbb2/attachment.html>

From barry at python.org  Fri Mar 25 17:05:05 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 25 Mar 2011 12:05:05 -0400
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <4D8C9DC8.6030701@palladion.com>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net> <imdcc7$2q4$1@dough.gmane.org>
	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D8B3D2D.7000200@palladion.com>
	<87oc4zrjz4.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D8C9DC8.6030701@palladion.com>
Message-ID: <20110325120505.19ccc1a3@neurotica.wooz.org>

On Mar 25, 2011, at 09:51 AM, Tres Seaver wrote:

>That was precisely my proposal:  when trying to check in changes to a
>stdlib module, we required that developers ensure that the module's
>tests, *and* those of its dependents, pass.  We would need to add new
>testing infrastructure to support this expectation by computing (and
>saving) the dependency graph of the stdlib.  I originally suggested
>build time for this, but now think that it would better be built during
>an intial full run of the suite.

That does seem to be a more fruitful avenue for improvement.

I'm also doing more investigation into exactly why certain tests are much
slower for me than for other people.  The main culprit appears to be the fact
that my $HOME is on an ecryptfs, so some performance hit is expected.  But 600
to 25000 times slower?  Hmm...

Also, something seems to be not working quite right with regrtest's cd'ing to
/tmp.  When I build and run the tests out of /tmp (i.e. a non-ecryptfs) with
-j100 it completes in under 3 minutes.  Hopefully I can investigate more later
today.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110325/5b60a14b/attachment.pgp>

From solipsis at pitrou.net  Fri Mar 25 17:14:58 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Mar 2011 17:14:58 +0100
Subject: [Python-Dev] A myriad of cross-compile patches (Was: Re:
 Embedded Python startup is slow)
References: <201103250120.35062.paul@boddie.org.uk>
	<20110325024041.255EFED7B1@kimball.webabinitio.net>
	<1301050096.9096.15.camel@marge> <4D8CB8EB.1080508@netwok.org>
Message-ID: <20110325171458.66828a24@pitrou.net>

On Fri, 25 Mar 2011 16:46:51 +0100
?ric Araujo <merwok at netwok.org> wrote:
> 
> The most experienced core dev about those matters is Martin von L?wis;
> other core devs who make reviews are Roumen Petrov and Gregory P. Smith
> (who?s recently been removing his name from nosy fields).

I don't think Roumen is a core developer (is he? I am not trying to
offend anyone).

Regards

Antoine.



From merwok at netwok.org  Fri Mar 25 17:18:01 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 25 Mar 2011 17:18:01 +0100
Subject: [Python-Dev] Dict access with double-dot (syntactic sugar)
In-Reply-To: <AANLkTim+sJ+p1sKWSTERtt6fcAg51WSLgONSeeWSKtbY@mail.gmail.com>
References: <AANLkTinD2N4q5xJrNoyj_omYMuQXXC7xBnj-uu9E6A7o@mail.gmail.com>	<AANLkTimV0Qg-2JzzEYYDOoD4rZZj0uaFTAo5=LwQjnNX@mail.gmail.com>	<AANLkTik=55oGcB9iWEdw=TBwnWAW4cB6bv6jiFWFysbF@mail.gmail.com>	<AANLkTi=TkU4xKhRRFp+_wCt+SM_tpeGBQg-rmxDQHTL+@mail.gmail.com>	<AANLkTi=sxmSGD4Wd_fF=KVQT4G4y5S7gGEyZ18iYrqM8@mail.gmail.com>	<AANLkTimegU+MuejbC8JXvCG02SF_yF7S_6rYqMi_ri5S@mail.gmail.com>	<AANLkTimvSiDcO3TwEqSzMjDGgrAKSwP=cv_os--1ukjk@mail.gmail.com>	<AANLkTi=RjQK4F-97KOnTcHvfiqfaOV+ff22xZgu0x_aU@mail.gmail.com>	<AANLkTinK4ee58jpRrGnD-gjCD8b3LsjEdLAHdmJw+M1a@mail.gmail.com>	<AANLkTin+X_xoqOYe3jMsHtTR3A6v1BDMHYpcRmdcsCQx@mail.gmail.com>
	<AANLkTim+sJ+p1sKWSTERtt6fcAg51WSLgONSeeWSKtbY@mail.gmail.com>
Message-ID: <4D8CC039.6020609@netwok.org>

Again, please keep this thread on python-ideas.  If people there agree
that this is a very common use case and find a syntax that is not ugly,
it will be time to come back to python-dev.  Thanks.

From merwok at netwok.org  Fri Mar 25 17:36:40 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 25 Mar 2011 17:36:40 +0100
Subject: [Python-Dev] A myriad of cross-compile patches (Was: Re:
 Embedded Python startup is slow)
In-Reply-To: <20110325171458.66828a24@pitrou.net>
References: <201103250120.35062.paul@boddie.org.uk>	<20110325024041.255EFED7B1@kimball.webabinitio.net>	<1301050096.9096.15.camel@marge>
	<4D8CB8EB.1080508@netwok.org> <20110325171458.66828a24@pitrou.net>
Message-ID: <4D8CC498.5020001@netwok.org>

> I don't think Roumen is a core developer (is he? I am not trying to
> offend anyone).

My mistake.  Roumen is a user who?s been commenting on a number of the
patches.

Regards

From victor.stinner at haypocalc.com  Fri Mar 25 17:39:30 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 25 Mar 2011 17:39:30 +0100
Subject: [Python-Dev] I plan to push faulthandler into Python 3.3 in one
 week
In-Reply-To: <1300924149.1028.15.camel@marge>
References: <1300924149.1028.15.camel@marge>
Message-ID: <1301071170.13057.10.camel@marge>

Le jeudi 24 mars 2011 ? 00:49 +0100, Victor Stinner a ?crit :
> If nobody complains, I plan to push my faulthandler module into Python
> 3.3 in one week. It's a module to display the Python backtrace on a
> segfault, on a user signal or after a timeout.

I created a feature repo to prepare the work, features/faulthandler, and
the integration is done. You can try it, or try the last patch attached
to #11393.

I choose to add faulthandler as a builtin module to be able to control
exactly when it is initialized/finalized.

You can enable it at startup using -X faulthandler=1 or
PYTHONFAULTHANDLER=1 env var.

Example:
--------------
$ ./python -X faulthandler Lib/test/crashers/borrowed_ref_2.py 
hi
Fatal Python error: Segmentation fault

Traceback (most recent call first):
  File "Lib/test/crashers/borrowed_ref_2.py", line 18 in __set__
  File "Lib/test/crashers/borrowed_ref_2.py", line 36 in <module>
Erreur de segmentation
--------------

Try Lib/test/crashers/recursive_call.py if you would like to try the
stack overflow feature: faulthandler is able to dump the traceback, even
after a stack overflow. But only if sigaltstack() is available (e.g. not
on Windows, sorry).

faulthandler can also dump the traceback explicitly, after a timeout, or
on a user signal: it is not specific to segmentation faults ;-)

Victor


From merwok at netwok.org  Fri Mar 25 17:44:26 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 25 Mar 2011 17:44:26 +0100
Subject: [Python-Dev] [Python-checkins] cpython: Revert the
 Lib/test/test_bigmem.py changes from commit 17891566a478 (and a
In-Reply-To: <E1Q34UC-0000Yl-SC@dinsdale.python.org>
References: <E1Q34UC-0000Yl-SC@dinsdale.python.org>
Message-ID: <4D8CC66A.5080405@netwok.org>

Hi,

> changeset:   68921:11dc3f270594
> user:        Thomas Wouters <thomas at python.org>
> date:        Fri Mar 25 11:42:37 2011 +0100
> summary:
>   Revert the Lib/test/test_bigmem.py changes from commit 17891566a478 (and a
> few other assertEqual tests that snuck in), and expand the docstrings and
> comments explaining why and how these tests are supposed to work.

Your commit message does not explain why you reverted the changes.  The
specific assert* methods give more useful messages than assertEqual in
case of failure.

Regards

From status at bugs.python.org  Fri Mar 25 18:07:20 2011
From: status at bugs.python.org (Python tracker)
Date: Fri, 25 Mar 2011 18:07:20 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20110325170720.775CA1CC5B@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2011-03-18 - 2011-03-25)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    2735 (+12)
  closed 20718 (+63)
  total  23453 (+75)

Open issues with patches: 1165 


Issues opened (57)
==================

#7391: Re-title the "Using Backslash to Continue Statements" anti-idi
http://bugs.python.org/issue7391  reopened by pitrou

#11597: Can't get ConfigParser.write to write unicode strings
http://bugs.python.org/issue11597  opened by the_isz

#11598: missing afxres.h error when building bdist_wininst in Visual S
http://bugs.python.org/issue11598  opened by carljm

#11599: Useless error message when distutils fails compiling
http://bugs.python.org/issue11599  opened by pitrou

#11600: PY_CFLAGS and PY_CPPFLAGS inconsistent
http://bugs.python.org/issue11600  opened by pitrou

#11601: UnixCCompiler always uses compiler_so, not compiler
http://bugs.python.org/issue11601  opened by pitrou

#11602: python-config code should be in sysconfig
http://bugs.python.org/issue11602  opened by pitrou

#11603: Python crashes or hangs when rebinding __repr__ as __str__
http://bugs.python.org/issue11603  opened by aerojockey

#11604: Have type(n,b,d) check for type(b[i]) is module
http://bugs.python.org/issue11604  opened by terry.reedy

#11605: EMail generator.flatten() disintegrates over non-ascii multipa
http://bugs.python.org/issue11605  opened by sdaoden

#11607: Apllication crashes when saving file
http://bugs.python.org/issue11607  opened by roobman26

#11612: xml.dom.minidom fail to parse SVG file.
http://bugs.python.org/issue11612  opened by ideasman42

#11614: import __hello__ is broken in Python 3
http://bugs.python.org/issue11614  opened by haypo

#11617: Sporadic failure in test_httpservers
http://bugs.python.org/issue11617  opened by pitrou

#11618: Locks broken wrt timeouts on Windows
http://bugs.python.org/issue11618  opened by sbt

#11619: On Windows, don't encode filenames in the import machinery
http://bugs.python.org/issue11619  opened by haypo

#11620: winsound.PlaySound() with SND_MEMORY should accept bytes inste
http://bugs.python.org/issue11620  opened by Tom.Felker

#11623: Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
http://bugs.python.org/issue11623  opened by jlindenbaum

#11624: distutils should support a custom list of exported symbols for
http://bugs.python.org/issue11624  opened by dholth

#11626: Py_LIMITED_API on windows: unresolved symbol	__imp___PyArg_Par
http://bugs.python.org/issue11626  opened by rjs

#11627: segfault raising an arbitrary object as an exception
http://bugs.python.org/issue11627  opened by michael.foord

#11629: Reference implementation for PEP 397
http://bugs.python.org/issue11629  opened by mhammond

#11631: Python 2.7.1 64bit, Win7 64bit problem to read and write with 
http://bugs.python.org/issue11631  opened by Kristoffer.Nilsson

#11632: difflib.unified_diff loses context
http://bugs.python.org/issue11632  opened by Brice.Videau

#11633: regression: print buffers output when end=''
http://bugs.python.org/issue11633  opened by techtonik

#11635: concurrent.futures uses polling
http://bugs.python.org/issue11635  opened by pitrou

#11637: Add cwd to sys.path for hooks
http://bugs.python.org/issue11637  opened by eric.araujo

#11638: pysetup un sdist crashes with weird trace if version is unicod
http://bugs.python.org/issue11638  opened by RonnyPfannschmidt

#11639: Documentation for *Config functions in logging module should b
http://bugs.python.org/issue11639  opened by santa4nt

#11640: Shelve references globals in its __del__ method
http://bugs.python.org/issue11640  opened by Peter.Davies

#11643: Use |version| instead of X.Y in the doc
http://bugs.python.org/issue11643  opened by eric.araujo

#11644: 2to3 documentation should mention that the sample file require
http://bugs.python.org/issue11644  opened by techtonik

#11645: "Expand 10 after" on rietveld shows a duplicate line
http://bugs.python.org/issue11645  opened by ubershmekel

#11646: 2to3: msvcrt.(get|put)ch -> (get|put)wch
http://bugs.python.org/issue11646  opened by techtonik

#11647: function decorated with a context manager can only be invoked 
http://bugs.python.org/issue11647  opened by pitrou

#11648: openlog()s 'logopt' keyword broken in syslog module
http://bugs.python.org/issue11648  opened by tbielawa

#11649: startElementNS in xml.sax.saxutils.XMLGenerator ignored encodi
http://bugs.python.org/issue11649  opened by gromgull

#11650: Faulty RESTART/EINTR handling in Parser/myreadline.c
http://bugs.python.org/issue11650  opened by sdaoden

#11651: Improve test targets in Makefile
http://bugs.python.org/issue11651  opened by pitrou

#11652: urlib{, 2} returns a pair of integers as the content-length va
http://bugs.python.org/issue11652  opened by Billy.Saelim

#11653: Problems with some tests using -j2
http://bugs.python.org/issue11653  opened by skip.montanaro

#11654: errors in atexit hooks don't change process exit code
http://bugs.python.org/issue11654  opened by pitrou

#11655: map() must not swallow exceptions from PyObject_GetIter
http://bugs.python.org/issue11655  opened by ebfe

#11656: Debug builds for Windows would be very helpful
http://bugs.python.org/issue11656  opened by jackjansen

#11657: multiprocessing_{send,recv}fd fail with fds > 256
http://bugs.python.org/issue11657  opened by Ben.Darnell

#11659: Fix ResourceWarning in test_subprocess
http://bugs.python.org/issue11659  opened by beardedp

#11661: test_collections.TestNamedTuple.test_source failing on many bu
http://bugs.python.org/issue11661  opened by r.david.murray

#11662: Redirect vulnerability in urllib/urllib2
http://bugs.python.org/issue11662  opened by gvanrossum

#11663: multiprocessing (and concurrent.futures) doesn't detect killed
http://bugs.python.org/issue11663  opened by pitrou

#11664: Add patch method to unittest.TestCase
http://bugs.python.org/issue11664  opened by eric.araujo

#11665: Regexp findall freezes
http://bugs.python.org/issue11665  opened by complex

#11666: Test pydoc to display full help for named tuples
http://bugs.python.org/issue11666  opened by rhettinger

#11668: _multiprocessing.Connection.poll with timeout uses polling und
http://bugs.python.org/issue11668  opened by pitrou

#11669: Clarify Lang Ref "Compound statements" footnote
http://bugs.python.org/issue11669  opened by gwideman

#11670: configparser read_file now iterates over f, docs still say it 
http://bugs.python.org/issue11670  opened by larry

#11671: Security hole in wsgiref.headers.Headers
http://bugs.python.org/issue11671  opened by Felix.Gr??bert

#11610: Improving property to accept abstract methods
http://bugs.python.org/issue11610  opened by dsdale24



Most recent 15 issues with no replies (15)
==========================================

#11671: Security hole in wsgiref.headers.Headers
http://bugs.python.org/issue11671

#11669: Clarify Lang Ref "Compound statements" footnote
http://bugs.python.org/issue11669

#11659: Fix ResourceWarning in test_subprocess
http://bugs.python.org/issue11659

#11657: multiprocessing_{send,recv}fd fail with fds > 256
http://bugs.python.org/issue11657

#11646: 2to3: msvcrt.(get|put)ch -> (get|put)wch
http://bugs.python.org/issue11646

#11643: Use |version| instead of X.Y in the doc
http://bugs.python.org/issue11643

#11640: Shelve references globals in its __del__ method
http://bugs.python.org/issue11640

#11639: Documentation for *Config functions in logging module should b
http://bugs.python.org/issue11639

#11637: Add cwd to sys.path for hooks
http://bugs.python.org/issue11637

#11632: difflib.unified_diff loses context
http://bugs.python.org/issue11632

#11620: winsound.PlaySound() with SND_MEMORY should accept bytes inste
http://bugs.python.org/issue11620

#11601: UnixCCompiler always uses compiler_so, not compiler
http://bugs.python.org/issue11601

#11600: PY_CFLAGS and PY_CPPFLAGS inconsistent
http://bugs.python.org/issue11600

#11588: Add "necessarily inclusive" groups to argparse
http://bugs.python.org/issue11588

#11580: Add width and precision formatters to PyBytes_FromFormatV()
http://bugs.python.org/issue11580



Most recent 15 issues waiting for review (15)
=============================================

#11669: Clarify Lang Ref "Compound statements" footnote
http://bugs.python.org/issue11669

#11666: Test pydoc to display full help for named tuples
http://bugs.python.org/issue11666

#11662: Redirect vulnerability in urllib/urllib2
http://bugs.python.org/issue11662

#11659: Fix ResourceWarning in test_subprocess
http://bugs.python.org/issue11659

#11652: urlib{, 2} returns a pair of integers as the content-length va
http://bugs.python.org/issue11652

#11651: Improve test targets in Makefile
http://bugs.python.org/issue11651

#11650: Faulty RESTART/EINTR handling in Parser/myreadline.c
http://bugs.python.org/issue11650

#11648: openlog()s 'logopt' keyword broken in syslog module
http://bugs.python.org/issue11648

#11640: Shelve references globals in its __del__ method
http://bugs.python.org/issue11640

#11635: concurrent.futures uses polling
http://bugs.python.org/issue11635

#11633: regression: print buffers output when end=''
http://bugs.python.org/issue11633

#11627: segfault raising an arbitrary object as an exception
http://bugs.python.org/issue11627

#11619: On Windows, don't encode filenames in the import machinery
http://bugs.python.org/issue11619

#11618: Locks broken wrt timeouts on Windows
http://bugs.python.org/issue11618

#11610: Improving property to accept abstract methods
http://bugs.python.org/issue11610



Top 10 most discussed issues (10)
=================================

#11618: Locks broken wrt timeouts on Windows
http://bugs.python.org/issue11618  31 msgs

#11650: Faulty RESTART/EINTR handling in Parser/myreadline.c
http://bugs.python.org/issue11650  25 msgs

#10050: urllib.request still has old 2.x urllib primitives
http://bugs.python.org/issue10050  17 msgs

#11393: Integrate faulthandler module into Python 3.3
http://bugs.python.org/issue11393  15 msgs

#11653: Problems with some tests using -j2
http://bugs.python.org/issue11653  14 msgs

#11662: Redirect vulnerability in urllib/urllib2
http://bugs.python.org/issue11662  14 msgs

#11635: concurrent.futures uses polling
http://bugs.python.org/issue11635  13 msgs

#11610: Improving property to accept abstract methods
http://bugs.python.org/issue11610  13 msgs

#11627: segfault raising an arbitrary object as an exception
http://bugs.python.org/issue11627  12 msgs

#11633: regression: print buffers output when end=''
http://bugs.python.org/issue11633  12 msgs



Issues closed (58)
==================

#3080: Full unicode import system
http://bugs.python.org/issue3080  closed by haypo

#4391: use proper gettext plurals forms in argparse and optparse
http://bugs.python.org/issue4391  closed by python-dev

#4498: Compiler warning "signed/unsigned comparison in mmapmodule"
http://bugs.python.org/issue4498  closed by rhettinger

#5537: LWPCookieJar cannot handle cookies with expirations of 2038 or
http://bugs.python.org/issue5537  closed by haypo

#8651: "s#" and friends can silently truncate buffer length
http://bugs.python.org/issue8651  closed by haypo

#10550: Windows: leak in test_concurrent_futures
http://bugs.python.org/issue10550  closed by skrah

#10610: Correct the float(), int() and complex() documentation
http://bugs.python.org/issue10610  closed by rhettinger

#10771: descriptor protocol documentation has two different definition
http://bugs.python.org/issue10771  closed by rhettinger

#10787: [random.gammavariate] Add the expression of the distribution i
http://bugs.python.org/issue10787  closed by rhettinger

#10833: Replace %.100s by %s in PyErr_Format(): the arbitrary limit of
http://bugs.python.org/issue10833  closed by haypo

#10988: Descriptor protocol documentation for super bindings is incorr
http://bugs.python.org/issue10988  closed by rhettinger

#11030: regrtest - allow for relative path with --coverdir
http://bugs.python.org/issue11030  closed by r.david.murray

#11031: regrtest - --testdir, new command-line option to specify alter
http://bugs.python.org/issue11031  closed by r.david.murray

#11046: setup.py/configure
http://bugs.python.org/issue11046  closed by ronaldoussoren

#11071: What's New review comments
http://bugs.python.org/issue11071  closed by rhettinger

#11093: test_future - rename not-unittest files to make regrtest.NOTTE
http://bugs.python.org/issue11093  closed by r.david.murray

#11127: sockets should not be pickleable
http://bugs.python.org/issue11127  closed by pitrou

#11210: PyErr_SetFromWindowsErrWithFilenameObject() doesn't exist: rem
http://bugs.python.org/issue11210  closed by python-dev

#11244: Negative tuple elements produce inefficient code.
http://bugs.python.org/issue11244  closed by mark.dickinson

#11333: Add empty __slots__ to collections.abc abstract base classes
http://bugs.python.org/issue11333  closed by rhettinger

#11395: print(s) fails on Windows with long strings
http://bugs.python.org/issue11395  closed by haypo

#11412: Section numbers in the Library Reference have a trailing perio
http://bugs.python.org/issue11412  closed by georg.brandl

#11415: ZipFile don't overwrite compresed files at create
http://bugs.python.org/issue11415  closed by terry.reedy

#11421: Subversion keywords missing on 2.5 checkout
http://bugs.python.org/issue11421  closed by loewis

#11456: Documentation csv RFC4180
http://bugs.python.org/issue11456  closed by skip.montanaro

#11459: Python select.select does not correctly report read readyness
http://bugs.python.org/issue11459  closed by pitrou

#11465: Set documentation: Link to wikipedia
http://bugs.python.org/issue11465  closed by terry.reedy

#11494: Confusing error message from warnings.warn
http://bugs.python.org/issue11494  closed by brett.cannon

#11563: test_urllibnet is triggering a ResourceWarning
http://bugs.python.org/issue11563  closed by python-dev

#11575: addresses.txt file leaks into search engines
http://bugs.python.org/issue11575  closed by pitrou

#11579: python 2.5 does not build from hg - looks for subversion keywo
http://bugs.python.org/issue11579  closed by python-dev

#11586: Python/pythonrun.c: get_codec_name() typo
http://bugs.python.org/issue11586  closed by haypo

#11589: Additional tests for email module
http://bugs.python.org/issue11589  closed by r.david.murray

#11590: email quoprimime.py patch for header_encode of empty string, d
http://bugs.python.org/issue11590  closed by r.david.murray

#11591: "python -S" should be robust against e.g. "from site import ad
http://bugs.python.org/issue11591  closed by eric.araujo

#11596: import error in test_fileinput.py when bz2 not installed (wind
http://bugs.python.org/issue11596  closed by brian.curtin

#11606: maxlinelen exceeded by email module's body_encode() function
http://bugs.python.org/issue11606  closed by r.david.murray

#11608: GzipFile cannot be used for streaming
http://bugs.python.org/issue11608  closed by ned.deily

#11609: urllib-related buildbot failures
http://bugs.python.org/issue11609  closed by orsenthil

#11613: test_subprocess fails under Windows
http://bugs.python.org/issue11613  closed by rnk

#11615: sporadic failure in test_posix
http://bugs.python.org/issue11615  closed by rosslagerwall

#11616: reap_children should not use WNOHANG
http://bugs.python.org/issue11616  closed by pitrou

#11621: build error: bootstrap issue with gettext
http://bugs.python.org/issue11621  closed by pitrou

#11622: Documentation
http://bugs.python.org/issue11622  closed by eric.araujo

#11625: Typo in collections.abc docs
http://bugs.python.org/issue11625  closed by rhettinger

#11628: cmp_to_key generated class should use __slots__
http://bugs.python.org/issue11628  closed by rhettinger

#11630: refleak in test_import
http://bugs.python.org/issue11630  closed by haypo

#11634: misleading comment on PyBytes_FromStringAndSize
http://bugs.python.org/issue11634  closed by eli.bendersky

#11636: fh is not defined in npyio.py fromregex
http://bugs.python.org/issue11636  closed by brian.curtin

#11641: raw_input() -> input() security issue
http://bugs.python.org/issue11641  closed by eric.smith

#11642: regression: input() doesn't strip a trailing newline on Window
http://bugs.python.org/issue11642  closed by brian.curtin

#11658: complex sqrt error
http://bugs.python.org/issue11658  closed by mark.dickinson

#11660: closure with too few cells segfaults
http://bugs.python.org/issue11660  closed by benjamin.peterson

#11667: 'configure' script overrides users setting of CFLAGS
http://bugs.python.org/issue11667  closed by amaury.forgeotdarc

#1214675: module warnings lacks a remove filter function
http://bugs.python.org/issue1214675  closed by gvanrossum

#6811: add a filename argument to marshal.load*
http://bugs.python.org/issue6811  closed by brett.cannon

#10828: Python 3 doesn't support non-ASCII module names with a locale 
http://bugs.python.org/issue10828  closed by terry.reedy

#11611: wxPython PropertyGrid Demo error and fix
http://bugs.python.org/issue11611  closed by ned.deily

From solipsis at pitrou.net  Fri Mar 25 18:09:28 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Mar 2011 18:09:28 +0100
Subject: [Python-Dev] [Python-checkins] cpython: Revert the
 Lib/test/test_bigmem.py changes from commit 17891566a478 (and a
References: <E1Q34UC-0000Yl-SC@dinsdale.python.org>
	<4D8CC66A.5080405@netwok.org>
Message-ID: <20110325180928.7ef6f692@pitrou.net>

On Fri, 25 Mar 2011 17:44:26 +0100
?ric Araujo <merwok at netwok.org> wrote:
> Hi,
> 
> > changeset:   68921:11dc3f270594
> > user:        Thomas Wouters <thomas at python.org>
> > date:        Fri Mar 25 11:42:37 2011 +0100
> > summary:
> >   Revert the Lib/test/test_bigmem.py changes from commit 17891566a478 (and a
> > few other assertEqual tests that snuck in), and expand the docstrings and
> > comments explaining why and how these tests are supposed to work.
> 
> Your commit message does not explain why you reverted the changes.  The
> specific assert* methods give more useful messages than assertEqual in
> case of failure.

Because they don't go well with huge inputs?

>>> s = "x" * (2**29)
>>> case.assertEqual(s + "a", s + "b")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 643,
in assertEqual assertion_func(first, second, msg=msg)
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 984,
in assertMultiLineEqual secondlines = [second + '\n']
MemoryError


(of course, the functions could just be fixed)



From martin at v.loewis.de  Fri Mar 25 19:54:24 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 25 Mar 2011 19:54:24 +0100
Subject: [Python-Dev] Unload a module written in C
In-Reply-To: <1301048056.9096.8.camel@marge>
References: <1301018620.25217.18.camel@marge> <4D8C3D3F.4000409@v.loewis.de>
	<1301048056.9096.8.camel@marge>
Message-ID: <4D8CE4E0.8060205@v.loewis.de>

Am 25.03.2011 11:14, schrieb Victor Stinner:
> Le vendredi 25 mars 2011 ? 07:59 +0100, "Martin v. L?wis" a ?crit :
>>> Is there a bug somewhere, or do I misunderstood something important?
>>
>> Module unloading is simply not implemented, and would be very difficult
>> to implement.
> 
> My problem is that if Python is embeded, my module will still be active
> after Py_FinalizeEx(). 

Ah. If that's the case, it's a bug.

Regards,
Martin

From N.D.Efford at leeds.ac.uk  Fri Mar 25 15:19:11 2011
From: N.D.Efford at leeds.ac.uk (Nick Efford)
Date: Fri, 25 Mar 2011 14:19:11 +0000 (GMT)
Subject: [Python-Dev] Python-Dev Digest, Vol 92, Issue 156
In-Reply-To: <mailman.8382.1301058430.1188.python-dev@python.org>
References: <mailman.8382.1301058430.1188.python-dev@python.org>
Message-ID: <alpine.LFD.2.00.1103251417480.27545@cslin112.csunix.comp.leeds.ac.uk>

On Fri, 25 Mar 2011, python-dev-request at python.org wrote:

> Send Python-Dev mailing list submissions to
>        python-dev at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://mail.python.org/mailman/listinfo/python-dev
> or, via email, send a message with subject or body 'help' to
>        python-dev-request at python.org
>
> You can reach the person managing the list at
>        python-dev-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-Dev digest..."
>
>
> Today's Topics:
>
>   1. Re: sprints and pushes (Nick Coghlan)
>   2. Re: Proposal for Python 3.3: dependence injection (Nick Coghlan)
>   3. Re: Proposal for Python 3.3: dependence injection (Xavier Morel)
>   4. Re: Proposal for Python 3.3: dependence injection (Nick Coghlan)
>   5. Re: CRLF line endings (Nick Coghlan)
>   6. Re: Unload a module written in C (Nick Coghlan)
>   7. Re: Unload a module written in C (Victor Stinner)
>   8. Re: [Python-checkins] cpython: Remove test_importable().
>      Couldn't see how to make this reliable across all (Nick Coghlan)
>   9. Re: Unload a module written in C (Nick Coghlan)
>  10. Python Core Mentorship program (Jesse Noller)
>  11. Re: CRLF line endings (Stefan Krah)
>  12. Re: Python Core Mentorship program (Jesse Noller)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 25 Mar 2011 21:00:25 +1000
> From: Nick Coghlan <ncoghlan at gmail.com>
> To: "Stephen J. Turnbull" <stephen at xemacs.org>
> Cc: Tres Seaver <tseaver at palladion.com>, python-dev at python.org
> Subject: Re: [Python-Dev] sprints and pushes
> Message-ID:
>        <AANLkTik7qQZPs0SXyo4BpaHTX=KvoeVZfWjF827Z29G1 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Mar 25, 2011 at 12:51 PM, Stephen J. Turnbull
> <stephen at xemacs.org> wrote:
>> Eg, much as I normally respect Barry's intuitions, his proposal (to
>> remove costly tests, without reference to the possibility of missing
>> something important) is IMHO absolutely the wrong criterion. ?I don't
>> really know about Python's test suite, but in XEmacs the time-
>> expensive tests are mostly the ones that involve timeouts and lots of
>> system calls because they interact with the OS -- and those are
>> precisely the finicky areas where a small change can occasion an
>> unexpected bug. ?For XEmacs, those bugs also are more likely than
>> average to be showstoppers for dependents, in the sense that until
>> they're fixed, the dependents can't be tested at all. ?So the cost of
>> *not* running those tests is relatively high, too.
>
> For Python, our most expensive, slow tests are generally process
> related or IO related (over time the threading related ones have been
> largely fixed to use Event based signalling rather than relying on
> timeouts, so they're significantly faster than they once were).
>
> These slow tests are *also* typically the most platform dependent
> tests, so a "green light" from a local test run is generally pretty
> inconclusive - you don't really find out whether you borked something
> until you get green lights on the buildbots for platforms other than
> those the patch was developed on.
>
> So I still see value in having a standard "smoke test" that runs
> through the platform independent stuff, to reduce the number of minor
> errors that needlessly cause the buildbots to go red.
>
> The idea would be to create a tiered test suite along the following lines:
>
> 1. The buildbots: run the entire (-uall) test suite across a variety
> of platforms. Performed for every commit pushed to
> hg.python.org/cpython.
> 2. Complete local test: run the entire (-uall) test suite on a local
> working copy. Recommended before first committing a fix or change to a
> branch.
> 3. Basic local test: run the test suite with no additional resources
> enabled on a local working copy. Current closest equivalent to a
> "smoke test"
> 4. Proposed "smoke test": quick test of platform independent code for
> use when merging heads after a push race
> 5. Specific tests: run specified tests for modules being worked on.
> Used during development to check fix validity and feature degree of
> completion.
>
> With the volume of platform dependent code we have in CPython and the
> standard library, the only way we're ever likely to achieve
> consistently green buildbots is to move to a "staging repo" model,
> where commits only get made to the central repo after they have
> already passed muster on the buildbots at least once. I think that's
> actually a good way for us to go in the long run, but I also think
> separating out a fast set of platform independent is a decent idea.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 25 Mar 2011 21:04:17 +1000
> From: Nick Coghlan <ncoghlan at gmail.com>
> To: Simon Cross <hodgestar+pythondev at gmail.com>
> Cc: Jesus Cea <jcea at jcea.es>, Python DEV <python-dev at python.org>
> Subject: Re: [Python-Dev] Proposal for Python 3.3: dependence
>        injection
> Message-ID:
>        <AANLkTin23KPuqUbUXN+BC_OWnu2fGxieTWPQZ9qm42=+ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Mar 25, 2011 at 7:22 PM, Simon Cross
> <hodgestar+pythondev at gmail.com> wrote:
>> On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> As an example of the last point, perhaps rather than modifying all the
>>> *clients* of the socket module, it may make more sense to have tools
>>> in the socket module itself to temporarily customise the socket
>>> creation process in the current thread. The advantage of such an
>>> approach is that it would then work for 3rd party libraries that
>>> create sockets, without requiring any further modification.
>>
>> -2. ?That wouldn't allow one to use normal sockets in one 3rd party
>> library and special sockets in another 3rd party library.
>
> Uh, yes it would. One possible implementation is to use exactly the
> same techniques that are used to implement contexts in the decimal
> module.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 25 Mar 2011 12:07:50 +0100
> From: Xavier Morel <python-dev at masklinn.net>
> To: Simon Cross <hodgestar+pythondev at gmail.com>
> Cc: Jesus Cea <jcea at jcea.es>, Nick Coghlan <ncoghlan at gmail.com>,
>        Python DEV <python-dev at python.org>
> Subject: Re: [Python-Dev] Proposal for Python 3.3: dependence
>        injection
> Message-ID: <A780E8D4-C85C-48C7-A970-CA78763D8A31 at masklinn.net>
> Content-Type: text/plain; charset=us-ascii
>
> On 2011-03-25, at 10:22 , Simon Cross wrote:
>> On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> As an example of the last point, perhaps rather than modifying all the
>>> *clients* of the socket module, it may make more sense to have tools
>>> in the socket module itself to temporarily customise the socket
>>> creation process in the current thread. The advantage of such an
>>> approach is that it would then work for 3rd party libraries that
>>> create sockets, without requiring any further modification.
>>
>> -2.  That wouldn't allow one to use normal sockets in one 3rd party
>> library and special sockets in another 3rd party library.
>>
>> Schiavo
>> Simon
>
> Or even in "first-party" code (in the stdlib) to set different timeouts on different APIs (say, an xmlrpclib.ServerProxy and an IMAP4 client).
>
> For instance, currently as far as I can tell setting a socket timeout on an xmlrpclib.ServerProxy without setting a global timeout involves:
>
> * subclassing all of xmlrpclib.Serverproxy, xmlrpclib.Transport, httplib.HTTP and httplib.HTTPConnection
> * overloading __init__ on the ServerProxy subclass (and on Transport if the timeout is to be a parameter)
> * overloading make_connection on the Transport subclass (in order to use the HTTP subclass and propagate the timeout)
> * overloading _connection_class on the HTTP subclass
> * overloading connect on the HTTPConnection class
>
> This *could* be solved by wrapping a socket-related thread-local context manager around each call resulting in the creation of a socket, but these call sites may not even be under control.
>
> ------------------------------
>
> Message: 4
> Date: Fri, 25 Mar 2011 21:10:08 +1000
> From: Nick Coghlan <ncoghlan at gmail.com>
> To: Glenn Linderman <v+python at g.nevcal.com>
> Cc: python-dev at python.org
> Subject: Re: [Python-Dev] Proposal for Python 3.3: dependence
>        injection
> Message-ID:
>        <AANLkTikgmses_8UH+o9WJsPXBSY+FA6PxJDBC39m3jf+ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Mar 25, 2011 at 12:22 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:
>> On 3/24/2011 4:25 PM, Nick Coghlan wrote:
>>
>> As an example of the last point, perhaps rather than modifying all the
>> *clients* of the socket module, it may make more sense to have tools
>> in the socket module itself to temporarily customise the socket
>> creation process in the current thread. The advantage of such an
>> approach is that it would then work for 3rd party libraries that
>> create sockets, without requiring any further modification.
>>
>> Would be easier to implement that way, not requiring changes to every client
>> of the socket library, but in some circles that would be called "action at a
>> distance", and harder to understand.
>
> Oh, it is definitely action at a distance, and quite deliberately so.
>
> My model for the suggestion is the context objects in the decimal
> module. They offer a constrained way to affect the way the entire
> decimal module goes about its business, and through judicious use of
> thread local storage and context managers, allow this to be done
> without distorting the public API of the decimal objects themselves.
>
> There's no reason a solution along those lines wouldn't work for the
> socket module, or any other API that would similarly benefit from
> providing a mechanism for applications to indirectly control library
> behaviour without resorting to monkey-patching.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 25 Mar 2011 21:12:19 +1000
> From: Nick Coghlan <ncoghlan at gmail.com>
> To: Stefan Krah <stefan at bytereef.org>
> Cc: python-dev at python.org
> Subject: Re: [Python-Dev] CRLF line endings
> Message-ID:
>        <AANLkTinWp3vOGymzS2bnrp8S3aRgOXL26FXSDY2nhxtC at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Mar 25, 2011 at 7:36 PM, Stefan Krah <stefan at bytereef.org> wrote:
>> Hi,
>>
>> A commit hook prevented pushing changes to the cdecimal repository:
>>
>> pushing to ssh://hg at hg.python.org/features/cdecimal
>> searching for changes
>> 8 changesets found
>> remote: adding changesets
>> remote: adding manifests
>> remote: adding file changes
>> remote: added 8 changesets with 117 changes to 117 files
>> remote: error: pretxnchangegroup.eol hook failed: Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not have CRLF line endings
>> remote: transaction abort!
>> remote: rollback completed
>> remote: abort: Modules/cdecimal/tests/dnloop.patch in 80914c366edf should not have CRLF line endings
>>
>>
>> However, dnloop.patch is correct and must have CRLF line endings. How
>> can I disable the commit hook?
>
> Don't disable the commit hook, update .hgeol to flag that file as
> requiring CRLF line endings.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 25 Mar 2011 21:14:59 +1000
> From: Nick Coghlan <ncoghlan at gmail.com>
> To: Victor Stinner <victor.stinner at haypocalc.com>
> Cc: "\"Martin v." <martin at v.loewis.de>, python-dev at python.org
> Subject: Re: [Python-Dev] Unload a module written in C
> Message-ID:
>        <AANLkTimM-g3mgTiKNvj-koT6rdM0-MOqgk9a3jO6XJnP at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Mar 25, 2011 at 8:14 PM, Victor Stinner
> <victor.stinner at haypocalc.com> wrote:
>> Le vendredi 25 mars 2011 ? 07:59 +0100, "Martin v. L?wis" a ?crit :
>>>> Is there a bug somewhere, or do I misunderstood something important?
>>>
>>> Module unloading is simply not implemented, and would be very difficult
>>> to implement.
>>
>> My problem is that if Python is embeded, my module will still be active
>> after Py_FinalizeEx(). For example, if it installed an handler for the
>> SIGSEGV signal: a segmentation fault will call the handler which will
>> try to get the interpreter state, but there is no more interpreter. I
>> don't know if it is a problem or not, but I would prefer to cleanup my
>> module on Py_FinalizeEx().
>
> And registering your cleanup function with atexit() isn't enough? Or
> does that remove the handler too early?
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 25 Mar 2011 12:36:01 +0100
> From: Victor Stinner <victor.stinner at haypocalc.com>
> To: Nick Coghlan <ncoghlan at gmail.com>
> Cc: "\"Martin v." <martin at v.loewis.de>, python-dev at python.org
> Subject: Re: [Python-Dev] Unload a module written in C
> Message-ID: <1301052961.11097.3.camel at marge>
> Content-Type: text/plain; charset="UTF-8"
>
> Le vendredi 25 mars 2011 ? 21:14 +1000, Nick Coghlan a ?crit :
>> On Fri, Mar 25, 2011 at 8:14 PM, Victor Stinner
>> <victor.stinner at haypocalc.com> wrote:
>>> Le vendredi 25 mars 2011 ? 07:59 +0100, "Martin v. L?wis" a ?crit :
>>>>> Is there a bug somewhere, or do I misunderstood something important?
>>>>
>>>> Module unloading is simply not implemented, and would be very difficult
>>>> to implement.
>>>
>>> My problem is that if Python is embeded, my module will still be active
>>> after Py_FinalizeEx(). For example, if it installed an handler for the
>>> SIGSEGV signal: a segmentation fault will call the handler which will
>>> try to get the interpreter state, but there is no more interpreter. I
>>> don't know if it is a problem or not, but I would prefer to cleanup my
>>> module on Py_FinalizeEx().
>>
>> And registering your cleanup function with atexit() isn't enough? Or
>> does that remove the handler too early?
>
> atexit() is too late: when Python is embeded, Py_Finalize() may be
> called a long time before the program does really finish.
>
> Well, I never embeded Python in another program, but it looks like some
> people do initialize/finalize Python more than once:
>
> http://bugs.python.org/issue11321
> "9th import of module _pickle always crashes"
>
> In this issue, Python is initialized/finalized 20 times.
>
> Victor
>
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 25 Mar 2011 21:37:09 +1000
> From: Nick Coghlan <ncoghlan at gmail.com>
> To: python-dev at python.org
> Cc: "raymond.hettinger" <python-checkins at python.org>
> Subject: Re: [Python-Dev] [Python-checkins] cpython: Remove
>        test_importable(). Couldn't see how to make this reliable across all
> Message-ID:
>        <AANLkTikXNhrsmAnPXCY1A+NdFLYGzGzdLoDHaWfPxi1d at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Mar 25, 2011 at 3:51 AM, raymond.hettinger
> <python-checkins at python.org> wrote:
>> http://hg.python.org/cpython/rev/5adddc6be3c1
>> changeset: ? 68902:5adddc6be3c1
>> user: ? ? ? ?Raymond Hettinger <python at rcn.com>
>> date: ? ? ? ?Thu Mar 24 10:51:06 2011 -0700
>> summary:
>> ?Remove test_importable(). ?Couldn't see how to make this reliable across all platforms.
>
> For this particular use case, a temporary directory added to sys,path,
> then some subsequent cleanup of sys.modules, sys.path and
> sys.path_importer_cache would likely do the trick.
>
> I've actually never been a fan of using TESTFN in tests - the tempfile
> module always struck me as being significantly more useful. It also
> makes tidying up the files afterwards really easy - the temporary
> directory context manager will blow everything away for you.
>
> Then again, quite a few of the tests I've written involved convoluted
> module hierarchies, so I'm likely a little biased by my typical use
> cases :)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 25 Mar 2011 21:47:16 +1000
> From: Nick Coghlan <ncoghlan at gmail.com>
> To: Victor Stinner <victor.stinner at haypocalc.com>
> Cc: "\"Martin v." <martin at v.loewis.de>, python-dev at python.org
> Subject: Re: [Python-Dev] Unload a module written in C
> Message-ID:
>        <AANLkTik0ORWLnCn7WAi9miP97eGuVunNeEA0H8K3DmEX at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Mar 25, 2011 at 9:36 PM, Victor Stinner
> <victor.stinner at haypocalc.com> wrote:
>>> And registering your cleanup function with atexit() isn't enough? Or
>>> does that remove the handler too early?
>>
>> atexit() is too late: when Python is embeded, Py_Finalize() may be
>> called a long time before the program does really finish.
>
> I'm talking about the Python "atexit" module - any callbacks
> registered there are invoked by Py_Finalize(), not by process
> termination.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
>
>
> ------------------------------
>
> Message: 10
> Date: Fri, 25 Mar 2011 08:03:43 -0400
> From: Jesse Noller <jnoller at gmail.com>
> To: Python-Dev <python-dev at python.org>
> Subject: [Python-Dev] Python Core Mentorship program
> Message-ID:
>        <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello everyone:
>
> I wanted to take a moment to outline another idea which came out of
> PyCon 2011 this year from numerous sources - a Python Core Mentorship
> Program predicated on the idea that Python-Core, and Python as a whole
> would be served by further lowering the barrier to entry of
> contribution, and to provide a program to connect new programmers,
> students, women, and others to experienced Python-Core developers
> (Mentors).
>
> Brett's revamp of the Dev guide was part one of "secret plan to get
> more people involved in python-core" - this is another part, but I'm
> not sure of the numbering scheme.
>
> The mission of the Python Core Mentor Program is to provide an open
> and welcoming place to connect students, programmers - and anyone
> interested in contributing to the Python-Core development. This
> project is based on the idea that the best way to welcome new people
> into any project is a venue which connects them to mentors who can
> assist in guiding them through the contribution process, including
> discussions on lists such as python-dev, and python-ideas, the bug
> tracker, mercurial, code reviews, etc.
>
> Additionally, mentors will assist in something incredibly critical to
> maintain contributor interest: getting patches through the process and
> actually *committed*. We all know - not everyone who is mentor will
> have all the answers, so mentors also act as conduits to others who
> will have the answer.
>
> The project itself will (hopefully) be low in time-spent, and largely
> self-managing. We will start simple with a mailing list
> (core-mentorship at python.org) where mentors, and those who wish to be
> mentored or ask questions may do so. This mailing list will have a
> code of conduct which will help prevent flame wars, or other
> counterproductive discussions - a code of conduct also makes it clear
> to mentors what they''re agreeing to when they decide to participate.
>
> The new list will also have a closed, members-only archive. After
> consulting with other core developers, we believe it's easier to ask
> questions when you don't have to worry about Google picking up your
> words from a public archive.
>
> We want to make this list a resource for people to be able to get
> started, ask "silly" questions, and so on - our goal is to turn anyone
> who wishes to be into an active, sustainable committer to Python.
>
> Mentors will be asked to answer questions - but also assist people in
> need of help with discussions on the mailing lists and bug tracker
> (conversations on which could have become contentious or stressful)
> and generally to be advocates for the people being mentored. For
> example - if a person submits a patch to the tracker, the mentor list
> may help them through initial code reviews, or discussions with other
> core developers. The job is to act as an experienced proxy for them.
>
> The first step to this project is to ask for volunteer mentors -
> people who are willing to help answer questions on the list, and
> generally guide people as needed being as friendly and courteous and
> welcoming as possible.
>
> If you are interested in being a mentor - or have feedback about this
> plan in general, please feel free to reach out to me
> (jnoller at gmail.com) directly. My goal, once this is setup, is to have
> the project largely self-managing, with the PSF helping to market it
> to the community as a whole.
>
> Jesse
>
>
> ------------------------------
>
> Message: 11
> Date: Fri, 25 Mar 2011 13:59:32 +0100
> From: Stefan Krah <stefan at bytereef.org>
> To: python-dev at python.org
> Subject: Re: [Python-Dev] CRLF line endings
> Message-ID: <20110325125932.GA13028 at sleipnir.bytereef.org>
> Content-Type: text/plain; charset=us-ascii
>
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> However, dnloop.patch is correct and must have CRLF line endings. How
>>> can I disable the commit hook?
>>
>> Don't disable the commit hook, update .hgeol to flag that file as
>> requiring CRLF line endings.
>
> Thanks, that works well.
>
>
> Stefan Krah
>
>
>
>
> ------------------------------
>
> Message: 12
> Date: Fri, 25 Mar 2011 09:06:48 -0400
> From: Jesse Noller <jnoller at gmail.com>
> To: exarkun at twistedmatrix.com
> Cc: Python-Dev <python-dev at python.org>
> Subject: Re: [Python-Dev] Python Core Mentorship program
> Message-ID:
>        <AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Mar 25, 2011 at 9:04 AM,  <exarkun at twistedmatrix.com> wrote:
>> On 12:03 pm, jnoller at gmail.com wrote:
>>>
>>> Hello everyone:
>>>
>>>
>>> The new list will also have a closed, members-only archive. After
>>> consulting with other core developers, we believe it's easier to ask
>>> questions when you don't have to worry about Google picking up your
>>> words from a public archive.
>>
>> Boggle.
>>
>> Jean-Paul
>>
>
> I assume that means your in, or you hate that idea?
>
>
> ------------------------------
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
>
>
> End of Python-Dev Digest, Vol 92, Issue 156
> *******************************************
>

-- 
Dr Nick Efford, School of | E: N.D.Efford at leeds.ac.uk
Computing, University of  | T: +44 113 343 6809
Leeds, Leeds, LS2 9JT, UK | W: http://www.comp.leeds.ac.uk/nde/
--------------------------+-----------------------------------------
PGP fingerprint: 6ADF 16C2 4E2D 320B F537  8F3C 402D 1C78 A668 8492

From reliable.domains at gmail.com  Fri Mar 25 19:56:19 2011
From: reliable.domains at gmail.com (Reliable Domains)
Date: Fri, 25 Mar 2011 11:56:19 -0700
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <19852.38080.246431.344709@montanaro.dyndns.org>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>	<AANLkTim9orMhAs3yZevWcCrZfwxTf3fLEw_h9SZBBZmK@mail.gmail.com>
	<19852.38080.246431.344709@montanaro.dyndns.org>
Message-ID: <4D8CE553.9020100@gmail.com>

On 3/25/2011 6:12 AM, skip at pobox.com wrote:
>      >>  Boggle.
>
>      Jesse>  I assume that means your in, or you hate that idea?
>
> Or that he just really likes to play Boggle.:-)

I really like to play Boggle.  It is even better with our local rules... 
5x5 grid, 5 letter minimum word size, and 4 minute time limit.

But I like the idea of the mentorship, especially as I'm just looking to 
learn to contribute to Python.

From benjamin at python.org  Fri Mar 25 20:12:00 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 25 Mar 2011 14:12:00 -0500
Subject: [Python-Dev] 2to3 status, repositories and HACKING guide
In-Reply-To: <AANLkTingP4ZwRv=ta6RC_C59nbS6gN-hkzVm15Xdd-2Y@mail.gmail.com>
References: <AANLkTi=Uh7f56LdZ_kgvwQVF7t_FYNgqpfH34DdgppNG@mail.gmail.com>
	<AANLkTingP4ZwRv=ta6RC_C59nbS6gN-hkzVm15Xdd-2Y@mail.gmail.com>
Message-ID: <AANLkTi=frkAceLLEtBYWDsQCKSOsVrQPv1jJ=G3h_jT1@mail.gmail.com>

The main cpython repo.

2011/3/25 anatoly techtonik <techtonik at gmail.com>:
> Hi, Benjamin,
>
> Is your repository for 2to3 is still actual?
> http://svn.python.org/view/sandbox/trunk/2to3/
>
> Which should I use to start hacking on 2to3?
>
> --
> anatoly t.
>
>
>
> On Wed, Mar 23, 2011 at 9:01 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> Hi,
>>
>> Currently 2to3 page at http://wiki.python.org/moin/2to3 lists
>> http://svn.python.org/view/sandbox/trunk/2to3 as a repository for 2to3
>> tool. There is also an outdated repository at http://hg.python.org/
>> and the page says that the code is finally integrated into CPython 2.6
>> - you can see it at
>> http://hg.python.org/cpython/file/default/Lib/lib2to3. So, what
>> version is more up-to-date?
>>
>> In svn repository there is a HACKING guide advising to use
>> find_pattern.py script for writing new fixer. However, there is no
>> find_pattern.py in CPython repository, no HACKING guide, no any
>> documentation about how to write fixers or description of PATTERN
>> format. Did I miss something?
>> --
>> anatoly t.
>>
>



-- 
Regards,
Benjamin

From martin at v.loewis.de  Fri Mar 25 21:11:03 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 25 Mar 2011 21:11:03 +0100
Subject: [Python-Dev] Unload a module written in C
In-Reply-To: <imhn04$u62$1@dough.gmane.org>
References: <1301018620.25217.18.camel@marge> <4D8C3D3F.4000409@v.loewis.de>
	<imhn04$u62$1@dough.gmane.org>
Message-ID: <4D8CF6D7.3020800@v.loewis.de>

Am 25.03.2011 10:24, schrieb Stefan Behnel:
> "Martin v. L?wis", 25.03.2011 07:59:
>>> Is there a bug somewhere, or do I misunderstood something important?
>>
>> Module unloading is simply not implemented, and would be very difficult
>> to implement.
> 
> Are you saying that because objects instantiated from a module do not
> normally keep a reference to it to keep it alive?

No, I'm saying that there is no support whatsoever to unload the shared
library of the extension module when the extension module would no
longer be used.

Regards,
Martin

From rndblnch at gmail.com  Fri Mar 25 21:25:41 2011
From: rndblnch at gmail.com (rndblnch)
Date: Fri, 25 Mar 2011 20:25:41 +0000 (UTC)
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
	<4D6AB409.40001@canterbury.ac.nz>
	<loom.20110322T000609-760@post.gmane.org>
	<AANLkTik6CZbJj2cPO+807vcp85S3qTfC-w5fMjmdzkuj@mail.gmail.com>
	<AANLkTimpM8ysUzJL1idHoKXuFCpbYgAjzaGb2DFsVF=u@mail.gmail.com>
	<loom.20110322T125508-35@post.gmane.org>
	<loom.20110324T151333-689@post.gmane.org>
Message-ID: <loom.20110325T205950-167@post.gmane.org>

rndblnch <rndblnch <at> gmail.com> writes:
> Now that I have figured out how to use patch queues with bitbucket, I will
> maintain greg's pep380 implementation as a patch on top of cpython here:
> <https://bitbucket.org/rndblnch/cpython-pep380/>

snip

> The patch is now visible here:
> <https://bitbucket.org/rndblnch/cpython-pep380/qseries?
apply=t&qs_apply=pep380>

There is a bug (acknowledged by bitbucket) preventing this page to display the
patch.
The error message is misleading, it states that the patch "pep380 did not apply
cleanly" but the problem is with bitbucket patching mechanism, not with the
patch.

The raw path is visible there:
<https://bitbucket.org/rndblnch/cpython-pep380/src/tip/pep380>
and I have documented how to use it on the wiki:
<https://bitbucket.org/rndblnch/cpython-pep380/wiki/>

I will stop spamming python-dev now...
It was just an attempt to help getting pep380 in python3.3 :)

renaud



From ben+python at benfinney.id.au  Fri Mar 25 21:57:41 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 26 Mar 2011 07:57:41 +1100
Subject: [Python-Dev] Python Core Mentorship program
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
Message-ID: <87ei5u2a0q.fsf@benfinney.id.au>

exarkun at twistedmatrix.com writes:

> On 12:03 pm, jnoller at gmail.com wrote:
> >The new list will also have a closed, members-only archive. After
> >consulting with other core developers, we believe it's easier to ask
> >questions when you don't have to worry about Google picking up your
> >words from a public archive.
>
> Boggle.

Indeed, I share this sentiment.

If you don't want a specific party snooping the site, just block that
specific party. Why make a walled garden that *nobody* outside can look
into? That undermines the free exchange of information.

Surely a forum specifically for mentorship will be more useful if
outsiders can be directed to existing discussions, without needing to
join the private club.

-- 
 \        ?Odious ideas are not entitled to hide from criticism behind |
  `\          the human shield of their believers' feelings.? ?Richard |
_o__)                                                         Stallman |
Ben Finney


From solipsis at pitrou.net  Fri Mar 25 22:12:22 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Mar 2011 22:12:22 +0100
Subject: [Python-Dev] Python Core Mentorship program
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
Message-ID: <20110325221222.636c9dc9@pitrou.net>

On Sat, 26 Mar 2011 07:57:41 +1100
Ben Finney <ben+python at benfinney.id.au> wrote:
> exarkun at twistedmatrix.com writes:
> 
> > On 12:03 pm, jnoller at gmail.com wrote:
> > >The new list will also have a closed, members-only archive. After
> > >consulting with other core developers, we believe it's easier to ask
> > >questions when you don't have to worry about Google picking up your
> > >words from a public archive.
> >
> > Boggle.
> 
> Indeed, I share this sentiment.
> 
> If you don't want a specific party snooping the site, just block that
> specific party. Why make a walled garden that *nobody* outside can look
> into? That undermines the free exchange of information.
> 
> Surely a forum specifically for mentorship will be more useful if
> outsiders can be directed to existing discussions, without needing to
> join the private club.

+1



From jacob at jacobian.org  Fri Mar 25 22:13:56 2011
From: jacob at jacobian.org (Jacob Kaplan-Moss)
Date: Fri, 25 Mar 2011 16:13:56 -0500
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <87ei5u2a0q.fsf@benfinney.id.au>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
Message-ID: <AANLkTimh9vuXpxC4aKFGhT99NuPPV1m5chGpjNOvJ_mN@mail.gmail.com>

On Fri, Mar 25, 2011 at 3:57 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> If you don't want a specific party snooping the site, just block that
> specific party. Why make a walled garden that *nobody* outside can look
> into? That undermines the free exchange of information.

I think the point is that most people aren't comfortable with their
fits, starts, and general n00bishness being published for the world to
see.

Heck, I've got a fairly thick skin but I'm not comfortable asking
stupid questions about compiling or patching Python here on
python-dev. I have trouble with the thought of my idiocy being part of
the public record. Doing things in private feels a lot more intimate
and comfortable.

But you know what? At the end of the day it doesn't matter. Arguments
about private versus public archives are like arguments about
reply-to: there's never going to be a "correct" answer. If this
proposed lists' archives are public I don't have to participate. If
they're private you don't have to participate. Let's just see where it
goes, eh?

Jacob

From guido at python.org  Fri Mar 25 22:16:49 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 25 Mar 2011 14:16:49 -0700
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <87ei5u2a0q.fsf@benfinney.id.au>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
Message-ID: <AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>

On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> If you don't want a specific party snooping the site, just block that
> specific party. Why make a walled garden that *nobody* outside can look
> into? That undermines the free exchange of information.
>
> Surely a forum specifically for mentorship will be more useful if
> outsiders can be directed to existing discussions, without needing to
> join the private club.

This argument comes up repeatedly. Some people object on principle to
all closed lists. Other people will not participate in a discussion
(or will not speak their minds about certain topics) unless they have
some sense that the list is "closed". The former group will then argue
that the closedness of the list is an illusion, that there are many
ways to snoop on the list regardless. (And there are, technically
speaking.) The latter group will still feel a different comfort level
and argue that *socially* it is not the same thing at all.

I propose to give it a rest. If you want to know what's going on
there, just subscribe, nobody will stop you (and if they did there are
plenty of public forums to complain). You will find soon enough that
nothing unsavory is being discussed. There's an understanding that
only people, not bots/indexers/etc., subscribe to the list, and that
the members are not to forward/publish what they read outside the list
without permission. That's enough to give group #2 the feeling of
comfort (depending, always, on how the attitude of the members turns
out to be of course) but it doesn't mean it's closed. There are other
ways to publish information that might be useful for others, e.g.
blogs, wikis, etc.

-- 
--Guido van Rossum (python.org/~guido)

From merwok at netwok.org  Fri Mar 25 22:22:04 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 25 Mar 2011 22:22:04 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <AANLkTikuO1Ob46imuZsnTQgaPMZ64es3wUEiE6aJgTi-@mail.gmail.com>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>	<4D889BC8.4080909@netwok.org>
	<AANLkTikuO1Ob46imuZsnTQgaPMZ64es3wUEiE6aJgTi-@mail.gmail.com>
Message-ID: <4D8D077C.7000302@netwok.org>

Le 22/03/2011 22:47, Nick Coghlan a ?crit :
> On Tue, Mar 22, 2011 at 10:53 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> You have to use one public repo per bug, as roundup will only use the
>> default branch to compute the diff.  Maybe adding support for named
>> branches so that you can have one repo used for many bug reports would
>> be useful.
> Since I run my sandbox that way, I asked Martin about that at Pycon -
> it's on his todo list for the integration.

Work has been started on that, thanks!  Roundup should soon support the
workflow described in the devguide for feature work, which will be awesome.

I?ve tried to use a clone with a named branch for
http://bugs.python.org/issue5845 and found those bugs:
- The revset code is not robust against an hyphen in the branch name.
- The first patch was empty (note that the repo was not up to date).
- After pulling, merging and pushing, the patch created contained the
merge diff, not the useful diff with my changes.

Another thing to make it rock more: In the repo list, use ?#? instead of
?:? as a separator between repo URI and branch name; it?s standard
Mercurial form and will allow people to copy-paste the whole thing to
get a clone of the repo up to that branch.

Regards

From martin at v.loewis.de  Fri Mar 25 22:42:56 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 25 Mar 2011 22:42:56 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D8D077C.7000302@netwok.org>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>	<4D889BC8.4080909@netwok.org>
	<AANLkTikuO1Ob46imuZsnTQgaPMZ64es3wUEiE6aJgTi-@mail.gmail.com>
	<4D8D077C.7000302@netwok.org>
Message-ID: <4D8D0C60.5070907@v.loewis.de>

> Work has been started on that, thanks!  Roundup should soon support the
> workflow described in the devguide for feature work, which will be awesome.

Make sure to submit issues to the meta tracker, please.

> I?ve tried to use a clone with a named branch for
> http://bugs.python.org/issue5845 and found those bugs:
> - The revset code is not robust against an hyphen in the branch name.

Ok, I'll investigate. Not sure whether the revset syntax even supports
that, though.

> - The first patch was empty (note that the repo was not up to date).

This I don't understand. What repo was not up to date?

> - After pulling, merging and pushing, the patch created contained the
> merge diff, not the useful diff with my changes.

Again, please elaborate. What is the "merge diff" that it contained?

> Another thing to make it rock more: In the repo list, use ?#? instead of
> ?:? as a separator between repo URI and branch name; it?s standard
> Mercurial form and will allow people to copy-paste the whole thing to
> get a clone of the repo up to that branch.

Ok, committed.

Regards,
Martin

From jnoller at gmail.com  Fri Mar 25 22:48:13 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Mar 2011 17:48:13 -0400
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
Message-ID: <AANLkTinGFY_25XvgP0GwkA9oJ6kmFHvg86VtnR7h=L9o@mail.gmail.com>

On Fri, Mar 25, 2011 at 5:16 PM, Guido van Rossum <guido at python.org> wrote:
> On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>> If you don't want a specific party snooping the site, just block that
>> specific party. Why make a walled garden that *nobody* outside can look
>> into? That undermines the free exchange of information.
>>
>> Surely a forum specifically for mentorship will be more useful if
>> outsiders can be directed to existing discussions, without needing to
>> join the private club.
>
> This argument comes up repeatedly. Some people object on principle to
> all closed lists. Other people will not participate in a discussion
> (or will not speak their minds about certain topics) unless they have
> some sense that the list is "closed". The former group will then argue
> that the closedness of the list is an illusion, that there are many
> ways to snoop on the list regardless. (And there are, technically
> speaking.) The latter group will still feel a different comfort level
> and argue that *socially* it is not the same thing at all.
>
> I propose to give it a rest. If you want to know what's going on
> there, just subscribe, nobody will stop you (and if they did there are
> plenty of public forums to complain). You will find soon enough that
> nothing unsavory is being discussed. There's an understanding that
> only people, not bots/indexers/etc., subscribe to the list, and that
> the members are not to forward/publish what they read outside the list
> without permission. That's enough to give group #2 the feeling of
> comfort (depending, always, on how the attitude of the members turns
> out to be of course) but it doesn't mean it's closed. There are other
> ways to publish information that might be useful for others, e.g.
> blogs, wikis, etc.
>
> --

+1 to what Guido and Jacob said. I know long time members of this list
uncomfortable with the prospect of bringing up anything on this
mailing list for various reasons. Given that, and my desire that we
provide a safe, friendly forum, biased towards the target audience
(newbies) versus those of us who are comfortable with public debate
and calcified attitudes, I'm pretty firm the archives stay "closed" to
only members.

Anyone, can of course, subscribe.

Jesse

From merwok at netwok.org  Fri Mar 25 22:51:03 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 25 Mar 2011 22:51:03 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D8D0C60.5070907@v.loewis.de>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>	<4D889BC8.4080909@netwok.org>
	<AANLkTikuO1Ob46imuZsnTQgaPMZ64es3wUEiE6aJgTi-@mail.gmail.com>
	<4D8D077C.7000302@netwok.org> <4D8D0C60.5070907@v.loewis.de>
Message-ID: <4D8D0E47.8090503@netwok.org>

> Make sure to submit issues to the meta tracker, please.

Right, I?ll do that.  Since you have questions in this message, for now
I?ll continue here.

>> - The first patch was empty (note that the repo was not up to date).
> This I don't understand. What repo was not up to date?

I mean that my linked repo didn?t have all changesets from
hg.python.org/cpython.  I don?t think it should matter, but I don?t know
why the diff was empty, so I thought this information might help.

>> - After pulling, merging and pushing, the patch created contained the
>> merge diff, not the useful diff with my changes.
> Again, please elaborate. What is the "merge diff" that it contained?

See http://bugs.python.org/file21398/c43e264256e4.diff : this
corresponds to a merge I did from default into my branch,
http://hg.python.org/sandbox/merwok/rev/c43e264256e4 .  It should have
been a diff corresponding to my branch - cpython?s main repo default
branch head IIUC.

Regards

From merwok at netwok.org  Fri Mar 25 22:55:13 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 25 Mar 2011 22:55:13 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <AANLkTinXMDrwtErXqMWxY1YLD9vVTB4GbRHEeEMWzotr@mail.gmail.com>
References: <4D72CB3A.5090006@v.loewis.de> <4D76E6D0.6020707@netwok.org>
	<AANLkTinXMDrwtErXqMWxY1YLD9vVTB4GbRHEeEMWzotr@mail.gmail.com>
Message-ID: <4D8D0F41.3020705@netwok.org>

Le 09/03/2011 03:41, Guido van Rossum a ?crit :
> On Tue, Mar 8, 2011 at 9:32 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> I?m of the opinion that hg diffs should always use the extended git
>> format, given their usefulness.  A tool working with hg diffs that does
>> not support this format is broken IMO.
> 
> Can you please contribute changes to Rietveld to support that format then?

It looks like changes are not needed in Rietveld itself but to a
python.org-specific script:
http://svn.python.org/view/tracker/instances/python-dev/scripts/addpatchsets?view=markup

If you?re saying that stock Rietveld supports Mercurial and rejects diff
--git, I can certainly open a bug report upstream.

I don?t know if I?ll be able to set up a whole Roundup and Rietveld
development environment shortly, but if Martin can?t or doesn?t want to
write the fix, I will try to.

Regards

From ben+python at benfinney.id.au  Fri Mar 25 22:55:05 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 26 Mar 2011 08:55:05 +1100
Subject: [Python-Dev] Python Core Mentorship program
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
Message-ID: <874o6q27d2.fsf@benfinney.id.au>

Guido van Rossum <guido at python.org> writes:

> On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> > Surely a forum specifically for mentorship will be more useful if
> > outsiders can be directed to existing discussions, without needing to
> > join the private club.
>
> This argument comes up repeatedly. Some people object on principle to
> all closed lists.

I apologise if anyone mistakes my position as that.

Closed forums are necessary for all kinds of reasons. If my position
were against all closed forums, people would be correct to regard that
position as too extreme.

No, I'm pointing out that a closed forum *for mentorship specifically*
is undermining the goal of mentorship: to efficiently share valuable
knowledge and help newbies learn from existing discussions with experts
and other newbies.

One of the great things about a discussion forum open view for the
public is that, when a topic comes up again in a *different* forum, I
can easily point anyone to the existing discussion without requiring
that they join some private group. That's invaluable for spreading
knowledge freely.

If the goal of spreading knowledge isn't primary for the forum, I think
it's a bit misleading to call it mentorship. Sure, mentorship can still
be private; but it's pretty inefficient ? and counter to the goal of
spreading knowledge ? if only a private group gets to benefit from the
discussions.

> Other people will not participate in a discussion (or will not speak
> their minds about certain topics) unless they have some sense that the
> list is "closed".

That's unfortunate, in my view, and I've stated the reasoning behind
this view. Others are, of course, entitled to their view, just as I'm
entitled to point out the flaws.

> I propose to give it a rest. If you want to know what's going on
> there, just subscribe, nobody will stop you (and if they did there are
> plenty of public forums to complain).

I thought that's exactly what I was doing; confusingly, in this
paragraph you seem to simultaneously suggest that I stop complaining
when I see something wrong and that I should complain when I see
something wrong.

I'm not requiring anyone change anything, only pointing out what I see
as a mistake.

> You will find soon enough that nothing unsavory is being discussed.

That was never the concern; I hope that's clear now.

-- 
 \        ?The problem with television is that the people must sit and |
  `\    keep their eyes glued on a screen: the average American family |
_o__)                 hasn't time for it.? ?_The New York Times_, 1939 |
Ben Finney


From guido at python.org  Fri Mar 25 23:09:17 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 25 Mar 2011 15:09:17 -0700
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <874o6q27d2.fsf@benfinney.id.au>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
Message-ID: <AANLkTimhQFnVn250FtnPV2TEOD2hVk7aQ8BsTKLouyrY@mail.gmail.com>

On Fri, Mar 25, 2011 at 2:55 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>> I propose to give it a rest. If you want to know what's going on
>> there, just subscribe, nobody will stop you (and if they did there are
>> plenty of public forums to complain).
>
> I thought that's exactly what I was doing; confusingly, in this
> paragraph you seem to simultaneously suggest that I stop complaining
> when I see something wrong and that I should complain when I see
> something wrong.

You misunderstood me. I meant that if for some reason you would be
refused a subscription you should complain publicly.

Apart from that correction of a misunderstanding, I don't think we
need to go back and forth more on this. The folks taking the
initiative on the mentorship list have a certain kind of environment
in mind, they've heard your objection, they are going ahead with the
policy they set. Let's see how the experiment goes. We can always
create a new public list later (though we cannot open the archives of
the original closed list).

-- 
--Guido van Rossum (python.org/~guido)

From jnoller at gmail.com  Fri Mar 25 23:14:02 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Mar 2011 18:14:02 -0400
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <874o6q27d2.fsf@benfinney.id.au>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
Message-ID: <AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>

On Fri, Mar 25, 2011 at 5:55 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Guido van Rossum <guido at python.org> writes:
>
>> On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>> > Surely a forum specifically for mentorship will be more useful if
>> > outsiders can be directed to existing discussions, without needing to
>> > join the private club.
>>
>> This argument comes up repeatedly. Some people object on principle to
>> all closed lists.
>
> I apologise if anyone mistakes my position as that.
>
> Closed forums are necessary for all kinds of reasons. If my position
> were against all closed forums, people would be correct to regard that
> position as too extreme.
>
> No, I'm pointing out that a closed forum *for mentorship specifically*
> is undermining the goal of mentorship: to efficiently share valuable
> knowledge and help newbies learn from existing discussions with experts
> and other newbies.
>
> One of the great things about a discussion forum open view for the
> public is that, when a topic comes up again in a *different* forum, I
> can easily point anyone to the existing discussion without requiring
> that they join some private group. That's invaluable for spreading
> knowledge freely.

Ben,

In principle I agree with you - I would like open archives for the
specific reasons you cite, but I value the ability for people who may
not be comfortable with coming out and openly discussing things on a
list if they know it's open to the magical powers of google and public
archives. Heck, having open archives makes it *easier to find out*
about the list itself, serving the purpose even more.

But - weighed in favor of the target audience (those that may not yet
be comfortable with "full disclosure", or discussing personality
clashes on the tracker, or those worried about future employers
digging up stuff) - I want to error on the side of the closed list
archives for now. In several months, we all might realize it was a
monumental mistake. At that time, we can fix the problem.

"The perfect is the enemy of the good." :)

jesse

From martin at v.loewis.de  Fri Mar 25 23:29:47 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 25 Mar 2011 23:29:47 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D8D0E47.8090503@netwok.org>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>	<4D889BC8.4080909@netwok.org>
	<AANLkTikuO1Ob46imuZsnTQgaPMZ64es3wUEiE6aJgTi-@mail.gmail.com>
	<4D8D077C.7000302@netwok.org> <4D8D0C60.5070907@v.loewis.de>
	<4D8D0E47.8090503@netwok.org>
Message-ID: <4D8D175B.8050303@v.loewis.de>

> I mean that my linked repo didn?t have all changesets from
> hg.python.org/cpython.  I don?t think it should matter, but I don?t know
> why the diff was empty, so I thought this information might help.
[...]
> See http://bugs.python.org/file21398/c43e264256e4.diff : this
> corresponds to a merge I did from default into my branch,
> http://hg.python.org/sandbox/merwok/rev/c43e264256e4 .  It should have
> been a diff corresponding to my branch - cpython?s main repo default
> branch head IIUC.

I see what happened: my revspec couldn't cope with the fact that you
branched fix5845 off rlcompleter-config. It was looking for the
branchpoint of that branch, and taking that as a potential base.
However, this didn't give a revision from default, but the latest
revision in rlcompleter-config as a candidate base.

It then compared that to the second parent of the latest merge into
fix5845, which was from the default branch, and tried to compute the
maximum. Since these two revisions are not ordered, max() returned
some junk revision (I don't understand what Mercurial does in this
case).

In any case, I have now changed the revspec to use Baptiste's idea,
which is really smart, which also allows me to drop the sourcebranch
information.

Let's see whether it is correct this time.

I also added quotes into the branch name, so hyphens should be allowed now.

Regards,
Martin

From ben+python at benfinney.id.au  Fri Mar 25 23:47:44 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 26 Mar 2011 09:47:44 +1100
Subject: [Python-Dev] Python Core Mentorship program
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>
Message-ID: <87vcz6zujz.fsf@benfinney.id.au>

Jesse Noller <jnoller at gmail.com> writes:

> In principle I agree with you
[?]

Thanks (truly!) for considering the feedback.

The only further comment I need to make is:

> I want to error on the side of the closed list archives for now. In
> several months, we all might realize it was a monumental mistake. At
> that time, we can fix the problem.

By the nature of the problem, I doubt it will be realised, since the
problem is knowledge *not* getting to the right people. That's hardly
something that will be observable nor measurable easily, certainly not
within a few months.

So, while I will be deprived of a clear ?I told you so? response, that
isn't something I'm much interested in anyway; on the other hand, the
members of a closed forum won't be able to detect the problem easily and
will likely not see the need to fix it.

Anyway, good hunting in your endeavours. I hope you can encourage more
people to quickly become confident enough to discuss their Python issues
in public.

-- 
 \                   ???????? (The virtuous are not abandoned, |
  `\                               they shall surely have neighbours.) |
_o__)                             ???? Confucius, 551 BCE ? 479 BCE |
Ben Finney


From merwok at netwok.org  Sat Mar 26 00:24:42 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 26 Mar 2011 00:24:42 +0100
Subject: [Python-Dev] Submitting changes through Mercurial
In-Reply-To: <4D8D175B.8050303@v.loewis.de>
References: <4D7D06F3.7020700@v.loewis.de>	<4D87E909.8050602@netwok.org>	<AANLkTim5NkF5BH_b-dmF8L6dfM5ZPYtTtR_RC2MaYxEr@mail.gmail.com>	<AANLkTim2Z7KXSXQxDhvxk1MAWNx3VmXbEiTyXrTPr1rE@mail.gmail.com>	<19848.38257.349896.870255@montanaro.dyndns.org>	<4D889BC8.4080909@netwok.org>
	<AANLkTikuO1Ob46imuZsnTQgaPMZ64es3wUEiE6aJgTi-@mail.gmail.com>
	<4D8D077C.7000302@netwok.org> <4D8D0C60.5070907@v.loewis.de>
	<4D8D0E47.8090503@netwok.org> <4D8D175B.8050303@v.loewis.de>
Message-ID: <4D8D243A.7010407@netwok.org>

> I see what happened: my revspec couldn't cope with the fact that you
> branched fix5845 off rlcompleter-config.
Ah, I hadn?t thought of that.  (I had to branch because of the former
issue with the hyphen; this is a pathological case.)

> In any case, I have now changed the revspec to use Baptiste's idea,
> which is really smart, which also allows me to drop the sourcebranch
> information.
> 
> Let's see whether it is correct this time.
It is!  (http://bugs.python.org/file21401/c43e264256e4.diff)  Thanks.

> I also added quotes into the branch name, so hyphens should be allowed now.
They are!  I changed the branch name back to the first name with an
hyphen and it successfully produced
http://bugs.python.org/file21402/d1cbf0347eb4.diff

Cheers

From merwok at netwok.org  Sat Mar 26 00:28:35 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 26 Mar 2011 00:28:35 +0100
Subject: [Python-Dev] hg diff
In-Reply-To: <il783i$k6a$2@dough.gmane.org>
References: <4D72CB3A.5090006@v.loewis.de>
	<4D76E6D0.6020707@netwok.org>	<4D7713C2.2090604@v.loewis.de>
	<il783i$k6a$2@dough.gmane.org>
Message-ID: <4D8D2523.8060000@netwok.org>

On 09.03.2011 06:44, "Martin v. L?wis" wrote:
> IMO, it's "hg diff --git" that's broken, as it doesn't include the base 
> revision (other formats, such as "hg export", do).

I asked about it on #mercurial.  It turns out that not including the
base changeset id in the diff is an oversight, not a choice; diffs made
by the git program actually contains a line of the form ?index
694512d..e5fde8a?, so the Mercurial lead dev told me they would consider
accepting a patch making hg diff --git include such a line.

Regards

From ericsnowcurrently at gmail.com  Sat Mar 26 00:33:42 2011
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 25 Mar 2011 17:33:42 -0600
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <87vcz6zujz.fsf@benfinney.id.au>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>
	<87vcz6zujz.fsf@benfinney.id.au>
Message-ID: <AANLkTik5nWtQNs-BHpnpwEtUKC5_-H-KvDGRtu6w0iKU@mail.gmail.com>

I see your point, but doesn't python-list already fill the role you indicate
may be diminished?  Seems like the new list is meant to fill a different
need.  Perhaps one concern would be over-use of the mentoring list when
someone would be fine with python-list.  I just don't see people turning
away from python-list in favor of the mentoring list.

-eric

On Fri, Mar 25, 2011 at 4:47 PM, Ben Finney <ben+python at benfinney.id.au>wrote:

> Jesse Noller <jnoller at gmail.com> writes:
>
> > In principle I agree with you
> [?]
>
> Thanks (truly!) for considering the feedback.
>
> The only further comment I need to make is:
>
> > I want to error on the side of the closed list archives for now. In
> > several months, we all might realize it was a monumental mistake. At
> > that time, we can fix the problem.
>
> By the nature of the problem, I doubt it will be realised, since the
> problem is knowledge *not* getting to the right people. That's hardly
> something that will be observable nor measurable easily, certainly not
> within a few months.
>
> So, while I will be deprived of a clear ?I told you so? response, that
> isn't something I'm much interested in anyway; on the other hand, the
> members of a closed forum won't be able to detect the problem easily and
> will likely not see the need to fix it.
>
> Anyway, good hunting in your endeavours. I hope you can encourage more
> people to quickly become confident enough to discuss their Python issues
> in public.
>
> --
>  \                   ???????? (The virtuous are not abandoned, |
>  `\                               they shall surely have neighbours.) |
> _o__)                             ???? Confucius, 551 BCE ? 479 BCE |
> Ben Finney
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110325/6eed968a/attachment.html>

From ben+python at benfinney.id.au  Sat Mar 26 00:46:27 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 26 Mar 2011 10:46:27 +1100
Subject: [Python-Dev] Python Core Mentorship program
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>
	<87vcz6zujz.fsf@benfinney.id.au>
	<AANLkTik5nWtQNs-BHpnpwEtUKC5_-H-KvDGRtu6w0iKU@mail.gmail.com>
Message-ID: <87mxkizru4.fsf@benfinney.id.au>

Eric Snow <ericsnowcurrently at gmail.com> writes:

> I see your point, but doesn't python-list already fill the role you
> indicate may be diminished?

The audience of the proposed forum (AFAICT) is people who want to learn
enough to contribute to the Python core. So, no, they're different
roles.

-- 
 \        ?Spam will be a thing of the past in two years' time.? ?Bill |
  `\                                                 Gates, 2004-01-24 |
_o__)                                                                  |
Ben Finney


From lac at openend.se  Sat Mar 26 01:14:25 2011
From: lac at openend.se (Laura Creighton)
Date: Sat, 26 Mar 2011 01:14:25 +0100
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: Message from Jesse Noller <jnoller@gmail.com> of "Fri,
	25 Mar 2011 18:14:02 -0400."
	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com> 
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com> 
Message-ID: <201103260014.p2Q0EPmK017453@theraft.openend.se>

In a message of Fri, 25 Mar 2011 18:14:02 -0400, Jesse Noller writes:
>Ben,
>
>In principle I agree with you - I would like open archives for the
>specific reasons you cite, but I value the ability for people who may
>not be comfortable with coming out and openly discussing things on a
>list if they know it's open to the magical powers of google and public
>archives. Heck, having open archives makes it *easier to find out*
>about the list itself, serving the purpose even more.
>
>But - weighed in favor of the target audience (those that may not yet
>be comfortable with "full disclosure", or discussing personality
>clashes on the tracker, or those worried about future employers
>digging up stuff) - I want to error on the side of the closed list
>archives for now. In several months, we all might realize it was a
>monumental mistake. At that time, we can fix the problem.

I would have thought that the set of people who were more comfortable
with the closed list was prettry close to zero.  Because the problem
with saying something stupid in public is really not one of perfect
strangers using google to find out that I said something stupid once,
but rather that current members of the target group, in this case
the subscribers to python-dev or python-dev-mentors will find out
that I think stupid thoughts _now_, and think less of me for it, and
maybe say some nasty things about me.

Python-dev historically has been rather special.  The forbidding message
"Do not post general Python questions to this list. For help with 
 Python please see the Python help page." in a red boarded box is
fairly effective at getting the message "do not waste the valuable
time of these people" across.  For a while, I remember, we lied and
said that subscriptions to python-dev needed to be approved, even
when they didn't.  That seemed to deter some people from even trying
to join, which was probably either a good thing, or a bad thing on
the whole (but, of course, we have no way to measure).  And the other
thing that makes python-dev unusual is that it is casually read by
a large number of people who never say a word.  All open mailing lists 
have lurkers, especially those who read them without a subscription,
through some other means, but python-dev is unsual in the number of
people who try to read it 'just in case something important happens',
and 'just to feel like they know what is going on in the python community'.
All of these factors add to the 'don't waste people's time' factor.

Thus there is a lot to be said about having a separate group, where
python-dev contributors answer questions that they have made time for,
even if others might consider them a waste of time.  Because those
others are not forced to subscribe and read them.  But I don't see
such a compelling reason for a closed group.  It's not as if we expect
that mentoring to be a source of deeply personal stories and
anecdotes.  Or that people want the safety to discuss heretical
approaches to changing CPython not expected to go down well with
python-dev.

It all seems to boil down to 'some people would be more comfortable
this way'.  I'd like to get some metrics on how many of those people
there are.  And I'd like to measure them against a different group,
people like me who won't contribute to a closed group, in part because
the whole closed-ness of it makes me undomfortable. My experience
with closed-groups vs open groups has been almost entirely negative,
which would be reason enough for me to hesitate to join one, but
especially when it comes to a _mentoring_ list.  The single most
important reason why I would post something I think might be really
stupid is because 'if I don't understand this, then there are probably
others out there like me in the same boat'.  So I ask such things with
the hope that the exchange will be googled _a whole lot_ in the
future.  And again, when I answer a question fully and completely, I
do so thinking 'I'll bet a lot of people, and not this one soul, will
be interested in this'.  If the answer will only be seen by the
comparatively few people in a closed mailing list, I am comparatively
unmotivated to write anything, or write anything substantial.

I've seen a whole lot of very bad behaviour on the part of self-styled
leaders of closed mailing lists.  They determine the party-line of the
group and then, because it is private, blast those souls who do not
conform with impunity.  Having been on the receiving end of a number
of such exchanges, my conclusion has been that having the whole thing
open is often the only defence one has.  Firstly, most people are
more restrained when what they say can be seen by the world at large,
so some of these incidents would not happen.  But secondly, the ability
to share the mail with others greatly empowers the people on the
receiving end.  But if you cannot get an outside opinion because doing
so would violate the group's closed-ness, then you are more vulnerable.

The point of bringing this up is not because I think that
python-dev-mentors is likely to run into these sorts of problems, but
to let you know that there is a substantial number of people out
there who are not emotionally comfortable with closed groups as
opposed to open ones.  And I don't see why the emotional comfort of
those who like closed groups should have precedence over the emotional
comfort of those of us who find closed groups threatening.

The argument 'we'll try it closed, and then we will see about opening
it up, later' doesn't work for me, because every time I have been
involved in such an effort, except once, the end result has been that
later _never_ happens. The people who like the group closed _always_
successfully resist such change.  It is too much easier for people
like me who only got involved in the first place because of the
expectation of the group's eventual opening to drop out and quit the
group than to spend the amount of energy necessary to open the group
up.  And for me, at any rate, my reluctance to spend the energy is in
large part because of the closed-ness of the group.  I'd care a lot
more about the group, if the group was open.

I don't think that people like me are that rare -- hmm, I should rephrase
that -- I don't think that people with this attitude towards closed groups
are that rare.  And it is hard to find out about us, because we're the
people who don't join such things.  So no matter how well a given closed
group works, according to those who are members of such a thing, it is
impossible to say whether the group would have been _so_ _much_ _better_
if it were open -- or whether being closed was essential to its success.

So 'In several months we might all realize that this was a momentual
mistake and then fix the problem' never works.  No matter what you do,
there will always be some people who like it, so you will never get the
'all'.  But what might be possible to measure is the number of people
who won't be joining a closed list, but who would join an open one,
versus those who will join the closed list but wouldn't join the
open one, by having some sort of vote.  Of course, a vote could only
measure people's intentions, which are often different from what they
really do, but it would at least allow some sort of measurement of
what isn't happening, which is otherwise close to impossible to see.

I for one would feel a lot better about what I was missing out on in
python-dev-mentors if I knew that there were some actual human beings
benefitting from it who would not have joined an open group.  Without
some sort of metric, I will always worry that it was done 'in case
there might be people like that out there' or 'to test the theory 
that the reason we don't have enough python-dev contributers is
because python-dev is an open group' without any actual use-cases
at all.

>
>"The perfect is the enemy of the good." :)
>

"If you can not measure it, you can not improve it."
Lord Kelvin: (Sir William Thomson)

Laura

>jesse


From _ at lvh.cc  Sat Mar 26 01:33:33 2011
From: _ at lvh.cc (Laurens Van Houtven)
Date: Sat, 26 Mar 2011 01:33:33 +0100
Subject: [Python-Dev] Python 3.3 release schedule posted
In-Reply-To: <AANLkTikt+PUE41h576o5oo+foT5o61RW=p=oEBF5qkzC@mail.gmail.com>
References: <imdj8n$dq0$1@dough.gmane.org>
	<AANLkTi=9bedAp40CPHQG-fkPTHwqrkzJ6q9Dr6X7p_f7@mail.gmail.com>
	<AANLkTikt+PUE41h576o5oo+foT5o61RW=p=oEBF5qkzC@mail.gmail.com>
Message-ID: <AANLkTinbgpQrPBU64OY_vD7QzmV5HGznr_uXNEEhMkcY@mail.gmail.com>

On Thu, Mar 24, 2011 at 12:18 AM, Thomas Wouters <thomas at python.org> wrote:

> It ended up that Jim Fulton is actually writing the PEP (with input from
> Twisted people and others.)
>
> --
> Thomas Wouters <thomas at python.org>
>
> Hi! I'm a .signature virus! copy me into your .signature file to help me
> spread!
>
>
Well, if help is still needed I'll gladly chip in. It's not  that I'm not
interested in doing it -- it's just that I don't know who's supposed to or
who's working on it :)

-- 
cheers
lvh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110326/267099e7/attachment.html>

From lac at openend.se  Sat Mar 26 01:44:11 2011
From: lac at openend.se (Laura Creighton)
Date: Sat, 26 Mar 2011 01:44:11 +0100
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: Message from Ben Finney <ben+python@benfinney.id.au> 
	of "Sat, 26 Mar 2011 10:46:27 +1100." <87mxkizru4.fsf@benfinney.id.au> 
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>
	<87vcz6zujz.fsf@benfinney.id.au>
	<AANLkTik5nWtQNs-BHpnpwEtUKC5_-H-KvDGRtu6w0iKU@mail.gmail.com>
	<87mxkizru4.fsf@benfinney.id.au> 
Message-ID: <201103260044.p2Q0iBXk020179@theraft.openend.se>

In a message of Sat, 26 Mar 2011 10:46:27 +1100, Ben Finney writes:
> The audience of the proposed forum (AFAICT) is people who want to learn
> enough to contribute to the Python core. So, no, they're different
> roles.

The other side of the proposed forum is people who want to teach such
people.  Many of them (and no doubt many of the learners) don't read
python-list due to its high volume.

Laura


From tommywolber at gmail.com  Sat Mar 26 01:44:47 2011
From: tommywolber at gmail.com (Tommy)
Date: Fri, 25 Mar 2011 20:44:47 -0400
Subject: [Python-Dev] Mentorship list
Message-ID: <AANLkTim7F25D_w3+pm3XvRCkdRUmD2CG+iieTovmpCcM@mail.gmail.com>

I was kinda hoping that a private list would have much less noise, and would
serve the actual mentoring better. Maybe a mailing list isnt't the ideal
tool?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110325/7abc9910/attachment.html>

From jnoller at gmail.com  Sat Mar 26 02:29:36 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Mar 2011 21:29:36 -0400
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <201103260014.p2Q0EPmK017453@theraft.openend.se>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>
	<201103260014.p2Q0EPmK017453@theraft.openend.se>
Message-ID: <25F3BF52-CEA4-4E70-8AD1-F52133E85CC9@gmail.com>



On Mar 25, 2011, at 8:14 PM, Laura Creighton <lac at openend.se> wrote:

> In a message of Fri, 25 Mar 2011 18:14:02 -0400, Jesse Noller writes:
>> Ben,
>> 
>> In principle I agree with you - I would like open archives for the
>> specific reasons you cite, but I value the ability for people who may
>> not be comfortable with coming out and openly discussing things on a
>> list if they know it's open to the magical powers of google and public
>> archives. Heck, having open archives makes it *easier to find out*
>> about the list itself, serving the purpose even more.
>> 
>> But - weighed in favor of the target audience (those that may not yet
>> be comfortable with "full disclosure", or discussing personality
>> clashes on the tracker, or those worried about future employers
>> digging up stuff) - I want to error on the side of the closed list
>> archives for now. In several months, we all might realize it was a
>> monumental mistake. At that time, we can fix the problem.
> 
> I would have thought that the set of people who were more comfortable
> with the closed list was prettry close to zero.  Because the problem
> with saying something stupid in public is really not one of perfect
> strangers using google to find out that I said something stupid once,
> but rather that current members of the target group, in this case
> the subscribers to python-dev or python-dev-mentors will find out
> that I think stupid thoughts _now_, and think less of me for it, and
> maybe say some nasty things about me.
> 
> Python-dev historically has been rather special.  The forbidding message
> "Do not post general Python questions to this list. For help with 
> Python please see the Python help page." in a red boarded box is
> fairly effective at getting the message "do not waste the valuable
> time of these people" across.  For a while, I remember, we lied and
> said that subscriptions to python-dev needed to be approved, even
> when they didn't.  That seemed to deter some people from even trying
> to join, which was probably either a good thing, or a bad thing on
> the whole (but, of course, we have no way to measure).  And the other
> thing that makes python-dev unusual is that it is casually read by
> a large number of people who never say a word.  All open mailing lists 
> have lurkers, especially those who read them without a subscription,
> through some other means, but python-dev is unsual in the number of
> people who try to read it 'just in case something important happens',
> and 'just to feel like they know what is going on in the python community'.
> All of these factors add to the 'don't waste people's time' factor.
> 
> Thus there is a lot to be said about having a separate group, where
> python-dev contributors answer questions that they have made time for,
> even if others might consider them a waste of time.  Because those
> others are not forced to subscribe and read them.  But I don't see
> such a compelling reason for a closed group.  It's not as if we expect
> that mentoring to be a source of deeply personal stories and
> anecdotes.  Or that people want the safety to discuss heretical
> approaches to changing CPython not expected to go down well with
> python-dev.
> 
> It all seems to boil down to 'some people would be more comfortable
> this way'.  I'd like to get some metrics on how many of those people
> there are.  And I'd like to measure them against a different group,
> people like me who won't contribute to a closed group, in part because
> the whole closed-ness of it makes me undomfortable. My experience
> with closed-groups vs open groups has been almost entirely negative,
> which would be reason enough for me to hesitate to join one, but
> especially when it comes to a _mentoring_ list.  The single most
> important reason why I would post something I think might be really
> stupid is because 'if I don't understand this, then there are probably
> others out there like me in the same boat'.  So I ask such things with
> the hope that the exchange will be googled _a whole lot_ in the
> future.  And again, when I answer a question fully and completely, I
> do so thinking 'I'll bet a lot of people, and not this one soul, will
> be interested in this'.  If the answer will only be seen by the
> comparatively few people in a closed mailing list, I am comparatively
> unmotivated to write anything, or write anything substantial.
> 
> I've seen a whole lot of very bad behaviour on the part of self-styled
> leaders of closed mailing lists.  They determine the party-line of the
> group and then, because it is private, blast those souls who do not
> conform with impunity.  Having been on the receiving end of a number
> of such exchanges, my conclusion has been that having the whole thing
> open is often the only defence one has.  Firstly, most people are
> more restrained when what they say can be seen by the world at large,
> so some of these incidents would not happen.  But secondly, the ability
> to share the mail with others greatly empowers the people on the
> receiving end.  But if you cannot get an outside opinion because doing
> so would violate the group's closed-ness, then you are more vulnerable.
> 
> The point of bringing this up is not because I think that
> python-dev-mentors is likely to run into these sorts of problems, but
> to let you know that there is a substantial number of people out
> there who are not emotionally comfortable with closed groups as
> opposed to open ones.  And I don't see why the emotional comfort of
> those who like closed groups should have precedence over the emotional
> comfort of those of us who find closed groups threatening.
> 
> The argument 'we'll try it closed, and then we will see about opening
> it up, later' doesn't work for me, because every time I have been
> involved in such an effort, except once, the end result has been that
> later _never_ happens. The people who like the group closed _always_
> successfully resist such change.  It is too much easier for people
> like me who only got involved in the first place because of the
> expectation of the group's eventual opening to drop out and quit the
> group than to spend the amount of energy necessary to open the group
> up.  And for me, at any rate, my reluctance to spend the energy is in
> large part because of the closed-ness of the group.  I'd care a lot
> more about the group, if the group was open.
> 
> I don't think that people like me are that rare -- hmm, I should rephrase
> that -- I don't think that people with this attitude towards closed groups
> are that rare.  And it is hard to find out about us, because we're the
> people who don't join such things.  So no matter how well a given closed
> group works, according to those who are members of such a thing, it is
> impossible to say whether the group would have been _so_ _much_ _better_
> if it were open -- or whether being closed was essential to its success.
> 
> So 'In several months we might all realize that this was a momentual
> mistake and then fix the problem' never works.  No matter what you do,
> there will always be some people who like it, so you will never get the
> 'all'.  But what might be possible to measure is the number of people
> who won't be joining a closed list, but who would join an open one,
> versus those who will join the closed list but wouldn't join the
> open one, by having some sort of vote.  Of course, a vote could only
> measure people's intentions, which are often different from what they
> really do, but it would at least allow some sort of measurement of
> what isn't happening, which is otherwise close to impossible to see.
> 
> I for one would feel a lot better about what I was missing out on in
> python-dev-mentors if I knew that there were some actual human beings
> benefitting from it who would not have joined an open group.  Without
> some sort of metric, I will always worry that it was done 'in case
> there might be people like that out there' or 'to test the theory 
> that the reason we don't have enough python-dev contributers is
> because python-dev is an open group' without any actual use-cases
> at all.
> 
>> 
>> "The perfect is the enemy of the good." :)
>> 
> 
> "If you can not measure it, you can not improve it."
> Lord Kelvin: (Sir William Thomson)
> 
> Laura


Thank you for the feedback Laura - I think that if the people volunteering to be mentors (a fair number have) can vote and/or change the policy once we have agreed to a code of conduct for the group.

I for one like to assume In the better side of people and things, and therefore I believe that the list as outlined will be a force for good, and not bad. Remember, anyone with a subscription can access anything - so it's not truly private.

Should you wish to participate, you would be welcome.

Jesse



> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110325/ebfdda8f/attachment.html>

From jnoller at gmail.com  Sat Mar 26 02:31:25 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Mar 2011 21:31:25 -0400
Subject: [Python-Dev] Mentorship list
In-Reply-To: <AANLkTim7F25D_w3+pm3XvRCkdRUmD2CG+iieTovmpCcM@mail.gmail.com>
References: <AANLkTim7F25D_w3+pm3XvRCkdRUmD2CG+iieTovmpCcM@mail.gmail.com>
Message-ID: <150C2086-E315-42A1-9FEE-ACED8D287016@gmail.com>



On Mar 25, 2011, at 8:44 PM, Tommy <tommywolber at gmail.com> wrote:

> I was kinda hoping that a private list would have much less noise, and would serve the actual mentoring better. Maybe a mailing list isnt't the ideal tool?
> 
That is a hope I would like to see realized. I don't think we will be changing the medium any time soon.

So, closed archives it stands for now. Please feel free to join.

Jesse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110325/0a5777ce/attachment.html>

From v+python at g.nevcal.com  Sat Mar 26 02:54:32 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Fri, 25 Mar 2011 18:54:32 -0700
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <201103260044.p2Q0iBXk020179@theraft.openend.se>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>	<87ei5u2a0q.fsf@benfinney.id.au>	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>	<874o6q27d2.fsf@benfinney.id.au>	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>	<87vcz6zujz.fsf@benfinney.id.au>	<AANLkTik5nWtQNs-BHpnpwEtUKC5_-H-KvDGRtu6w0iKU@mail.gmail.com>	<87mxkizru4.fsf@benfinney.id.au>
	<201103260044.p2Q0iBXk020179@theraft.openend.se>
Message-ID: <4D8D4758.3050108@g.nevcal.com>

On 3/25/2011 5:44 PM, Laura Creighton wrote:
> The other side of the proposed forum is people who want to teach such
> people.  Many of them (and no doubt many of the learners) don't read
> python-list due to its high volume.

Indeed.  I see 76000+ unread messages on Python-list since I subscribed 
2.5 years ago.  I search it when I have a Python question, that is not 
immediately answerable by reading docs... issues of style mostly.  But 
that is mostly about how to use Python, not about how to contribute.  
And I don't have time to read it all.  I wonder if anyone reads it all, 
and gets anything else done in life.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110325/5b0467cf/attachment.html>

From v+python at g.nevcal.com  Sat Mar 26 02:59:15 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Fri, 25 Mar 2011 18:59:15 -0700
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <201103260014.p2Q0EPmK017453@theraft.openend.se>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>	<87ei5u2a0q.fsf@benfinney.id.au>	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>	<874o6q27d2.fsf@benfinney.id.au>	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>
	<201103260014.p2Q0EPmK017453@theraft.openend.se>
Message-ID: <4D8D4873.3000707@g.nevcal.com>

So... start two mentoring groups, one open, one closed, and see which 
one survives.

From jnoller at gmail.com  Sat Mar 26 03:27:14 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Mar 2011 22:27:14 -0400
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <4D8D4873.3000707@g.nevcal.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>
	<201103260014.p2Q0EPmK017453@theraft.openend.se>
	<4D8D4873.3000707@g.nevcal.com>
Message-ID: <BANLkTi=FVbxXsQF3NK=6jE2mx1HMAicd8g@mail.gmail.com>

On Fri, Mar 25, 2011 at 9:59 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> So... start two mentoring groups, one open, one closed, and see which one
> survives.

I'd rather not. I'd rather walk away from the idea entirely. In fact,
this entire thread is quickly becoming an example of why people
*don't* want to bring issues to this list.

Jesse

From benjamin at python.org  Sat Mar 26 03:52:52 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 25 Mar 2011 21:52:52 -0500
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <4D8D4873.3000707@g.nevcal.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
	<AANLkTikAu5KgpaTt9NH+xrYOdwAYpNmwPragv1mTyACT@mail.gmail.com>
	<201103260014.p2Q0EPmK017453@theraft.openend.se>
	<4D8D4873.3000707@g.nevcal.com>
Message-ID: <AANLkTikmJf_QzBByZonQxW5EKwJ+qDZtLHSk3rYejh6j@mail.gmail.com>

2011/3/25 Glenn Linderman <v+python at g.nevcal.com>:
> So... start two mentoring groups, one open, one closed, and see which one
> survives.

This is all tangential to the actual point of this discussion: To help
people get involved! It's not a social experiment about mailing lists.

In fact, I think this thread can die about now. Honestly, if we spent
half the energy we spend worrying about mailing list details on actual
work....



-- 
Regards,
Benjamin

From ncoghlan at gmail.com  Sat Mar 26 04:23:10 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 Mar 2011 13:23:10 +1000
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <874o6q27d2.fsf@benfinney.id.au>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
Message-ID: <AANLkTi==PvRVxyi7TTV4Wn62u5-QUGBE1uQm8KRmvRwd@mail.gmail.com>

On Sat, Mar 26, 2011 at 7:55 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> One of the great things about a discussion forum open view for the
> public is that, when a topic comes up again in a *different* forum, I
> can easily point anyone to the existing discussion without requiring
> that they join some private group. That's invaluable for spreading
> knowledge freely.
>
> If the goal of spreading knowledge isn't primary for the forum, I think
> it's a bit misleading to call it mentorship. Sure, mentorship can still
> be private; but it's pretty inefficient ? and counter to the goal of
> spreading knowledge ? if only a private group gets to benefit from the
> discussions.

And that's why I made sure to point out that any more widely
applicable information *will be incorporated into the devguide*.

So rather than pointing people to a potentially meandering discussion,
we'll be able to point them to a straightforward coherent answer,
without all the false starts and clarifications that happen in a real
mailing list conversation.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sat Mar 26 04:47:40 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 Mar 2011 13:47:40 +1000
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
In-Reply-To: <loom.20110325T205950-167@post.gmane.org>
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
	<4D6AB409.40001@canterbury.ac.nz>
	<loom.20110322T000609-760@post.gmane.org>
	<AANLkTik6CZbJj2cPO+807vcp85S3qTfC-w5fMjmdzkuj@mail.gmail.com>
	<AANLkTimpM8ysUzJL1idHoKXuFCpbYgAjzaGb2DFsVF=u@mail.gmail.com>
	<loom.20110322T125508-35@post.gmane.org>
	<loom.20110324T151333-689@post.gmane.org>
	<loom.20110325T205950-167@post.gmane.org>
Message-ID: <AANLkTimz5xhcWxm0uvyOSSi+ZazXC1UT90-HixeCYtZY@mail.gmail.com>

On Sat, Mar 26, 2011 at 6:25 AM, rndblnch <rndblnch at gmail.com> wrote:
> The raw path is visible there:
> <https://bitbucket.org/rndblnch/cpython-pep380/src/tip/pep380>
> and I have documented how to use it on the wiki:
> <https://bitbucket.org/rndblnch/cpython-pep380/wiki/>
>
> I will stop spamming python-dev now...
> It was just an attempt to help getting pep380 in python3.3 :)

Thanks for your efforts - I created tracker issue #11682 and linked it
to your bitbucket repo to help keep track of this updated version.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ethan at stoneleaf.us  Sat Mar 26 06:14:48 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 25 Mar 2011 22:14:48 -0700
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTi==PvRVxyi7TTV4Wn62u5-QUGBE1uQm8KRmvRwd@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>	<87ei5u2a0q.fsf@benfinney.id.au>	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>	<874o6q27d2.fsf@benfinney.id.au>
	<AANLkTi==PvRVxyi7TTV4Wn62u5-QUGBE1uQm8KRmvRwd@mail.gmail.com>
Message-ID: <4D8D7648.4040108@stoneleaf.us>

On 3/25/2011 8:23 PM, Nick Coghlan wrote:
> On Sat, Mar 26, 2011 at 7:55 AM, Ben Finney<ben+python at benfinney.id.au>  wrote:
>> One of the great things about a discussion forum open view for the
>> public is that, when a topic comes up again in a *different* forum, I
>> can easily point anyone to the existing discussion without requiring
>> that they join some private group. That's invaluable for spreading
>> knowledge freely.
>>
>> If the goal of spreading knowledge isn't primary for the forum, I think
>> it's a bit misleading to call it mentorship. Sure, mentorship can still
>> be private; but it's pretty inefficient ? and counter to the goal of
>> spreading knowledge ? if only a private group gets to benefit from the
>> discussions.
>
> And that's why I made sure to point out that any more widely
> applicable information *will be incorporated into the devguide*.
>
> So rather than pointing people to a potentially meandering discussion,
> we'll be able to point them to a straightforward coherent answer,
> without all the false starts and clarifications that happen in a real
> mailing list conversation.

You mean like this one?  ;)

~Ethan~

From ethan at stoneleaf.us  Sat Mar 26 06:20:38 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 25 Mar 2011 22:20:38 -0700
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <874o6q27d2.fsf@benfinney.id.au>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>	<87ei5u2a0q.fsf@benfinney.id.au>	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au>
Message-ID: <4D8D77A6.9070108@stoneleaf.us>

On 3/25/2011 2:55 PM, Ben Finney wrote:
> Guido van Rossum<guido at python.org>  writes:
>> On Fri, Mar 25, 2011 at 1:57 PM, Ben Finney<ben+python at benfinney.id.au>  wrote:
>>> Surely a forum specifically for mentorship will be more useful if
>>> outsiders can be directed to existing discussions, without needing to
>>> join the private club.
>>
>> This argument comes up repeatedly. Some people object on principle to
>> all closed lists.
>
> No, I'm pointing out that a closed forum *for mentorship specifically*
> is undermining the goal of mentorship: to efficiently share valuable
> knowledge and help newbies learn from existing discussions with experts
> and other newbies.

I disagree.  The goal of mentorship is to help someone learn -- a 
subtle, yet distinct, difference.  I think a closed list will suit that 
purpose better.

Keep in mind also that the list is *closed*, not *locked* -- anyone can 
join, and anyone who has joined has full access to current goings-on and 
to the archives.

~Ethan~

From ncoghlan at gmail.com  Sat Mar 26 06:55:23 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 Mar 2011 15:55:23 +1000
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <4D8D77A6.9070108@stoneleaf.us>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au> <4D8D77A6.9070108@stoneleaf.us>
Message-ID: <AANLkTi=PDUTZendD5O-Zui5a25dYroMoHQxcCUgTAs2B@mail.gmail.com>

On Sat, Mar 26, 2011 at 3:20 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>
> I disagree. ?The goal of mentorship is to help someone learn -- a subtle,
> yet distinct, difference. ?I think a closed list will suit that purpose
> better.
>
> Keep in mind also that the list is *closed*, not *locked* -- anyone can
> join, and anyone who has joined has full access to current goings-on and to
> the archives.

The other thing to remember is that part of the purpose of the new
list is to fulfil roles that python-dev doesn't (and shouldn't really
be expected to) handle.

These are things like:
- keeping in touch with new contributors that participate in core sprints
- asking for clarifications of points that may not be clear in the devguide
- how to respond to negative feedback on the public lists and on the tracker
- advice on "who's who" on the public mailing lists

Anyone that is themselves comfortable with the rough-and-tumble of
typical open source development may see the list as unnecessary, and
that's fine. python-dev does see new contributors arriving without an
active mentorship program, and that's great.

However, there are still an *awful* lot of modules on
http://docs.python.org/devguide/experts that don't have names against
them. The tracker still has a huge backlog of issues, some of which
are there because they're genuinely difficult, but others are there
just because none of the current core devs have the interest and/or
expertise to make the necessary calls as to what changes are needed
and how they should be made.

If we can broaden our developer base by giving people a specific place
to ease into things without having to dive straight into the deep end
of python-dev, then I think it's an experiment worth trying.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From zstone at gmail.com  Sat Mar 26 07:33:08 2011
From: zstone at gmail.com (Zak Stone)
Date: Sat, 26 Mar 2011 02:33:08 -0400
Subject: [Python-Dev] Python Core Mentorship program
In-Reply-To: <AANLkTi=PDUTZendD5O-Zui5a25dYroMoHQxcCUgTAs2B@mail.gmail.com>
References: <AANLkTin=6-tARdp2BM+XaKr8oGS8x27hJM=MhWqgDhSi@mail.gmail.com>
	<20110325130418.1992.1190671764.divmod.xquotient.42@localhost.localdomain>
	<87ei5u2a0q.fsf@benfinney.id.au>
	<AANLkTinmJ9U_5XeN_kdmWrDnDgP1Cd-=nJTuKiW6vfAb@mail.gmail.com>
	<874o6q27d2.fsf@benfinney.id.au> <4D8D77A6.9070108@stoneleaf.us>
	<AANLkTi=PDUTZendD5O-Zui5a25dYroMoHQxcCUgTAs2B@mail.gmail.com>
Message-ID: <AANLkTin5=qeHMPzOqwyUGS_Sgf=VL0zgxWQt8CH6Q9zA@mail.gmail.com>

Hello everyone,

I'm new to this list, but I have been an informal mentor for computer
science students at Harvard for several years, and I'd like to share
some observations that may be relevant. In my experience, students are
willing to ask many technical questions in person that they simply
won't ask privately over email, and very few students seem willing to
ask questions on public mailing lists at all.

My impression from these personal observations is that many students
benefit greatly from informal, ephemeral communication with technical
mentors. It may not be easy to analyze _why_ things work this way, but
I believe part of the answer is that the student-mentor relationship
is not primarily about the information exchanged; it is about trust.
The student knows that in a moment of deep frustration, he or she can
privately turn to someone with the patience and experience to help
without being humiliated, which is tremendously reassuring.

At Harvard, we are currently witnessing a huge increase in student
interest in computer science in general and Python in particular,
which I hope is representative of a broader trend. Excellent
mentorship is rare, and I believe strong mentors from the Python
community could be a potent draw for new contributors in this
atmosphere of enthusiasm. One way or another, I hope you can
facilitate informal, ephemeral communication between these newcomers
and their mentors to maximize the newcomers' chances of success.

Many thanks,
Zak

From stephen at xemacs.org  Sat Mar 26 07:56:04 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 26 Mar 2011 15:56:04 +0900
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <4D8C9DC8.6030701@palladion.com>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>
	<20110323143123.4be80686@pitrou.net>
	<19850.2977.894754.352174@montanaro.dyndns.org>
	<20110323115156.25bd2845@neurotica.wooz.org>
	<19850.9561.366432.287634@montanaro.dyndns.org>
	<4D8A2CED.7080504@stoneleaf.us>
	<20110323182400.04ce46cf@pitrou.net> <imdcc7$2q4$1@dough.gmane.org>
	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D8B3D2D.7000200@palladion.com>
	<87oc4zrjz4.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D8C9DC8.6030701@palladion.com>
Message-ID: <8762r64bgb.fsf@uwakimon.sk.tsukuba.ac.jp>

Tres Seaver writes:

 > That was precisely my proposal:

Sorry about that.  I live in a disaster area, and was limited to
GMail until two days ago, and lost a fair amount of context in the
switch back.


From steven.bethard at gmail.com  Sat Mar 26 10:39:17 2011
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sat, 26 Mar 2011 10:39:17 +0100
Subject: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135
In-Reply-To: <AANLkTimCF_p3F7QnG-_zaeSj9Uc_J05wu86kLBcLP=6k@mail.gmail.com>
References: <AANLkTimCF_p3F7QnG-_zaeSj9Uc_J05wu86kLBcLP=6k@mail.gmail.com>
Message-ID: <BANLkTi=ZsYZb+hAtB1skQUK6_UPc6C5=qQ@mail.gmail.com>

On Mon, Feb 21, 2011 at 1:52 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> As the subject line asks, is there anything preventing the following
> PEPs from being marked Final?
>
> ?SA ?389 ?argparse - New Command Line Parsing Module ? ? ? ? ? ? ?Bethard

Sorry for taking forever to get back to this. So I looked over PEP 389
and it's basically complete, but I never implemented the code
deprecation warnings for optparse (only the documentation deprecation
warnings). The PEP claims:

Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided at
the command line, then importing optparse will issue a
DeprecationWarning. Otherwise no warnings will be issued.

Python 3.2+ -- Importing optparse will issue a
PendingDeprecationWarning, which is not displayed by default.

I'm kind of inclined to just remove those lines from the PEP since
optparse is not being removed and since 2.7 and 3.2 are already out
the door. If anyone thinks those deprecation warnings really need to
be implemented, let me know in the next couple days. Otherwise, I'll
update the PEP and mark it as final.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
? ? ? ? --- The Hiphopopotamus

From ncoghlan at gmail.com  Sat Mar 26 11:28:48 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 Mar 2011 20:28:48 +1000
Subject: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135
In-Reply-To: <BANLkTi=ZsYZb+hAtB1skQUK6_UPc6C5=qQ@mail.gmail.com>
References: <AANLkTimCF_p3F7QnG-_zaeSj9Uc_J05wu86kLBcLP=6k@mail.gmail.com>
	<BANLkTi=ZsYZb+hAtB1skQUK6_UPc6C5=qQ@mail.gmail.com>
Message-ID: <AANLkTinzGmvwsFYhzBHwRux3TxGMbKu+NAzY-ZT41WoK@mail.gmail.com>

On Sat, Mar 26, 2011 at 7:39 PM, Steven Bethard
<steven.bethard at gmail.com> wrote:
> I'm kind of inclined to just remove those lines from the PEP since
> optparse is not being removed and since 2.7 and 3.2 are already out
> the door. If anyone thinks those deprecation warnings really need to
> be implemented, let me know in the next couple days. Otherwise, I'll
> update the PEP and mark it as final.

My recollection is that omitting the deprecation warnings was a
deliberate decision during the implementation phase, so updating the
PEP with a note to that effect and then marking it as final sounds
like the right thing to do.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From techtonik at gmail.com  Sat Mar 26 12:14:14 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 26 Mar 2011 13:14:14 +0200
Subject: [Python-Dev] [issue7284] argparse - display version in usage by
	default
In-Reply-To: <1301134813.4.0.909666638413.issue7284@psf.upfronthosting.co.za>
References: <1257641781.98.0.415542584092.issue7284@psf.upfronthosting.co.za>
	<1301134813.4.0.909666638413.issue7284@psf.upfronthosting.co.za>
Message-ID: <AANLkTikFVqAD_pys1sHatshSEUDBaPXeUBs+X1i1R3rs@mail.gmail.com>

On Sat, Mar 26, 2011 at 12:20 PM, Steven Bethard <report at bugs.python.org> wrote:
>
> I see though that vi puts the full name and version before the usage (which is currently impossible in argparse):

That was exactly my use case, which I'd say is very common for small
utilities. Just in 10 minutes I could find that about a half of
command line utilities on my Windows machine are reporting full name
and version before the usage with --help option, including NSIS,
PuTTY, Far Manager, Android Debug Bridge and 7-Zip.

A pity that before argparse replaced optparse, there was no research
made to gather the output from various console tools to see how
argparse really saves people from reinventing their solutions.

Do you think we could avoid this problem if there was more active
turnaround between Roundup community and Python community to import
all issues from Google Code tracker in time to do some planning?
http://code.google.com/p/argparse/issues/detail?id=50

From ncoghlan at gmail.com  Sat Mar 26 16:14:48 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Mar 2011 01:14:48 +1000
Subject: [Python-Dev] [issue7284] argparse - display version in usage by
	default
In-Reply-To: <AANLkTikFVqAD_pys1sHatshSEUDBaPXeUBs+X1i1R3rs@mail.gmail.com>
References: <1257641781.98.0.415542584092.issue7284@psf.upfronthosting.co.za>
	<1301134813.4.0.909666638413.issue7284@psf.upfronthosting.co.za>
	<AANLkTikFVqAD_pys1sHatshSEUDBaPXeUBs+X1i1R3rs@mail.gmail.com>
Message-ID: <AANLkTi=d875YNtOwo6KCEx_YFJjZ4PVHg3+w0w9tSeT7@mail.gmail.com>

On Sat, Mar 26, 2011 at 9:14 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> A pity that before argparse replaced optparse, there was no research
> made to gather the output from various console tools to see how
> argparse really saves people from reinventing their solutions.

argparse was adopted because it was a significant improvement over
optparse, not because anyone was under the illusion that it was
perfect.

There'll always be room for additional feature requests, and many of
them won't cause backwards compatibility problems.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From facundobatista at gmail.com  Sat Mar 26 16:39:18 2011
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 26 Mar 2011 12:39:18 -0300
Subject: [Python-Dev] Decisions about workflow
Message-ID: <AANLkTikcxFtWuA84+7eaS6w_G+XURua3pVSy70RHjMpE@mail.gmail.com>

I know there's a big ideas exchange in this list about how to use
Mercurial in the Python project.

I know that still there is not wide and firm consensus about the whole
workflow to follow.

But maybe some small decisions are already taken, some suggestions
about the best way to do this or that, even if there are others that
are not taken.

Is this being documented somewhere?

Thank you!

-- 
.? ? Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From solipsis at pitrou.net  Sat Mar 26 16:49:46 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Mar 2011 16:49:46 +0100
Subject: [Python-Dev] Decisions about workflow
References: <AANLkTikcxFtWuA84+7eaS6w_G+XURua3pVSy70RHjMpE@mail.gmail.com>
Message-ID: <20110326164946.1e5bb78b@pitrou.net>


Hello Facundo,

> But maybe some small decisions are already taken, some suggestions
> about the best way to do this or that, even if there are others that
> are not taken.
> 
> Is this being documented somewhere?

Take a look at:
http://docs.python.org/devguide/committing.html

Regards

Antoine.



From skip at pobox.com  Sat Mar 26 16:54:45 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 26 Mar 2011 10:54:45 -0500
Subject: [Python-Dev] Decisions about workflow
In-Reply-To: <20110326164946.1e5bb78b@pitrou.net>
References: <AANLkTikcxFtWuA84+7eaS6w_G+XURua3pVSy70RHjMpE@mail.gmail.com>
	<20110326164946.1e5bb78b@pitrou.net>
Message-ID: <19854.3141.877605.103648@montanaro.dyndns.org>


    Antoine> Take a look at:
    Antoine> http://docs.python.org/devguide/committing.html

What form should directed graphs be in for inclusion?

Thx,

Skip


From techtonik at gmail.com  Sat Mar 26 17:55:39 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 26 Mar 2011 18:55:39 +0200
Subject: [Python-Dev] GSoC idea: PEP process enhancements (Was: [issue7284]
 argparse - display version in usage by default)
Message-ID: <AANLkTimkrf3-j6h9EUkxhEkR8e7zuqnKPKhTFwa_=7Z8@mail.gmail.com>

On Sat, Mar 26, 2011 at 5:14 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, Mar 26, 2011 at 9:14 PM, anatoly techtonik <techtonik at gmail.com> wrote:
>> A pity that before argparse replaced optparse, there was no research
>> made to gather the output from various console tools to see how
>> argparse really saves people from reinventing their solutions.
>
> argparse was adopted because it was a significant improvement over
> optparse, not because anyone was under the illusion that it was
> perfect.

What if we could accompany every PEP draft with series of use
cases/user stories? I don't know how many people actually reviewed
this particular PEP 389, and that's bad, because without this info it
is hard to say if there were enough reviews from future users.

The process is also complicated, because you can't comment on the
document inline. As a Python user I can spend 15 minutes on reading
PEP, but I can't spend hour composing email copy/pasting text for
commenting. For example, if the paragraph about "why aren't getopt and
optparse enough" [1] was reduced to just :
- no support for positional arguments
- no variable number of arguments
- subcommands

Perhaps then I could see that my simple use case to make output
formatting more flexible and concise is not covered by this PEP.

[1] http://www.python.org/dev/peps/pep-0389/#why-aren-t-getopt-and-optparse-enough

> There'll always be room for additional feature requests, and many of
> them won't cause backwards compatibility problems.

Actually, if we could bring this issue earlier, my request would be to
replace a bunch of parameters in constructor with a simple template.
But by the time I was able to get back to making a letter about this
proposal, argparse is already released and Python 3.2 is outside the
hangar too.

E.g. instead of:
argparse.ArgumentParser([description][, epilog][, prog][, usage][,
add_help][, argument_default][, parents][, prefix_chars][,
conflict_handler][, formatter_class])

use
argparse.Parser([help][, argument_default][, parents][, chars][,
conflict_handler][, formatter][, help_vars])
  help_vars = dict([prolog][, description][, epilog][, prog][,
progname][, usage][, version])
and strip HelpFormatter from formatters (they're already inherited)
  RawDescriptionHelpFormatter    -> RawDescription
  RawTextHelpFormatter              -> RawText
  ArgumentDefaultsHelpFormatter -> ArgumentDefaults

so that the final "pythonic" invocation syntax would be:

parser = argparse.Parser(help=True, formatter=argparse.RawText,
                 template=""""
%progname

%description

%help
""",
                 help_vars=dict(progname="mA keWl UtIL",
version=__version__, description=__doc__))


Actually it doesn't look as more flexible to me, but the idea is to
provide more variants for consideration and make sure as much people
as possible reviewed them.

That's why I'd like to propose to develop this system for a GSoC
project. I can mentor its development with some support from
interested people around.
--
anatoly t.

From tseaver at palladion.com  Sat Mar 26 18:08:03 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 26 Mar 2011 13:08:03 -0400
Subject: [Python-Dev] sprints and pushes
In-Reply-To: <8762r64bgb.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTi=9t0K8_2776B8Re71ZZePCdhsD+XxThMvFp81F@mail.gmail.com>	<20110323143123.4be80686@pitrou.net>	<19850.2977.894754.352174@montanaro.dyndns.org>	<20110323115156.25bd2845@neurotica.wooz.org>	<19850.9561.366432.287634@montanaro.dyndns.org>	<4D8A2CED.7080504@stoneleaf.us>	<20110323182400.04ce46cf@pitrou.net>
	<imdcc7$2q4$1@dough.gmane.org>	<87pqph8fll.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D8B3D2D.7000200@palladion.com>	<87oc4zrjz4.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D8C9DC8.6030701@palladion.com>
	<8762r64bgb.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D8E1D73.5010502@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/26/2011 02:56 AM, Stephen J. Turnbull wrote:
> Tres Seaver writes:
> 
>  > That was precisely my proposal:
> 
> Sorry about that.  I live in a disaster area, and was limited to
> GMail until two days ago, and lost a fair amount of context in the
> switch back.

I'm sorry to hear that!  I hope all is well for you and yours -- we are
still waiting to hear about my sister-in-law's family in the northeast.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2OHXMACgkQ+gerLs4ltQ4hPgCfes3/sHOKxWUyGgR8nsSOfhFU
SwcAnjElVvSq1WKIXeMWzcMrYuMnNvaq
=hbWU
-----END PGP SIGNATURE-----


From g.brandl at gmx.net  Sat Mar 26 19:17:19 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 26 Mar 2011 19:17:19 +0100
Subject: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use
	enumerate().
In-Reply-To: <E1Q366l-0001CZ-Dt@dinsdale.python.org>
References: <E1Q366l-0001CZ-Dt@dinsdale.python.org>
Message-ID: <imlajm$1g9$1@dough.gmane.org>

"Refactor" doesn't sound like it belongs in the 3.1 branch...

Georg

On 25.03.2011 13:27, ezio.melotti wrote:
> http://hg.python.org/cpython/rev/ed02db9921ac
> changeset:   68924:ed02db9921ac
> branch:      3.1
> user:        Ezio Melotti <ezio.melotti at gmail.com>
> date:        Fri Mar 25 14:19:30 2011 +0200
> summary:
>   #2650: Refactor re.escape to use enumerate().
> 
> files:
>   Lib/re.py |  3 +--
>   1 files changed, 1 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/Lib/re.py b/Lib/re.py
> --- a/Lib/re.py
> +++ b/Lib/re.py
> @@ -223,8 +223,7 @@
>      if isinstance(pattern, str):
>          alphanum = _alphanum_str
>          s = list(pattern)
> -        for i in range(len(pattern)):
> -            c = pattern[i]
> +        for i, c in enumerate(pattern):
>              if c not in alphanum:
>                  if c == "\000":
>                      s[i] = "\\000"
> 
> 
> 
> 
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins



From tjreedy at udel.edu  Sat Mar 26 20:00:29 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 26 Mar 2011 15:00:29 -0400
Subject: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use
	enumerate().
In-Reply-To: <imlajm$1g9$1@dough.gmane.org>
References: <E1Q366l-0001CZ-Dt@dinsdale.python.org>
	<imlajm$1g9$1@dough.gmane.org>
Message-ID: <imld49$e83$1@dough.gmane.org>

On 3/26/2011 2:17 PM, Georg Brandl wrote:
> "Refactor" doesn't sound like it belongs in the 3.1 branch...

>> -        for i in range(len(pattern)):
>> -            c = pattern[i]
>> +        for i, c in enumerate(pattern):

I would call thin 'Replace obsolete idiom in' rather than 'Refactor'.
So are you criticizing the replacement or the mislabeling?

-- 
Terry Jan Reedy


From solipsis at pitrou.net  Sat Mar 26 20:08:24 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Mar 2011 20:08:24 +0100
Subject: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use
	enumerate().
References: <E1Q366l-0001CZ-Dt@dinsdale.python.org>
	<imlajm$1g9$1@dough.gmane.org> <imld49$e83$1@dough.gmane.org>
Message-ID: <20110326200824.61c2b4fb@pitrou.net>

On Sat, 26 Mar 2011 15:00:29 -0400
Terry Reedy <tjreedy at udel.edu> wrote:
> On 3/26/2011 2:17 PM, Georg Brandl wrote:
> > "Refactor" doesn't sound like it belongs in the 3.1 branch...
> 
> >> -        for i in range(len(pattern)):
> >> -            c = pattern[i]
> >> +        for i, c in enumerate(pattern):
> 
> I would call thin 'Replace obsolete idiom in' rather than 'Refactor'.
> So are you criticizing the replacement or the mislabeling?

I think the criticism is that such gratuitous replacements in bugfix
branches are both a waste of time and a possible regression. The only
good reason to do them is if you think it will improve further merges
of bugfix patches.

Regards

Antoine.



From martin at v.loewis.de  Sat Mar 26 20:19:09 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 26 Mar 2011 20:19:09 +0100
Subject: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use
 enumerate().
In-Reply-To: <imld49$e83$1@dough.gmane.org>
References: <E1Q366l-0001CZ-Dt@dinsdale.python.org>	<imlajm$1g9$1@dough.gmane.org>
	<imld49$e83$1@dough.gmane.org>
Message-ID: <4D8E3C2D.2040807@v.loewis.de>

Am 26.03.2011 20:00, schrieb Terry Reedy:
> On 3/26/2011 2:17 PM, Georg Brandl wrote:
>> "Refactor" doesn't sound like it belongs in the 3.1 branch...
> 
>>> -        for i in range(len(pattern)):
>>> -            c = pattern[i]
>>> +        for i, c in enumerate(pattern):
> 
> I would call thin 'Replace obsolete idiom in' rather than 'Refactor'.
> So are you criticizing the replacement or the mislabeling?

No - I believe he is critizing that a stylistic change is done
in a maintenance branch. It's not a bug fix, AFAICT, so it should not
have been done.

Regards,
Martin

P.S. I haven't looked into the specific context, but the diff alone
may actually cause behavior changes, depending on what pattern exactly
is.

From martin at v.loewis.de  Sat Mar 26 20:34:27 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 26 Mar 2011 20:34:27 +0100
Subject: [Python-Dev] git-style diffs in Rietveld
Message-ID: <4D8E3FC3.7020804@v.loewis.de>

I changed the patch importer in Rietveld to recognize diffs without
a base changeset, which means that --git-style diffs are supported
as long as they apply to the default branch.

The tracker will provide review for a patch, iff, for all files in
the patch:
- a line starting with "diff " is found, and
- the line ends with a valid filename (an optional b/ is stripped
  first), and
- either:
  * it applies cleanly against its base revision, or
  * the base revision does not exist, and it is a patch creating
    a new file

To determine what the base revision is (and whether the file name
is valid), it checks that
* that the patch starts with 'diff -r <12digits>', taking 12digits as
  the base; if not,
* that the patch applies against cpython's "default"

To determine that the patch applies cleanly, it doesn't do any fuzzy
matching (unlike patch(1)). i.e. the old text must match exactly,
and by line numbers.

As a consequence, the following patches cannot be reviewed in
this Rietveld installation:
- patches not starting with "diff"
- patches generated with diff(1) if the path in the patch doesn't
  match cpython
- git-style diffs where the base file has been changed after the
  diff was produced.

If you find that it doesn't work in cases not discussed above,
please report this to the meta-tracker.

Regards,
Martin

From g.brandl at gmx.net  Sat Mar 26 23:03:13 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 26 Mar 2011 23:03:13 +0100
Subject: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use
	enumerate().
In-Reply-To: <4D8E3C2D.2040807@v.loewis.de>
References: <E1Q366l-0001CZ-Dt@dinsdale.python.org>	<imlajm$1g9$1@dough.gmane.org>
	<imld49$e83$1@dough.gmane.org> <4D8E3C2D.2040807@v.loewis.de>
Message-ID: <imlnqq$oo$1@dough.gmane.org>

On 26.03.2011 20:19, "Martin v. L?wis" wrote:
> Am 26.03.2011 20:00, schrieb Terry Reedy:
>> On 3/26/2011 2:17 PM, Georg Brandl wrote:
>>> "Refactor" doesn't sound like it belongs in the 3.1 branch...
>> 
>>>> -        for i in range(len(pattern)):
>>>> -            c = pattern[i]
>>>> +        for i, c in enumerate(pattern):
>> 
>> I would call thin 'Replace obsolete idiom in' rather than 'Refactor'.
>> So are you criticizing the replacement or the mislabeling?
> 
> No - I believe he is critizing that a stylistic change is done
> in a maintenance branch. It's not a bug fix, AFAICT, so it should not
> have been done.

Exactly, and two changesets before that there was another commit
"Refactor the tests for re.escape" that was by far larger than this one,
and not as easily reviewed as this one.

In the end, this kind of change in a bugfix branch has zero gain, but
a nonzero risk of gratuitous breakage.  If it is necessary for future
fixes or ease of merging bugfixes, I'd at least expect a note of that
in the commit message justifying the breach of policy for a
barely-maintenance branch.

Georg


From ncoghlan at gmail.com  Sun Mar 27 01:49:14 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Mar 2011 10:49:14 +1000
Subject: [Python-Dev] GSoC idea: PEP process enhancements (Was:
 [issue7284] argparse - display version in usage by default)
In-Reply-To: <AANLkTimkrf3-j6h9EUkxhEkR8e7zuqnKPKhTFwa_=7Z8@mail.gmail.com>
References: <AANLkTimkrf3-j6h9EUkxhEkR8e7zuqnKPKhTFwa_=7Z8@mail.gmail.com>
Message-ID: <AANLkTikNWfMgYXzqgkBfphBWviKs7BYRt7yq+E70yjV1@mail.gmail.com>

On Sun, Mar 27, 2011 at 2:55 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> What if we could accompany every PEP draft with series of use
> cases/user stories? I don't know how many people actually reviewed
> this particular PEP 389, and that's bad, because without this info it
> is hard to say if there were enough reviews from future users.

I admire your passion to make everything perfect, and your dream that
there are technological solutions to every social problem (i.e. people
missing things, or settling for "better" when you want them to aim for
"best").

It's a volunteer community. We muddle through as best we can, without
the ability to undertake full blown usability studies and analyses,
instead relying on straw polls of mailing lists, anecdotal evidence
and simple gut instinct of experienced developers. That's the reality
of open source development when you don't have a well-funded
individual in the driver's seat with the ability and desire to force a
particular design direction (ala Shuttleworth and Ubuntu).

You're welcome to come up with what you think is an improvement over
simply cloning the PEPs repo and maintaining a competing PEP (or
proposing patches to the existing one), but don't expect people to
just fall in love with whatever you suggest (remember past experiences
with advocating the use of Google Wave).

However, even if you did decide to do this, it wouldn't be suitable as
a GSoC project, as it would ultimately be about social engineering,
not coding.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ezio.melotti at gmail.com  Sun Mar 27 07:59:23 2011
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sun, 27 Mar 2011 08:59:23 +0300
Subject: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use
 enumerate().
In-Reply-To: <imlnqq$oo$1@dough.gmane.org>
References: <E1Q366l-0001CZ-Dt@dinsdale.python.org>	<imlajm$1g9$1@dough.gmane.org>	<imld49$e83$1@dough.gmane.org>
	<4D8E3C2D.2040807@v.loewis.de> <imlnqq$oo$1@dough.gmane.org>
Message-ID: <4D8ED23B.60703@gmail.com>

On 27/03/2011 0.03, Georg Brandl wrote:
> On 26.03.2011 20:19, "Martin v. L?wis" wrote:
>> Am 26.03.2011 20:00, schrieb Terry Reedy:
>>> On 3/26/2011 2:17 PM, Georg Brandl wrote:
>>>> "Refactor" doesn't sound like it belongs in the 3.1 branch...
>>>>> -        for i in range(len(pattern)):
>>>>> -            c = pattern[i]
>>>>> +        for i, c in enumerate(pattern):
>>> I would call thin 'Replace obsolete idiom in' rather than 'Refactor'.
>>> So are you criticizing the replacement or the mislabeling?
>> No - I believe he is critizing that a stylistic change is done
>> in a maintenance branch. It's not a bug fix, AFAICT, so it should not
>> have been done.
> Exactly, and two changesets before that there was another commit
> "Refactor the tests for re.escape" that was by far larger than this one,
> and not as easily reviewed as this one.
>
> In the end, this kind of change in a bugfix branch has zero gain, but
> a nonzero risk of gratuitous breakage.  If it is necessary for future
> fixes or ease of merging bugfixes, I'd at least expect a note of that
> in the commit message justifying the breach of policy for a
> barely-maintenance branch.

Hi,
these commits are part of #2650[0].
First, I refactored the existing tests[1] and added a few more tests[2] 
to have better coverage.  Tests are usually ported to maintenance 
branches as well (because they could uncover bugs and also make merging 
easier), so I started working on 3.1.
Then I refactored the function[3], and since the refactoring was trivial 
and I had extensive tests to make sure that the behavior was unchanged I 
included the refactoring in 3.1 too.

FWIW I've been porting most of the commits that I do on 3.2 on 3.1 too 
(i.e. I'm considering both of them maintenance branches), and merging 3 
branches rather than 2 doesn't make much difference with mercurial.

[0]: http://bugs.python.org/issue2650
[1]: http://hg.python.org/cpython/rev/1402c719b7cf
[2]: http://hg.python.org/cpython/rev/9147f7ed75b3
[3]: http://hg.python.org/cpython/rev/ed02db9921ac

Best Regards,
Ezio Melotti


> Georg
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ezio.melotti%40gmail.com
>


From skip at pobox.com  Sun Mar 27 17:06:49 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 27 Mar 2011 10:06:49 -0500
Subject: [Python-Dev] utf-8 encoding in checkins?
Message-ID: <19855.21129.360534.876590@montanaro.dyndns.org>

It seems that all checkin mails are utf-8-encoded.  This makes it
challenging to view checkin mails if you have a text-based mail reader.  (I
use VM within XEmacs.  XEmacs doesn't seem to support utf-8 out of the box.
I believe you need to add MULE to it.)  Is there some reason such messages
can't be encoded in ASCII unless a non-ASCII message body is detected?

Skip


From solipsis at pitrou.net  Sun Mar 27 17:21:08 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Mar 2011 17:21:08 +0200
Subject: [Python-Dev] utf-8 encoding in checkins?
References: <19855.21129.360534.876590@montanaro.dyndns.org>
Message-ID: <20110327172108.2fc1ec0c@pitrou.net>

On Sun, 27 Mar 2011 10:06:49 -0500
skip at pobox.com wrote:
> It seems that all checkin mails are utf-8-encoded.  This makes it
> challenging to view checkin mails if you have a text-based mail reader.  (I
> use VM within XEmacs.  XEmacs doesn't seem to support utf-8 out of the box.
> I believe you need to add MULE to it.)

Hmm, are you sure? Software (especially mail-reading software) that
doesn't support utf-8 in 2011 should be considered extremely broken.

(I understand you may be a native English speaker, but do you never
receive non-ASCII utf-8 e-mail at all? doesn't it get displayed
properly?)

Regards

Antoine.



From jon+python-dev at unequivocal.co.uk  Sun Mar 27 18:33:04 2011
From: jon+python-dev at unequivocal.co.uk (Jon Ribbens)
Date: Sun, 27 Mar 2011 17:33:04 +0100
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <20110327172108.2fc1ec0c@pitrou.net>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<20110327172108.2fc1ec0c@pitrou.net>
Message-ID: <20110327163304.GM17437@snowy.squish.net>

On Sun, Mar 27, 2011 at 05:21:08PM +0200, Antoine Pitrou wrote:
> On Sun, 27 Mar 2011 10:06:49 -0500
> skip at pobox.com wrote:
> > It seems that all checkin mails are utf-8-encoded.  This makes it
> > challenging to view checkin mails if you have a text-based mail reader.  (I
> > use VM within XEmacs.  XEmacs doesn't seem to support utf-8 out of the box.
> > I believe you need to add MULE to it.)
> 
> Hmm, are you sure? Software (especially mail-reading software) that
> doesn't support utf-8 in 2011 should be considered extremely broken.
> 
> (I understand you may be a native English speaker, but do you never
> receive non-ASCII utf-8 e-mail at all? doesn't it get displayed
> properly?)

In my experience it is very difficult to get a whole system
configured, such that UTF-8 works reliably. In my case that would
mean, I think, Linux, glibc, mutt, screen, elinks, and SecureCRT would
all have to simultaneously be configured precisely correctly in order
to get it to work. I have certainly never managed it, anyway.

Mind you, I've never managed to get the <-- button working reliably
either, but to be fair that's insanely complicated too.

From skip at pobox.com  Sun Mar 27 20:08:02 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 27 Mar 2011 13:08:02 -0500
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <20110327172108.2fc1ec0c@pitrou.net>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<20110327172108.2fc1ec0c@pitrou.net>
Message-ID: <19855.32002.499787.700334@montanaro.dyndns.org>


    Antoine> Hmm, are you sure? Software (especially mail-reading software)
    Antoine> that doesn't support utf-8 in 2011 should be considered
    Antoine> extremely broken.

I'm not disputing that, and I understand that my current choice of mail
reader limits me.  I was just asking if it would be possible (read: fairly
easy) to only generate utf-8 when it was necessary.

For the time being I'm using a procmail hack to blindly rewrite utf-8 to
us-ascii in the checking messages.  I'll see how that works before doing
something more elaborate like switching out my mail reader.

Skip

From eltoder at gmail.com  Sun Mar 27 20:13:29 2011
From: eltoder at gmail.com (Eugene Toder)
Date: Sun, 27 Mar 2011 14:13:29 -0400
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <19855.32002.499787.700334@montanaro.dyndns.org>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<20110327172108.2fc1ec0c@pitrou.net>
	<19855.32002.499787.700334@montanaro.dyndns.org>
Message-ID: <AANLkTikk51XYEP49EGOsyjP8E_qNyMfinXNvHQt0Ln_g@mail.gmail.com>

> I'm not disputing that, and I understand that my current choice of mail
> reader limits me. ?I was just asking if it would be possible (read: fairly
> easy) to only generate utf-8 when it was necessary.

Isn't utf-8 itself same as ascii where no non-ascii symbols are used?

Eugene

From g.brandl at gmx.net  Sun Mar 27 20:19:25 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 27 Mar 2011 20:19:25 +0200
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <20110327163304.GM17437@snowy.squish.net>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<20110327172108.2fc1ec0c@pitrou.net>
	<20110327163304.GM17437@snowy.squish.net>
Message-ID: <imnv31$jev$1@dough.gmane.org>

On 27.03.2011 18:33, Jon Ribbens wrote:
> On Sun, Mar 27, 2011 at 05:21:08PM +0200, Antoine Pitrou wrote:
>> On Sun, 27 Mar 2011 10:06:49 -0500
>> skip at pobox.com wrote:
>> > It seems that all checkin mails are utf-8-encoded.  This makes it
>> > challenging to view checkin mails if you have a text-based mail reader.  (I
>> > use VM within XEmacs.  XEmacs doesn't seem to support utf-8 out of the box.
>> > I believe you need to add MULE to it.)
>> 
>> Hmm, are you sure? Software (especially mail-reading software) that
>> doesn't support utf-8 in 2011 should be considered extremely broken.
>> 
>> (I understand you may be a native English speaker, but do you never
>> receive non-ASCII utf-8 e-mail at all? doesn't it get displayed
>> properly?)
> 
> In my experience it is very difficult to get a whole system
> configured, such that UTF-8 works reliably. In my case that would
> mean, I think, Linux, glibc, mutt, screen, elinks, and SecureCRT would
> all have to simultaneously be configured precisely correctly in order
> to get it to work. I have certainly never managed it, anyway.

But surely there is a difference between input and output encoding?
Even if a mail program cannot output UTF-8 correctly (due to whatever
misconfiguration in the output chain), it should still be able to
read base-64 encoded utf-8 blocks, and display most of them, even if
the odd non-ASCII character is broken.

> Mind you, I've never managed to get the <-- button working reliably
> either, but to be fair that's insanely complicated too.

Sorry, I'm not familiar with that button.

Georg


From rdmurray at bitdance.com  Sun Mar 27 20:21:25 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 27 Mar 2011 14:21:25 -0400
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <20110327163304.GM17437@snowy.squish.net>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<20110327172108.2fc1ec0c@pitrou.net>
	<20110327163304.GM17437@snowy.squish.net>
Message-ID: <20110327182125.0E40A164D8F@kimball.webabinitio.net>

On Sun, 27 Mar 2011 17:33:04 +0100, Jon Ribbens wrote:
> In my experience it is very difficult to get a whole system
> configured, such that UTF-8 works reliably. In my case that would
> mean, I think, Linux, glibc, mutt, screen, elinks, and SecureCRT would
> all have to simultaneously be configured precisely correctly in order
> to get it to work. I have certainly never managed it, anyway.

I remember a few small bumps when I switched to using utf8 by default
in Linux, but nothing very difficult to figure out.  There are still
a few places where it isn't displayed properly, but they are isolated
cases and don't bother me much (mostly a couple older tools that just
don't have good non-ascii support).

> Mind you, I've never managed to get the <-- button working reliably
> either, but to be fair that's insanely complicated too.

No idea what that is.

--
R. David Murray           http://www.bitdance.com

From martin at v.loewis.de  Sun Mar 27 20:29:30 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 27 Mar 2011 20:29:30 +0200
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <19855.21129.360534.876590@montanaro.dyndns.org>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
Message-ID: <4D8F820A.5010200@v.loewis.de>

Am 27.03.2011 17:06, schrieb skip at pobox.com:
> It seems that all checkin mails are utf-8-encoded.  This makes it
> challenging to view checkin mails if you have a text-based mail reader.  (I
> use VM within XEmacs.  XEmacs doesn't seem to support utf-8 out of the box.
> I believe you need to add MULE to it.)  Is there some reason such messages
> can't be encoded in ASCII unless a non-ASCII message body is detected?

Even if it was easy to change, I'd advise against doing so. IIUC, we use
the standard email hook from the Mercurial sources, to change it would
mean to fork it. Users with email readers that can't display UTF-8 at
all (even if the characters are all ASCII) will need to find a way of
coping with that.

Regards,
Martin

From jon+python-dev at unequivocal.co.uk  Sun Mar 27 20:43:40 2011
From: jon+python-dev at unequivocal.co.uk (Jon Ribbens)
Date: Sun, 27 Mar 2011 19:43:40 +0100
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <AANLkTikk51XYEP49EGOsyjP8E_qNyMfinXNvHQt0Ln_g@mail.gmail.com>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<20110327172108.2fc1ec0c@pitrou.net>
	<19855.32002.499787.700334@montanaro.dyndns.org>
	<AANLkTikk51XYEP49EGOsyjP8E_qNyMfinXNvHQt0Ln_g@mail.gmail.com>
Message-ID: <20110327184340.GA28020@snowy.squish.net>

On Sun, Mar 27, 2011 at 02:13:29PM -0400, Eugene Toder wrote:
> > I'm not disputing that, and I understand that my current choice of mail
> > reader limits me. ?I was just asking if it would be possible (read: fairly
> > easy) to only generate utf-8 when it was necessary.
> 
> Isn't utf-8 itself same as ascii where no non-ascii symbols are used?

Yes, however some software will label outgoing stuff as UTF-8 even if
actually it contains no non-ASCII characters. Then, other software
will assume that it cannot understand the message (either because it
assumes the charset label is correct or because it doesn't know that
it can understand "UTF-8" that contains no top-bit-set characters).

From jon+python-dev at unequivocal.co.uk  Sun Mar 27 20:46:35 2011
From: jon+python-dev at unequivocal.co.uk (Jon Ribbens)
Date: Sun, 27 Mar 2011 19:46:35 +0100
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <20110327182125.0E40A164D8F@kimball.webabinitio.net>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<20110327172108.2fc1ec0c@pitrou.net>
	<20110327163304.GM17437@snowy.squish.net>
	<20110327182125.0E40A164D8F@kimball.webabinitio.net>
Message-ID: <20110327184635.GB28020@snowy.squish.net>

On Sun, Mar 27, 2011 at 02:21:25PM -0400, R. David Murray wrote:
> > Mind you, I've never managed to get the <-- button working reliably
> > either, but to be fair that's insanely complicated too.
> 
> No idea what that is.

"Backspace" key.

From skip at pobox.com  Sun Mar 27 20:50:24 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 27 Mar 2011 13:50:24 -0500
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <AANLkTikk51XYEP49EGOsyjP8E_qNyMfinXNvHQt0Ln_g@mail.gmail.com>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<20110327172108.2fc1ec0c@pitrou.net>
	<19855.32002.499787.700334@montanaro.dyndns.org>
	<AANLkTikk51XYEP49EGOsyjP8E_qNyMfinXNvHQt0Ln_g@mail.gmail.com>
Message-ID: <19855.34544.489432.723994@montanaro.dyndns.org>


    >> I'm not disputing that, and I understand that my current choice of
    >> mail reader limits me. ?I was just asking if it would be possible
    >> (read: fairly easy) to only generate utf-8 when it was necessary.

    Eugene> Isn't utf-8 itself same as ascii where no non-ascii symbols are
    Eugene> used?

Sure, but the mime header tells VM that the body of the part is utf-8
encoded, and it's base64-encoded.  If it wasn't base64-encoded I could
simply hit D in my mail reader to expand the part.

Skip

From skip at pobox.com  Sun Mar 27 21:10:39 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 27 Mar 2011 14:10:39 -0500
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <4D8F820A.5010200@v.loewis.de>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<4D8F820A.5010200@v.loewis.de>
Message-ID: <19855.35759.729216.533872@montanaro.dyndns.org>


    Martin> Am 27.03.2011 17:06, schrieb skip at pobox.com:
    >> It seems that all checkin mails are utf-8-encoded.  This makes it
    >> challenging to view checkin mails if you have a text-based mail
    >> reader.  (I use VM within XEmacs.  XEmacs doesn't seem to support
    >> utf-8 out of the box.  I believe you need to add MULE to it.)  Is
    >> there some reason such messages can't be encoded in ASCII unless a
    >> non-ASCII message body is detected?

    Martin> Even if it was easy to change, I'd advise against doing
    Martin> so. IIUC, we use the standard email hook from the Mercurial
    Martin> sources, to change it would mean to fork it. Users with email
    Martin> readers that can't display UTF-8 at all (even if the characters
    Martin> are all ASCII) will need to find a way of coping with that.

That's fine.  I was just asking.  

I guess I have my work cut out for me.  It appears my preferred mail reader,
VM, is not supported out-of-the-box by GNU Emacs (they still use Rmail and
Babyl for some reason), and I'm not sure the investment trying to get XEmacs
built with MULE is worth the effort.

Skip

From tjreedy at udel.edu  Sun Mar 27 21:19:41 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 27 Mar 2011 15:19:41 -0400
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <AANLkTikk51XYEP49EGOsyjP8E_qNyMfinXNvHQt0Ln_g@mail.gmail.com>
References: <19855.21129.360534.876590@montanaro.dyndns.org>	<20110327172108.2fc1ec0c@pitrou.net>	<19855.32002.499787.700334@montanaro.dyndns.org>
	<AANLkTikk51XYEP49EGOsyjP8E_qNyMfinXNvHQt0Ln_g@mail.gmail.com>
Message-ID: <imo2k8$7bt$1@dough.gmane.org>

On 3/27/2011 2:13 PM, Eugene Toder wrote:
>> I'm not disputing that, and I understand that my current choice of mail
>> reader limits me.  I was just asking if it would be possible (read: fairly
>> easy) to only generate utf-8 when it was necessary.
>
> Isn't utf-8 itself same as ascii where no non-ascii symbols are used?

Yes, except for the content encoding header. Any mail reader today 
should know that and at least replace any non-ascii bytes (very rare in 
checkin messages) with some symbol and continue, rather than crash.

-- 
Terry Jan Reedy


From rdmurray at bitdance.com  Sun Mar 27 21:44:47 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 27 Mar 2011 15:44:47 -0400
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <20110327184635.GB28020@snowy.squish.net>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<20110327172108.2fc1ec0c@pitrou.net>
	<20110327163304.GM17437@snowy.squish.net>
	<20110327182125.0E40A164D8F@kimball.webabinitio.net>
	<20110327184635.GB28020@snowy.squish.net>
Message-ID: <20110327194447.D5FE1729DF@kimball.webabinitio.net>

On Sun, 27 Mar 2011 19:46:35 +0100, Jon Ribbens <jon+python-dev at unequivocal.co.uk> wrote:
> On Sun, Mar 27, 2011 at 02:21:25PM -0400, R. David Murray wrote:
> > > Mind you, I've never managed to get the <-- button working reliably
> > > either, but to be fair that's insanely complicated too.
> > 
> > No idea what that is.
> 
> "Backspace" key.

Ah, yes.  The backspace key is indeed harder to get right across all
applications than utf-8 is.  Which makes one wonder, considering
that the backspace key problem has been with us a lot longer.

--
R. David Murray           http://www.bitdance.com

From crossd at cs.rpi.edu  Mon Mar 28 01:07:08 2011
From: crossd at cs.rpi.edu (David E. Cross)
Date: Sun, 27 Mar 2011 19:07:08 -0400 (EDT)
Subject: [Python-Dev] Python 2.7 on Irix 6.5.22 fails ctypes callback test
Message-ID: <20110327190034.T3772@monica.cs.rpi.edu>

Trying to compile and install Python 2.7 on irix 6.5.22 IP22 (N32 ABI 
model), Using gcc-4.5.1 and binutils 2.20.1.  Everything goes well (I 
applied th patches listed at: 
http://bugs.python.org/file15915/python-2.7-irix.patch )

It compiles and the test mostly work except for the callback ctypes 
(libffi) test where it segfaults on a pyDECREFF.  Digging in, the O_get 
call is returning a NULL pointer (and pyDECREF is understandably choking 
on that).

Since I am very new to python, I am at a bit of a loss to tracing the C 
code back through this particulat section of code to see why the PyOBJECT 
isn't being assigned here.  Any help would be welomed.

-- 
David E. Cross

From nas at python.ca  Sun Mar 27 21:15:05 2011
From: nas at python.ca (Neil Schemenauer)
Date: Sun, 27 Mar 2011 19:15:05 +0000 (UTC)
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
Message-ID: <imo2bp$5ok$1@dough.gmane.org>

Guido van Rossum <guido at python.org> wrote:
> What is "rebase"? Why does everyone want it and hate it at the same time?

It's the same thing that happens when you do a "svn up" with local
changes in your checkout.  Logically, your patch gets modified so
that it applies on a different (newer) version of the code.

If you don't rebase then those modifications end up getting stored
in the history as merge nodes.  That's quite messy in my opinion and
generally not a good idea.  Rebase is an important tool (which can
at times be abused).

Regarding collapsing multiple comments (and rewriting history in
general), I feel there are two main schools of thought.  One school
considers the development history of a change important and that it
should be preserved: every step and misstep of development should
end up in the public repository.

The other school, which I am a member of, considers a logical
development sequence more important than actual development history.
I like to see a feature or fix developed in smallish, logical steps
and I'm willing to spend a lot of time to rewrite patches to make it
happen.  IMO, future maintainers will thank you for the effort.

Note though, when you are worked with a distributed system, you
should not rebase commits that are in other people's repositories.
In practice this is generally not a problem.  If you have a long
lived branch that you are sharing with other people, you can have a
agreement that everyone will destory their old copy when it is
rebased.  Alternatively, you just take care to only publicly push
logical changes.

Regards,

  Neil


From nas at arctrix.com  Sun Mar 27 21:39:10 2011
From: nas at arctrix.com (Neil Schemenauer)
Date: Sun, 27 Mar 2011 13:39:10 -0600
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
Message-ID: <4d9008bc.04558f0a.2b7b.ffffe50b@mx.google.com>

Barry Warsaw <barry at python.org> wrote:
> I'm asking because I don't know hg and git well enough to answer the
> question.  In my own use of Bazaar over the last 4+ years, I've almost never
> rebased or even been asked to.

Maybe it depends on what kind of changes you commit.  I consider
future maintainers the most important "customer" of the repository
history.  As such, I try to make each commit a logical change that
takes a working system and produces another working system.  In that
way, each change to be potentially reversed if later on if it found
to cause problems.  Also, ideally, each revision can be tested to
narrow down the version where a bug was introduced.

I see a VCS system as having two related but different purposes.
The first is to help keep track of changes when they are developed.
This is messy.  I don't know about you but I make lots of mistakes:
changes that don't do what I want, crazy ideas that turn into dead
ends, etc.  I use a VCS to keep track of this experimentation and my
incremental progress.

The second is to keep a record of the change history of a long lived
piece of software.  In that case, I like it that each change has a
logical purpose.  In the first case the "customer" is the developer.
In the second it is the maintainer.

> In this graph:
>
>>          A --- B ------------.
>>         /                     \
>>... --- X --- C --- D --- E --- M
>
> A and B do exist, but I shouldn't care or notice them unless I explicitly
> drill down.

In my case, I usually have something like:

         A --- B --- C
         /            
... --- X --- F --- G --- H 

A, B, and C are messy and not logical.  Maybe I write them so I have
two logical patches (assuming they are only in my private repo):

         A' --- B'
         /            
... --- X --- F --- G --- H 

Next, putting the merge in public repository generally serves no
purpose so I rebase on H:

... --- X --- F --- G --- H --- A'' --- B''

This very much matches the result I would get if using CVS or
Subversion.  IMHO, the changes A, B, and C represent partially
complete development and there is no purpose to put them in the
public repo.

If you are able to directly commit A' and B' and your tool does a
good job of hiding the logically unimportant merge then I guess you
wouldn't miss the ability to modify history.

  Neil

From stutzbach at google.com  Mon Mar 28 06:11:04 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sun, 27 Mar 2011 21:11:04 -0700
Subject: [Python-Dev] [Python-checkins] cpython: Add optional *func*
	argument to itertools.accumulate().
In-Reply-To: <E1Q41cw-0006qn-De@dinsdale.python.org>
References: <E1Q41cw-0006qn-De@dinsdale.python.org>
Message-ID: <BANLkTina4uRMccc9vxtk8J7E0AsJ0j3bfg@mail.gmail.com>

On Sun, Mar 27, 2011 at 6:52 PM, raymond.hettinger <
python-checkins at python.org> wrote:

> -.. function:: accumulate(iterable)

+.. function:: accumulate(iterable[, func])
>


>     Make an iterator that returns accumulated sums. Elements may be any
> addable
> -    type including :class:`Decimal` or :class:`Fraction`.  Equivalent to::
> +    type including :class:`Decimal` or :class:`Fraction`.  If the optional
> +    *func* argument is supplied, it should be a function of two arguments
> +    and it will be used instead of addition.
>

Is there a good use-case for the func argument?  I can only think of bad
use-cases (where "func" does something that does not remotely resemble
addition).  I fear that people will actually implement these bad use-cases,
and I will have to try to read and understand their code.

Adding the func argument seems analogous to adding a func argument to sum(),
which would give it all of the power of reduce().

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110327/2ae6aa76/attachment.html>

From ncoghlan at gmail.com  Mon Mar 28 07:53:52 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 28 Mar 2011 15:53:52 +1000
Subject: [Python-Dev] [Python-checkins] cpython: Add optional *func*
 argument to itertools.accumulate().
In-Reply-To: <BANLkTina4uRMccc9vxtk8J7E0AsJ0j3bfg@mail.gmail.com>
References: <E1Q41cw-0006qn-De@dinsdale.python.org>
	<BANLkTina4uRMccc9vxtk8J7E0AsJ0j3bfg@mail.gmail.com>
Message-ID: <AANLkTimAAWYjZKgwTc=Hv4wsJKRGAbdvbJTfNjVbn+MD@mail.gmail.com>

On Mon, Mar 28, 2011 at 2:11 PM, Daniel Stutzbach <stutzbach at google.com> wrote:
> Is there a good use-case for the func argument? ?I can only think of bad
> use-cases (where "func" does something that does not remotely resemble
> addition). ?I fear that people will actually implement these bad use-cases,
> and I will have to try to read and understand their code.
> Adding the func argument seems analogous to adding a func argument to sum(),
> which would give it all of the power of reduce().

The difference lies in the fact that, because accumulate is an
iterator that yields a *running* result, the two corner cases that
make reduce problematic in practice (i.e. correctly handling empty and
1-item input iterables) are handled naturally.

The examples that Raymond gives in the docs (cumulative
multiplication, running min/max, cash flow accumulation) look fairly
solid to me.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ben+python at benfinney.id.au  Mon Mar 28 08:14:00 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 28 Mar 2011 17:14:00 +1100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<imo2bp$5ok$1@dough.gmane.org>
Message-ID: <87mxkfrcuv.fsf@benfinney.id.au>

Neil Schemenauer <nas at python.ca> writes:

> Regarding collapsing multiple comments (and rewriting history in
> general), I feel there are two main schools of thought. One school
> considers the development history of a change important and that it
> should be preserved: every step and misstep of development should end
> up in the public repository.

Yep, that's the school I'm in. Other people don't get to say what I
would find useful, and the cost of having data there is very low
compared to the inability to re-create it at the times when it's needed.

> The other school, which I am a member of, considers a logical
> development sequence more important than actual development history.

That seems to be an artefact of VCS tools which force you to choose
between those two. The reason I prefer Bazaar is that it gives me both
without compromising either.

> I like to see a feature or fix developed in smallish, logical steps
> and I'm willing to spend a lot of time to rewrite patches to make it
> happen. IMO, future maintainers will thank you for the effort.

Right, and those logical steps are done as merges from the feature
branch into the trunk (substitute those names as you like). I consider
the merging from one branch to another as the time to decide how to
present my VCS work for others to view.

I haven't heard a useful case for rebase that I don't get with Bazaar's
merging, default history presentation, and shelve capability. And all of
that without ever having to re-write history ? nor even choose what
valuable information to lose.

-- 
 \      ?The way to build large Python applications is to componentize |
  `\             and loosely-couple the hell out of everything.? ?Aahz |
_o__)                                                                  |
Ben Finney


From stutzbach at google.com  Mon Mar 28 09:38:08 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Mon, 28 Mar 2011 00:38:08 -0700
Subject: [Python-Dev] [Python-checkins] cpython: Add optional *func*
 argument to itertools.accumulate().
In-Reply-To: <AANLkTimAAWYjZKgwTc=Hv4wsJKRGAbdvbJTfNjVbn+MD@mail.gmail.com>
References: <E1Q41cw-0006qn-De@dinsdale.python.org>
	<BANLkTina4uRMccc9vxtk8J7E0AsJ0j3bfg@mail.gmail.com>
	<AANLkTimAAWYjZKgwTc=Hv4wsJKRGAbdvbJTfNjVbn+MD@mail.gmail.com>
Message-ID: <BANLkTikNMEU1ZEUGmghG7tURSDM6fY=m9Q@mail.gmail.com>

On Sun, Mar 27, 2011 at 10:53 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Mon, Mar 28, 2011 at 2:11 PM, Daniel Stutzbach <stutzbach at google.com>
> wrote:
> > Is there a good use-case for the func argument?
>


> The examples that Raymond gives in the docs (cumulative
> multiplication, running min/max, cash flow accumulation) look fairly
> solid to me.


(I had the nagging suspicion that I was making a blunder in my email, but I
couldn't see it despite rereading my email several times before sending.  My
blunder was in not rereading the patch to see the examples.  Anyway...)

When would a running product, min, or max be useful?

for running_min in accumulate(data, min):
    # Do what?

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110328/97bea9fc/attachment.html>

From raymond.hettinger at gmail.com  Mon Mar 28 09:49:03 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 28 Mar 2011 00:49:03 -0700
Subject: [Python-Dev] [Python-checkins] cpython: Add optional *func*
	argument to itertools.accumulate().
In-Reply-To: <BANLkTikNMEU1ZEUGmghG7tURSDM6fY=m9Q@mail.gmail.com>
References: <E1Q41cw-0006qn-De@dinsdale.python.org>
	<BANLkTina4uRMccc9vxtk8J7E0AsJ0j3bfg@mail.gmail.com>
	<AANLkTimAAWYjZKgwTc=Hv4wsJKRGAbdvbJTfNjVbn+MD@mail.gmail.com>
	<BANLkTikNMEU1ZEUGmghG7tURSDM6fY=m9Q@mail.gmail.com>
Message-ID: <9E18EF69-FBFC-43C9-83E2-36F831A8FDAE@gmail.com>


On Mar 28, 2011, at 12:38 AM, Daniel Stutzbach wrote:

> On Sun, Mar 27, 2011 at 10:53 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Mar 28, 2011 at 2:11 PM, Daniel Stutzbach <stutzbach at google.com> wrote:
> > Is there a good use-case for the func argument?
>  
> The examples that Raymond gives in the docs (cumulative
> multiplication, running min/max, cash flow accumulation) look fairly
> solid to me.
> 
> (I had the nagging suspicion that I was making a blunder in my email, but I couldn't see it despite rereading my email several times before sending.  My blunder was in not rereading the patch to see the examples.  Anyway...)
> 
> When would a running product, min, or max be useful?

There's no need to speculate.  This API has long been present in other languages and libraries.

Do a google code search for R's builtin functions cumsum, cumprod, cummin, and cummax. Look at mumpy's accumulate ufunc which works with many operators. APL and K also have an accumulate tool which takes arbitrary functions.

Or consider as an API principle that there should be s useful default (addition in this case) and also hooks or parameters provided so that users don't have to do backflips to override hard-wired behaviors.


Raymond  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110328/49d7958e/attachment.html>

From p.f.moore at gmail.com  Mon Mar 28 12:13:55 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 28 Mar 2011 11:13:55 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <imo2bp$5ok$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<imo2bp$5ok$1@dough.gmane.org>
Message-ID: <AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>

On 27 March 2011 20:15, Neil Schemenauer <nas at python.ca> wrote:
> Guido van Rossum <guido at python.org> wrote:
>> What is "rebase"? Why does everyone want it and hate it at the same time?
[...]
> The other school, which I am a member of, considers a logical
> development sequence more important than actual development history.
> I like to see a feature or fix developed in smallish, logical steps
> and I'm willing to spend a lot of time to rewrite patches to make it
> happen. ?IMO, future maintainers will thank you for the effort.

This philosophy is essentially what the "mq" extension to Mercurial
tries to capture. In mq, you maintain a series of patches "on top of"
your repository, amending, refining and rebasing them as you wish
until they are ready to commit, at which time you take them off the
patch queue and convert them into final commits in the repository.

The one downside of mq is that you do not get the usual benefits of
distributed version control - local commits of your work, branching to
manage experiments, etc. This isn't really surprising, as that sort of
"messy" development doesn't really fit with a nice clean picture of
logical and well-defined patches (at least, it doesn't fit easily
enough that it can be automated :-)). There is a facility in mq to try
to integrate the two, by versioning your patch queue, but that makes
my head hurt, so I can't really comment on how useful that is...

For people in the "clean history" school, I'd recommend looking at mq
for your personal use. But it's definitely an advanced feature of
Mercurial, so it may be better to understand core Mercurial (and at
least temporarily accept that Mercurial is based on the "keep all
history" school of thought, or you'll struggle to match the
assumptions of the documentation to your thinking :-)) before diving
into mq.

Paul.

PS You can do everything that mq provides using core Mercurial
commands - and in theory, do it more safely - but it won't necessarily
fit the way you think quite as well...

From ncoghlan at gmail.com  Mon Mar 28 12:35:33 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 28 Mar 2011 20:35:33 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<imo2bp$5ok$1@dough.gmane.org>
	<AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>
Message-ID: <AANLkTim_fR9FRKEZ2GVruiUw+vWvbe2Eb1jBop=uZXbk@mail.gmail.com>

On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> For people in the "clean history" school, I'd recommend looking at mq
> for your personal use. But it's definitely an advanced feature of
> Mercurial, so it may be better to understand core Mercurial (and at
> least temporarily accept that Mercurial is based on the "keep all
> history" school of thought, or you'll struggle to match the
> assumptions of the documentation to your thinking :-)) before diving
> into mq.

I'm seeing if I can get the best of both worlds by having a public
sandbox repo where I work on things (which has the full messy history
of development on its feature branches), and then just drop them into
the main repo as coherent patches. Once I land a patch, I'll close the
original feature branch in the sandbox, so merge conflicts won't be an
issue.

Mercurial makes merging easy enough that I'm happy with the way that
approach is working so far.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From p.f.moore at gmail.com  Mon Mar 28 12:44:36 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 28 Mar 2011 11:44:36 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTim_fR9FRKEZ2GVruiUw+vWvbe2Eb1jBop=uZXbk@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<imo2bp$5ok$1@dough.gmane.org>
	<AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>
	<AANLkTim_fR9FRKEZ2GVruiUw+vWvbe2Eb1jBop=uZXbk@mail.gmail.com>
Message-ID: <AANLkTimuU49gM6TqpLwBz6+ABXxROzvPhRHwuyyZmNqP@mail.gmail.com>

On 28 March 2011 11:35, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> For people in the "clean history" school, I'd recommend looking at mq
>> for your personal use. But it's definitely an advanced feature of
>> Mercurial, so it may be better to understand core Mercurial (and at
>> least temporarily accept that Mercurial is based on the "keep all
>> history" school of thought, or you'll struggle to match the
>> assumptions of the documentation to your thinking :-)) before diving
>> into mq.
>
> I'm seeing if I can get the best of both worlds by having a public
> sandbox repo where I work on things (which has the full messy history
> of development on its feature branches), and then just drop them into
> the main repo as coherent patches. Once I land a patch, I'll close the
> original feature branch in the sandbox, so merge conflicts won't be an
> issue.
>
> Mercurial makes merging easy enough that I'm happy with the way that
> approach is working so far.

That's in essence what I was thinking of when I said "You can do
everything that mq provides using core Mercurial
commands", but never having done it myself, I wasn't sure how
straightforward it would feel to someone in Neil's "second school".

Paul.

From fuzzyman at voidspace.org.uk  Mon Mar 28 14:48:03 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 28 Mar 2011 13:48:03 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTim_fR9FRKEZ2GVruiUw+vWvbe2Eb1jBop=uZXbk@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<imo2bp$5ok$1@dough.gmane.org>	<AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>
	<AANLkTim_fR9FRKEZ2GVruiUw+vWvbe2Eb1jBop=uZXbk@mail.gmail.com>
Message-ID: <4D908383.2070505@voidspace.org.uk>

On 28/03/2011 11:35, Nick Coghlan wrote:
> On Mon, Mar 28, 2011 at 8:13 PM, Paul Moore<p.f.moore at gmail.com>  wrote:
>> For people in the "clean history" school, I'd recommend looking at mq
>> for your personal use. But it's definitely an advanced feature of
>> Mercurial, so it may be better to understand core Mercurial (and at
>> least temporarily accept that Mercurial is based on the "keep all
>> history" school of thought, or you'll struggle to match the
>> assumptions of the documentation to your thinking :-)) before diving
>> into mq.
> I'm seeing if I can get the best of both worlds by having a public
> sandbox repo where I work on things (which has the full messy history
> of development on its feature branches), and then just drop them into
> the main repo as coherent patches. Once I land a patch, I'll close the
> original feature branch in the sandbox, so merge conflicts won't be an
> issue.
>
> Mercurial makes merging easy enough that I'm happy with the way that
> approach is working so far.

For any non-trivial work I think this is the best approach. You still 
get all the advantages of working with mercurial (able to commit 
frequently) without polluting the history of the core repository.

It has the major advantage of also being very simple to understand.

All the best,

Michael
> Cheers,
> Nick.
>


-- 
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


From ncoghlan at gmail.com  Mon Mar 28 14:52:59 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 28 Mar 2011 22:52:59 +1000
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <4D908383.2070505@voidspace.org.uk>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<imo2bp$5ok$1@dough.gmane.org>
	<AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>
	<AANLkTim_fR9FRKEZ2GVruiUw+vWvbe2Eb1jBop=uZXbk@mail.gmail.com>
	<4D908383.2070505@voidspace.org.uk>
Message-ID: <AANLkTimLvHv2aCzuDBSH3Wq14Y18N54u1Z=48+A5MOXM@mail.gmail.com>

On Mon, Mar 28, 2011 at 10:48 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 28/03/2011 11:35, Nick Coghlan wrote:
>> Mercurial makes merging easy enough that I'm happy with the way that
>> approach is working so far.
>
> For any non-trivial work I think this is the best approach. You still get
> all the advantages of working with mercurial (able to commit frequently)
> without polluting the history of the core repository.
>
> It has the major advantage of also being very simple to understand.

Martin also seems to have worked the kinks out of the Roundup patch
generation, so generating updated patches for people to review in the
tracker is just a matter of clicking a button.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From dsdale24 at gmail.com  Mon Mar 28 15:30:30 2011
From: dsdale24 at gmail.com (Darren Dale)
Date: Mon, 28 Mar 2011 09:30:30 -0400
Subject: [Python-Dev] improvement to declaring abstract properties
In-Reply-To: <AANLkTino7Gt7XuLHT0Rt273-G5p8nLN3a913MQd_NZLe@mail.gmail.com>
References: <AANLkTino7Gt7XuLHT0Rt273-G5p8nLN3a913MQd_NZLe@mail.gmail.com>
Message-ID: <AANLkTi=_Dm546q=OmNcsPHq8KpXs2MD0=gLQJr9e3jLW@mail.gmail.com>

On Sat, Mar 19, 2011 at 3:06 PM, Darren Dale <dsdale24 at gmail.com> wrote:
> I suggested at python-ideas a way that the declaration of abstract
> properties could be improved to support the decorator syntax:
> http://mail.python.org/pipermail/python-ideas/2011-March/009411.html .
> A relatively small change to the property builtin would allow
> properties to identify themselves as abstract when they are passed
> abstract methods (the same way that function objects identify
> themselves as abstract when decorated with @abstractmethod). As a
> result, @abstractproperty would no longer be needed.
>
> ?I submitted a patch at http://bugs.python.org/issue11610. It includes
> the changes to the property builtin, documentation, and unit tests.

This patch has been improved so it only touches abc.abstractproperty.
"make test" yields the same results with and without the patch. As a
result of the review (http://bugs.python.org/review/11610/show), the
documentation was improved to make it clear that the changes are
backward compatible. The reviewer seemed satisfied and provided some
encouraging feedback, but will not be available to guide the patch to
submission. So I am soliciting for another core committer to continue
the review and hopefully apply the changes for python-3.3.

Thanks,
Darren

From solipsis at pitrou.net  Mon Mar 28 17:33:39 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Mar 2011 17:33:39 +0200
Subject: [Python-Dev] Python 2.7 on Irix 6.5.22 fails ctypes callback
	test
References: <20110327190034.T3772@monica.cs.rpi.edu>
Message-ID: <20110328173339.79552853@pitrou.net>

On Sun, 27 Mar 2011 19:07:08 -0400 (EDT)
"David E. Cross" <crossd at cs.rpi.edu> wrote:
> Trying to compile and install Python 2.7 on irix 6.5.22 IP22 (N32 ABI 
> model), Using gcc-4.5.1 and binutils 2.20.1.  Everything goes well (I 
> applied th patches listed at: 
> http://bugs.python.org/file15915/python-2.7-irix.patch )
> 
> It compiles and the test mostly work except for the callback ctypes 
> (libffi) test where it segfaults on a pyDECREFF.  Digging in, the O_get 
> call is returning a NULL pointer (and pyDECREF is understandably choking 
> on that).
> 
> Since I am very new to python, I am at a bit of a loss to tracing the C 
> code back through this particulat section of code to see why the PyOBJECT 
> isn't being assigned here.  Any help would be welomed.

One thing you might find useful is to instrument gdb to display more
information about Python objects (the opaque PyObject pointers). See:
http://docs.python.org/devguide/gdb.html

Regards

Antoine.



From barry at python.org  Mon Mar 28 19:56:17 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Mar 2011 13:56:17 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<im5akg$ptc$1@dough.gmane.org>
	<20110321122015.3add347b@limelight.wooz.org>
	<4d9008bc.04558f0a.2b7b.ffffe50b@mx.google.com>
Message-ID: <20110328135617.61e059cc@neurotica.wooz.org>

On Mar 27, 2011, at 01:39 PM, Neil Schemenauer wrote:

>Barry Warsaw <barry at python.org> wrote:
>> I'm asking because I don't know hg and git well enough to answer the
>> question.  In my own use of Bazaar over the last 4+ years, I've almost never
>> rebased or even been asked to.
>
>Maybe it depends on what kind of changes you commit.  I consider
>future maintainers the most important "customer" of the repository
>history.  As such, I try to make each commit a logical change that
>takes a working system and produces another working system.  In that
>way, each change to be potentially reversed if later on if it found
>to cause problems.  Also, ideally, each revision can be tested to
>narrow down the version where a bug was introduced.

I always try to follow TDD, so good commit points for local development
branches are places where you've fixed a broken test and done your refactoring
step.  This means that even for local lines of development, revisions should
produce workable code, although perhaps only localized to the tests being
modified.

>If you are able to directly commit A' and B' and your tool does a
>good job of hiding the logically unimportant merge then I guess you
>wouldn't miss the ability to modify history.

Right.  As Ben Finney has pointed out, Bazaar does a very good job of this, so
it's just not something a typical Bazaar user worries much about.  It's there
if you want it of course, and some projects do, but most don't bother.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110328/82bbc45d/attachment.pgp>

From g.brandl at gmx.net  Mon Mar 28 22:02:50 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 28 Mar 2011 22:02:50 +0200
Subject: [Python-Dev] [Python-checkins] cpython: Add optional *func*
	argument to itertools.accumulate().
In-Reply-To: <9E18EF69-FBFC-43C9-83E2-36F831A8FDAE@gmail.com>
References: <E1Q41cw-0006qn-De@dinsdale.python.org>
	<BANLkTina4uRMccc9vxtk8J7E0AsJ0j3bfg@mail.gmail.com>
	<AANLkTimAAWYjZKgwTc=Hv4wsJKRGAbdvbJTfNjVbn+MD@mail.gmail.com>
	<BANLkTikNMEU1ZEUGmghG7tURSDM6fY=m9Q@mail.gmail.com>
	<9E18EF69-FBFC-43C9-83E2-36F831A8FDAE@gmail.com>
Message-ID: <imqpig$g0e$1@dough.gmane.org>

On 28.03.2011 09:49, Raymond Hettinger wrote:
> 
> On Mar 28, 2011, at 12:38 AM, Daniel Stutzbach wrote:
> 
>> On Sun, Mar 27, 2011 at 10:53 PM, Nick Coghlan <ncoghlan at gmail.com
>> <mailto:ncoghlan at gmail.com>> wrote:
>>
>>     On Mon, Mar 28, 2011 at 2:11 PM, Daniel Stutzbach <stutzbach at google.com
>>     <mailto:stutzbach at google.com>> wrote:
>>     > Is there a good use-case for the func argument?
>>
>>  
>>
>>     The examples that Raymond gives in the docs (cumulative
>>     multiplication, running min/max, cash flow accumulation) look fairly
>>     solid to me.
>>
>>
>> (I had the nagging suspicion that I was making a blunder in my email, but I
>> couldn't see it despite rereading my email several times before sending.  My
>> blunder was in not rereading the patch to see the examples.  Anyway...)
>>
>> When would a running product, min, or max be useful?
> 
> There's no need to speculate.  This API has long been present in other languages
> and libraries.
> 
> Do a google code search for R's builtin functions cumsum, cumprod, cummin, and
> cummax. Look at mumpy's accumulate ufunc which works with many operators. APL
> and K also have an accumulate tool which takes arbitrary functions.

And incidentally I just could have used it myself yesterday.  So thanks for
adding it! :)

Georg


From ethan at stoneleaf.us  Mon Mar 28 22:05:26 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 28 Mar 2011 13:05:26 -0700
Subject: [Python-Dev] Issue Tracker
Message-ID: <4D90EA06.3030003@stoneleaf.us>

Greetings!

I'm not sure where the best place is to ask this question, so I'll start 
here -- feel free to redirect me if necessary.

I would like to have some software to keep track of bugs, to-do's, 
ideas, etc., etc. -- you know, an issue tracker!  Naturally I thought of 
the one we use to track Python.  Is it available?  Is it written in 
Python?  Are there any others that are recommended?

Thanks!

~Ethan~

From brian.curtin at gmail.com  Mon Mar 28 22:14:20 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Mon, 28 Mar 2011 15:14:20 -0500
Subject: [Python-Dev] Issue Tracker
In-Reply-To: <4D90EA06.3030003@stoneleaf.us>
References: <4D90EA06.3030003@stoneleaf.us>
Message-ID: <AANLkTikK=4Js-4Z2NRgmkhhkfKX_CufXTi3E0A2MhTPe@mail.gmail.com>

On Mon, Mar 28, 2011 at 15:05, Ethan Furman <ethan at stoneleaf.us> wrote:

> Greetings!
>
> I'm not sure where the best place is to ask this question, so I'll start
> here -- feel free to redirect me if necessary.
>
> I would like to have some software to keep track of bugs, to-do's, ideas,
> etc., etc. -- you know, an issue tracker!  Naturally I thought of the one we
> use to track Python.  Is it available?  Is it written in Python?  Are there
> any others that are recommended?
>
> Thanks!
>
> ~Ethan~


bugs.python.org uses http://pypi.python.org/pypi/roundup, which is written
in Python.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110328/ed7f9a81/attachment-0001.html>

From solipsis at pitrou.net  Mon Mar 28 22:31:12 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Mar 2011 22:31:12 +0200
Subject: [Python-Dev] Issue Tracker
References: <4D90EA06.3030003@stoneleaf.us>
	<AANLkTikK=4Js-4Z2NRgmkhhkfKX_CufXTi3E0A2MhTPe@mail.gmail.com>
Message-ID: <20110328223112.76482a9d@pitrou.net>

On Mon, 28 Mar 2011 15:14:20 -0500
Brian Curtin <brian.curtin at gmail.com> wrote:
> On Mon, Mar 28, 2011 at 15:05, Ethan Furman <ethan at stoneleaf.us> wrote:
> 
> > Greetings!
> >
> > I'm not sure where the best place is to ask this question, so I'll start
> > here -- feel free to redirect me if necessary.
> >
> > I would like to have some software to keep track of bugs, to-do's, ideas,
> > etc., etc. -- you know, an issue tracker!  Naturally I thought of the one we
> > use to track Python.  Is it available?  Is it written in Python?  Are there
> > any others that are recommended?
> >
> > Thanks!
> >
> > ~Ethan~
> 
> 
> bugs.python.org uses http://pypi.python.org/pypi/roundup, which is written
> in Python.

Well, don't take bugs.python.org as an example, though, since AFAIK it
is heavily modified. http://mercurial.selenic.com/bts/ and
http://psf.upfronthosting.co.za/roundup/meta/ look more like vanilla
installs.

Otherwise there's also Trac.

Regards

Antoine.



From ethan at stoneleaf.us  Mon Mar 28 22:38:44 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 28 Mar 2011 13:38:44 -0700
Subject: [Python-Dev] Issue Tracker
In-Reply-To: <AANLkTikK=4Js-4Z2NRgmkhhkfKX_CufXTi3E0A2MhTPe@mail.gmail.com>
References: <4D90EA06.3030003@stoneleaf.us>
	<AANLkTikK=4Js-4Z2NRgmkhhkfKX_CufXTi3E0A2MhTPe@mail.gmail.com>
Message-ID: <4D90F1D4.4000101@stoneleaf.us>

Brian Curtin wrote:
> On Mon, Mar 28, 2011 at 15:05, Ethan Furman <ethan at stoneleaf.us 
> <mailto:ethan at stoneleaf.us>> wrote:
> 
>     Greetings!
> 
>     I'm not sure where the best place is to ask this question, so I'll
>     start here -- feel free to redirect me if necessary.
> 
>     I would like to have some software to keep track of bugs, to-do's,
>     ideas, etc., etc. -- you know, an issue tracker!  Naturally I
>     thought of the one we use to track Python.  Is it available?  Is it
>     written in Python?  Are there any others that are recommended?
> 
>     Thanks!
> 
>     ~Ethan~
> 
> 
> bugs.python.org <http://bugs.python.org> 
> uses http://pypi.python.org/pypi/roundup, which is written in Python. 

Thank you!  That explains a lot.  (I kept wondering about the occasional 
roundup comment I would see in threads, but hadn't put it together.)

~Ethan~

From ethan at stoneleaf.us  Mon Mar 28 23:12:13 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 28 Mar 2011 14:12:13 -0700
Subject: [Python-Dev] Issue Tracker
In-Reply-To: <20110328223112.76482a9d@pitrou.net>
References: <4D90EA06.3030003@stoneleaf.us>	<AANLkTikK=4Js-4Z2NRgmkhhkfKX_CufXTi3E0A2MhTPe@mail.gmail.com>
	<20110328223112.76482a9d@pitrou.net>
Message-ID: <4D90F9AD.8010204@stoneleaf.us>

Antoine Pitrou wrote:
> On Mon, 28 Mar 2011 15:14:20 -0500
> Brian Curtin <brian.curtin at gmail.com> wrote:
>> On Mon, Mar 28, 2011 at 15:05, Ethan Furman <ethan at stoneleaf.us> wrote:
>>> I would like to have some software to keep track of bugs, to-do's, ideas,
>>> etc., etc. -- you know, an issue tracker!  Naturally I thought of the one we
>>> use to track Python.  Is it available?  Is it written in Python?  Are there
>>> any others that are recommended?
>>
>> bugs.python.org uses http://pypi.python.org/pypi/roundup, which is written
>> in Python.
> 
> Well, don't take bugs.python.org as an example, though, since AFAIK it
> is heavily modified. http://mercurial.selenic.com/bts/ and
> http://psf.upfronthosting.co.za/roundup/meta/ look more like vanilla
> installs.
> 
> Otherwise there's also Trac.

Thanks, Antoine!  I'll keep that in mind.

~Ethan~

From tjreedy at udel.edu  Mon Mar 28 23:29:38 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 28 Mar 2011 17:29:38 -0400
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>	<20110317002026.51802b86@pitrou.net>	<20110317034114.0628C24A416@kimball.webabinitio.net>	<4D8189EB.7040800@jcea.es>	<20110317051425.96F40253152@kimball.webabinitio.net>	<ilsnk6$v38$1@dough.gmane.org>	<20110317132426.2A4DC200407@kimball.webabinitio.net>	<20110317143300.73e699b6@pitrou.net>	<20110320040601.573A4D5EAB@kimball.webabinitio.net>	<20110320155235.30B81F4A1B@kimball.webabinitio.net>	<1300636439.3481.10.camel@localhost.localdomain>	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>	<imo2bp$5ok$1@dough.gmane.org>
	<AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>
Message-ID: <imquk3$gpa$1@dough.gmane.org>

On 3/28/2011 6:13 AM, Paul Moore wrote:

> This philosophy is essentially what the "mq" extension to Mercurial
> tries to capture. In mq, you maintain a series of patches "on top of"
> your repository, amending, refining and rebasing them as you wish
> until they are ready to commit, at which time you take them off the
> patch queue and convert them into final commits in the repository.

 From what you write, it seems that mq is actually an unordered patch 
set, not a queue (in the FIFO) sense. (Or do you have to commit and 
remove in FIFO order?) Why the confusing mislabel, if indeed I 
understood correctly?

-- 
Terry Jan Reedy


From p.f.moore at gmail.com  Mon Mar 28 23:41:31 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 28 Mar 2011 22:41:31 +0100
Subject: [Python-Dev] Hg: inter-branch workflow
In-Reply-To: <imquk3$gpa$1@dough.gmane.org>
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<imo2bp$5ok$1@dough.gmane.org>
	<AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>
	<imquk3$gpa$1@dough.gmane.org>
Message-ID: <AANLkTi=R69jwkx_YJkiJWjQma4O6fKFfDv8RA6aLt2wC@mail.gmail.com>

On 28 March 2011 22:29, Terry Reedy <tjreedy at udel.edu> wrote:
> From what you write, it seems that mq is actually an unordered patch set,
> not a queue (in the FIFO) sense. (Or do you have to commit and remove in
> FIFO order?) Why the confusing mislabel, if indeed I understood correctly?

It's a queue (FIFO). Sorry if my description was misleading - I don't
use mq much myself. (There are ways of reordering patches, but that's
advanced use of an already-advanced feature...)

Paul.

From stutzbach at google.com  Tue Mar 29 00:51:56 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Mon, 28 Mar 2011 15:51:56 -0700
Subject: [Python-Dev] [Python-checkins] cpython: Add optional *func*
 argument to itertools.accumulate().
In-Reply-To: <9E18EF69-FBFC-43C9-83E2-36F831A8FDAE@gmail.com>
References: <E1Q41cw-0006qn-De@dinsdale.python.org>
	<BANLkTina4uRMccc9vxtk8J7E0AsJ0j3bfg@mail.gmail.com>
	<AANLkTimAAWYjZKgwTc=Hv4wsJKRGAbdvbJTfNjVbn+MD@mail.gmail.com>
	<BANLkTikNMEU1ZEUGmghG7tURSDM6fY=m9Q@mail.gmail.com>
	<9E18EF69-FBFC-43C9-83E2-36F831A8FDAE@gmail.com>
Message-ID: <BANLkTimtfEyrn8Dr4G0faroDYzzZ-ejmUw@mail.gmail.com>

On Mon, Mar 28, 2011 at 12:49 AM, Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:

> Do a google code search for R's builtin functions cumsum, cumprod, cummin,
> and cummax. Look at mumpy's accumulate ufunc which works with many
> operators. APL and K also have an accumulate tool which takes arbitrary
> functions.
>

Thanks.  I had not been thinking along numeric lines.  I can see how these
would be useful for working with matrices, vectors, and similar constructs.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110328/0272073c/attachment.html>

From ben+python at benfinney.id.au  Tue Mar 29 01:44:28 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 29 Mar 2011 10:44:28 +1100
Subject: [Python-Dev] Hg: inter-branch workflow
References: <A755A9A5-4C99-4AEF-BA4D-77F6FE065A34@gmail.com>
	<20110317002026.51802b86@pitrou.net>
	<20110317034114.0628C24A416@kimball.webabinitio.net>
	<4D8189EB.7040800@jcea.es>
	<20110317051425.96F40253152@kimball.webabinitio.net>
	<ilsnk6$v38$1@dough.gmane.org>
	<20110317132426.2A4DC200407@kimball.webabinitio.net>
	<20110317143300.73e699b6@pitrou.net>
	<20110320040601.573A4D5EAB@kimball.webabinitio.net>
	<20110320155235.30B81F4A1B@kimball.webabinitio.net>
	<1300636439.3481.10.camel@localhost.localdomain>
	<AANLkTinPdz8JkcyY_nXxgsQaReaPWosnvJg5syGtoSpL@mail.gmail.com>
	<imo2bp$5ok$1@dough.gmane.org>
	<AANLkTikFDS=b3jfyEhJ1-9LP_MMsmGD+S5KywZe3MSY8@mail.gmail.com>
	<AANLkTim_fR9FRKEZ2GVruiUw+vWvbe2Eb1jBop=uZXbk@mail.gmail.com>
	<4D908383.2070505@voidspace.org.uk>
Message-ID: <877hbiresj.fsf@benfinney.id.au>

Michael Foord <fuzzyman at voidspace.org.uk> writes:

> On 28/03/2011 11:35, Nick Coghlan wrote:
> > I'm seeing if I can get the best of both worlds by having a public
> > sandbox repo where I work on things (which has the full messy
> > history of development on its feature branches), and then just drop
> > them into the main repo as coherent patches. Once I land a patch,
> > I'll close the original feature branch in the sandbox, so merge
> > conflicts won't be an issue.

Yes, using Bazaar I get something similar by nominating one of my
branches (often named ?devel?) as the integration branch.

All commit-often work is done on feature branches, with all the warts
exposed. Merges into the integration branch are accompanied by a
high-level commit message summarising the changes of interest to
whomever follows that branch.

Patches upstream, in the cases where upstream is not using Bazaar, are
made from the integration branch with their useful-to-others diff and
commit message.

> For any non-trivial work I think this is the best approach. You still
> get all the advantages of working with mercurial (able to commit
> frequently) without polluting the history of the core repository.
>
> It has the major advantage of also being very simple to understand.

I'm glad others have come to a similar conclusion. Perhaps the Python
developers can encourage the Mercurial developers to make this workflow
more obvious to new users?

-- 
 \      ?My interest is in the future, as I am going to spend the rest |
  `\                          of my life there.? ?Charles F. Kettering |
_o__)                                                                  |
Ben Finney


From rdmurray at bitdance.com  Tue Mar 29 03:37:56 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 28 Mar 2011 21:37:56 -0400
Subject: [Python-Dev] Issue Tracker
In-Reply-To: <20110328223112.76482a9d@pitrou.net>
References: <4D90EA06.3030003@stoneleaf.us>
	<AANLkTikK=4Js-4Z2NRgmkhhkfKX_CufXTi3E0A2MhTPe@mail.gmail.com>
	<20110328223112.76482a9d@pitrou.net>
Message-ID: <20110329013756.99EB8D64A7@kimball.webabinitio.net>

On Mon, 28 Mar 2011 22:31:12 +0200, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 28 Mar 2011 15:14:20 -0500
> Brian Curtin <brian.curtin at gmail.com> wrote:
> > On Mon, Mar 28, 2011 at 15:05, Ethan Furman <ethan at stoneleaf.us> wrote:
> > > I would like to have some software to keep track of bugs, to-do's, ideas,
> > > etc., etc. -- you know, an issue tracker!  Naturally I thought of the one we
> > > use to track Python.  Is it available?  Is it written in Python?  Are there
> > > any others that are recommended?
> > 
> > bugs.python.org uses http://pypi.python.org/pypi/roundup, which is written
> > in Python.
> 
> Well, don't take bugs.python.org as an example, though, since AFAIK it
> is heavily modified. http://mercurial.selenic.com/bts/ and
> http://psf.upfronthosting.co.za/roundup/meta/ look more like vanilla
> installs.

Roundup is wonderfully customizable.  It's not hard to do, either,
(though of course there is a learning curve).  I built an issue
tracker for my business with per-customer queues, consultant logins,
and time tracking in about two days of work starting from vanilla
roundup.

The hardest part is debugging the TAL when you make a mistake, but
even that isn't a whole lot worse than any other templating language.

--
R. David Murray           http://www.bitdance.com

From tleeuwenburg at gmail.com  Tue Mar 29 12:01:36 2011
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Tue, 29 Mar 2011 03:01:36 -0700
Subject: [Python-Dev] Information about how cpython in benchmarked
Message-ID: <AANLkTikDt9fOwf0WGQSSqs7O09EL_Vu6OTUZHJdhhbL9@mail.gmail.com>

Hi all,

Apologies for emailing this list with such an apparently trivial question.
Is there some source of documentation or information on how Python is
benchmarked? I am aware of the Python regression testing module,
regrtest.py, which I presume, if profiled, would good be a good baseline
test.

PyPy maintains http://speed.pypy.org/, which provides very clear information
about the relative performance of PyPy trunk against some version of cpython
(presumably 2.6 or 2.7). I'm not aware of a similar site for cpython, but
that could easily just be my ignorance speaking.

My interest is that I'm looking at building a benchmarking solution at work.
and I can't think of a better way to build something good and general than
to try and write something that could potentially be released as open source
and be useful to others. As such I thought that benchmarking cpython would
be a great use case, but I want to find out as much as I can about how
people currently go about benchmarking Python. Initially I'm just looking at
CPU profiling since it's easiest.

Anyway, if this is the wrong place to send this email, I'm very sorry for
clogging up your inbox.

Thanks very much,
-Tennessee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110329/82ffed00/attachment.html>

From ncoghlan at gmail.com  Tue Mar 29 13:00:44 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 29 Mar 2011 21:00:44 +1000
Subject: [Python-Dev] Information about how cpython in benchmarked
In-Reply-To: <AANLkTikDt9fOwf0WGQSSqs7O09EL_Vu6OTUZHJdhhbL9@mail.gmail.com>
References: <AANLkTikDt9fOwf0WGQSSqs7O09EL_Vu6OTUZHJdhhbL9@mail.gmail.com>
Message-ID: <AANLkTimTLv7qrO0q7fZWK0kTCUc2dgJNzHi18PozwOUv@mail.gmail.com>

On Tue, Mar 29, 2011 at 8:01 PM, Tennessee Leeuwenburg
<tleeuwenburg at gmail.com> wrote:
> PyPy maintains?http://speed.pypy.org/, which provides very clear information
> about the relative performance of PyPy trunk against some version of cpython
> (presumably 2.6 or 2.7). I'm not aware of a similar site for cpython, but
> that could easily just be my ignorance speaking.
> My interest is that I'm looking at building a benchmarking solution at work.
> and I can't think of a better way to build something good and general than
> to try and write something that could potentially be released as open source
> and be useful to others. As such I thought that benchmarking cpython would
> be a great use case, but I want to find out as much as I can about how
> people currently go about benchmarking Python. Initially I'm just looking at
> CPU profiling since it's easiest.

One of the points coming out of the VM summit at Pycon is actually
that we want to create a shared benchmarking site for CPython, PyPy,
Jython, IronPython (and possibly Stackless) under the python.org
banner (either speed.python.org, or possibly performance.python.org,
since we want to do memory profiling as well).

speed.pypy.org will be the reference site for this, but Maciej
indicated at the VM summit that the code that runs that site needs
some improvements before it will really be up to the task of
effectively benchmarking multiple targets.

So, according to http://speed.pypy.org/about/, the place to start with
your benchmarking system would probably be
https://github.com/tobami/codespeed.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From jnoller at gmail.com  Tue Mar 29 13:47:47 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Tue, 29 Mar 2011 07:47:47 -0400
Subject: [Python-Dev] Information about how cpython in benchmarked
In-Reply-To: <AANLkTimTLv7qrO0q7fZWK0kTCUc2dgJNzHi18PozwOUv@mail.gmail.com>
References: <AANLkTikDt9fOwf0WGQSSqs7O09EL_Vu6OTUZHJdhhbL9@mail.gmail.com>
	<AANLkTimTLv7qrO0q7fZWK0kTCUc2dgJNzHi18PozwOUv@mail.gmail.com>
Message-ID: <BANLkTikFTAtjrW=WfEAPM9oS+kpo5_Z2pw@mail.gmail.com>

On Tue, Mar 29, 2011 at 7:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Mar 29, 2011 at 8:01 PM, Tennessee Leeuwenburg
> <tleeuwenburg at gmail.com> wrote:
>> PyPy maintains?http://speed.pypy.org/, which provides very clear information
>> about the relative performance of PyPy trunk against some version of cpython
>> (presumably 2.6 or 2.7). I'm not aware of a similar site for cpython, but
>> that could easily just be my ignorance speaking.
>> My interest is that I'm looking at building a benchmarking solution at work.
>> and I can't think of a better way to build something good and general than
>> to try and write something that could potentially be released as open source
>> and be useful to others. As such I thought that benchmarking cpython would
>> be a great use case, but I want to find out as much as I can about how
>> people currently go about benchmarking Python. Initially I'm just looking at
>> CPU profiling since it's easiest.
>
> One of the points coming out of the VM summit at Pycon is actually
> that we want to create a shared benchmarking site for CPython, PyPy,
> Jython, IronPython (and possibly Stackless) under the python.org
> banner (either speed.python.org, or possibly performance.python.org,
> since we want to do memory profiling as well).
>
> speed.pypy.org will be the reference site for this, but Maciej
> indicated at the VM summit that the code that runs that site needs
> some improvements before it will really be up to the task of
> effectively benchmarking multiple targets.
>
> So, according to http://speed.pypy.org/about/, the place to start with
> your benchmarking system would probably be
> https://github.com/tobami/codespeed.
>
> Cheers,
> Nick.

Essentially echoing what nick said. I'm currently working on getting
the HW for this together.

From skip at pobox.com  Tue Mar 29 18:17:00 2011
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 29 Mar 2011 11:17:00 -0500
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <4D91FA72.3070504@jmunch.dk>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<4D8F820A.5010200@v.loewis.de>
	<19855.35759.729216.533872@montanaro.dyndns.org>
	<4D91FA72.3070504@jmunch.dk>
Message-ID: <19858.1532.530002.847055@montanaro.dyndns.org>


    >> I guess I have my work cut out for me.  It appears my preferred mail
    >> reader, VM, is not supported out-of-the-box by GNU Emacs (they still
    >> use Rmail and Babyl for some reason), and I'm not sure the investment
    >> trying to get XEmacs built with MULE is worth the effort.

    Anders> Use a 21.5 beta of XEmacs instead of 21.4, 21.5 deals with utf-8
    Anders> quite well.

Thanks for the various responses, both public and private.  In part because
Barry made the leap back from XEmacs to GNU Emacs (and I trust Barry in all
things Emacs), I decided to dip my toe back into the GNU water.  I needed to
install a recent version of VM, but it does do utf-8, so my original problem
is solved.  In response to Anders, I had tried 21.5b28 awhile ago but backed
off from it.  I no longer recall why.

My only issues now are:

 * make sure the ediff and vc packages recognize version-controlled files
   (It seems they do, but I haven't put them through their paces)

 * replace the GNU python.el with python-mode.el from the python-mode
   project (formerly distributed with Python, but now all grown up and moved
   away).

Skip

From 2011 at jmunch.dk  Tue Mar 29 17:27:46 2011
From: 2011 at jmunch.dk (Anders J. Munch)
Date: Tue, 29 Mar 2011 17:27:46 +0200
Subject: [Python-Dev] utf-8 encoding in checkins?
In-Reply-To: <19855.35759.729216.533872@montanaro.dyndns.org>
References: <19855.21129.360534.876590@montanaro.dyndns.org>	<4D8F820A.5010200@v.loewis.de>
	<19855.35759.729216.533872@montanaro.dyndns.org>
Message-ID: <4D91FA72.3070504@jmunch.dk>

skip at pobox.com wrote:
> I guess I have my work cut out for me.  It appears my preferred mail reader,
> VM, is not supported out-of-the-box by GNU Emacs (they still use Rmail and
> Babyl for some reason), and I'm not sure the investment trying to get XEmacs
> built with MULE is worth the effort.

Use a 21.5 beta of XEmacs instead of 21.4, 21.5 deals with utf-8 quite well.

- Anders


From vinay_sajip at yahoo.co.uk  Tue Mar 29 18:35:08 2011
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Tue, 29 Mar 2011 16:35:08 +0000 (UTC)
Subject: [Python-Dev] Proposed change to logging.basicConfig
Message-ID: <loom.20110329T182724-83@post.gmane.org>

I'm planning a change to logging.basicConfig to add an optional "handlers"
keyword argument which defaults to None.

If specified, this should be an iterable of already created handlers, which will
be added to the root logger (if it doesn't already have any handlers). Any
handler in the iterable which does not have a formatter assigned will be
assigned the formatter created by basicConfig.

If "handlers" is specified, the "stream", "filename" and "filemode" arguments
will be ignored.

If any of you can see any problems with this change, or can suggest any
improvement to the approach, please respond. I expect to check this change in
within the next few days.

Regards,

Vinay Sajip



From solipsis at pitrou.net  Tue Mar 29 18:41:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 29 Mar 2011 18:41:25 +0200
Subject: [Python-Dev] Proposed change to logging.basicConfig
References: <loom.20110329T182724-83@post.gmane.org>
Message-ID: <20110329184125.17717ffc@pitrou.net>

On Tue, 29 Mar 2011 16:35:08 +0000 (UTC)
Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> I'm planning a change to logging.basicConfig to add an optional "handlers"
> keyword argument which defaults to None.
> 
> If specified, this should be an iterable of already created handlers, which will
> be added to the root logger (if it doesn't already have any handlers). Any
> handler in the iterable which does not have a formatter assigned will be
> assigned the formatter created by basicConfig.
> 
> If "handlers" is specified, the "stream", "filename" and "filemode" arguments
> will be ignored.
> 
> If any of you can see any problems with this change, or can suggest any
> improvement to the approach, please respond.

I'm not a logging expert, but the fact that your description above
mentions at least two instances of special-casing make it sound like
the API has an usability (or learnability) problem.

Regards

Antoine.



From michael at voidspace.org.uk  Tue Mar 29 20:23:25 2011
From: michael at voidspace.org.uk (Michael Foord)
Date: Tue, 29 Mar 2011 19:23:25 +0100
Subject: [Python-Dev] Security implications of pep 383
Message-ID: <4D92239D.5070908@voidspace.org.uk>

Hey all,

Not sure how real the security risk is here:

     http://blog.omega-prime.co.uk/?p=107

Basically  he is saying that if you store a list of blacklisted files 
with names encoded in big-5 (or some other non-utf8 compatible encoding) 
if those names are passed at the command line, or otherwise read in and 
decoded from an assumed-utf8 source with surrogate escaping, the 
surrogate escape decoded names will not match the properly decoded 
blacklisted names.

All the best,

Michael Foord

-- 
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


From tjreedy at udel.edu  Tue Mar 29 20:48:56 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 29 Mar 2011 14:48:56 -0400
Subject: [Python-Dev] Proposed change to logging.basicConfig
In-Reply-To: <loom.20110329T182724-83@post.gmane.org>
References: <loom.20110329T182724-83@post.gmane.org>
Message-ID: <imt9in$9u6$1@dough.gmane.org>

On 3/29/2011 12:35 PM, Vinay Sajip wrote:
> I'm planning a change to logging.basicConfig to add an optional "handlers"
> keyword argument which defaults to None.
>
> If specified, this should be an iterable of already created handlers, which will
> be added to the root logger (if it doesn't already have any handlers). Any
> handler in the iterable which does not have a formatter assigned will be
> assigned the formatter created by basicConfig.
>
> If "handlers" is specified, the "stream", "filename" and "filemode" arguments
> will be ignored.
>
> If any of you can see any problems with this change, or can suggest any
> improvement to the approach, please respond. I expect to check this change in
> within the next few days.

I am bothered by mutually exclusive parameters. This is one reason I was 
glad to see cmp eliminated from list.sort. Quick: what happens if one 
passes both cmp and key to list.sort? There are three reasonable 
possibilities. As far as I can read, the answer is not documented.#

I am not familiar with logging, but I wonder if you should have two 
functions for the two quite different signatures. If not, I think the 
result of passing conflicting parameters should be something like 
TypeError: conflicting parameters passed. "In the face of ambiguity, 
refuse to guess."

# Experiment with 2.7 shows that cmp wins. Though too late to change, I 
consider this the worst choice of three. I think an exception should be 
raised. Failing that, I think key should win on the basis that if one 
adds a 'new-fangled' key func to an existing call with cmp (and forgets 
to remove cmp), the key func is the one intended. Also, the doc clearly 
indicates that key is considered superior to cmp.

-- 
Terry Jan Reedy


From solipsis at pitrou.net  Tue Mar 29 20:53:39 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 29 Mar 2011 20:53:39 +0200
Subject: [Python-Dev] Security implications of pep 383
References: <4D92239D.5070908@voidspace.org.uk>
Message-ID: <20110329205339.6fa59ec1@pitrou.net>

On Tue, 29 Mar 2011 19:23:25 +0100
Michael Foord <michael at voidspace.org.uk> wrote:
> Hey all,
> 
> Not sure how real the security risk is here:
> 
>      http://blog.omega-prime.co.uk/?p=107
> 
> Basically  he is saying that if you store a list of blacklisted files 
> with names encoded in big-5 (or some other non-utf8 compatible encoding) 
> if those names are passed at the command line, or otherwise read in and 
> decoded from an assumed-utf8 source with surrogate escaping, the 
> surrogate escape decoded names will not match the properly decoded 
> blacklisted names.

This has nothing to do specifically with PEP 383. The same issues can
arise without PEP 383 if you replace utf-8 with, say, latin-1 in the
above example.

Basically, what this says is if you are decoding the same bytestring
using two different encodings, you get two different unicode strings
(which therefore compare unequal).

Another observation is that, in the script which is presented, if the
user were to extract a filename from the blacklist and call open() on
it, they wouldn't actually open one of the blacklisted files, since the
encoded representation using the filesystem encoding (e.g. utf-8 or
latin-1) would be different from the Big-5 representation.

A solution would be to open the blacklist file in binary mode and call
os.fsdecode() on the result.

Regards

Antoine.



From martin at v.loewis.de  Tue Mar 29 20:56:41 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 29 Mar 2011 20:56:41 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <4D92239D.5070908@voidspace.org.uk>
References: <4D92239D.5070908@voidspace.org.uk>
Message-ID: <4D922B69.1010102@v.loewis.de>

> Not sure how real the security risk is here:
> 
>     http://blog.omega-prime.co.uk/?p=107
> 
> Basically  he is saying that if you store a list of blacklisted files
> with names encoded in big-5 (or some other non-utf8 compatible encoding)
> if those names are passed at the command line, or otherwise read in and
> decoded from an assumed-utf8 source with surrogate escaping, the
> surrogate escape decoded names will not match the properly decoded
> blacklisted names.

As described, I find the problem a little bit artificial: supposedly,
he was passing the file name on the command line. However, since his
terminal is in UTF-8 and the file name in Big5, the console didn't
display the file name in a meaningful way when he ran the program. So
whoever ran the program ignored the moji-bake, and didn't wonder whether
it could have any effect on proper functioning of the program. In
addition, if he did ls(1) on the directory, it would have displayed
question marks throughout. This should alert the user that something bad
is going on.

Notice that this isn't really PEP-383's fault. If the file system
encoding was UTF-8, and the blacklist was UTF-8, and the program
ran in a Latin-1 locale, it would have decoded the file name nicely
(without surrogates), but the blacklist check would still have failed.

He should have opened the file in the locale's encoding (i.e. giving no
encoding), using the surrogate escape handler.

Regards,
Martin

From merwok at netwok.org  Tue Mar 29 21:02:35 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 29 Mar 2011 21:02:35 +0200
Subject: [Python-Dev] [Python-checkins] cpython (2.6): Issue #11639:
 Configuration function documentation	referred to logging.XXX
In-Reply-To: <E1Q4McA-0002dT-Va@dinsdale.python.org>
References: <E1Q4McA-0002dT-Va@dinsdale.python.org>
Message-ID: <4D922CCB.1060408@netwok.org>

Le 29/03/2011 02:16, vinay.sajip a ?crit :
> http://hg.python.org/cpython/rev/bfa2a8d91859
> changeset:   69034:bfa2a8d91859
> branch:      2.6
> parent:      68802:b99c94261225
> user:        Vinay Sajip <vinay_sajip at yahoo.co.uk>
> date:        Tue Mar 29 01:07:50 2011 +0100
> summary:
>   Issue #11639: Configuration function documentation referred to logging.XXX rather than logging.config.XXX.

Only security fixes should go into 2.5 and 2.6.  Could you revert (hg
backout) this changeset?

Regards

From lac at openend.se  Tue Mar 29 21:06:45 2011
From: lac at openend.se (Laura Creighton)
Date: Tue, 29 Mar 2011 21:06:45 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: Message from Michael Foord <michael@voidspace.org.uk> 
	of "Tue, 29 Mar 2011 19:23:25 BST." <4D92239D.5070908@voidspace.org.uk> 
References: <4D92239D.5070908@voidspace.org.uk> 
Message-ID: <201103291906.p2TJ6jbY024137@theraft.openend.se>

In a message of Tue, 29 Mar 2011 19:23:25 BST, Michael Foord writes:
>Hey all,
>
>Not sure how real the security risk is here:
>
>     http://blog.omega-prime.co.uk/?p=107
>
>Basically  he is saying that if you store a list of blacklisted files 
>with names encoded in big-5 (or some other non-utf8 compatible encoding) 
>if those names are passed at the command line, or otherwise read in and 
>decoded from an assumed-utf8 source with surrogate escaping, the 
>surrogate escape decoded names will not match the properly decoded 
>blacklisted names.

>All the best,
>
>Michael Foord
>

I am not sure there are any security related gotchas here.  All he is
saying is that if you decode the same bytestring using two different
encodings, you will get two different unicode strings (which therefore
will compare unequal).  Where's the problem, except in that you might
have unrealistic expectations?

Laura

From a.badger at gmail.com  Tue Mar 29 21:10:58 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 29 Mar 2011 12:10:58 -0700
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <4D92239D.5070908@voidspace.org.uk>
References: <4D92239D.5070908@voidspace.org.uk>
Message-ID: <20110329191058.GJ3698@unaka.lan>

On Tue, Mar 29, 2011 at 07:23:25PM +0100, Michael Foord wrote:
> Hey all,
> 
> Not sure how real the security risk is here:
> 
>     http://blog.omega-prime.co.uk/?p=107
> 
> Basically  he is saying that if you store a list of blacklisted files
> with names encoded in big-5 (or some other non-utf8 compatible
> encoding) if those names are passed at the command line, or otherwise
> read in and decoded from an assumed-utf8 source with surrogate
> escaping, the surrogate escape decoded names will not match the
> properly decoded blacklisted names.
> 
The example is correct.  The security risk is real.  However, there's a flaw
in the program and whether the question of whether there's also a flaw in
python is not so certain.

Here's the line I'd say is contentious::
  blacklist = open("blacklist.big5", encoding='big5').read().split()

The blacklist file contains a list of filenames.  However, this code treats
it as a list of strings.  This a logic error in the program, and he should
really be doing this::
  blacklist = open("blacklist.big5", 'rb').read().split()

Then, when comparing it against the values of sys.argv, either sys.argv gets
converted into bytes (using the system locale since that's what was used to
encode to unicode) or the items in blacklist get converted to unicode with
surrogateescape.

The possible flaw in python is this:  Code like the blog poster wrote passes
python3 without an error or a warning.  This gives the programmer no
feedback that they're doing something wrong until it actually bites them in
the foot in deployed code.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110329/8bbdc9e1/attachment.pgp>

From matthew at woodcraft.me.uk  Tue Mar 29 22:02:45 2011
From: matthew at woodcraft.me.uk (Matthew Woodcraft)
Date: Tue, 29 Mar 2011 20:02:45 +0000 (UTC)
Subject: [Python-Dev] Proposed change to logging.basicConfig
References: <loom.20110329T182724-83@post.gmane.org>
	<imt9in$9u6$1@dough.gmane.org>
Message-ID: <imtdt5$vll$1@dough.gmane.org>

Terry Reedy  <tjreedy at udel.edu> wrote:
> I am bothered by mutually exclusive parameters. This is one reason I was
> glad to see cmp eliminated from list.sort. Quick: what happens if one
> passes both cmp and key to list.sort? There are three reasonable
> possibilities. As far as I can read, the answer is not documented.#

> # Experiment with 2.7 shows that cmp wins. Though too late to change, I
> consider this the worst choice of three. I think an exception should be
> raised. Failing that, I think key should win on the basis that if one
> adds a 'new-fangled' key func to an existing call with cmp (and forgets
> to remove cmp), the key func is the one intended. Also, the doc clearly
> indicates that key is considered superior to cmp.

Neither 'wins': cmp is applied to the output of key.

I agree that it would have been worth documenting this explicitly.

-M-


From roundup-admin at psf.upfronthosting.co.za  Tue Mar 29 22:10:55 2011
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Tue, 29 Mar 2011 20:10:55 +0000
Subject: [Python-Dev] Failed issue tracker submission
Message-ID: <20110329201055.BE7561DEB2@psf.upfronthosting.co.za>



The node specified by the designator in the subject of your message
("22663") does not exist.

Subject was: "[issue22663]"



Mail Gateway Help
=================
Incoming messages are examined for multiple parts:
 . In a multipart/mixed message or part, each subpart is extracted and
   examined. The text/plain subparts are assembled to form the textual
   body of the message, to be stored in the file associated with a "msg"
   class node. Any parts of other types are each stored in separate files
   and given "file" class nodes that are linked to the "msg" node.
 . In a multipart/alternative message or part, we look for a text/plain
   subpart and ignore the other parts.

Summary
-------
The "summary" property on message nodes is taken from the first non-quoting
section in the message body. The message body is divided into sections by
blank lines. Sections where the second and all subsequent lines begin with
a ">" or "|" character are considered "quoting sections". The first line of
the first non-quoting section becomes the summary of the message.

Addresses
---------
All of the addresses in the To: and Cc: headers of the incoming message are
looked up among the user nodes, and the corresponding users are placed in
the "recipients" property on the new "msg" node. The address in the From:
header similarly determines the "author" property of the new "msg"
node. The default handling for addresses that don't have corresponding
users is to create new users with no passwords and a username equal to the
address. (The web interface does not permit logins for users with no
passwords.) If we prefer to reject mail from outside sources, we can simply
register an auditor on the "user" class that prevents the creation of user
nodes with no passwords.

Actions
-------
The subject line of the incoming message is examined to determine whether
the message is an attempt to create a new item or to discuss an existing
item. A designator enclosed in square brackets is sought as the first thing
on the subject line (after skipping any "Fwd:" or "Re:" prefixes).

If an item designator (class name and id number) is found there, the newly
created "msg" node is added to the "messages" property for that item, and
any new "file" nodes are added to the "files" property for the item.

If just an item class name is found there, we attempt to create a new item
of that class with its "messages" property initialized to contain the new
"msg" node and its "files" property initialized to contain any new "file"
nodes.

Triggers
--------
Both cases may trigger detectors (in the first case we are calling the
set() method to add the message to the item's spool; in the second case we
are calling the create() method to create a new node). If an auditor raises
an exception, the original message is bounced back to the sender with the
explanatory message given in the exception.

$Id: mailgw.py,v 1.196 2008-07-23 03:04:44 richard Exp $
-------------- next part --------------
Return-Path: <python-dev at python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
	by psf.upfronthosting.co.za (Postfix) with ESMTPS id 7DCEE1DEB0
	for <report at bugs.python.org>; Tue, 29 Mar 2011 22:10:55 +0200 (CEST)
Received: from albatross.python.org (localhost [127.0.0.1])
	by mail.python.org (Postfix) with ESMTP id 3PzjsW1q1lz7Lmy
	for <report at bugs.python.org>; Tue, 29 Mar 2011 22:10:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
	t=1301429455; bh=WYL3NF6gQtbDZ+R9KxXHGS2PSlCAxyY+EQEgb/Yw5jI=;
	h=Date:Message-Id:Content-Type:MIME-Version:
	 Content-Transfer-Encoding:From:To:Subject;
	b=RiMAivS4Shae7bPg7E7SocheqYB9pzk/Svimv+qumX5arnUaaC8h9iIJo8MFDcDdi
	 +Wk0XzTjTjKsbobrKgZnfZf9a8j6Fv4Ym1nTyTcPcyjCMritjq9xNUluVQvHv/Vn2e
	 RhpV2FUWOdCtBx83eUopMPGEEEwABnbG5ZwgsDzM=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
  by albatross.python.org with SMTP; 29 Mar 2011 22:10:55 +0200
Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.python.org (Postfix) with ESMTPS
	for <report at bugs.python.org>; Tue, 29 Mar 2011 22:10:55 +0200 (CEST)
Received: from localhost
	([127.0.0.1] helo=dinsdale.python.org ident=hg)
	by dinsdale.python.org with esmtp (Exim 4.72)
	(envelope-from <python-dev at python.org>)
	id 1Q4fFf-00023G-4C
	for report at bugs.python.org; Tue, 29 Mar 2011 22:10:55 +0200
Date: Tue, 29 Mar 2011 22:10:55 +0200
Message-Id: <E1Q4fFf-00023G-4C at dinsdale.python.org>
Content-Type: text/plain; charset="utf8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
From: python-dev at python.org
To: report at bugs.python.org
Subject: [issue22663]

TmV3IGNoYW5nZXNldCBkZDg1MmEwZjkyZDYgYnkgZ3VpZG8gaW4gYnJhbmNoICcyLjUnOgpJc3N1
ZSAyMjY2MzogZml4IHJlZGlyZWN0IHZ1bG5lcmFiaWxpdHkgaW4gdXJsbGliL3VybGxpYjIuCmh0
dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2L2RkODUyYTBmOTJkNgo=

From victor.stinner at haypocalc.com  Tue Mar 29 22:23:14 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Tue, 29 Mar 2011 22:23:14 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <4D92239D.5070908@voidspace.org.uk>
References: <4D92239D.5070908@voidspace.org.uk>
Message-ID: <1301430194.30032.9.camel@marge>

Le mardi 29 mars 2011 ? 19:23 +0100, Michael Foord a ?crit :
> Hey all,
> 
> Not sure how real the security risk is here:
> 
>      http://blog.omega-prime.co.uk/?p=107
> 
> Basically  he is saying that if you store a list of blacklisted files 
> with names encoded in big-5 (or some other non-utf8 compatible encoding) 
> if those names are passed at the command line, or otherwise read in and 
> decoded from an assumed-utf8 source with surrogate escaping, the 
> surrogate escape decoded names will not match the properly decoded 
> blacklisted names.

Yes, if you decode two byte strings from two different encodings, you
get different unicode strings. It's not related to surrogateescape (PEP
383).

Sorry, '\u4f60\u597d'.encode('big5').decode('latin1') doesn't give you
'\u4f60\u597d' but '?A?n', and it doesn't warn you that latin1 is not
big5 (there is no UnicodeEncodeError, even if the error handler is
strict).

I think that the example has two issues:

 - security using blacklists doesn't work (it is better to use 
   a whitelist)
 - if filenames are stored as Big5, they must be decoded from Big5,
   and so the locale encoding must be Big5

I don't understand the last paragraph:

"P.P.S I will further note that you get the same issue even if the
blacklist and filename had been in UTF-8, but this time it gets broken
from a terminal in the Big5 locale. I didn?t show it this way around
because I understand that Python 3 may only have just recently started
using the locale to decode argv, rather than being hardcoded to UTF-8."

Python filesystem encoding is only hardcoded to UTF-8 on Mac OS X, on
other operating systems, it is the locale encoding.

Victor


From regebro at gmail.com  Tue Mar 29 22:45:43 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 29 Mar 2011 22:45:43 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
References: <4D92239D.5070908@voidspace.org.uk>
	<1301430194.30032.9.camel@marge>
	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
Message-ID: <AANLkTi=s+tPTD4dZoSiQq+CB66T2L5J0bHuCO_QBCNKN@mail.gmail.com>

On Tue, Mar 29, 2011 at 22:40, Lennart Regebro <regebro at gmail.com> wrote:
> The lesson here seems to be "if you have to use blacklists, and you
> use unicode strings for those blacklists, also make sure the string
> you compare with doesn't have surrogates".
>

For that matter, what happens with combining characters?

'\N{LATIN SMALL LETTER O}\N{COMBINING DIAERESIS}' != '\N{LATIN SMALL
LETTER O WITH DIAERESIS}'

I guess the filesystem shouldn't treat these as the same (even though
they are), but what if some webservice does? I suspect you should
normalize both strings before comparing them in any blacklist, and
what happens with surrogates when you normalize?

//Lennart

From regebro at gmail.com  Tue Mar 29 22:40:01 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 29 Mar 2011 22:40:01 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <1301430194.30032.9.camel@marge>
References: <4D92239D.5070908@voidspace.org.uk>
	<1301430194.30032.9.camel@marge>
Message-ID: <AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>

The lesson here seems to be "if you have to use blacklists, and you
use unicode strings for those blacklists, also make sure the string
you compare with doesn't have surrogates".

//Lennart

From victor.stinner at haypocalc.com  Tue Mar 29 22:55:47 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Tue, 29 Mar 2011 22:55:47 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
References: <4D92239D.5070908@voidspace.org.uk>
	<1301430194.30032.9.camel@marge>
	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
Message-ID: <1301432147.30032.14.camel@marge>

Le mardi 29 mars 2011 ? 22:40 +0200, Lennart Regebro a ?crit :
> The lesson here seems to be "if you have to use blacklists, and you
> use unicode strings for those blacklists, also make sure the string
> you compare with doesn't have surrogates".

No. '\u4f60\u597d'.encode('big5').decode('latin1') gives '?A?n' which
doesn't contain any surrogate character.

The lesson is: if you compare Unicode filenames on UNIX, make sure that
your system is correctly configured (the locale encoding must be the
filesystem encoding).

Victor


From solipsis at pitrou.net  Tue Mar 29 22:56:27 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 29 Mar 2011 22:56:27 +0200
Subject: [Python-Dev] Security implications of pep 383
References: <4D92239D.5070908@voidspace.org.uk>
	<1301430194.30032.9.camel@marge>
	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
Message-ID: <20110329225627.597c96ce@pitrou.net>

On Tue, 29 Mar 2011 22:40:01 +0200
Lennart Regebro <regebro at gmail.com> wrote:
> The lesson here seems to be "if you have to use blacklists, and you
> use unicode strings for those blacklists, also make sure the string
> you compare with doesn't have surrogates".

Not really. As everyone said, this can happen even without surrogates.

Regards

Antoine.



From victor.stinner at haypocalc.com  Tue Mar 29 23:02:47 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Tue, 29 Mar 2011 23:02:47 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <AANLkTi=s+tPTD4dZoSiQq+CB66T2L5J0bHuCO_QBCNKN@mail.gmail.com>
References: <4D92239D.5070908@voidspace.org.uk>
	<1301430194.30032.9.camel@marge>
	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
	<AANLkTi=s+tPTD4dZoSiQq+CB66T2L5J0bHuCO_QBCNKN@mail.gmail.com>
Message-ID: <1301432567.30032.18.camel@marge>

Le mardi 29 mars 2011 ? 22:45 +0200, Lennart Regebro a ?crit :
> On Tue, Mar 29, 2011 at 22:40, Lennart Regebro <regebro at gmail.com> wrote:
> > The lesson here seems to be "if you have to use blacklists, and you
> > use unicode strings for those blacklists, also make sure the string
> > you compare with doesn't have surrogates".
> >
> 
> For that matter, what happens with combining characters?
> 
> '\N{LATIN SMALL LETTER O}\N{COMBINING DIAERESIS}' != '\N{LATIN SMALL
> LETTER O WITH DIAERESIS}'
> 
> I guess the filesystem shouldn't treat these as the same (even though
> they are), but what if some webservice does?

Mac OS X does normalize filenames to a variant of the D (decomposed)
form.
http://www.haypocalc.com/tmp/unicode-2011-03-25/html/operating_systems.html#mac-os-x

> I suspect you should normalize both strings before comparing them in any blacklist,

Yes, but a blacklist is not safe: use a whitelist.

> and what happens with surrogates when you normalize?

Surrogates are not the same in forms N, D, KC and KD.

>>> unicodedata.normalize('NFC', '\uDC80') ==
unicodedata.normalize('NFC', '\uDC80') == unicodedata.normalize('NFKC',
'\uDC80') == unicodedata.normalize('NFKD', '\uDC80') == '\uDC80'
True

Victor


From vinay_sajip at yahoo.co.uk  Tue Mar 29 23:09:25 2011
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Tue, 29 Mar 2011 21:09:25 +0000 (UTC)
Subject: [Python-Dev] Proposed change to logging.basicConfig
References: <loom.20110329T182724-83@post.gmane.org>
	<20110329184125.17717ffc@pitrou.net>
Message-ID: <loom.20110329T221510-487@post.gmane.org>

Antoine Pitrou <solipsis <at> pitrou.net> writes:

> I'm not a logging expert, but the fact that your description above
> mentions at least two instances of special-casing make it sound like
> the API has an usability (or learnability) problem.

Well, basicConfig() was provided to make it as easy as possible to configure
logging for the common use cases - logging to console and logging to file. To do
this, keyword parameters are passed: stream= (defaulting to sys.stderr, for
logging to console) or filename= and filemode= which specify a file to log to.
These sets are not compatible. Of course I could have provided two different
functions with different signatures, but it seemed simpler to have a single
function, which is typically used in just one place in an application script.
This is unlike the cmp/key case Terry mentions, and in any case the effect of
passing incompatible parameters is documented in the case of basicConfig().

If by special casing you're referring to "(if it doesn't already have any
handlers)", that's existing behaviour, and not a change. If you're referring to
"the arguments will be ignored" sentence - Terry makes a valid point about
raising an exception if incompatible parameters are passed, and I will do this.
If you're referring to the sentence about formatters, I don't see it as a
special case, it's about convenience. Each logging handler can have a formatter,
and the proposed API allows both bespoke formatters to be set for individual
handlers and for a common formatter to be set for multiple handlers, with ISTM
minimal effort for the API user.

If you're referring to something else entirely, I'm not sure what that might be.

Regards,

Vinay Sajip



From martin at v.loewis.de  Tue Mar 29 23:17:32 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 29 Mar 2011 23:17:32 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <AANLkTi=s+tPTD4dZoSiQq+CB66T2L5J0bHuCO_QBCNKN@mail.gmail.com>
References: <4D92239D.5070908@voidspace.org.uk>	<1301430194.30032.9.camel@marge>	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
	<AANLkTi=s+tPTD4dZoSiQq+CB66T2L5J0bHuCO_QBCNKN@mail.gmail.com>
Message-ID: <4D924C6C.4060105@v.loewis.de>

> '\N{LATIN SMALL LETTER O}\N{COMBINING DIAERESIS}' != '\N{LATIN SMALL
> LETTER O WITH DIAERESIS}'
> 
> I guess the filesystem shouldn't treat these as the same (even though
> they are), but what if some webservice does? I suspect you should
> normalize both strings before comparing them in any blacklist, and
> what happens with surrogates when you normalize?

I think the whole blacklist example is artificial. The string in the
blacklist is actually a Chinese "hello" greeting, so it surely isn't
the string being blacklisted. For proper blacklisting, you would likely
use substring searches, case-insensitivity, transliterations, and
perhaps even regular expressions and word stemming. If you consider all
these things, proper or alternative encodings of the same text are just
another issue to consider.

Regards,
Martin



From ben+python at benfinney.id.au  Wed Mar 30 00:20:09 2011
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 30 Mar 2011 09:20:09 +1100
Subject: [Python-Dev] Differences among Emacsen (was: utf-8 encoding in
	checkins?)
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<4D8F820A.5010200@v.loewis.de>
	<19855.35759.729216.533872@montanaro.dyndns.org>
	<4D91FA72.3070504@jmunch.dk>
	<19858.1532.530002.847055@montanaro.dyndns.org>
Message-ID: <87oc4tpo12.fsf_-_@benfinney.id.au>

skip at pobox.com writes:

> My only issues now are:
>
>  * make sure the ediff and vc packages recognize version-controlled files
>    (It seems they do, but I haven't put them through their paces)

The ?vc? package (I'm using Debian's GNU Emacs 23.2.1) now recognises
DVCS-controlled *files*, and works well with them. It's still unaware
that modern VCS deals with project *trees*, so works only at an
individual file level. Still quite useful (e.g. ?vc-diff? and the like).

The ?dvc? project <URL:http://download.gna.org/dvc/> shows promise, but
isn't yet in Debian so I haven't tried it.

I just use ?ediff? between different working trees on the filesystem, so
I don't know how well it works with files that don't exist.

>  * replace the GNU python.el with python-mode.el from the python-mode
>    project (formerly distributed with Python, but now all grown up and moved
>    away).

What's the current thinking on that? The native GNU Emacs Python mode
seems fine to me, but I'm not a particularly clever Emacs user so am
probably missing a whole lot.

-- 
 \                ?Science doesn't work by vote and it doesn't work by |
  `\        authority.? ?Richard Dawkins, _Big Mistake_ (The Guardian, |
_o__)                                                      2006-12-27) |
Ben Finney


From barry at python.org  Wed Mar 30 00:48:39 2011
From: barry at python.org (Barry Warsaw)
Date: Tue, 29 Mar 2011 18:48:39 -0400
Subject: [Python-Dev] Differences among Emacsen (was: utf-8 encoding in
 checkins?)
In-Reply-To: <87oc4tpo12.fsf_-_@benfinney.id.au>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<4D8F820A.5010200@v.loewis.de>
	<19855.35759.729216.533872@montanaro.dyndns.org>
	<4D91FA72.3070504@jmunch.dk>
	<19858.1532.530002.847055@montanaro.dyndns.org>
	<87oc4tpo12.fsf_-_@benfinney.id.au>
Message-ID: <20110329184839.5c92e2c5@neurotica.wooz.org>

On Mar 30, 2011, at 09:20 AM, Ben Finney wrote:

>The ?vc? package (I'm using Debian's GNU Emacs 23.2.1) now recognises
>DVCS-controlled *files*, and works well with them. It's still unaware
>that modern VCS deals with project *trees*, so works only at an
>individual file level. Still quite useful (e.g. ?vc-diff? and the like).
>
>The ?dvc? project <URL:http://download.gna.org/dvc/> shows promise, but
>isn't yet in Debian so I haven't tried it.

That'll be interesting to track.  I do something probably similar to you: I
diff inside Emacs but always $vcs commit from a shell.  I vaguely remember
some ancient way of doing tree-based commits using svn in Emacs, but those
brain cells have long been recycled.

>I just use ?ediff? between different working trees on the filesystem, so
>I don't know how well it works with files that don't exist.

One thing I miss so far with Mercurial is 'smerge' mode.  When I have a
conflict in a Bazaar branch, I can just visit the conflicting file and Emacs
dumps me in a minor mode called smerge.  This gives me key bindings to hop
around between conflict areas, select which part I want (or both) and then
automatically calls $vcs resolve when all the conflict areas are taken care
of.  Makes it *very* nice for dealing with such things, but in the one case I
tried it with Mercurial conflicts, it didn't work.  I'll have to investigate
further, but I'm guessing it's caused by some incompatibility with hg's
conflict markers.

>>  * replace the GNU python.el with python-mode.el from the python-mode
>>    project (formerly distributed with Python, but now all grown up and moved
>>    away).
>
>What's the current thinking on that? The native GNU Emacs Python mode
>seems fine to me, but I'm not a particularly clever Emacs user so am
>probably missing a whole lot.

In case you missed it, there are now *three* Python modes.  Tim Peters'
original and best (in my completely unbiased opinion <wink>) python-mode.el
which is still being developed, the older but apparently removed from Emacs
python.el and the 'new' (so I've heard) python.el.

Since Skip and I work on python-mode.el, you can tell what our preference is.
The fact that it hasn't been pulled into Emacs is a long and dark political
tale full of intrigue, subterfuge, fast cars, Matt Damon, sharks with frickin'
laser beams attached to their heads, and downright redonkulousness.  If you
want the full gory details (or just want to help make the most awesome Python
editing mode even awesomer), come join us on python-mode at python.org.

-Barry

P.S. pdbtrack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110329/62ab2650/attachment.pgp>

From tjreedy at udel.edu  Wed Mar 30 01:04:30 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 29 Mar 2011 19:04:30 -0400
Subject: [Python-Dev] cmp= & key= (Re: Proposed change to
	logging.basicConfig)
In-Reply-To: <imtdt5$vll$1@dough.gmane.org>
References: <loom.20110329T182724-83@post.gmane.org>	<imt9in$9u6$1@dough.gmane.org>
	<imtdt5$vll$1@dough.gmane.org>
Message-ID: <imtoht$166$1@dough.gmane.org>

On 3/29/2011 4:02 PM, Matthew Woodcraft wrote:
> Terry Reedy<tjreedy at udel.edu>  wrote:
>> # Experiment with 2.7 shows that cmp wins. Though too late to change, I
>> consider this the worst choice of three. I think an exception should be
>> raised. Failing that, I think key should win on the basis that if one
>> adds a 'new-fangled' key func to an existing call with cmp (and forgets
>> to remove cmp), the key func is the one intended. Also, the doc clearly
>> indicates that key is considered superior to cmp.
>
> Neither 'wins': cmp is applied to the output of key.

Added to http://bugs.python.org/issue11712 (for 2.7 only ;-)

> I agree that it would have been worth documenting this explicitly.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Wed Mar 30 01:07:01 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 29 Mar 2011 19:07:01 -0400
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <4D92239D.5070908@voidspace.org.uk>
References: <4D92239D.5070908@voidspace.org.uk>
Message-ID: <imtomj$166$2@dough.gmane.org>

On 3/29/2011 2:23 PM, Michael Foord wrote:

> Not sure how real the security risk is here:
>
> http://blog.omega-prime.co.uk/?p=107
>
> Basically he is saying that if you store a list of blacklisted files
> with names encoded in big-5 (or some other non-utf8 compatible encoding)
> if those names are passed at the command line, or otherwise read in and
> decoded from an assumed-utf8 source with surrogate escaping, the
> surrogate escape decoded names will not match the properly decoded
> blacklisted names.

I posted link to this as comment, with my summary of thread.

-- 
Terry Jan Reedy


From mhammond at skippinet.com.au  Wed Mar 30 02:11:45 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 30 Mar 2011 11:11:45 +1100
Subject: [Python-Dev] .hgignore including site-packages and scripts
	directories?
Message-ID: <4D927541.20201@skippinet.com.au>

I'm wondering if it is a reasonable idea to have .hgignore exclude all 
files from 'Lib/site-packages' and 'Scripts'?  As I install packages 
into my source builds, a 'hg status' lists *many* files in both those 
directories forcing me to scroll up a number of pages to see files which 
have actually changed.

IIUC, listing a directory in .hgignore doesn't preclude files from that 
directory being added to hg, and doesn't prevent files in those 
directories already under hg from being detected as changed.  The only 
downside I can see if that if new files are added to those directories 
which should be added to hg, a simple "hg st" will not show it - someone 
must remember and explicitly add it.  However, ISTM those files are 
already likely to be missed given the large amount of noise 'hg st' 
shows in that directory - the files are likely to be in the middle of a 
very long list which my brain will be trained to habitually skip over. 
The number of new files which legitimately need to be added to those 
directories seem so small that this risk seems worthwhile.

Any thoughts?

Mark

From tleeuwenburg at gmail.com  Wed Mar 30 02:24:14 2011
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Wed, 30 Mar 2011 11:24:14 +1100
Subject: [Python-Dev] Information about how cpython in benchmarked
In-Reply-To: <BANLkTikFTAtjrW=WfEAPM9oS+kpo5_Z2pw@mail.gmail.com>
References: <AANLkTikDt9fOwf0WGQSSqs7O09EL_Vu6OTUZHJdhhbL9@mail.gmail.com>
	<AANLkTimTLv7qrO0q7fZWK0kTCUc2dgJNzHi18PozwOUv@mail.gmail.com>
	<BANLkTikFTAtjrW=WfEAPM9oS+kpo5_Z2pw@mail.gmail.com>
Message-ID: <AANLkTi=0JfkG80BOUt-g5LGEu-rpoKoe5+XDeRJ=AwiV@mail.gmail.com>

Hi Nick, Jesse,

Thanks both for your responses, it's much appreciated! It's very useful to
have a clear pointer to the right place to begin looking.

Regards,
-Tennessee

On Tue, Mar 29, 2011 at 10:47 PM, Jesse Noller <jnoller at gmail.com> wrote:

> On Tue, Mar 29, 2011 at 7:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On Tue, Mar 29, 2011 at 8:01 PM, Tennessee Leeuwenburg
> > <tleeuwenburg at gmail.com> wrote:
> >> PyPy maintains http://speed.pypy.org/, which provides very clear
> information
> >> about the relative performance of PyPy trunk against some version of
> cpython
> >> (presumably 2.6 or 2.7). I'm not aware of a similar site for cpython,
> but
> >> that could easily just be my ignorance speaking.
> >> My interest is that I'm looking at building a benchmarking solution at
> work.
> >> and I can't think of a better way to build something good and general
> than
> >> to try and write something that could potentially be released as open
> source
> >> and be useful to others. As such I thought that benchmarking cpython
> would
> >> be a great use case, but I want to find out as much as I can about how
> >> people currently go about benchmarking Python. Initially I'm just
> looking at
> >> CPU profiling since it's easiest.
> >
> > One of the points coming out of the VM summit at Pycon is actually
> > that we want to create a shared benchmarking site for CPython, PyPy,
> > Jython, IronPython (and possibly Stackless) under the python.org
> > banner (either speed.python.org, or possibly performance.python.org,
> > since we want to do memory profiling as well).
> >
> > speed.pypy.org will be the reference site for this, but Maciej
> > indicated at the VM summit that the code that runs that site needs
> > some improvements before it will really be up to the task of
> > effectively benchmarking multiple targets.
> >
> > So, according to http://speed.pypy.org/about/, the place to start with
> > your benchmarking system would probably be
> > https://github.com/tobami/codespeed.
> >
> > Cheers,
> > Nick.
>
> Essentially echoing what nick said. I'm currently working on getting
> the HW for this together.
>



-- 
--------------------------------------------------
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110330/ce1c8fa7/attachment.html>

From rdmurray at bitdance.com  Wed Mar 30 03:09:16 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 29 Mar 2011 21:09:16 -0400
Subject: [Python-Dev] .hgignore including site-packages and scripts
	directories?
In-Reply-To: <4D927541.20201@skippinet.com.au>
References: <4D927541.20201@skippinet.com.au>
Message-ID: <20110330010917.31A7613F983@kimball.webabinitio.net>

On Wed, 30 Mar 2011 11:11:45 +1100, Mark Hammond <mhammond at skippinet.com.au> wrote:
> I'm wondering if it is a reasonable idea to have .hgignore exclude all 
> files from 'Lib/site-packages' and 'Scripts'?  As I install packages 
> into my source builds, a 'hg status' lists *many* files in both those 
> directories forcing me to scroll up a number of pages to see files which 
> have actually changed.

I hardly ever install things into my source build.  The first time I've
done that, in fact, was to run coverage.  The solution is to add such
directories and/or files to your personal ignore list See the 'ignore'
entry under 'ui' in the hgrc documentation.

--
R. David Murray           http://www.bitdance.com

From mhammond at skippinet.com.au  Wed Mar 30 03:17:05 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 30 Mar 2011 12:17:05 +1100
Subject: [Python-Dev] .hgignore including site-packages and scripts
	directories?
In-Reply-To: <20110330010917.31A7613F983@kimball.webabinitio.net>
References: <4D927541.20201@skippinet.com.au>
	<20110330010917.31A7613F983@kimball.webabinitio.net>
Message-ID: <4D928491.9040604@skippinet.com.au>

On 30/03/2011 12:09 PM, R. David Murray wrote:
> On Wed, 30 Mar 2011 11:11:45 +1100, Mark Hammond<mhammond at skippinet.com.au>  wrote:
>> I'm wondering if it is a reasonable idea to have .hgignore exclude all
>> files from 'Lib/site-packages' and 'Scripts'?  As I install packages
>> into my source builds, a 'hg status' lists *many* files in both those
>> directories forcing me to scroll up a number of pages to see files which
>> have actually changed.
>
> I hardly ever install things into my source build.  The first time I've
> done that, in fact, was to run coverage.

Windows doesn't really have an install process integrated into the 
build, so it is probably fairly common there.

> The solution is to add such
> directories and/or files to your personal ignore list See the 'ignore'
> entry under 'ui' in the hgrc documentation.

Yeah - but I was wondering if it could be made more convenient by 
default given the downside seems quite small...

Mark

From rdmurray at bitdance.com  Wed Mar 30 04:37:27 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 29 Mar 2011 22:37:27 -0400
Subject: [Python-Dev] .hgignore including site-packages and scripts
	directories?
In-Reply-To: <4D928491.9040604@skippinet.com.au>
References: <4D927541.20201@skippinet.com.au>
	<20110330010917.31A7613F983@kimball.webabinitio.net>
	<4D928491.9040604@skippinet.com.au>
Message-ID: <20110330023727.65D79ED455@kimball.webabinitio.net>

On Wed, 30 Mar 2011 12:17:05 +1100, Mark Hammond <mhammond at skippinet.com.au> wrote:
> On 30/03/2011 12:09 PM, R. David Murray wrote:
> > The solution is to add such
> > directories and/or files to your personal ignore list See the 'ignore'
> > entry under 'ui' in the hgrc documentation.
> 
> Yeah - but I was wondering if it could be made more convenient by 
> default given the downside seems quite small...

I suppose I wouldn't care about site-packages.  Nothing except the
existing README should ever get checked in there, I think.  And I don't
seem to have a 'Scripts' directory, just Tools/scripts, which shouldn't
be ignored.  Is Scripts windows specific?  (I also have a build/scripts,
but build is ignored.)

--
R. David Murray           http://www.bitdance.com

From mhammond at skippinet.com.au  Wed Mar 30 04:43:08 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 30 Mar 2011 13:43:08 +1100
Subject: [Python-Dev] .hgignore including site-packages and scripts
	directories?
In-Reply-To: <20110330023727.65D79ED455@kimball.webabinitio.net>
References: <4D927541.20201@skippinet.com.au>
	<20110330010917.31A7613F983@kimball.webabinitio.net>
	<4D928491.9040604@skippinet.com.au>
	<20110330023727.65D79ED455@kimball.webabinitio.net>
Message-ID: <4D9298BC.10104@skippinet.com.au>

On 30/03/2011 1:37 PM, R. David Murray wrote:
> On Wed, 30 Mar 2011 12:17:05 +1100, Mark Hammond<mhammond at skippinet.com.au>  wrote:
>> On 30/03/2011 12:09 PM, R. David Murray wrote:
>>> The solution is to add such
>>> directories and/or files to your personal ignore list See the 'ignore'
>>> entry under 'ui' in the hgrc documentation.
>>
>> Yeah - but I was wondering if it could be made more convenient by
>> default given the downside seems quite small...
>
> I suppose I wouldn't care about site-packages.  Nothing except the
> existing README should ever get checked in there, I think.  And I don't
> seem to have a 'Scripts' directory, just Tools/scripts, which shouldn't
> be ignored.  Is Scripts windows specific?  (I also have a build/scripts,
> but build is ignored.)

Yeah, "Scripts" is indeed Windows specific - which I admit I had 
forgotten until a couple of hours ago when debugging why a script using 
virtualenv failed on Windows due to assuming stuff went into a 'bin' 
directory and not the 'Scripts' directory.  The directory is normally 
populated by the distutils 'install' command, easy_install, etc

Mark

From nstinemates at gmail.com  Wed Mar 30 07:19:21 2011
From: nstinemates at gmail.com (Nick Stinemates)
Date: Tue, 29 Mar 2011 22:19:21 -0700
Subject: [Python-Dev] Information about how cpython in benchmarked
In-Reply-To: <AANLkTimTLv7qrO0q7fZWK0kTCUc2dgJNzHi18PozwOUv@mail.gmail.com>
References: <AANLkTikDt9fOwf0WGQSSqs7O09EL_Vu6OTUZHJdhhbL9@mail.gmail.com>
	<AANLkTimTLv7qrO0q7fZWK0kTCUc2dgJNzHi18PozwOUv@mail.gmail.com>
Message-ID: <AANLkTin4fQQJvP37f2RaxrTZg2G7Buqi6NG8sfi6dGUG@mail.gmail.com>

This is really great to hear and something I would be hugely interested in
contributing to.

Lurking has paid off :)

Nick

On Tue, Mar 29, 2011 at 4:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Tue, Mar 29, 2011 at 8:01 PM, Tennessee Leeuwenburg
> <tleeuwenburg at gmail.com> wrote:
> > PyPy maintains http://speed.pypy.org/, which provides very clear
> information
> > about the relative performance of PyPy trunk against some version of
> cpython
> > (presumably 2.6 or 2.7). I'm not aware of a similar site for cpython, but
> > that could easily just be my ignorance speaking.
> > My interest is that I'm looking at building a benchmarking solution at
> work.
> > and I can't think of a better way to build something good and general
> than
> > to try and write something that could potentially be released as open
> source
> > and be useful to others. As such I thought that benchmarking cpython
> would
> > be a great use case, but I want to find out as much as I can about how
> > people currently go about benchmarking Python. Initially I'm just looking
> at
> > CPU profiling since it's easiest.
>
> One of the points coming out of the VM summit at Pycon is actually
> that we want to create a shared benchmarking site for CPython, PyPy,
> Jython, IronPython (and possibly Stackless) under the python.org
> banner (either speed.python.org, or possibly performance.python.org,
> since we want to do memory profiling as well).
>
> speed.pypy.org will be the reference site for this, but Maciej
> indicated at the VM summit that the code that runs that site needs
> some improvements before it will really be up to the task of
> effectively benchmarking multiple targets.
>
> So, according to http://speed.pypy.org/about/, the place to start with
> your benchmarking system would probably be
> https://github.com/tobami/codespeed.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/nstinemates%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110329/df4e2bb3/attachment.html>

From a.badger at gmail.com  Wed Mar 30 07:54:39 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 29 Mar 2011 22:54:39 -0700
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <1301432147.30032.14.camel@marge>
References: <4D92239D.5070908@voidspace.org.uk>
	<1301430194.30032.9.camel@marge>
	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
	<1301432147.30032.14.camel@marge>
Message-ID: <20110330055438.GB15288@unaka.lan>

On Tue, Mar 29, 2011 at 10:55:47PM +0200, Victor Stinner wrote:
> Le mardi 29 mars 2011 ? 22:40 +0200, Lennart Regebro a ?crit :
> > The lesson here seems to be "if you have to use blacklists, and you
> > use unicode strings for those blacklists, also make sure the string
> > you compare with doesn't have surrogates".
> 
> No. '\u4f60\u597d'.encode('big5').decode('latin1') gives '?A?n' which
> doesn't contain any surrogate character.
> 
> The lesson is: if you compare Unicode filenames on UNIX, make sure that
> your system is correctly configured (the locale encoding must be the
> filesystem encoding).
>
You're both wrong :-)

Lennart is missing that you just need to use the same encoding
+ surrogateescape (or stick with bytes) for decoding the byte strings that
you are comparing.

You're missing that on UNIX there is no filesystem encoding so the idea of
locale and filesystem encoding matching is false (and unnecessary -- the
encodings that you use within python just need to be the same.  They don't
even need to match up to the reality of what's used on the filesystem or the
user's locale.)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110329/1abbe888/attachment-0001.pgp>

From regebro at gmail.com  Wed Mar 30 08:36:43 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 30 Mar 2011 08:36:43 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <20110330055438.GB15288@unaka.lan>
References: <4D92239D.5070908@voidspace.org.uk>
	<1301430194.30032.9.camel@marge>
	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
	<1301432147.30032.14.camel@marge> <20110330055438.GB15288@unaka.lan>
Message-ID: <AANLkTi=e3pHKco4xTpWXDbkNj=kPHEwGhG75mBEnQkoF@mail.gmail.com>

On Wed, Mar 30, 2011 at 07:54, Toshio Kuratomi <a.badger at gmail.com> wrote:
> Lennart is missing that you just need to use the same encoding
> + surrogateescape (or stick with bytes) for decoding the byte strings that
> you are comparing.

You lost me here. I need to do this for what?

//Lennart

From regebro at gmail.com  Wed Mar 30 08:37:53 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 30 Mar 2011 08:37:53 +0200
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <4D924C6C.4060105@v.loewis.de>
References: <4D92239D.5070908@voidspace.org.uk>
	<1301430194.30032.9.camel@marge>
	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
	<AANLkTi=s+tPTD4dZoSiQq+CB66T2L5J0bHuCO_QBCNKN@mail.gmail.com>
	<4D924C6C.4060105@v.loewis.de>
Message-ID: <AANLkTimJd9dcUgy8RQB_xaJH2Un8=8R7+iV6tvvHu-GK@mail.gmail.com>

On Tue, Mar 29, 2011 at 23:17, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I think the whole blacklist example is artificial. The string in the
> blacklist is actually a Chinese "hello" greeting, so it surely isn't
> the string being blacklisted. For proper blacklisting, you would likely
> use substring searches, case-insensitivity, transliterations, and
> perhaps even regular expressions and word stemming.

Good point.

//Lennart

From greg at krypto.org  Wed Mar 30 08:57:27 2011
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 29 Mar 2011 23:57:27 -0700
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <imtomj$166$2@dough.gmane.org>
References: <4D92239D.5070908@voidspace.org.uk> <imtomj$166$2@dough.gmane.org>
Message-ID: <AANLkTimrU7Bw6_tBj6qFQOhS6vz3T_wSkKx_m66OfHjT@mail.gmail.com>

On Tue, Mar 29, 2011 at 4:07 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 3/29/2011 2:23 PM, Michael Foord wrote:
>
>  Not sure how real the security risk is here:
>>
>> http://blog.omega-prime.co.uk/?p=107
>>
>> Basically he is saying that if you store a list of blacklisted files
>> with names encoded in big-5 (or some other non-utf8 compatible encoding)
>> if those names are passed at the command line, or otherwise read in and
>> decoded from an assumed-utf8 source with surrogate escaping, the
>> surrogate escape decoded names will not match the properly decoded
>> blacklisted names.
>>
>
> I posted link to this as comment, with my summary of thread.
>
> --
> Terry Jan Reedy


I don't see your comment on the blog post.  So either the author is
moderating comments and hasn't seen yours yet (likely) or they don't want
disagreement in their comments. ;)

Regardless, is isn't a bug with Python or PEP 383.  If someone is dealing
with security and does not know what formats the various inputs to their
program that are used to make the security check can come in as they
shouldn't be writing security oriented code at all...  (But that's never
stopped anyone).

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110329/d360063a/attachment.html>

From ralf at brainbot.com  Wed Mar 30 09:43:24 2011
From: ralf at brainbot.com (Ralf Schmitt)
Date: Wed, 30 Mar 2011 09:43:24 +0200
Subject: [Python-Dev] Differences among Emacsen
In-Reply-To: <20110329184839.5c92e2c5@neurotica.wooz.org> (Barry Warsaw's
	message of "Tue, 29 Mar 2011 18:48:39 -0400")
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<4D8F820A.5010200@v.loewis.de>
	<19855.35759.729216.533872@montanaro.dyndns.org>
	<4D91FA72.3070504@jmunch.dk>
	<19858.1532.530002.847055@montanaro.dyndns.org>
	<87oc4tpo12.fsf_-_@benfinney.id.au>
	<20110329184839.5c92e2c5@neurotica.wooz.org>
Message-ID: <87aagdhx43.fsf@muni.brainbot.com>

Barry Warsaw <barry at python.org> writes:

>
> In case you missed it, there are now *three* Python modes.  Tim Peters'
> original and best (in my completely unbiased opinion <wink>) python-mode.el
> which is still being developed, the older but apparently removed from Emacs
> python.el and the 'new' (so I've heard) python.el.

https://github.com/fgallina/python.el is the fourth one..

From amauryfa at gmail.com  Wed Mar 30 11:02:31 2011
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Wed, 30 Mar 2011 11:02:31 +0200
Subject: [Python-Dev] Failed issue tracker submission
In-Reply-To: <20110329201055.BE7561DEB2@psf.upfronthosting.co.za>
References: <20110329201055.BE7561DEB2@psf.upfronthosting.co.za>
Message-ID: <AANLkTikr3uu=SPbTHHdCPP9sEhd33P7NttRyRmtb54Qb@mail.gmail.com>

2011/3/29 Python tracker <roundup-admin at psf.upfronthosting.co.za>:
>
>
> The node specified by the designator in the subject of your message
> ("22663") does not exist.
>
> Subject was: "[issue22663]"

Aha.
This email was probably generated by a commit hook because
this changeset http://hg.python.org/cpython/rev/dd852a0f92d6
has a typo in the issue number, it should have been 11662.

>
>
>
> Mail Gateway Help
> =================
> Incoming messages are examined for multiple parts:
> ?. In a multipart/mixed message or part, each subpart is extracted and
> ? examined. The text/plain subparts are assembled to form the textual
> ? body of the message, to be stored in the file associated with a "msg"
> ? class node. Any parts of other types are each stored in separate files
> ? and given "file" class nodes that are linked to the "msg" node.
> ?. In a multipart/alternative message or part, we look for a text/plain
> ? subpart and ignore the other parts.
>
> Summary
> -------
> The "summary" property on message nodes is taken from the first non-quoting
> section in the message body. The message body is divided into sections by
> blank lines. Sections where the second and all subsequent lines begin with
> a ">" or "|" character are considered "quoting sections". The first line of
> the first non-quoting section becomes the summary of the message.
>
> Addresses
> ---------
> All of the addresses in the To: and Cc: headers of the incoming message are
> looked up among the user nodes, and the corresponding users are placed in
> the "recipients" property on the new "msg" node. The address in the From:
> header similarly determines the "author" property of the new "msg"
> node. The default handling for addresses that don't have corresponding
> users is to create new users with no passwords and a username equal to the
> address. (The web interface does not permit logins for users with no
> passwords.) If we prefer to reject mail from outside sources, we can simply
> register an auditor on the "user" class that prevents the creation of user
> nodes with no passwords.
>
> Actions
> -------
> The subject line of the incoming message is examined to determine whether
> the message is an attempt to create a new item or to discuss an existing
> item. A designator enclosed in square brackets is sought as the first thing
> on the subject line (after skipping any "Fwd:" or "Re:" prefixes).
>
> If an item designator (class name and id number) is found there, the newly
> created "msg" node is added to the "messages" property for that item, and
> any new "file" nodes are added to the "files" property for the item.
>
> If just an item class name is found there, we attempt to create a new item
> of that class with its "messages" property initialized to contain the new
> "msg" node and its "files" property initialized to contain any new "file"
> nodes.
>
> Triggers
> --------
> Both cases may trigger detectors (in the first case we are calling the
> set() method to add the message to the item's spool; in the second case we
> are calling the create() method to create a new node). If an auditor raises
> an exception, the original message is bounced back to the sender with the
> explanatory message given in the exception.
>
> $Id: mailgw.py,v 1.196 2008-07-23 03:04:44 richard Exp $
>
> Return-Path: <python-dev at python.org>
> X-Original-To: report at bugs.python.org
> Delivered-To: roundup+tracker at psf.upfronthosting.co.za
> Received: from mail.python.org (mail.python.org [82.94.164.166])
> ? ? ? ?by psf.upfronthosting.co.za (Postfix) with ESMTPS id 7DCEE1DEB0
> ? ? ? ?for <report at bugs.python.org>; Tue, 29 Mar 2011 22:10:55 +0200 (CEST)
> Received: from albatross.python.org (localhost [127.0.0.1])
> ? ? ? ?by mail.python.org (Postfix) with ESMTP id 3PzjsW1q1lz7Lmy
> ? ? ? ?for <report at bugs.python.org>; Tue, 29 Mar 2011 22:10:55 +0200 (CEST)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
> ? ? ? ?t=1301429455; bh=WYL3NF6gQtbDZ+R9KxXHGS2PSlCAxyY+EQEgb/Yw5jI=;
> ? ? ? ?h=Date:Message-Id:Content-Type:MIME-Version:
> ? ? ? ? Content-Transfer-Encoding:From:To:Subject;
> ? ? ? ?b=RiMAivS4Shae7bPg7E7SocheqYB9pzk/Svimv+qumX5arnUaaC8h9iIJo8MFDcDdi
> ? ? ? ? +Wk0XzTjTjKsbobrKgZnfZf9a8j6Fv4Ym1nTyTcPcyjCMritjq9xNUluVQvHv/Vn2e
> ? ? ? ? RhpV2FUWOdCtBx83eUopMPGEEEwABnbG5ZwgsDzM=
> Received: from localhost (HELO mail.python.org) (127.0.0.1)
> ?by albatross.python.org with SMTP; 29 Mar 2011 22:10:55 +0200
> Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4])
> ? ? ? ?(using TLSv1 with cipher AES256-SHA (256/256 bits))
> ? ? ? ?(No client certificate requested)
> ? ? ? ?by mail.python.org (Postfix) with ESMTPS
> ? ? ? ?for <report at bugs.python.org>; Tue, 29 Mar 2011 22:10:55 +0200 (CEST)
> Received: from localhost
> ? ? ? ?([127.0.0.1] helo=dinsdale.python.org ident=hg)
> ? ? ? ?by dinsdale.python.org with esmtp (Exim 4.72)
> ? ? ? ?(envelope-from <python-dev at python.org>)
> ? ? ? ?id 1Q4fFf-00023G-4C
> ? ? ? ?for report at bugs.python.org; Tue, 29 Mar 2011 22:10:55 +0200
> Date: Tue, 29 Mar 2011 22:10:55 +0200
> Message-Id: <E1Q4fFf-00023G-4C at dinsdale.python.org>
> Content-Type: text/plain; charset="utf8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: base64
> From: python-dev at python.org
> To: report at bugs.python.org
> Subject: [issue22663]
>
> TmV3IGNoYW5nZXNldCBkZDg1MmEwZjkyZDYgYnkgZ3VpZG8gaW4gYnJhbmNoICcyLjUnOgpJc3N1
> ZSAyMjY2MzogZml4IHJlZGlyZWN0IHZ1bG5lcmFiaWxpdHkgaW4gdXJsbGliL3VybGxpYjIuCmh0
> dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2L2RkODUyYTBmOTJkNgo=
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/amauryfa%40gmail.com
>
>



-- 
Amaury Forgeot d'Arc

From jnoller at gmail.com  Wed Mar 30 12:19:01 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 30 Mar 2011 06:19:01 -0400
Subject: [Python-Dev] Information about how cpython in benchmarked
In-Reply-To: <AANLkTin4fQQJvP37f2RaxrTZg2G7Buqi6NG8sfi6dGUG@mail.gmail.com>
References: <AANLkTikDt9fOwf0WGQSSqs7O09EL_Vu6OTUZHJdhhbL9@mail.gmail.com>
	<AANLkTimTLv7qrO0q7fZWK0kTCUc2dgJNzHi18PozwOUv@mail.gmail.com>
	<AANLkTin4fQQJvP37f2RaxrTZg2G7Buqi6NG8sfi6dGUG@mail.gmail.com>
Message-ID: <BANLkTinJpgoVnvry9QevL8RQM4mUgwpD-w@mail.gmail.com>

On Wed, Mar 30, 2011 at 1:19 AM, Nick Stinemates <nstinemates at gmail.com> wrote:
> This is really great to hear and something I would be hugely interested in
> contributing to.
> Lurking has paid off :)
> Nick
>

Once I get the machine in place, and the team engaged, I am sure
they'll be looking for help. As it stands, the best place to start
helping is by getting in conact with the speed.pypy.org team (the pypy
folks) and look into the codespeed codebase. We have to start work on
it now to get it ready to be more general use.

jesse

From ncoghlan at gmail.com  Wed Mar 30 12:42:22 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 30 Mar 2011 20:42:22 +1000
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <AANLkTimrU7Bw6_tBj6qFQOhS6vz3T_wSkKx_m66OfHjT@mail.gmail.com>
References: <4D92239D.5070908@voidspace.org.uk> <imtomj$166$2@dough.gmane.org>
	<AANLkTimrU7Bw6_tBj6qFQOhS6vz3T_wSkKx_m66OfHjT@mail.gmail.com>
Message-ID: <AANLkTi=9zvhiewZkoK87ewUD2QygkbpKQqZw6cYiSMcp@mail.gmail.com>

On Wed, Mar 30, 2011 at 4:57 PM, Gregory P. Smith <greg at krypto.org> wrote:
> I don't see your comment on the blog post. ?So either the author is
> moderating comments and hasn't seen yours yet (likely) or they don't want
> disagreement in their comments. ;)

My comment was sitting in the moderation queue last time I looked as well.

While Toshio is correct that there is no one correct "filesystem
encoding" on Linux systems, Python still does its best to guess one
(even though it may be wrong for some of the mounted filesystems).
That's what it will use when encoding Unicode strings to pass to
bytes-oriented POSIX APIs, so you can always "pre-check" values by
using os.fsencode to get everything into the bytes format that will
actually be passed to the underlying OS API.

Python 3.2 provides the tools to do this kind of thing correctly, but
it is finicky enough that there isn't really any way for us to make it
easy.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Wed Mar 30 13:01:06 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 30 Mar 2011 13:01:06 +0200
Subject: [Python-Dev] .hgignore including site-packages and scripts
	directories?
References: <4D927541.20201@skippinet.com.au>
	<20110330010917.31A7613F983@kimball.webabinitio.net>
	<4D928491.9040604@skippinet.com.au>
Message-ID: <20110330130106.426f5367@pitrou.net>

On Wed, 30 Mar 2011 12:17:05 +1100
Mark Hammond <mhammond at skippinet.com.au> wrote:
> On 30/03/2011 12:09 PM, R. David Murray wrote:
> > On Wed, 30 Mar 2011 11:11:45 +1100, Mark Hammond<mhammond at skippinet.com.au>  wrote:
> >> I'm wondering if it is a reasonable idea to have .hgignore exclude all
> >> files from 'Lib/site-packages' and 'Scripts'?  As I install packages
> >> into my source builds, a 'hg status' lists *many* files in both those
> >> directories forcing me to scroll up a number of pages to see files which
> >> have actually changed.
> >
> > I hardly ever install things into my source build.  The first time I've
> > done that, in fact, was to run coverage.
> 
> Windows doesn't really have an install process integrated into the 
> build, so it is probably fairly common there.
> 
> > The solution is to add such
> > directories and/or files to your personal ignore list See the 'ignore'
> > entry under 'ui' in the hgrc documentation.
> 
> Yeah - but I was wondering if it could be made more convenient by 
> default given the downside seems quite small...

I don't see any downside myself.

Regards

Antoine.



From v+python at g.nevcal.com  Tue Mar 29 22:00:51 2011
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Tue, 29 Mar 2011 13:00:51 -0700
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <20110329191058.GJ3698@unaka.lan>
References: <4D92239D.5070908@voidspace.org.uk>
	<20110329191058.GJ3698@unaka.lan>
Message-ID: <4D923A73.6070506@g.nevcal.com>

On 3/29/2011 12:10 PM, Toshio Kuratomi wrote:
> The possible flaw in python is this:  Code like the blog poster wrote passes
> python3 without an error or a warning.  This gives the programmer no
> feedback that they're doing something wrong until it actually bites them in
> the foot in deployed code.

Yes there is a certain level of knowledge required of the system 
configuration and python defaults for accessing the system for things 
like filenames.  It can be coded in any of several ways.

But by the above definition of "possible flaw", that seems equivalent to 
saying that Python should give a warning for things like

os.unlink("my-most-important-file.doc")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110329/3b21fb29/attachment.html>

From victor.stinner at haypocalc.com  Wed Mar 30 17:59:02 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Wed, 30 Mar 2011 17:59:02 +0200
Subject: [Python-Dev] Test "Force Build" on custom buildbots
Message-ID: <1301500742.4065.11.camel@marge>

Hi,

I'm testing my faulthandler repository on the custom buildbots, here are
some remarks and issues.

The form still refers to SVN ('Branch to build' is relative to
http://svn.python.org/projects/python.) => the branch is relative to
hg.python.org/

I cannot write "#" in the branch field to specify... the branch (only
the repository). If the branch contains "#", the request looks to be
ignored (without any warning/error). I merged my faulthandler branch
into the default branch (in my features/faulthandler branch).

I don't understand the meaning of the "project" field. It is maybe
something specific to Subversion?

What are the 3 optional properties?

If branch doesn't end with a slash (e.g. "features/faulthandler"), the
request is ignored (without any warning/error).

I canceled a build on a Windows buildbot during the "tests" step using
the [Cancel] button, but it failed to kill the process:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%
20custom/builds/2/steps/test/logs/stdio
-----------
command interrupted, killing pid 2168
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1
-----------

To test my faulthandler feature branch, the correct parameters are:
--
Name: haypo
Reason: test faulthandler
Branch: features/faulthandler/
Revision: tip
Repository: features/faulthandler
(leave the project and the 6 property fields empty)
--

The repository looks like a duplicate of the branch field. I would be
better to use "default" as the branch and "features/faulthandler" as the
repository.

I would be nice to have error messages.

Victor


From solipsis at pitrou.net  Wed Mar 30 18:04:43 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 30 Mar 2011 18:04:43 +0200
Subject: [Python-Dev] Test "Force Build" on custom buildbots
References: <1301500742.4065.11.camel@marge>
Message-ID: <20110330180443.3451c4a4@pitrou.net>

On Wed, 30 Mar 2011 17:59:02 +0200
Victor Stinner <victor.stinner at haypocalc.com> wrote:
> 
> I cannot write "#" in the branch field to specify... the branch (only
> the repository). If the branch contains "#", the request looks to be
> ignored (without any warning/error). I merged my faulthandler branch
> into the default branch (in my features/faulthandler branch).

You could have put the branch name in the "revision" field instead (as
I told you on #python-dev).

This is very much an unofficial feature right now, which also explains
that the UI has not been adapted.

> I canceled a build on a Windows buildbot during the "tests" step using
> the [Cancel] button, but it failed to kill the process:
> 
> http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%
> 20custom/builds/2/steps/test/logs/stdio
> -----------
> command interrupted, killing pid 2168
> SIGKILL failed to kill process
> using fake rc=-1
> program finished with exit code -1
> -----------

This is the kind of question you have to ask on the buildbot channels. I
don't think any of us knows enough about buildbot internals to answer
it or give any guidance.

Thank you

Antoine.



From victor.stinner at haypocalc.com  Wed Mar 30 18:11:53 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Wed, 30 Mar 2011 18:11:53 +0200
Subject: [Python-Dev] Test "Force Build" on custom buildbots
In-Reply-To: <1301500742.4065.11.camel@marge>
References: <1301500742.4065.11.camel@marge>
Message-ID: <1301501513.4065.19.camel@marge>

Le mercredi 30 mars 2011 ? 17:59 +0200, Victor Stinner a ?crit :
> I'm testing my faulthandler repository on the custom buildbots, here are
> some remarks and issues.

Oh, I forgot something: there is an error on hg purge.

Example on a Windows buildbot:
----
C:\Program Files\Mercurial\hg.EXE purge --all
 ...
 argv: ['C:\\Program Files\\Mercurial\\hg.EXE', 'purge', '--all']
 ...
program finished with exit code -1
'hg purge' failed: Mercurial Distributed SCM
----

It looks like build slaves require the purge extension.

Victor


From solipsis at pitrou.net  Wed Mar 30 18:27:13 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 30 Mar 2011 18:27:13 +0200
Subject: [Python-Dev] Test "Force Build" on custom buildbots
References: <1301500742.4065.11.camel@marge> <1301501513.4065.19.camel@marge>
Message-ID: <20110330182713.48ab52fa@pitrou.net>

On Wed, 30 Mar 2011 18:11:53 +0200
Victor Stinner <victor.stinner at haypocalc.com> wrote:
> Le mercredi 30 mars 2011 ? 17:59 +0200, Victor Stinner a ?crit :
> > I'm testing my faulthandler repository on the custom buildbots, here are
> > some remarks and issues.
> 
> Oh, I forgot something: there is an error on hg purge.
[...]

It's not an error, it falls back on another purging method when the
purge extension is not enabled.

cheers

Antoine.



From tjreedy at udel.edu  Wed Mar 30 20:53:51 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 30 Mar 2011 14:53:51 -0400
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <AANLkTimrU7Bw6_tBj6qFQOhS6vz3T_wSkKx_m66OfHjT@mail.gmail.com>
References: <4D92239D.5070908@voidspace.org.uk> <imtomj$166$2@dough.gmane.org>
	<AANLkTimrU7Bw6_tBj6qFQOhS6vz3T_wSkKx_m66OfHjT@mail.gmail.com>
Message-ID: <imvu7u$5hf$1@dough.gmane.org>

On 3/30/2011 2:57 AM, Gregory P. Smith wrote:

>>> http://blog.omega-prime.co.uk/?p=107

>> I posted link to this as comment, with my summary of thread.

> I don't see your comment on the blog post.  So either the author is
> moderating comments and hasn't seen yours yet (likely)

My comment and Nick's are now both posted. Blogger Max replied

"Nick, thanks for that info. It is certainly nice that there is a work 
around, and perhaps this indeed the best that can be done if you still 
want the convenience of representing filenames as strings.

Terry: thanks also for the link to the mailing list thread. It is 
certainly interesting, and the argument regarding latin1 is a compelling 
one ? this issue is indeed not specific to PEP383. So the dangerous 
operation seems to be comparing strings that were originally created 
from byte strings in two different encodings. It?s not clear to me that 
it would be sensible for the language to check this (perhaps by throwing 
an exception if you try it).

The other 2 comments are also followed by responses.

-- 
Terry Jan Reedy



From barry at python.org  Wed Mar 30 20:54:40 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 30 Mar 2011 14:54:40 -0400
Subject: [Python-Dev] Differences among Emacsen
In-Reply-To: <87aagdhx43.fsf@muni.brainbot.com>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<4D8F820A.5010200@v.loewis.de>
	<19855.35759.729216.533872@montanaro.dyndns.org>
	<4D91FA72.3070504@jmunch.dk>
	<19858.1532.530002.847055@montanaro.dyndns.org>
	<87oc4tpo12.fsf_-_@benfinney.id.au>
	<20110329184839.5c92e2c5@neurotica.wooz.org>
	<87aagdhx43.fsf@muni.brainbot.com>
Message-ID: <20110330145440.21c15646@neurotica.wooz.org>

On Mar 30, 2011, at 09:43 AM, Ralf Schmitt wrote:

>Barry Warsaw <barry at python.org> writes:
>>
>> In case you missed it, there are now *three* Python modes.  Tim Peters'
>> original and best (in my completely unbiased opinion <wink>) python-mode.el
>> which is still being developed, the older but apparently removed from Emacs
>> python.el and the 'new' (so I've heard) python.el.
>
>https://github.com/fgallina/python.el is the fourth one..

Wonderful.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110330/a0184325/attachment.pgp>

From glyph at twistedmatrix.com  Wed Mar 30 21:35:08 2011
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Wed, 30 Mar 2011 15:35:08 -0400
Subject: [Python-Dev] Differences among Emacsen
In-Reply-To: <20110330145440.21c15646@neurotica.wooz.org>
References: <19855.21129.360534.876590@montanaro.dyndns.org>
	<4D8F820A.5010200@v.loewis.de>
	<19855.35759.729216.533872@montanaro.dyndns.org>
	<4D91FA72.3070504@jmunch.dk>
	<19858.1532.530002.847055@montanaro.dyndns.org>
	<87oc4tpo12.fsf_-_@benfinney.id.au>
	<20110329184839.5c92e2c5@neurotica.wooz.org>
	<87aagdhx43.fsf@muni.brainbot.com>
	<20110330145440.21c15646@neurotica.wooz.org>
Message-ID: <063B91D9-C180-453D-A4A8-76D19E239DE4@twistedmatrix.com>


On Mar 30, 2011, at 2:54 PM, Barry Warsaw wrote:

> On Mar 30, 2011, at 09:43 AM, Ralf Schmitt wrote:
> 
>> Barry Warsaw <barry at python.org> writes:
>>> 
>>> In case you missed it, there are now *three* Python modes.  Tim Peters'
>>> original and best (in my completely unbiased opinion <wink>) python-mode.el
>>> which is still being developed, the older but apparently removed from Emacs
>>> python.el and the 'new' (so I've heard) python.el.
>> 
>> https://github.com/fgallina/python.el is the fourth one..
> 
> Wonderful.

I have a plea for posterity: since I'm sure that a hundred people will see this post and decide that the best solution to this proliferation of python plugins for emacs is that there should be a new one that is even better than all these other ones (and also totally incompatible, of course)...

I won't try to stop you all from doing that, but please at least don't call it "python.el".  This is like if ActiveState, Wing, PyCharm and PyDev for Eclipse had all decided to call their respective projects "IDLE" because that's what you call a Python IDE :).  It would be nice to be able to talk about Python / Emacs code without having to do an Abbott and Costello routine.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110330/3c05d151/attachment.html>

From mal at egenix.com  Wed Mar 30 22:06:31 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 30 Mar 2011 22:06:31 +0200
Subject: [Python-Dev] Replace useless %.100s by %s in PyErr_Format()
In-Reply-To: <1301008885.25217.5.camel@marge>
References: <1300967158.17607.16.camel@marge> <4D8B3797.7070500@egenix.com>
	<1301008885.25217.5.camel@marge>
Message-ID: <4D938D47.6070309@egenix.com>

Victor Stinner wrote:
> Le jeudi 24 mars 2011 ? 13:22 +0100, M.-A. Lemburg a ?crit :
>> BTW: Why do you think that %.100s is not supported in
>> PyErr_Format() in Python 2.x ? PyString_FromFormatV()
>> does support this. The change to use Unicode error strings
>> introduced the problem, since PyUnicode_FromFormatV() for
>> some reason ignores the precision (which is shouldn't).
> 
> Oh... You are right, it is a regression in Python 3. We started to write
> unit tests for PyBytes_FromFormat() and PyUnicode_FromFormat(), I hope
> that they will improve the situation.
> 
>> That said, it's a good idea to add the #7330 fix
>> to at least Python 2.7 as well, since ignoring the precision
>> is definitely a bug. It may even be security relevant, since
>> it could be used for DOS attacks on servers (e.g. causing them
>> to write huge strings to log files instead of just a few
>> hundreds bytes per message), so may even need to go into Python 2.6.
> 
> Python 2 is not affected because PyErr_Format() uses
> PyString_FromFormatV() which supports precision for %s format (e.g.
> %.100s truncate the string to 100 bytes).

Right, but the PyUnicode_FromFormatV() which ignores
the precision is still present in Python 2.6 and 2.7,
even though it is not used by PyErr_Format().

> Do you think that Python 3.1-3.3 should be fixed?

Yes, indeed. The above mentioned security threat is real.

The CPython code only has a few cases where this could be use
for a DOS (e.g. in the pickle module or the AST code), but
since this function is used in 3rd party extensions,
those are affected indirectly as well.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 30 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From barry at python.org  Wed Mar 30 22:17:09 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 30 Mar 2011 16:17:09 -0400
Subject: [Python-Dev] Issue 11715: building Python from source on multiarch
	Debian/Ubuntu
Message-ID: <20110330161709.756b27f7@neurotica.wooz.org>

Ubuntu 11.04 added support for multiarch libraries:

https://wiki.ubuntu.com/MultiarchSpec
http://wiki.debian.org/ReleaseGoals/MultiArch

At the moment, I don't care about issue 1294959 which I think addresses
building multiarch flavors of Python:

http://bugs.python.org/issue1294959

I have a much more short-term concern, which is being able to build Python
from source *on* a multiarch Debian/Ubuntu:

http://bugs.python.org/issue11715

The problem is that without this patch (or something like it), several of the
extension modules do not build because setup.py does not search the
directories in which the third party .so files live.  The patch in the tracker
is fairly straightforward and should be robust enough for platforms without
dpkg-architecture(1).  It's adapted from the patch in the Ubuntu source
package.

I would like to apply this patch (or its moral equivalent) to all active,
affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as
soon as possible.  Without this, it will be very difficult for anyone on
future Ubuntu or Debian releases to build Python.  Since it's not a new
feature, but just a minor fix to the build process, I think it should be okay
to back port.

Please comment here or in the tracker for issue 11715.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110330/ad750952/attachment-0001.pgp>

From solipsis at pitrou.net  Wed Mar 30 22:20:04 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 30 Mar 2011 22:20:04 +0200
Subject: [Python-Dev] devguide: Add a table of contents to the FAQ.
References: <E1Q4e9O-0001X5-Jr@dinsdale.python.org>
Message-ID: <20110330222004.5b23bcc5@pitrou.net>

On Tue, 29 Mar 2011 21:00:22 +0200
ezio.melotti <python-checkins at python.org> wrote:
> http://hg.python.org/devguide/rev/f722956afeac
> changeset:   405:f722956afeac
> user:        Ezio Melotti
> date:        Tue Mar 29 22:00:13 2011 +0300
> summary:
>   Add a table of contents to the FAQ.

Could it be collapsed by default? It's quite long, and redundant with
the sidebar.

thanks

Antoine.



From solipsis at pitrou.net  Wed Mar 30 23:01:00 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 30 Mar 2011 23:01:00 +0200
Subject: [Python-Dev] Documenting the buildbots
References: <1301500742.4065.11.camel@marge>
Message-ID: <20110330230100.51d170a1@pitrou.net>


For the record, I added a page documenting our continuous integration
setup at:
http://docs.python.org/devguide/buildbots.html

Regards

Antoine.



On Wed, 30 Mar 2011 17:59:02 +0200
Victor Stinner <victor.stinner at haypocalc.com> wrote:
> Hi,
> 
> I'm testing my faulthandler repository on the custom buildbots, here are
> some remarks and issues.
> 
> The form still refers to SVN ('Branch to build' is relative to
> http://svn.python.org/projects/python.) => the branch is relative to
> hg.python.org/
> 
> I cannot write "#" in the branch field to specify... the branch (only
> the repository). If the branch contains "#", the request looks to be
> ignored (without any warning/error). I merged my faulthandler branch
> into the default branch (in my features/faulthandler branch).
> 
> I don't understand the meaning of the "project" field. It is maybe
> something specific to Subversion?
> 
> What are the 3 optional properties?
> 
> If branch doesn't end with a slash (e.g. "features/faulthandler"), the
> request is ignored (without any warning/error).
> 
> I canceled a build on a Windows buildbot during the "tests" step using
> the [Cancel] button, but it failed to kill the process:
> 
> http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%
> 20custom/builds/2/steps/test/logs/stdio
> -----------
> command interrupted, killing pid 2168
> SIGKILL failed to kill process
> using fake rc=-1
> program finished with exit code -1
> -----------
> 
> To test my faulthandler feature branch, the correct parameters are:
> --
> Name: haypo
> Reason: test faulthandler
> Branch: features/faulthandler/
> Revision: tip
> Repository: features/faulthandler
> (leave the project and the 6 property fields empty)
> --
> 
> The repository looks like a duplicate of the branch field. I would be
> better to use "default" as the branch and "features/faulthandler" as the
> repository.
> 
> I would be nice to have error messages.
> 
> Victor
> 



From jnoller at gmail.com  Wed Mar 30 23:14:10 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 30 Mar 2011 17:14:10 -0400
Subject: [Python-Dev] Documenting the buildbots
In-Reply-To: <20110330230100.51d170a1@pitrou.net>
References: <1301500742.4065.11.camel@marge>
	<20110330230100.51d170a1@pitrou.net>
Message-ID: <BANLkTi=9--Z_c4W33RYn3nff01x2X1wgHQ@mail.gmail.com>

On Wed, Mar 30, 2011 at 5:01 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> For the record, I added a page documenting our continuous integration
> setup at:
> http://docs.python.org/devguide/buildbots.html
>
> Regards
>
> Antoine.
>

that's awesome. should we document how to donate/add a buildbot
somewhere in the same section (or alongside)?

From solipsis at pitrou.net  Wed Mar 30 23:24:37 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 30 Mar 2011 23:24:37 +0200
Subject: [Python-Dev] Documenting the buildbots
In-Reply-To: <BANLkTi=9--Z_c4W33RYn3nff01x2X1wgHQ@mail.gmail.com>
References: <1301500742.4065.11.camel@marge>
	<20110330230100.51d170a1@pitrou.net>
	<BANLkTi=9--Z_c4W33RYn3nff01x2X1wgHQ@mail.gmail.com>
Message-ID: <20110330232437.3d1eba66@pitrou.net>

On Wed, 30 Mar 2011 17:14:10 -0400
Jesse Noller <jnoller at gmail.com> wrote:

> On Wed, Mar 30, 2011 at 5:01 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >
> > For the record, I added a page documenting our continuous integration
> > setup at:
> > http://docs.python.org/devguide/buildbots.html
> >
> > Regards
> >
> > Antoine.
> >
> 
> that's awesome. should we document how to donate/add a buildbot
> somewhere in the same section (or alongside)?

It's documented at http://wiki.python.org/moin/BuildBot.
I think it's a bit outside the scope of the devguide.

(perhaps we should have an infrastructure/sysadmin contribution guide)

Regards

Antoine.

From jnoller at gmail.com  Wed Mar 30 23:29:51 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 30 Mar 2011 17:29:51 -0400
Subject: [Python-Dev] Documenting the buildbots
In-Reply-To: <20110330232437.3d1eba66@pitrou.net>
References: <1301500742.4065.11.camel@marge>
	<20110330230100.51d170a1@pitrou.net>
	<BANLkTi=9--Z_c4W33RYn3nff01x2X1wgHQ@mail.gmail.com>
	<20110330232437.3d1eba66@pitrou.net>
Message-ID: <BANLkTi=rhqxVnaCec4y9rKQimkp835-dSg@mail.gmail.com>

On Wed, Mar 30, 2011 at 5:24 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 30 Mar 2011 17:14:10 -0400
> Jesse Noller <jnoller at gmail.com> wrote:
>
>> On Wed, Mar 30, 2011 at 5:01 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> >
>> > For the record, I added a page documenting our continuous integration
>> > setup at:
>> > http://docs.python.org/devguide/buildbots.html
>> >
>> > Regards
>> >
>> > Antoine.
>> >
>>
>> that's awesome. should we document how to donate/add a buildbot
>> somewhere in the same section (or alongside)?
>
> It's documented at http://wiki.python.org/moin/BuildBot.
> I think it's a bit outside the scope of the devguide.
>
> (perhaps we should have an infrastructure/sysadmin contribution guide)
>

Not a bad idea.

From tjreedy at udel.edu  Wed Mar 30 23:35:42 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 30 Mar 2011 17:35:42 -0400
Subject: [Python-Dev] Please revert autofolding of tracker edit form
Message-ID: <in07nd$5nb$1@dough.gmane.org>

The tracker was recently changed so that when I click on a link to a 
tracker page, the page is properly displayed, but then a fraction of a 
second it blinks and redisplays with the edit form hidden. This is so 
obnoxious to me that I no longer want to visit the tracker. Then I have 
to find and click the button to get back the edit form that I nearly 
always want to see, as I often make changes. All this to compress the 
page by half a screen, which makes almost no difference once one grabs 
the scrollbar anyway.

If someone actually considers this a desired feature, after using it, 
then please add a field on the profile page to select autofolding or 
not. Also, there should be a button to fold as well as one to unfold.

-- 
Terry Jan Reedy


From db3l.net at gmail.com  Thu Mar 31 00:33:39 2011
From: db3l.net at gmail.com (David Bolen)
Date: Wed, 30 Mar 2011 18:33:39 -0400
Subject: [Python-Dev] Notification for buildbot builder changes for slaves?
Message-ID: <m24o6ktf0c.fsf@valheru.db3l.homeip.net>

I was wondering if it might be possible to have a channel (message
here, email to a list of slave owners or whatever) to mention when the
set of builders for the slaves is getting adjusted?  A new builder
tree can burn a good deal of disk space in some cases for example
(each tree adds in the neighborhood of .5GB for each of my Windows
buildbots), and while it's generally not an issue, the recent
conversion to hg actually exhausted my disk space on several slaves,
for example.

I'm not looking to get in the way of any process - just have a way to
hear about such changes in advance when possible in case I need to
make adjustments.

Thanks.

-- David


From a.badger at gmail.com  Thu Mar 31 00:39:29 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 30 Mar 2011 15:39:29 -0700
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <AANLkTi=e3pHKco4xTpWXDbkNj=kPHEwGhG75mBEnQkoF@mail.gmail.com>
References: <4D92239D.5070908@voidspace.org.uk>
	<1301430194.30032.9.camel@marge>
	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>
	<1301432147.30032.14.camel@marge>
	<20110330055438.GB15288@unaka.lan>
	<AANLkTi=e3pHKco4xTpWXDbkNj=kPHEwGhG75mBEnQkoF@mail.gmail.com>
Message-ID: <20110330223929.GC15288@unaka.lan>

On Wed, Mar 30, 2011 at 08:36:43AM +0200, Lennart Regebro wrote:
> On Wed, Mar 30, 2011 at 07:54, Toshio Kuratomi <a.badger at gmail.com> wrote:
> > Lennart is missing that you just need to use the same encoding
> > + surrogateescape (or stick with bytes) for decoding the byte strings that
> > you are comparing.
> 
> You lost me here. I need to do this for what?
"""
The lesson here seems to be "if you have to use blacklists, and you
use unicode strings for those blacklists, also make sure the string
you compare with doesn't have surrogates".>
"""

Really, surrogates are a red herring to this whole issue.  The issue is that
the original code was trying to compare two different transformations of
byte sequences and expecting them to be equal.  Let's say that you have the
following byte value::
  b_test_value = b'\xa4\xaf'

This is something that's stored in a file or the filename of something on
a unix filesystem or stored in a database or any number of other things.
Now you want to compare that to another piece of data that you've read in
from somewhere outside of python.  You'd expect any of the following to
work::
  b_test_value == b_other_byte_value
  b_test_value.encode('utf-8', 'surrogateescape') == b_other_byte_value('utf-8', 'surrogateescape')
  b_test_value.encode('latin-1') == b_other_byte_value('latin-1')
  b_test_value.encode('euc_jp') == b_other_byte_value('euc_jp')

You wouldn't expect this to work::
  b_test_value.encode('latin-1') == b_other_byte_value('euc_jp')

Once you see that, you realize that the following is only a specific case of
the former, surrogateescape doesn't really matter::
  b_test_value.encode('utf-8', 'surrogateescape') == b_other_byte_value('euc_jp')

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110330/c52ddc69/attachment.pgp>

From ncoghlan at gmail.com  Thu Mar 31 00:54:41 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 31 Mar 2011 08:54:41 +1000
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <in07nd$5nb$1@dough.gmane.org>
References: <in07nd$5nb$1@dough.gmane.org>
Message-ID: <AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>

On Thu, Mar 31, 2011 at 7:35 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> The tracker was recently changed so that when I click on a link to a tracker
> page, the page is properly displayed, but then a fraction of a second it
> blinks and redisplays with the edit form hidden. This is so obnoxious to me
> that I no longer want to visit the tracker. Then I have to find and click
> the button to get back the edit form that I nearly always want to see, as I
> often make changes. All this to compress the page by half a screen, which
> makes almost no difference once one grabs the scrollbar anyway.

Interesting - it comes straight up with the folded screen for me, no
flickering at all.

It may depend on how a given browser handles the scripts involved.

> If someone actually considers this a desired feature, after using it, then
> please add a field on the profile page to select autofolding or not. Also,
> there should be a button to fold as well as one to unfold.

Skip objected to the amount of noise at the top of the tracker screen,
so I assume whoever added the feature was doing so in response to that
concern. Since it doesn't flicker for me, I actually found it to be an
elegant solution.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From raymond.hettinger at gmail.com  Thu Mar 31 01:05:59 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 30 Mar 2011 16:05:59 -0700
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <in07nd$5nb$1@dough.gmane.org>
References: <in07nd$5nb$1@dough.gmane.org>
Message-ID: <64E90C5F-0B7A-43FF-BC5B-A38A7A1F9034@gmail.com>


On Mar 30, 2011, at 2:35 PM, Terry Reedy wrote:

> The tracker was recently changed so that when I click on a link to a tracker page, the page is properly displayed, but then a fraction of a second it blinks and redisplays with the edit form hidden. This is so obnoxious to me that I no longer want to visit the tracker. Then I have to find and click the button to get back the edit form that I nearly always want to see, as I often make changes. All this to compress the page by half a screen, which makes almost no difference once one grabs the scrollbar anyway.

Same thing happening here (Google Chrome browser running on Snow Leopard).
I also find it weird and irritating.


> If someone actually considers this a desired feature, after using it, then please add a field on the profile page to select autofolding or not. Also, there should be a button to fold as well as one to unfold.

+1


Raymond

From hodgestar+pythondev at gmail.com  Thu Mar 31 01:17:57 2011
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Thu, 31 Mar 2011 01:17:57 +0200
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
References: <in07nd$5nb$1@dough.gmane.org>
	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
Message-ID: <AANLkTi=CYVA4-Uk76UMEnp+pd0AKFbz13gE-hWSN175=@mail.gmail.com>

On Thu, Mar 31, 2011 at 12:54 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Interesting - it comes straight up with the folded screen for me, no
> flickering at all.

I didn't get any flicker either and my first impression of the change
was also positive -- I usually skip straight to the comments the first
time I visit an issue.

Schiavo
Simon

From solipsis at pitrou.net  Thu Mar 31 01:32:08 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 31 Mar 2011 01:32:08 +0200
Subject: [Python-Dev] Please revert autofolding of tracker edit form
References: <in07nd$5nb$1@dough.gmane.org>
	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
Message-ID: <20110331013208.0a708867@pitrou.net>

On Thu, 31 Mar 2011 08:54:41 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Thu, Mar 31, 2011 at 7:35 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> > The tracker was recently changed so that when I click on a link to a tracker
> > page, the page is properly displayed, but then a fraction of a second it
> > blinks and redisplays with the edit form hidden. This is so obnoxious to me
> > that I no longer want to visit the tracker. Then I have to find and click
> > the button to get back the edit form that I nearly always want to see, as I
> > often make changes. All this to compress the page by half a screen, which
> > makes almost no difference once one grabs the scrollbar anyway.
> 
> Interesting - it comes straight up with the folded screen for me, no
> flickering at all.

It has flickered occasionally here (Firefox 4).

> It may depend on how a given browser handles the scripts involved.

Or how fast they get loaded compared to the main HTML, which can then
interact with some redraw timers in your browser or whatever else.

> > If someone actually considers this a desired feature, after using it, then
> > please add a field on the profile page to select autofolding or not. Also,
> > there should be a button to fold as well as one to unfold.
> 
> Skip objected to the amount of noise at the top of the tracker screen,
> so I assume whoever added the feature was doing so in response to that
> concern. Since it doesn't flicker for me, I actually found it to be an
> elegant solution.

There's a lot of "noise" but that noise is useful. I find the
natural language summary to be much too terse and doesn't make it easy
to visualize said information as opposed to the form fields.
What's more, it lacks the most important: the issue title.

Regards

Antoine.



From skip at pobox.com  Thu Mar 31 02:43:21 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 30 Mar 2011 19:43:21 -0500
Subject: [Python-Dev] Documenting the buildbots
In-Reply-To: <BANLkTi=9--Z_c4W33RYn3nff01x2X1wgHQ@mail.gmail.com>
References: <1301500742.4065.11.camel@marge>
	<20110330230100.51d170a1@pitrou.net>
	<BANLkTi=9--Z_c4W33RYn3nff01x2X1wgHQ@mail.gmail.com>
Message-ID: <19859.52777.208699.502715@montanaro.dyndns.org>


    >> For the record, I added a page documenting our continuous integration
    >> setup at: http://docs.python.org/devguide/buildbots.html

    Jesse> that's awesome. should we document how to donate/add a buildbot
    Jesse> somewhere in the same section (or alongside)?

I must admit, it wasn't obvious to me where the link to this page exists in
the devguide.  Also, I see a link to this page:

  http://python.org/dev/buildbot/

labelled "buildbot status".  Should it link back to Antoine's new page?

S

From victor.stinner at haypocalc.com  Thu Mar 31 03:54:34 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 31 Mar 2011 03:54:34 +0200
Subject: [Python-Dev] faulthandler is now part of Python 3.3
Message-ID: <1301536474.23107.16.camel@marge>

Hi,

I pushed my faulthandler module into the default branch (Python 3.3).
Since one week, I fixed a lot of bugs (platform issues), improved the
tests and Antoine wrote a new implementation of dump_backtraces_later()
using a thread (instead of SIGALRM+alarm()). It should now work on all
platforms (but register() is not available on Windows).

Use "python -X faulthandler" or "PYTHONFAULTHANDLER=1 python" to install
the fault handler at startup (catch segfaults and other fatal errors).

You can also register a signal (e.g. SIGUSR1) to dump the traceback on
this signal.

The latest added feature is to be able to the dump the traceback after a
timeout and exit the process: we may use it on regrtest.py to learn more
about test_multiprocess and test_threadsignals hangs. Issue #11393 has a
patch implementing this issue: add --timeout option to regrtest.py. You
can also just dump the traceback after the timeout without exiting.

Py_FatalError() always print the Python traceback (except if an
exception was raised: print the exception with its traceback).

For more information, read the doc:
http://docs.python.org/dev/library/faulthandler.html

Please tell me if you have any issue related to faulthandler.

--

If you get "undefined reference to `_PyFaulthandler_Init'" compiler
error, copy Modules/Setup.dist to Modules/Setup (cp Modules/Setup.dist
Modules/Setup).

test_faulthandler hangs on AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana
3.x. It looks to be related to the stack overflow test (the stack is
maybe not limited on these buildbots?). I have a patch, but I cannot
test it because these buildbots are dead (oops, sorry!).

Most buildbots are red because a regression in test_logging (since 2
days): I disabled temporary the test (issue #11557), I hope that the
situation will be better in a few hours.

Thank you Antoine for your reviews!

Victor


From tjreedy at udel.edu  Thu Mar 31 04:08:09 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 30 Mar 2011 22:08:09 -0400
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <20110331013208.0a708867@pitrou.net>
References: <in07nd$5nb$1@dough.gmane.org>	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
	<20110331013208.0a708867@pitrou.net>
Message-ID: <in0nm8$m0u$1@dough.gmane.org>

On 3/30/2011 7:32 PM, Antoine Pitrou wrote:

> There's a lot of "noise" but that noise is useful. I find the
> natural language summary to be much too terse and doesn't make it easy
> to visualize said information as opposed to the form fields.

Yes, there is a good reason why database records are routinely displayed 
in labeled and located fields rather than in variable length natural 
language sentences with a monochrome font. Form letters, of course, are 
an exception.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Thu Mar 31 04:30:43 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 30 Mar 2011 22:30:43 -0400
Subject: [Python-Dev] Security implications of pep 383
In-Reply-To: <20110330223929.GC15288@unaka.lan>
References: <4D92239D.5070908@voidspace.org.uk>	<1301430194.30032.9.camel@marge>	<AANLkTik8AqdEV8QjV+o3tFpG1QtQ9CxJJCuTbLyGGisk@mail.gmail.com>	<1301432147.30032.14.camel@marge>	<20110330055438.GB15288@unaka.lan>	<AANLkTi=e3pHKco4xTpWXDbkNj=kPHEwGhG75mBEnQkoF@mail.gmail.com>
	<20110330223929.GC15288@unaka.lan>
Message-ID: <in0p0i$rvn$1@dough.gmane.org>

On 3/30/2011 6:39 PM, Toshio Kuratomi wrote:

> Really, surrogates are a red herring to this whole issue.  The issue is that
> the original code was trying to compare two different transformations of
> byte sequences and expecting them to be equal.  Let's say that you have the
> following byte value::
>    b_test_value = b'\xa4\xaf'
>
> This is something that's stored in a file or the filename of something on
> a unix filesystem or stored in a database or any number of other things.
> Now you want to compare that to another piece of data that you've read in
> from somewhere outside of python.  You'd expect any of the following to
> work::
>    b_test_value == b_other_byte_value
>    b_test_value.encode('utf-8', 'surrogateescape') == b_other_byte_value('utf-8', 'surrogateescape')
>    b_test_value.encode('latin-1') == b_other_byte_value('latin-1')
>    b_test_value.encode('euc_jp') == b_other_byte_value('euc_jp')
>
> You wouldn't expect this to work::
>    b_test_value.encode('latin-1') == b_other_byte_value('euc_jp')
>
> Once you see that, you realize that the following is only a specific case of
> the former, surrogateescape doesn't really matter::
>    b_test_value.encode('utf-8', 'surrogateescape') == b_other_byte_value('euc_jp')

All the encodes above should be decodes instead. Aside from that. your 
point is correct, and not limited to CS. The whole art of disguise, for 
instance, is about effecting a transformation to falsely pass or fail an 
identity or equality comparison.

-- 
Terry Jan Reedy


From rdmurray at bitdance.com  Thu Mar 31 06:05:13 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 31 Mar 2011 00:05:13 -0400
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
References: <in07nd$5nb$1@dough.gmane.org>
	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
Message-ID: <20110331040513.A82B54B71F@kimball.webabinitio.net>

On Thu, 31 Mar 2011 08:54:41 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Thu, Mar 31, 2011 at 7:35 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> > If someone actually considers this a desired feature, after using it, then
> > please add a field on the profile page to select autofolding or not. Also,
> > there should be a button to fold as well as one to unfold.
> 
> Skip objected to the amount of noise at the top of the tracker screen,
> so I assume whoever added the feature was doing so in response to that
> concern. Since it doesn't flicker for me, I actually found it to be an
> elegant solution.

Flicker or not, I don't like it myself.  I've turned off javascript on
bugs.python.org in my browser, and now it doesn't bother me anymore.
But I don't think that is a good long term solution.  Making it optional
based on a setting in the user profile might be OK.

--
R. David Murray           http://www.bitdance.com

From mhammond at skippinet.com.au  Thu Mar 31 06:31:01 2011
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Thu, 31 Mar 2011 15:31:01 +1100
Subject: [Python-Dev] Non-code changes on "old" branches
Message-ID: <4D940385.6050805@skippinet.com.au>

Hi,
   There are a couple of changes I'd like to make and would like some 
guidance on policy:

http://bugs.python.org/issue6498 is a documentation bug which exists in 
Python 2.6 and later.  The patch in that bug touches the docs and a 
comment in one source file.  Is it acceptable to push that change to the 
2.6 branch, or should I start with 2.7?

My request re .hgignore from yesterday didn't get any complaints, so I 
intend opening a bug, asking for review here and if I don't get 
objections in a day or so, pushing the change.  This really should go 
all the way back to 2.5 even though that release has long been closed. 
Is it acceptable to push a change to .hgignore to the 2.5 branch?  If 
not, where should I start with such a change?

I ask these questions primarily as the dev guide tells me I should 
forward-port all changes - thus, I need to know the earliest versions I 
can use before I can even start the process...

Thanks,

Mark

From fdrake at acm.org  Thu Mar 31 12:16:42 2011
From: fdrake at acm.org (Fred Drake)
Date: Thu, 31 Mar 2011 06:16:42 -0400
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <in0nm8$m0u$1@dough.gmane.org>
References: <in07nd$5nb$1@dough.gmane.org>
	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
	<20110331013208.0a708867@pitrou.net> <in0nm8$m0u$1@dough.gmane.org>
Message-ID: <AANLkTinargcusSrm=TK-gofvP08ikLa83oTH6=CuJGbh@mail.gmail.com>

On Wed, Mar 30, 2011 at 10:08 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Yes, there is a good reason why database records are routinely displayed in
> labeled and located fields rather than in variable length natural language
> sentences with a monochrome font. Form letters, of course, are an exception.

Yep.

While I'm fine with folding away some of the verbose fields, the
current implementation is jarring.  I also get the flicker before the
fold happens, but the sentence describing status doesn't seem like a
good idea for regular users.  I would expect only the "second box"
from the top to get folded.

Making folding a per-user setting would be appropriate.


-- 
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"Give me the luxuries of life and I will willingly do without the necessities."
?? --Frank Lloyd Wright

From skip at pobox.com  Thu Mar 31 12:50:58 2011
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 31 Mar 2011 05:50:58 -0500
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <20110331040513.A82B54B71F@kimball.webabinitio.net>
References: <in07nd$5nb$1@dough.gmane.org>
	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
	<20110331040513.A82B54B71F@kimball.webabinitio.net>
Message-ID: <19860.23698.260679.739252@montanaro.dyndns.org>

Please see this thread in the tracker-discuss list:

    http://mail.python.org/pipermail/tracker-discuss/2011-March/thread.html

Skip

From skip at pobox.com  Thu Mar 31 13:20:03 2011
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 31 Mar 2011 06:20:03 -0500
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <19860.23698.260679.739252@montanaro.dyndns.org>
References: <in07nd$5nb$1@dough.gmane.org>
	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
	<20110331040513.A82B54B71F@kimball.webabinitio.net>
	<19860.23698.260679.739252@montanaro.dyndns.org>
Message-ID: <19860.25443.131458.388306@montanaro.dyndns.org>


    skip> Please see this thread in the tracker-discuss list:
    skip>     http://mail.python.org/pipermail/tracker-discuss/2011-March/thread.html

That didn't read right.  I meant see that thread to see other discussion
about the folding topic, not that it would necessary convince you all to
change your minds.

I'd still like to see some folding, but more selective and with closer
attention paid to the current stage of the issue.

Skip

From solipsis at pitrou.net  Thu Mar 31 14:16:12 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 31 Mar 2011 14:16:12 +0200
Subject: [Python-Dev] Please revert autofolding of tracker edit form
References: <in07nd$5nb$1@dough.gmane.org>
	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
	<20110331040513.A82B54B71F@kimball.webabinitio.net>
	<19860.23698.260679.739252@montanaro.dyndns.org>
	<19860.25443.131458.388306@montanaro.dyndns.org>
Message-ID: <20110331141612.5ad2097a@pitrou.net>

On Thu, 31 Mar 2011 06:20:03 -0500
skip at pobox.com wrote:
> 
>     skip> Please see this thread in the tracker-discuss list:
>     skip>     http://mail.python.org/pipermail/tracker-discuss/2011-March/thread.html
> 
> That didn't read right.  I meant see that thread to see other discussion
> about the folding topic, not that it would necessary convince you all to
> change your minds.
> 
> I'd still like to see some folding, but more selective and with closer
> attention paid to the current stage of the issue.

Agreed that some folding could be beneficial, but with a better UI
(no flickering, use of a jQuery-alike recommended). Also, field-based
visualization of tracker properties should be retained in the
"minimized" form, instead of natural language.

It would be nice if someone with UI design experience was interested in
maintaining/improving the tracker.

Regards

Antoine.



From tseaver at palladion.com  Thu Mar 31 14:47:52 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 31 Mar 2011 08:47:52 -0400
Subject: [Python-Dev] faulthandler is now part of Python 3.3
In-Reply-To: <1301536474.23107.16.camel@marge>
References: <1301536474.23107.16.camel@marge>
Message-ID: <in1t5o$lal$2@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/30/2011 09:54 PM, Victor Stinner wrote:
> Hi,
> 
> I pushed my faulthandler module into the default branch (Python 3.3).
> Since one week, I fixed a lot of bugs (platform issues), improved the
> tests and Antoine wrote a new implementation of dump_backtraces_later()
> using a thread (instead of SIGALRM+alarm()). It should now work on all
> platforms (but register() is not available on Windows).
> 
> Use "python -X faulthandler" or "PYTHONFAULTHANDLER=1 python" to install
> the fault handler at startup (catch segfaults and other fatal errors).
> 
> You can also register a signal (e.g. SIGUSR1) to dump the traceback on
> this signal.
> 
> The latest added feature is to be able to the dump the traceback after a
> timeout and exit the process: we may use it on regrtest.py to learn more
> about test_multiprocess and test_threadsignals hangs. Issue #11393 has a
> patch implementing this issue: add --timeout option to regrtest.py. You
> can also just dump the traceback after the timeout without exiting.
> 
> Py_FatalError() always print the Python traceback (except if an
> exception was raised: print the exception with its traceback).
> 
> For more information, read the doc:
> http://docs.python.org/dev/library/faulthandler.html
> 
> Please tell me if you have any issue related to faulthandler.
> 
> --
> 
> If you get "undefined reference to `_PyFaulthandler_Init'" compiler
> error, copy Modules/Setup.dist to Modules/Setup (cp Modules/Setup.dist
> Modules/Setup).
> 
> test_faulthandler hangs on AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana
> 3.x. It looks to be related to the stack overflow test (the stack is
> maybe not limited on these buildbots?). I have a patch, but I cannot
> test it because these buildbots are dead (oops, sorry!).
> 
> Most buildbots are red because a regression in test_logging (since 2
> days): I disabled temporary the test (issue #11557), I hope that the
> situation will be better in a few hours.
> 
> Thank you Antoine for your reviews!

Thanks very much for you hard work on this cool new feature.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Ud/gACgkQ+gerLs4ltQ6BVACgo822OajfnxbVQInroX8q5L7B
wX0AoMpEJLNk0ffEBJs+C2CDXiaIz+yf
=rf2C
-----END PGP SIGNATURE-----


From tjreedy at udel.edu  Thu Mar 31 14:56:54 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 31 Mar 2011 08:56:54 -0400
Subject: [Python-Dev] Non-code changes on "old" branches
In-Reply-To: <4D940385.6050805@skippinet.com.au>
References: <4D940385.6050805@skippinet.com.au>
Message-ID: <in1tmk$qqe$1@dough.gmane.org>

On 3/31/2011 12:31 AM, Mark Hammond wrote:
> Hi,
> There are a couple of changes I'd like to make and would like some
> guidance on policy:
>
> http://bugs.python.org/issue6498 is a documentation bug which exists in
> Python 2.6 and later. The patch in that bug touches the docs and a
> comment in one source file. Is it acceptable to push that change to the
> 2.6 branch, or should I start with 2.7?

I believe no, not 2.6, lest you be asked to revert.
Start with 2.7

-- 
Terry Jan Reedy


From palla74 at gmail.com  Thu Mar 31 15:15:17 2011
From: palla74 at gmail.com (Palla)
Date: Thu, 31 Mar 2011 15:15:17 +0200
Subject: [Python-Dev] EuroPython 2011: call for paper is ending - Please
	spread the word!
Message-ID: <AANLkTi=5ZtTNQ81Mw0pRrqC3=XjLxgsDrjxujdybcgRc@mail.gmail.com>

Hi all members,
I'm Francesco and I am writing on behalf of "Python Italia APS", a no-profit
association promoting EuroPython conference. (www.europython.eu)

Europython End of Call for Presentations is April 6th. I'd like to ask to
you to forward this mail to anyone that you feel may be interested.

We're looking for proposals on every aspects of Python: programming from
novice to advanced levels, applications and frameworks, or how you have been
involved in introducing Python into your organisation.

**First-time speakers are especially welcome**; EuroPython is a community
conference and we are eager to hear about your experience. If you have
friends or colleagues who have something valuable to contribute, twist their
arms to tell us about it!


Presenting at EuroPython
------------------------
We will accept a broad range of presentations, from reports on academic and
commercial projects to tutorials and case studies. As long as the
presentation is interesting and potentially useful to the Python community,
it will be considered for inclusion in the programme.

Can you show the conference-goers something new and useful? Can you show
attendees how to: use a module? Explore a Python language feature? Package
an application? If so, consider submitting a talk.


Talks and hands-on trainings
----------------------------
There are two different kind of presentations that you can give as a speaker
at EuroPython:

 * **Regular talk**. These are standard "talk with slides", allocated in
slots of 45, 60 or 90 minutes, depending on your preference and scheduling
constraints. A Q&A session is held at the end of the talk.
 * **Hands-on training**. These are advanced training sessions for a smaller
audience (10-20 people), to dive into the subject with all details. These
sessions are 4-hours long, and audience will be strongly encouraged to bring
a laptop to experiment. They should be prepared with less slides and more
source code. If possible, trainers will also give a short "teaser talk" of
30 minutes the day before the training, to tease delegates into attending
the training.

In the talk submission form, we assume that you intend to give a regular
talk on the subject, but you will be asked if you are available for also
doing a hands-on training on the very same subject.

Speakers that will give a hands-on training are rewarded with a **free
entrance** to EuroPython to compensate for the longer preparation required,
and might also be eligible for a speaking fee (which we cannot confirm at
the moment).

Topics and goals
----------------
Specific topics for EuroPython presentations include, but are not limited
to:

- Core Python
- Other implementations: Jython, IronPython, PyPy, and Stackless
- Python libraries and extensions
- Python 3.x migration
- Databases
- Documentation
- GUI Programming
- Game Programming
- Network Programming
- Open Source Python projects
- Packaging Issues
- Programming Tools
- Project Best Practices
- Embedding and Extending
- Science and Math
- Web-based Systems

Presentation goals usually are some of the following:

- Introduce audience to a new topic they are unaware of
- Introduce audience to new developments on a well-known topic
- Show audience real-world usage scenarios for a specific topic (case study)
- Dig into advanced and relatively-unknown details on a topic
- Compare different options in the market on a topic


Community-based talk voting
---------------------------
This year, for the first time in EuroPython history, the talk voting process
is fully public. Every partecipant gains the right to vote for talks
submitted during the Call For Papers, as soon as they commit to their
presence at the conference by buying a ticket. See all the details in the
talk voting[1] page.

Contacts
--------
For any further question, feel free to contact the organizers at
info at pycon.it. Thank you!

[1]: http://ep2011.europython.eu/talk-voting


-- 
->PALLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110331/051a9e8e/attachment.html>

From ncoghlan at gmail.com  Thu Mar 31 15:48:02 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 31 Mar 2011 23:48:02 +1000
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <20110331141612.5ad2097a@pitrou.net>
References: <in07nd$5nb$1@dough.gmane.org>
	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
	<20110331040513.A82B54B71F@kimball.webabinitio.net>
	<19860.23698.260679.739252@montanaro.dyndns.org>
	<19860.25443.131458.388306@montanaro.dyndns.org>
	<20110331141612.5ad2097a@pitrou.net>
Message-ID: <AANLkTik927x3CBJHdrXBuGNkOhtZCV9NSS7A_4UHnaoB@mail.gmail.com>

On Thu, Mar 31, 2011 at 10:16 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> It would be nice if someone with UI design experience was interested in
> maintaining/improving the tracker.

The challenge is the same as with any UI designer involvement in open
source stuff though: they really need to be given the freedom to do
proper workflow analysis and come up with something that *works*, but
in practice things tend to get derailed into endless bikeshed
arguments, since *everyone* has an opinion on the UI design of the
tools they have to use.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Thu Mar 31 15:59:19 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 31 Mar 2011 15:59:19 +0200
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <AANLkTik927x3CBJHdrXBuGNkOhtZCV9NSS7A_4UHnaoB@mail.gmail.com>
References: <in07nd$5nb$1@dough.gmane.org>
	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
	<20110331040513.A82B54B71F@kimball.webabinitio.net>
	<19860.23698.260679.739252@montanaro.dyndns.org>
	<19860.25443.131458.388306@montanaro.dyndns.org>
	<20110331141612.5ad2097a@pitrou.net>
	<AANLkTik927x3CBJHdrXBuGNkOhtZCV9NSS7A_4UHnaoB@mail.gmail.com>
Message-ID: <1301579959.3535.10.camel@localhost.localdomain>

Le jeudi 31 mars 2011 ? 23:48 +1000, Nick Coghlan a ?crit :
> On Thu, Mar 31, 2011 at 10:16 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > It would be nice if someone with UI design experience was interested in
> > maintaining/improving the tracker.
> 
> The challenge is the same as with any UI designer involvement in open
> source stuff though: they really need to be given the freedom to do
> proper workflow analysis and come up with something that *works*, but
> in practice things tend to get derailed into endless bikeshed
> arguments, since *everyone* has an opinion on the UI design of the
> tools they have to use.

Well, obviously they have, since they are users and are directly
impacted by any changes.
The line this draws is between clean-sheet design and iterative
improvement. Clearly it would be difficult to try to sell us a wholesale
change in how the issue tracker organizes things.

(AFAIK, Roundup itself comes from a platonic, clean-sheet design of an
ideal bug tracker: we had to customize it a lot)

Regards

Antoine.



From benjamin at python.org  Thu Mar 31 17:01:49 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 31 Mar 2011 10:01:49 -0500
Subject: [Python-Dev] faulthandler is now part of Python 3.3
In-Reply-To: <in1t5o$lal$2@dough.gmane.org>
References: <1301536474.23107.16.camel@marge>
	<in1t5o$lal$2@dough.gmane.org>
Message-ID: <AANLkTimYKKxVdHzdO1SWYHPVXqSJS7D_CSC49-vhFYg1@mail.gmail.com>

2011/3/31 Tres Seaver <tseaver at palladion.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/30/2011 09:54 PM, Victor Stinner wrote:
>> Hi,
>>
>> I pushed my faulthandler module into the default branch (Python 3.3).
>> Since one week, I fixed a lot of bugs (platform issues), improved the
>> tests and Antoine wrote a new implementation of dump_backtraces_later()
>> using a thread (instead of SIGALRM+alarm()). It should now work on all
>> platforms (but register() is not available on Windows).
>>
>> Use "python -X faulthandler" or "PYTHONFAULTHANDLER=1 python" to install
>> the fault handler at startup (catch segfaults and other fatal errors).
>>
>> You can also register a signal (e.g. SIGUSR1) to dump the traceback on
>> this signal.
>>
>> The latest added feature is to be able to the dump the traceback after a
>> timeout and exit the process: we may use it on regrtest.py to learn more
>> about test_multiprocess and test_threadsignals hangs. Issue #11393 has a
>> patch implementing this issue: add --timeout option to regrtest.py. You
>> can also just dump the traceback after the timeout without exiting.
>>
>> Py_FatalError() always print the Python traceback (except if an
>> exception was raised: print the exception with its traceback).
>>
>> For more information, read the doc:
>> http://docs.python.org/dev/library/faulthandler.html
>>
>> Please tell me if you have any issue related to faulthandler.
>>
>> --
>>
>> If you get "undefined reference to `_PyFaulthandler_Init'" compiler
>> error, copy Modules/Setup.dist to Modules/Setup (cp Modules/Setup.dist
>> Modules/Setup).
>>
>> test_faulthandler hangs on AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana
>> 3.x. It looks to be related to the stack overflow test (the stack is
>> maybe not limited on these buildbots?). I have a patch, but I cannot
>> test it because these buildbots are dead (oops, sorry!).
>>
>> Most buildbots are red because a regression in test_logging (since 2
>> days): I disabled temporary the test (issue #11557), I hope that the
>> situation will be better in a few hours.
>>
>> Thank you Antoine for your reviews!
>
> Thanks very much for you hard work on this cool new feature.

Furthermore, let's hope we don't have to use it much! :)



-- 
Regards,
Benjamin

From ezio.melotti at gmail.com  Thu Mar 31 17:47:39 2011
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Thu, 31 Mar 2011 18:47:39 +0300
Subject: [Python-Dev] devguide: Add a table of contents to the FAQ.
In-Reply-To: <20110330222004.5b23bcc5@pitrou.net>
References: <E1Q4e9O-0001X5-Jr@dinsdale.python.org>
	<20110330222004.5b23bcc5@pitrou.net>
Message-ID: <4D94A21B.9040501@gmail.com>

On 30/03/2011 23.20, Antoine Pitrou wrote:
> On Tue, 29 Mar 2011 21:00:22 +0200
> ezio.melotti<python-checkins at python.org>  wrote:
>> http://hg.python.org/devguide/rev/f722956afeac
>> changeset:   405:f722956afeac
>> user:        Ezio Melotti
>> date:        Tue Mar 29 22:00:13 2011 +0300
>> summary:
>>    Add a table of contents to the FAQ.
> Could it be collapsed by default?

I don't think there's an easy way to collapse it by default.
In most of the cases I anyway check the FAQ for something specific.  
Having a list at the top provides an overview of the questions and also 
an easy way to locate and jump to the right answer.

>   It's quite long, and redundant with the sidebar.

The list is indeed redundant, but the sidebar is not really usable here.

Best Regards,
Ezio Melotti

> thanks
>
> Antoine.
>


From rdmurray at bitdance.com  Thu Mar 31 18:34:26 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 31 Mar 2011 12:34:26 -0400
Subject: [Python-Dev] devguide: Add a table of contents to the FAQ.
In-Reply-To: <4D94A21B.9040501@gmail.com>
References: <E1Q4e9O-0001X5-Jr@dinsdale.python.org>
	<20110330222004.5b23bcc5@pitrou.net> <4D94A21B.9040501@gmail.com>
Message-ID: <20110331163426.C4ABCD64A7@kimball.webabinitio.net>

On Thu, 31 Mar 2011 18:47:39 +0300, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> On 30/03/2011 23.20, Antoine Pitrou wrote:
> > On Tue, 29 Mar 2011 21:00:22 +0200
> > ezio.melotti<python-checkins at python.org>  wrote:
> >> http://hg.python.org/devguide/rev/f722956afeac
> >> changeset:   405:f722956afeac
> >> user:        Ezio Melotti
> >> date:        Tue Mar 29 22:00:13 2011 +0300
> >> summary:
> >>    Add a table of contents to the FAQ.
> > Could it be collapsed by default?
> 
> I don't think there's an easy way to collapse it by default.
> In most of the cases I anyway check the FAQ for something specific.  
> Having a list at the top provides an overview of the questions and also 
> an easy way to locate and jump to the right answer.
> 
> >   It's quite long, and redundant with the sidebar.
> 
> The list is indeed redundant, but the sidebar is not really usable here.

I agree with this point.  The sidebar list of questions is effectively
useless.

Most FAQ lists start with the long list of questions.  I don't see
why this one should be different :)

--
R. David Murray           http://www.bitdance.com

From victor.stinner at haypocalc.com  Thu Mar 31 18:35:43 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 31 Mar 2011 18:35:43 +0200
Subject: [Python-Dev] Use regrtest.py --timeout on buildbots
Message-ID: <1301589343.29322.7.camel@marge>

Hi,

I just added a --timeout option to Lib/test/regrtest.py: if a test (one
function, not a whole file) takes more than TIMEOUT seconds, the
traceback is dumped and it exits. I tested it on 3 buildbots with a
timeout of 5 minutes and it worked as expected: see #11727 for
examples. 

It would be nice to have this feature enabled on all buildbots.

We may set a default timeout of 15 minutes. If a test takes more than 15
minutes, something goes wrong! Some buildbot use a timeout of 1200 or
3600 seconds for regrtest (all tests). But the build slave should be
able to override the default timeout.

What do you think?

Victor


From tjreedy at udel.edu  Thu Mar 31 18:52:23 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 31 Mar 2011 12:52:23 -0400
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <1301579959.3535.10.camel@localhost.localdomain>
References: <in07nd$5nb$1@dough.gmane.org>	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>	<20110331040513.A82B54B71F@kimball.webabinitio.net>	<19860.23698.260679.739252@montanaro.dyndns.org>	<19860.25443.131458.388306@montanaro.dyndns.org>	<20110331141612.5ad2097a@pitrou.net>	<AANLkTik927x3CBJHdrXBuGNkOhtZCV9NSS7A_4UHnaoB@mail.gmail.com>
	<1301579959.3535.10.camel@localhost.localdomain>
Message-ID: <in2bg7$v5q$1@dough.gmane.org>

On 3/31/2011 9:59 AM, Antoine Pitrou wrote:
> Le jeudi 31 mars 2011 ? 23:48 +1000, Nick Coghlan a ?crit :
>> On Thu, Mar 31, 2011 at 10:16 PM, Antoine Pitrou<solipsis at pitrou.net>  wrote:
>>> It would be nice if someone with UI design experience was interested in
>>> maintaining/improving the tracker.
>>
>> The challenge is the same as with any UI designer involvement in open
>> source stuff though: they really need to be given the freedom to do
>> proper workflow analysis and come up with something that *works*, but
>> in practice things tend to get derailed into endless bikeshed
>> arguments, since *everyone* has an opinion on the UI design of the
>> tools they have to use.
>
> Well, obviously they have, since they are users and are directly
> impacted by any changes.
> The line this draws is between clean-sheet design and iterative
> improvement. Clearly it would be difficult to try to sell us a wholesale
> change in how the issue tracker organizes things.

Here is my proposal for a redesign based on an analysis of my usage ;-).
I have a 1600x1050 (or thereabouts), 20" (measured) diagonal, 17" across 
screen.

The left column has a 7/8" margin, 2 3/8" text area, and 1" gutter. 
These could be shrunk to say, 1/4, 2, 1/4, saving 1 3/8".
The comment box is 8 1/2", message boxes are wider, but the extra width 
is not used if one uses hard returns in the comment box. In any case, 
the message boxes could be narrowed by 1 1/8".
This would allow a right column of 1/4+2+1/4".

Except for title, comment, and file boxes, we then stack the 
classification and process boxes in the right column.
The nosy box would be last so it can list one name per line.
It would end with an [ add  me ] button. It should also have a box for 
adding people (as with Assigned To). Having to look up tracker names in 
Assigned To and retype exactly in the nosy list is an error-prone 
nuisance. Putting all these boxes to the side leaves them visible for 
those who want them but out of the way and ignorable for those who do not.

I would be nice is both the left and right columns had buttons to hide 
and show. This would help people accessing issues from smaller screens, 
as with a netbook.

The title is not really classification and belongs at the very top. It 
could even go in the 1 1/8" top bar, which is currently mostly empty, 
along with the issue number.

I would like to try putting the comment box after the last (most recent) 
comment, as that is the message one most ofter responds to. Having to 
now scroll up and down between comment box and last message(s) is often 
of a nuisance.

-- 
Terry Jan Reedy



From merwok at netwok.org  Thu Mar 31 19:35:09 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 31 Mar 2011 19:35:09 +0200
Subject: [Python-Dev] Issue 11715: building Python from source on
 multiarch Debian/Ubuntu
In-Reply-To: <20110330161709.756b27f7@neurotica.wooz.org>
References: <20110330161709.756b27f7@neurotica.wooz.org>
Message-ID: <4D94BB4D.8030405@netwok.org>

> I would like to apply this patch (or its moral equivalent) to all active,
> affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as
> soon as possible.  Without this, it will be very difficult for anyone on
> future Ubuntu or Debian releases to build Python.  Since it's not a new
> feature, but just a minor fix to the build process, I think it should be okay
> to back port.

If I understand the policy correctly, 2.5 and 2.6 are not considered
active branches, so any doc, build or bug fixes are not acceptable.

Regards

From ezio.melotti at gmail.com  Thu Mar 31 19:30:28 2011
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Thu, 31 Mar 2011 20:30:28 +0300
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <in2bg7$v5q$1@dough.gmane.org>
References: <in07nd$5nb$1@dough.gmane.org>	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>	<20110331040513.A82B54B71F@kimball.webabinitio.net>	<19860.23698.260679.739252@montanaro.dyndns.org>	<19860.25443.131458.388306@montanaro.dyndns.org>	<20110331141612.5ad2097a@pitrou.net>	<AANLkTik927x3CBJHdrXBuGNkOhtZCV9NSS7A_4UHnaoB@mail.gmail.com>	<1301579959.3535.10.camel@localhost.localdomain>
	<in2bg7$v5q$1@dough.gmane.org>
Message-ID: <4D94BA34.90502@gmail.com>

Hi,

On 31/03/2011 19.52, Terry Reedy wrote:
> On 3/31/2011 9:59 AM, Antoine Pitrou wrote:
>> Le jeudi 31 mars 2011 ? 23:48 +1000, Nick Coghlan a ?crit :
>>> On Thu, Mar 31, 2011 at 10:16 PM, Antoine 
>>> Pitrou<solipsis at pitrou.net>  wrote:
>>>> It would be nice if someone with UI design experience was 
>>>> interested in
>>>> maintaining/improving the tracker.
>>>
>>> The challenge is the same as with any UI designer involvement in open
>>> source stuff though: they really need to be given the freedom to do
>>> proper workflow analysis and come up with something that *works*, but
>>> in practice things tend to get derailed into endless bikeshed
>>> arguments, since *everyone* has an opinion on the UI design of the
>>> tools they have to use.
>>
>> Well, obviously they have, since they are users and are directly
>> impacted by any changes.
>> The line this draws is between clean-sheet design and iterative
>> improvement. Clearly it would be difficult to try to sell us a wholesale
>> change in how the issue tracker organizes things.
>
> Here is my proposal for a redesign based on an analysis of my usage ;-).

You can add your proposal to 
http://wiki.python.org/moin/DesiredTrackerFeatures

There you can find several suggestions and discussions about possible 
changes to the tracker (it's similar to python-ideas ML, but it's about 
the tracker and it's on a wiki page).

Bugs and concrete suggestions should be submitted to the meta-tracker 
(http://psf.upfronthosting.co.za/roundup/meta/) or discussed on the 
tracker-discuss mailing list.

> I have a 1600x1050 (or thereabouts), 20" (measured) diagonal, 17" 
> across screen.
>
> The left column has a 7/8" margin, 2 3/8" text area, and 1" gutter. 
> These could be shrunk to say, 1/4, 2, 1/4, saving 1 3/8".
> The comment box is 8 1/2", message boxes are wider, but the extra 
> width is not used if one uses hard returns in the comment box. In any 
> case, the message boxes could be narrowed by 1 1/8".
> This would allow a right column of 1/4+2+1/4".
>
> Except for title, comment, and file boxes, we then stack the 
> classification and process boxes in the right column.
> The nosy box would be last so it can list one name per line.
> It would end with an [ add  me ] button. It should also have a box for 
> adding people (as with Assigned To). Having to look up tracker names 
> in Assigned To and retype exactly in the nosy list is an error-prone 
> nuisance. Putting all these boxes to the side leaves them visible for 
> those who want them but out of the way and ignorable for those who do 
> not.

You can also use the "(list)" link to open a popup and search for users 
to add to the nosy instead of copying them from the "Assigned To" list 
by hand.  (I know that popup are not the most usable thing and that the 
search has some limitation (e.g. it's case sensitive), but that's the 
best we have right now, and works fairly well for me.)

Also one of the design goal is to keep the interface as simple as 
possible, so we try to avoid adding more things unless they are really 
useful.  Having an expanded list of names doesn't sound too useful to me.

>
> I would be nice is both the left and right columns had buttons to hide 
> and show. This would help people accessing issues from smaller 
> screens, as with a netbook.
>
> The title is not really classification and belongs at the very top. It 
> could even go in the 1 1/8" top bar, which is currently mostly empty, 
> along with the issue number.
>
> I would like to try putting the comment box after the last (most 
> recent) comment, as that is the message one most ofter responds to. 
> Having to now scroll up and down between comment box and last 
> message(s) is often of a nuisance.
>

This summer I plan to participate again to GSOC and work on the bug 
tracker (if my proposal gets accepted).  There are already a few things 
I want to improve and I also have some patches ready that just need to 
be updated and applied.

In the meanwhile you can use 
http://wiki.python.org/moin/DesiredTrackerFeatures to list the things 
that you would like to see, so that they don't get lost in the archives 
of python-dev.

Best Regards,
Ezio Melotti

From victor.stinner at haypocalc.com  Thu Mar 31 20:26:34 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 31 Mar 2011 20:26:34 +0200
Subject: [Python-Dev] [Python-checkins] cpython: Issue #11393: get more
 information on	assertion error	(test_faulthandler)
In-Reply-To: <4D94BB70.1040608@udel.edu>
References: <E1Q5LLz-0005Q2-IP@dinsdale.python.org> <4D94BB70.1040608@udel.edu>
Message-ID: <1301595994.8046.0.camel@marge>

> > http://hg.python.org/cpython/rev/61626c3f3a54
> >...
> > -    assert (b -a)>= pause
> > +    assert (b - a)>= pause, "{{}}<  {{}}".format(b - a, pause)
> 
> > +        assert (b - a)>= pause, "{{}}<  {{}}".format(b - a, pause)
> 
>  >>> a,b,pause = 0,0,1
>  >>> "{{}} < {{}}".format(b - a, pause)
> '{} < {}'
> 
> I suspect you want 1 or 3 braces.
> 
> Terry

Nope, I really want {{}}: the diff is on a template using to generate
Python code executed in a subprocess.

Victor


From martin at v.loewis.de  Thu Mar 31 23:59:36 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 31 Mar 2011 23:59:36 +0200
Subject: [Python-Dev] Please revert autofolding of tracker edit form
In-Reply-To: <20110331013208.0a708867@pitrou.net>
References: <in07nd$5nb$1@dough.gmane.org>	<AANLkTimtQVdm-9_cveQtbeCdkOj6cQ7C=Qa+qMqp+zBY@mail.gmail.com>
	<20110331013208.0a708867@pitrou.net>
Message-ID: <4D94F948.3010203@v.loewis.de>

> What's more, it lacks the most important: the issue title.

Notice that the issue title was always there, in your browser's title
bar (unless you have a web browser that doesn't display the page title).

Regards,
Martin

From lauramdf at gmail.com  Wed Mar 30 00:48:18 2011
From: lauramdf at gmail.com (Laura)
Date: Tue, 29 Mar 2011 19:48:18 -0300
Subject: [Python-Dev] not possible to install python 3.2
Message-ID: <AANLkTimqf_SifJWBFREqzpSKmmk3EgodvDiEtUeUkrM0@mail.gmail.com>

I order to install Python as python3 on Linux, i did:


    ./configure
    make
    make test
    sudo make install


However, when i typed "make test", i got two error messages:

"test test_distutils failed -- multiple errors occurred; run in verbose mode
for details"

"sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null'
mode='a' encoding='ANSI_X3.4-1968'>
make: *** [test] Error 1"

The Result?  When I type python on Linux, i get the older version 2.7.1
instead of the version that i just installed (python 3.2).


Could you help me?



Thank you,

Laura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110329/38b11303/attachment.html>