From ethan at stoneleaf.us  Tue Feb  1 00:10:06 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 31 Jan 2011 15:10:06 -0800
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
 Windows
In-Reply-To: <AANLkTikc0vyt5=-FYC5z8UmWpswxM6sOumAHOdEQ3uqx@mail.gmail.com>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>	<4D431724.4010002@voidspace.org.uk>	<7DA37C12-D3DA-49B3-996A-017CF304BC5C@gmail.com>	<ihv97t$vff$1@dough.gmane.org>	<AANLkTikcwapO5uHZH9sG98zYdePkzKiz8oJ-SgPKhAjM@mail.gmail.com>	<AANLkTi=A9JGjy1zu88y0wUJsm4C5vf3s8Lsou2yLyGJV@mail.gmail.com>	<AANLkTin9Om3CTQCiUQ6x5ESyJTsx0wevDoMef+NwGvjF@mail.gmail.com>	<AANLkTi=one+Jf9OmbF1=6xyRucyGp=0GC-3YZvcK-TzX@mail.gmail.com>
	<AANLkTikc0vyt5=-FYC5z8UmWpswxM6sOumAHOdEQ3uqx@mail.gmail.com>
Message-ID: <4D47414E.5080602@stoneleaf.us>

Brian Curtin wrote:
> On Mon, Jan 31, 2011 at 15:43, anatoly techtonik <techtonik at gmail.com 
> <mailto:techtonik at gmail.com>> wrote:
>> That's the easy part. It doesn't cover any of the real issues with doing
>> this.
> 
> Please be more specific. It will also help if you integrate this part
> while it's still hot.
> --
> anatoly t.
> 
> 
> There are numerous comments in the various PATH-related issues on the 
> issue tracker, and many of them are duplicated in this very thread.

Imagine that -- discussion and coordination on b.p.o.!  ;)

~Ethan~

From ncoghlan at gmail.com  Tue Feb  1 00:38:00 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 1 Feb 2011 09:38:00 +1000
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>
	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
Message-ID: <AANLkTi=aWyAo8Y8z_p-95Q+e-8A0BwBw2yhkxXmqUxBK@mail.gmail.com>

On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> To me polluting tracker with the
> issues that are neither bugs nor feature requests only makes bug
> triaging process and search more cumbersome.

Anatoly, your constant efforts to try to force python-dev to adapt to
*your* way of doing things, instead of being willing to work with the
documented processes are *seriously* annoying. Which is a shame, since
it obscures the fact that your underlying suggestions are often quite
reasonable.

Cheers,
Nick.

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

From martin at v.loewis.de  Tue Feb  1 01:05:08 2011
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Tue, 01 Feb 2011 00:05:08 +0000
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
Message-ID: <0022152d655912c0d4049b2d4917@google.com>

What's the rationale of this change? It certainly doesn't remove the
dependency from win32com.client (i.e. the code continues to depend on
win32com).



http://codereview.appspot.com/4080047/

From martin at v.loewis.de  Tue Feb  1 01:10:34 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 01 Feb 2011 01:10:34 +0100
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
 Windows
In-Reply-To: <AANLkTi=A9JGjy1zu88y0wUJsm4C5vf3s8Lsou2yLyGJV@mail.gmail.com>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>	<4D431724.4010002@voidspace.org.uk>	<7DA37C12-D3DA-49B3-996A-017CF304BC5C@gmail.com>	<ihv97t$vff$1@dough.gmane.org>	<AANLkTikcwapO5uHZH9sG98zYdePkzKiz8oJ-SgPKhAjM@mail.gmail.com>
	<AANLkTi=A9JGjy1zu88y0wUJsm4C5vf3s8Lsou2yLyGJV@mail.gmail.com>
Message-ID: <4D474F7A.2090800@v.loewis.de>

Am 31.01.2011 22:13, schrieb anatoly techtonik:
> Ok. Here is the patch. I used Orca to reverse installer tables of
> Mercurial MSI and inserted similar entry for Python.

This doesn't do uninstallation correctly.

Regards,
Martin

From martin at v.loewis.de  Tue Feb  1 01:24:47 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 01 Feb 2011 01:24:47 +0100
Subject: [Python-Dev] Mercurial style patch submission (Was: MSI: Remove
 dependency from win32com.client module (issue4080047))
In-Reply-To: <AANLkTimH=OoYd26Hn7OMqbSrX7nQzgFWkLT3tU7pxx75@mail.gmail.com>
References: <AANLkTi=nhenOyk7j3oQR+1ExP0Cw-N9jbuqCFNFFz6=c@mail.gmail.com>
	<AANLkTimH=OoYd26Hn7OMqbSrX7nQzgFWkLT3tU7pxx75@mail.gmail.com>
Message-ID: <4D4752CF.3090902@v.loewis.de>

>> If you don't want to receive a stupid answer, why don't you read the
>> link and say what you don't like in this approach in a constructive
>> manner?
> 
> As I understand it, there used to be patches at python.org. I'm not sure
> why this was discontinued, so perhaps someone more senior should chime
> in. :)

As a mailing list, it was unmaintainable, since there was no tracking
of what patches still need consideration. So a web-based bug tracker
got into use (although I forgot the name of the tracker software that
was used before SourceForge).

Regards,
Martin

From dirkjan at ochtman.nl  Tue Feb  1 08:11:14 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Tue, 1 Feb 2011 08:11:14 +0100
Subject: [Python-Dev] Mercurial style patch submission (Was: MSI: Remove
 dependency from win32com.client module (issue4080047))
In-Reply-To: <AANLkTi=nhenOyk7j3oQR+1ExP0Cw-N9jbuqCFNFFz6=c@mail.gmail.com>
References: <AANLkTi=nhenOyk7j3oQR+1ExP0Cw-N9jbuqCFNFFz6=c@mail.gmail.com>
Message-ID: <AANLkTimG7d=DftasKumUx0KBZX+5G6ZPTq3MwgKdY4rV@mail.gmail.com>

On Mon, Jan 31, 2011 at 22:50, anatoly techtonik <techtonik at gmail.com> wrote:
> If you don't want to receive a stupid answer, why don't you read the
> link and say what you don't like in this approach in a constructive
> manner?

Mercurial is a much smaller project, so it has different needs. It
would be nice if you could respect the process the developers on any
project have laid out for their project and assume they know what
works best for them.

Cheers,

Dirkjan

From techtonik at gmail.com  Tue Feb  1 08:22:58 2011
From: techtonik at gmail.com (techtonik at gmail.com)
Date: Tue, 01 Feb 2011 07:22:58 +0000
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
Message-ID: <20cf305497e3db5c18049b336617@google.com>

It removes the dependency from msi.py making it easier to do the rest in
subsequent patches.

http://codereview.appspot.com/4080047/

From techtonik at gmail.com  Tue Feb  1 08:35:12 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 1 Feb 2011 09:35:12 +0200
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTikKwqqczJ=ZF_amrZ=VnV2_gqOd9oNHQ39Ox9jf@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>
	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
	<AANLkTikKwqqczJ=ZF_amrZ=VnV2_gqOd9oNHQ39Ox9jf@mail.gmail.com>
Message-ID: <AANLkTimpxwqVb6FcH0fu8tAn027J-JtHGBpJVcEa+o4T@mail.gmail.com>

On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson <benjamin at python.org> wrote:
>>>>
>>>> I see no reason for b.p.o bureaucracy.
>>>
>>> It provides a place for discussion, and makes it easier to coordinate
>>> multiple efforts.
>>
>> Code review system provides a better space for discussion if we are
>> speaking about simple code cleanup. To me polluting tracker with the
>> issues that are neither bugs nor feature requests only makes bug
>> triaging process and search more cumbersome.
>
> If it's not a bug or a feature request, why does it need to change?

Because code cleanup patches pave road for more complex pieces of
work. Clean code makes patches easier to review. It saves developer's
time and as a result useful patches are integrated into codebase more
quickly.
-- 
anatoly t.

From g.brandl at gmx.net  Tue Feb  1 08:45:44 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 01 Feb 2011 08:45:44 +0100
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
Message-ID: <ii8dnb$t6h$1@dough.gmane.org>

Am 31.01.2011 22:58, schrieb anatoly techtonik:
> On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> techtonik at gmail.com wrote:
>>>
>>> I see no reason for b.p.o bureaucracy.
>>
>> It provides a place for discussion, and makes it easier to coordinate
>> multiple efforts.
> 
> Code review system provides a better space for discussion if we are
> speaking about simple code cleanup. To me polluting tracker with the
> issues that are neither bugs nor feature requests only makes bug
> triaging process and search more cumbersome.

Note that while the domain may be "bugs.python.org" (because that is a
traditional name used by many projects), it really is an *issue tracker*,
and for us, all patches are issues that should be tracked there.

A mailing list works only if you have a small group of core developers
who can independently organize the incoming mails using local tools,
such as the read/unread marking of the email client.  For a larger
group this doesn't work (how do you assign a patch to someone using
a mailing list?).  It sure is more convenient to do patch review, but
that's why we are working on Rietveld integration in the tracker.

Georg


From g.brandl at gmx.net  Tue Feb  1 08:49:00 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 01 Feb 2011 08:49:00 +0100
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTimrXSMUCLMauPsGTvFBqEAi+iOfjFNLstkOj7pk@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>	<ii77q5$s2b$1@dough.gmane.org>
	<AANLkTimrXSMUCLMauPsGTvFBqEAi+iOfjFNLstkOj7pk@mail.gmail.com>
Message-ID: <ii8dtf$u04$1@dough.gmane.org>

Am 31.01.2011 23:05, schrieb anatoly techtonik:
> On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>> Am 31.01.2011 21:45, schrieb techtonik at gmail.com:
>>> There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
>>> to clean up the code a bit while I am trying to understand how to add
>>> Python to the PATH.
>>>
>>> I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
>>> more beneficial to development as it doesn't require switching from
>>> console to browser for submitting changes. This way tiny changes can be
>>> integrated/updated more rapidly.
>>
>> The tracker is not bureaucracy, it's how our development process works.
> 
> Don't you want to improve this process? Code review system is a much
> better place to review patches than mailing list or bug tracker.
> Especially patches that are not related to actual bugs.

If there are patches only on the code review system, others only on the
issue tracker, and still others on both, people will get confused quickly.
There needs to be a single canonical place to collect issues, and that needs
to be the issue tracker (since bug reports cannot go anywhere else).

I'm enthusiastic about anything that *improves* this process, but you're
proposing to *change* it.

>> I know that Mercurial uses a different process, with patches always going
>> to the mailing list and being reviewed there, but that would be way too
>> much volume for python-dev considering our number of patches.
> 
> Seems reasonable. Do you have any stats how many patches are sent
> weekly and how many of them are actually integrated?

No, but you can have a look at the weekly "Summary of Python tracker issues"
emails that are sent to this list by a script.

Georg


From ncoghlan at gmail.com  Tue Feb  1 11:15:09 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 1 Feb 2011 20:15:09 +1000
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTimpxwqVb6FcH0fu8tAn027J-JtHGBpJVcEa+o4T@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>
	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
	<AANLkTikKwqqczJ=ZF_amrZ=VnV2_gqOd9oNHQ39Ox9jf@mail.gmail.com>
	<AANLkTimpxwqVb6FcH0fu8tAn027J-JtHGBpJVcEa+o4T@mail.gmail.com>
Message-ID: <AANLkTi=hpaQHD-cNDXK4hv-sJf3ohngR3y30FRzD2dSN@mail.gmail.com>

On Tue, Feb 1, 2011 at 5:35 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> Because code cleanup patches pave road for more complex pieces of
> work. Clean code makes patches easier to review. It saves developer's
> time and as a result useful patches are integrated into codebase more
> quickly.

While I've occasionally wished for the ability to enter
"clarification" as the issue type (especially for docs patches),
simply leaving the issue type blank when none of the available
categories fits has worked well enough as an alternative.

If it helps, try to think of it as "this code isn't clear as it could
be, which is a readability bug"

Cheers,
Nick.

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

From lukasz at langa.pl  Tue Feb  1 11:22:57 2011
From: lukasz at langa.pl (=?UTF-8?B?xYF1a2FzeiBMYW5nYQ==?=)
Date: Tue, 01 Feb 2011 11:22:57 +0100
Subject: [Python-Dev] Mercurial style patch submission (Was: MSI: Remove
 dependency from win32com.client module (issue4080047))
In-Reply-To: <4D4752CF.3090902@v.loewis.de>
References: <AANLkTi=nhenOyk7j3oQR+1ExP0Cw-N9jbuqCFNFFz6=c@mail.gmail.com>	<AANLkTimH=OoYd26Hn7OMqbSrX7nQzgFWkLT3tU7pxx75@mail.gmail.com>
	<4D4752CF.3090902@v.loewis.de>
Message-ID: <4D47DF01.1070100@langa.pl>

W dniu 2011-02-01 01:24, "Martin v. L?wis" pisze:
> As a mailing list, it was unmaintainable, since there was no tracking
> of what patches still need consideration. So a web-based bug tracker
> got into use (although I forgot the name of the tracker software that
> was used before SourceForge).

JitterBug!

Best regards,
?ukasz

From brian.curtin at gmail.com  Tue Feb  1 15:35:41 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Tue, 1 Feb 2011 08:35:41 -0600
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTimpxwqVb6FcH0fu8tAn027J-JtHGBpJVcEa+o4T@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>
	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
	<AANLkTikKwqqczJ=ZF_amrZ=VnV2_gqOd9oNHQ39Ox9jf@mail.gmail.com>
	<AANLkTimpxwqVb6FcH0fu8tAn027J-JtHGBpJVcEa+o4T@mail.gmail.com>
Message-ID: <AANLkTikgEpPUCwaN8ECpio-JQZPzTzM1E75ZbVBajn9e@mail.gmail.com>

On Tue, Feb 1, 2011 at 01:35, anatoly techtonik <techtonik at gmail.com> wrote:

> On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson <benjamin at python.org>
> wrote:
> >>>>
> >>>> I see no reason for b.p.o bureaucracy.
> >>>
> >>> It provides a place for discussion, and makes it easier to coordinate
> >>> multiple efforts.
> >>
> >> Code review system provides a better space for discussion if we are
> >> speaking about simple code cleanup. To me polluting tracker with the
> >> issues that are neither bugs nor feature requests only makes bug
> >> triaging process and search more cumbersome.
> >
> > If it's not a bug or a feature request, why does it need to change?
>
> Because code cleanup patches pave road for more complex pieces of
> work. Clean code makes patches easier to review. It saves developer's
> time and as a result useful patches are integrated into codebase more
> quickly.
> --
> anatoly t.


Code cleanup patches, if you mean minor refactoring, are generally not where
developer time is best spent. We could all come in and make 50 check-ins
each of refactoring but the net benefit is even, if not negative. Yes, clean
code is easier to work with, easier to review, etc., but keep in mind we're
working with multiple branches that also need to be kept in sync.

Refactoring some function in py3k should probably be replicated in
release31-maint, and possibly release27-maint, otherwise patching between
the branches becomes more time intensive. Adding time intensive work with no
net gain is probably the last thing we want to do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110201/460a1235/attachment.html>

From techtonik at gmail.com  Tue Feb  1 16:51:57 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 1 Feb 2011 17:51:57 +0200
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTi=aWyAo8Y8z_p-95Q+e-8A0BwBw2yhkxXmqUxBK@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>
	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
	<AANLkTi=aWyAo8Y8z_p-95Q+e-8A0BwBw2yhkxXmqUxBK@mail.gmail.com>
Message-ID: <AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>

On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> To me polluting tracker with the
>> issues that are neither bugs nor feature requests only makes bug
>> triaging process and search more cumbersome.
>
> Anatoly, your constant efforts to try to force python-dev to adapt to
> *your* way of doing things, instead of being willing to work with the
> documented processes are *seriously* annoying. Which is a shame, since
> it obscures the fact that your underlying suggestions are often quite
> reasonable.

I'll abandon my efforts when you prove me that current "documented
process" is a top-notch way for all interested parties to do a quality
contributions to make Python better. So that the process is open,
straightforward, transparent and doesn't waste people's time more than
necessary to communicate a change, make it visible for all interested
parties, get feedback, polish and finally integrate.

There are many ways for improvement, but if people won't try
alternative approaches, they won't see them. I am not sure if I can
manage to get to PyCon, so I didn't do any talk preparation, but if by
chance I get there and there will be an Open Space, we can definitely
find a lot of ways to improve Python development process for general
public. As well as discuss ways to get around stdlib graveyard and
dealing with really complicated problems that won't budge over the
years - like out of the box UTC support.

The most valuable contributions are coming from professionals, and
these people often don't have enough time to follow "documented
process". In the era of information abundance you often have only 140
symbols to communicate the idea, and instead of blaming people of
annoying behavior, it might be more useful to make process intuitive
and easy to follow. If that's not possible, there should always be an
exact link to a reasonable explanation about why you need the process
to be so complicated.

So far only Georg explained what patches sent to mailing list will not
be reviewed, because there is too much volume. But bugtracker is not a
patch tracker. It doesn't allow to monitor incoming patches by module,
its search is very poor. Of course mailing lists are even worse in
this regard, but there is nothing Python community can't deal with.
The problem is to keep non-core people outside motivated, and the
biggest problem with current "documented process" is that nobody even
thinks about it.
-- 
anatoly t.

From amauryfa at gmail.com  Tue Feb  1 17:07:26 2011
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 1 Feb 2011 17:07:26 +0100
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>
	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
	<AANLkTi=aWyAo8Y8z_p-95Q+e-8A0BwBw2yhkxXmqUxBK@mail.gmail.com>
	<AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
Message-ID: <AANLkTi=acJ3ZNXriUzQs9ubBQLOsb3owEkMGar1=cthH@mail.gmail.com>

2011/2/1 anatoly techtonik <techtonik at gmail.com>:
> we can definitely
> find a lot of ways to improve Python development process for general
> public

Definitely. And the future migration to Mercurial will certainly help as well.

But this thread started with a patch review, not with a proposal to
change the development process!
For the moment, we use svn and the issue tracker.
If every patch comes with its own workflow, no coordination is possible.

-- 
Amaury Forgeot d'Arc

From brian.curtin at gmail.com  Tue Feb  1 17:20:40 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Tue, 1 Feb 2011 10:20:40 -0600
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>
	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
	<AANLkTi=aWyAo8Y8z_p-95Q+e-8A0BwBw2yhkxXmqUxBK@mail.gmail.com>
	<AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
Message-ID: <AANLkTimopzn+govJvRbPQTN4w2N8CqroNY4NzKpS_1uY@mail.gmail.com>

On Tue, Feb 1, 2011 at 09:51, anatoly techtonik <techtonik at gmail.com> wrote:

> On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik <techtonik at gmail.com>
> wrote:
> >> To me polluting tracker with the
> >> issues that are neither bugs nor feature requests only makes bug
> >> triaging process and search more cumbersome.
> >
> > Anatoly, your constant efforts to try to force python-dev to adapt to
> > *your* way of doing things, instead of being willing to work with the
> > documented processes are *seriously* annoying. Which is a shame, since
> > it obscures the fact that your underlying suggestions are often quite
> > reasonable.
>
> I'll abandon my efforts when you prove me that current "documented
> process" is a top-notch way for all interested parties to do a quality
> contributions to make Python better. So that the process is open,
> straightforward, transparent and doesn't waste people's time more than
> necessary to communicate a change, make it visible for all interested
> parties, get feedback, polish and finally integrate.


The burden of proof should not be on us to prove to you why we do things the
way we do them. I'm not even sure you are familiar with the process that you
want to change so badly.

You do realize that no one else, from the people in Misc/developers.txt to
the one-time patch submitters, has a monthly process gripe, correct? It's
certainly working for a few of us.

There are many ways for improvement, but if people won't try
> alternative approaches, they won't see them.


This is true of just about anything in the world, but I don't think it's a
bad thing. We decided on something, it works, and we use it.

I umpire college baseball in my free time and people like to propose tweaks
to our on-field mechanics all the time because they think certain
alternatives work better. To even get me to think about that stuff is a tall
task because not only is my time on the job limited, my actual ability to
practice these alternatives is more limited. I'll stick to what's in our
book -- it works.


> I am not sure if I can
> manage to get to PyCon, so I didn't do any talk preparation, but if by
> chance I get there and there will be an Open Space, we can definitely
> find a lot of ways to improve Python development process for general
> public.


I could list a few ways to improve it as well. Do we need any of them to
survive? No.


> The most valuable contributions are coming from professionals, and
> these people often don't have enough time to follow "documented
> process".


Sorry, but sometimes that's the cost of doing business. Just because the
court system has a lengthy process for suing people doesn't mean you can
skip to the end if you just want to get your money. You have to tell your
story first.


> In the era of information abundance you often have only 140
> symbols to communicate the idea, and instead of blaming people of
> annoying behavior, it might be more useful to make process intuitive
> and easy to follow.


Thankfully Twitter is not our bug tracker.


> If that's not possible, there should always be an
> exact link to a reasonable explanation about why you need the process
> to be so complicated.
>

There's a few things the process is, and complicated it is not. In most
cases it is as simple as: report a bug, provide a failing test case, provide
a complete patch, review the patch, commit the patch.

To an outsider, they don't have to worry about the bug tracker fields, who's
doing the commit, what branches it goes into, etc. Just write the code and
it'll speak for itself.

So far only Georg explained what patches sent to mailing list will not
> be reviewed, because there is too much volume. But bugtracker is not a
> patch tracker.


Yes it is, or at least that is one of the functions it is currently serving.

It doesn't allow to monitor incoming patches by module,
> its search is very poor.


Patches are certainly welcome if you want to make it happen. I think it
would be a nice addition.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110201/6cecc695/attachment.html>

From techtonik at gmail.com  Tue Feb  1 17:25:24 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 1 Feb 2011 18:25:24 +0200
Subject: [Python-Dev] Rietveld integration status (Was: MSI: Remove
 dependency from win32com.client module (issue4080047))
Message-ID: <AANLkTik=qhBRvK3Xm9QmUfO0hPnmk5RwJjix0yY0K5VO@mail.gmail.com>

On Tue, Feb 1, 2011 at 9:45 AM, Georg Brandl <g.brandl at gmx.net> wrote:
>
> A mailing list works only if you have a small group of core developers
> who can independently organize the incoming mails using local tools,
> such as the read/unread marking of the email client. ?For a larger
> group this doesn't work (how do you assign a patch to someone using
> a mailing list?).

If you can filter patches by module (and it can be done
automatically), then you won't need to assign patches. People can
subscribe to interested parts and participate independently.

> It sure is more convenient to do patch review, but
> that's why we are working on Rietveld integration in the tracker.

Where is the code? What is the status? Where is the roadmap, i.e. how
can people help? Why can't you use hosted Rietveld instance if there
are troubles to setup server properly?
-- 
anatoly t.

From hsoft at hardcoded.net  Tue Feb  1 17:30:23 2011
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Tue, 1 Feb 2011 17:30:23 +0100
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>
	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
	<AANLkTi=aWyAo8Y8z_p-95Q+e-8A0BwBw2yhkxXmqUxBK@mail.gmail.com>
	<AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
Message-ID: <06806A67-A999-4026-B3B8-6F2D50847BAD@hardcoded.net>


On 2011-02-01, at 4:51 PM, anatoly techtonik wrote:
> 
> I'll abandon my efforts when you prove me that current "documented
> process" is a top-notch way for all interested parties to do a quality
> contributions to make Python better. So that the process is open,
> straightforward, transparent and doesn't waste people's time more than
> necessary to communicate a change, make it visible for all interested
> parties, get feedback, polish and finally integrate.
> 
> There are many ways for improvement, but if people won't try
> alternative approaches, they won't see them. I am not sure if I can
> manage to get to PyCon, so I didn't do any talk preparation, but if by
> chance I get there and there will be an Open Space, we can definitely
> find a lot of ways to improve Python development process for general
> public. As well as discuss ways to get around stdlib graveyard and
> dealing with really complicated problems that won't budge over the
> years - like out of the box UTC support.
> 
> The most valuable contributions are coming from professionals, and
> these people often don't have enough time to follow "documented
> process". In the era of information abundance you often have only 140
> symbols to communicate the idea, and instead of blaming people of
> annoying behavior, it might be more useful to make process intuitive
> and easy to follow. If that's not possible, there should always be an
> exact link to a reasonable explanation about why you need the process
> to be so complicated.
> 
> So far only Georg explained what patches sent to mailing list will not
> be reviewed, because there is too much volume. But bugtracker is not a
> patch tracker. It doesn't allow to monitor incoming patches by module,
> its search is very poor. Of course mailing lists are even worse in
> this regard, but there is nothing Python community can't deal with.
> The problem is to keep non-core people outside motivated, and the
> biggest problem with current "documented process" is that nobody even
> thinks about it.

It's nice to see that you want to improve the tracker. I'm happy to point you to the appropriate place for such proposals:

http://psf.upfronthosting.co.za/roundup/meta/

The mailing list about the tracker is:

http://mail.python.org/mailman/listinfo/tracker-discuss

As for the "mailing list/patch" proposal, I think you should drop it. It's been made abundantly clear, by people much more knowledgable about the dev process of Python than you, why it can't work.

Also, not being keen on "following the documented process" is a good indication, IMHO, of unprofessionalism.

--
Virgil Dupras

From stephen at xemacs.org  Tue Feb  1 18:02:19 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 02 Feb 2011 02:02:19 +0900
Subject: [Python-Dev] MSI: Remove dependency from win32com.client
	module	(issue4080047)
In-Reply-To: <AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>
	<4D4724FC.1040705@stoneleaf.us>
	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>
	<AANLkTi=aWyAo8Y8z_p-95Q+e-8A0BwBw2yhkxXmqUxBK@mail.gmail.com>
	<AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
Message-ID: <87r5br3cys.fsf@uwakimon.sk.tsukuba.ac.jp>

anatoly techtonik writes:

 > I'll abandon my efforts when you prove me that current "documented
 > process" is a top-notch way for all interested parties to do a quality
 > contributions to make Python better.

I think the product of the process speaks very well for the process.

 > The most valuable contributions are coming from professionals, and
 > these people often don't have enough time to follow "documented
 > process".

I think you have that exactly backward.  It is precisely the seasoned
professionals who value process most.  Professionals are good at
managing their own time and can handle process if they can make it
routine; but they get annoyed and go away if you break their routine.
It's non-professional newcomers who are most attracted by minimal
process.

 > the biggest problem with current "documented process" is that
 > nobody even thinks about it.

Look harder.  People thinking about the "Python process" are all over
this list, not to mention featured PEP authors.  (It's this kind of
gratuitous exaggeration that Nick speaks of.)

In general, you remind me of the "let's import Japanese practices"
management consultancies of the '80s.  They failed dismally, because
none of the famous Japanese process innovations are standalone.  They
depend on each other and on a common culture, both lacking in the
U.S. and Europe.  That doesn't mean that quality circles, JIT, and the
like haven't been successfully applied outside of Japan, but they work
differently and organizations had to adapt both the Japanese practices
and their existing processes to get any advantage from the
innovations.  I think the analogy to software process, including in
open, open source projects like Python, is quite strong.

If you want to change the process, I believe that the most effective
way is kaizen, ie, gradually improving by sanding down some rough
spots, not by whacking off whole subprocesses that you believe are
wasteful.  Truly wasteful subprocesses generally don't survive in this
environment.  You should look harder to figure out what they're good
for, and then gradually wean the project from them by providing
alternative ways to accomplish those goals that are less wasteful, but
compatible with other aspects of the existing process.


From rdmurray at bitdance.com  Tue Feb  1 18:28:50 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 01 Feb 2011 12:28:50 -0500
Subject: [Python-Dev] Rietveld integration status (Was: MSI: Remove
	dependency from win32com.client module (issue4080047))
In-Reply-To: <AANLkTik=qhBRvK3Xm9QmUfO0hPnmk5RwJjix0yY0K5VO@mail.gmail.com>
References: <AANLkTik=qhBRvK3Xm9QmUfO0hPnmk5RwJjix0yY0K5VO@mail.gmail.com>
Message-ID: <20110201172850.43AD1234B7B@kimball.webabinitio.net>

On Tue, 01 Feb 2011 18:25:24 +0200, anatoly techtonik <techtonik at gmail.com> wrote:
> On Tue, Feb 1, 2011 at 9:45 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> > It sure is more convenient to do patch review, but
> > that's why we are working on Rietveld integration in the tracker.
> 
> Where is the code? What is the status? Where is the roadmap, i.e. how
> can people help? Why can't you use hosted Rietveld instance if there
> are troubles to setup server properly?

See http://wiki.python.org/moin/TrackerDevelopment for how to set up
a test instance to hack on.  The rietveld stuff is in
http://svn.python.org/view/tracker/instances/python-dev/rietveld/.
The problem with the rietveld setup is that the script that looks for
patches and sets up review tickets has a problem where it consumes ever
larger amounts of memory and doesn't finish its run.  So the "roadmap"
is to debug and fix that script.  Martin hasn't had time to do it,
and I haven't had time to learn enough about rietveld to try.

Getting set up to test tracker patches is distinctly non-trivial,
which is probably why very few people work on it.

--
R. David Murray                                      www.bitdance.com

From scott+python-dev at scottdial.com  Tue Feb  1 20:04:05 2011
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Tue, 01 Feb 2011 14:04:05 -0500
Subject: [Python-Dev] Issue #11051: system calls per import
In-Reply-To: <AANLkTi=5_tsR7H77NkAUKj4RV9hKgPju1SPU=XHM9JX2@mail.gmail.com>
References: <1296377778.24415.4.camel@marge>
	<4D452E71.6070401@python.org>	<AANLkTikgN53=j+_t6_D3rcwADEYxwdrS2wjdnV3rWLOF@mail.gmail.com>	<1296405345.24507.9.camel@marge>
	<4D45D6E1.6030906@canterbury.ac.nz>	<4D4665B9.9000108@v.loewis.de>	<AANLkTi=AtFMMhkEzsCf3i-J4Xte+bx+YD2TqLRkvm1RB@mail.gmail.com>	<20110131134300.2babc577@pitrou.net>
	<AANLkTi=5_tsR7H77NkAUKj4RV9hKgPju1SPU=XHM9JX2@mail.gmail.com>
Message-ID: <4D485925.7090603@scottdial.com>

On 1/31/2011 1:38 PM, Brett Cannon wrote:
> I should mention that I have considered implementing a caching finder
> and loader for filesystems in importlib for people to optionally
> install to use for themselves. The real trick, though, is should it
> only cache hits, misses, or both? Regardless, though, it would be a
> very simple mixin or subclass to implement if there is demand for this
> sort of thing.

I have in the past implemented a PEP302 finder/loader zipfile-based
cache. On campus, I use a version of python installed to my home
directory that is on an NFS share. I found such a cache often gave
slower startup times for applications like bzr and hg.

My cache merely stores things it finds things in sys.path and loads from
the zipfile names that it knows and storing those that it doesn't. I
make no attempt to invalidate the cache contents once stored. So, I am
already talking about a best-case scenario for caching. I'm not sure how
you could invalidate the cache without paying the cost of all the normal
syscalls that we are trying to avoid.

My finder/loader is not bug-free, but I'd be glad to make it available
to someone if they want to play around with it.

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

From martin at v.loewis.de  Tue Feb  1 20:50:23 2011
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Tue, 01 Feb 2011 19:50:23 +0000
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
Message-ID: <001636e1e9e9e06748049b3dd7cc@google.com>

On 2011/02/01 07:22:57, techtonik wrote:
> It removes the dependency from msi.py making it easier to do the rest
in
> subsequent patches.

What rest specifically? Why are the msilib changes needed for that?

http://codereview.appspot.com/4080047/

From g.brandl at gmx.net  Tue Feb  1 22:39:59 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 01 Feb 2011 22:39:59 +0100
Subject: [Python-Dev] Rietveld integration status (Was: MSI: Remove
 dependency from win32com.client module (issue4080047))
In-Reply-To: <AANLkTik=qhBRvK3Xm9QmUfO0hPnmk5RwJjix0yY0K5VO@mail.gmail.com>
References: <AANLkTik=qhBRvK3Xm9QmUfO0hPnmk5RwJjix0yY0K5VO@mail.gmail.com>
Message-ID: <ii9ujj$g49$1@dough.gmane.org>

Am 01.02.2011 17:25, schrieb anatoly techtonik:
> On Tue, Feb 1, 2011 at 9:45 AM, Georg Brandl <g.brandl at gmx.net> wrote:
>>
>> A mailing list works only if you have a small group of core developers
>> who can independently organize the incoming mails using local tools,
>> such as the read/unread marking of the email client.  For a larger
>> group this doesn't work (how do you assign a patch to someone using
>> a mailing list?).
> 
> If you can filter patches by module (and it can be done
> automatically), then you won't need to assign patches. People can
> subscribe to interested parts and participate independently.

That's not true.  Assignment isn't meant to make searching issues easier,
it's meant for the developers to help them collect and work on their tasks.

Georg


From g.brandl at gmx.net  Tue Feb  1 22:46:28 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 01 Feb 2011 22:46:28 +0100
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>	<4D4724FC.1040705@stoneleaf.us>	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>	<AANLkTi=aWyAo8Y8z_p-95Q+e-8A0BwBw2yhkxXmqUxBK@mail.gmail.com>
	<AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
Message-ID: <ii9uvo$ib4$1@dough.gmane.org>

Am 01.02.2011 16:51, schrieb anatoly techtonik:
> On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>>> To me polluting tracker with the
>>> issues that are neither bugs nor feature requests only makes bug
>>> triaging process and search more cumbersome.
>>
>> Anatoly, your constant efforts to try to force python-dev to adapt to
>> *your* way of doing things, instead of being willing to work with the
>> documented processes are *seriously* annoying. Which is a shame, since
>> it obscures the fact that your underlying suggestions are often quite
>> reasonable.
> 
> I'll abandon my efforts when you prove me that current "documented
> process" is a top-notch way for all interested parties to do a quality
> contributions to make Python better.

And who or what decides what this "top-notch way" is?

> So that the process is open, straightforward, transparent

Ah.  Well, that's definitely very a concise spec.

> and doesn't waste people's time more than
> necessary to communicate a change, make it visible for all interested
> parties, get feedback, polish and finally integrate.

[...]

> The most valuable contributions are coming from professionals, and
> these people often don't have enough time to follow "documented
> process". In the era of information abundance you often have only 140
> symbols to communicate the idea,

That's a great idea for a change: report bugs by twitter.  We need to
set up a twitter search for #PythonBug, and then you simply enter

#PythonBug the process is slow

and it is converted to an issue on b.p.o.  Very open, very transparent,
and of course very straightforward.  Let's not care about how to reach
the submitter when clarification is needed, or what to do about patches.
If it doesn't fit into 140 characters, it doesn't exist!

> and instead of blaming people of
> annoying behavior, it might be more useful to make process intuitive
> and easy to follow. If that's not possible, there should always be an
> exact link to a reasonable explanation about why you need the process
> to be so complicated.

The new devguide (docs.python.org/devguide) should provide exactly that,
and in a central location.

> So far only Georg explained what patches sent to mailing list will not
> be reviewed, because there is too much volume. But bugtracker is not a
> patch tracker.

As I explained, it is an *issue tracker*.  And since in 99% of cases there
is an actual issue underlying a patch, it is more than justified to use
it to track issues that have patches.

> It doesn't allow to monitor incoming patches by module,
> its search is very poor. Of course mailing lists are even worse in
> this regard, but there is nothing Python community can't deal with.

Exactly, so let us continue the ongoing work in improving the tracker.

> The problem is to keep non-core people outside motivated, and the
> biggest problem with current "documented process" is that nobody even
> thinks about it.

I think others already wrote enough about that.

Georg


From techtonik at gmail.com  Wed Feb  2 06:18:50 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 2 Feb 2011 07:18:50 +0200
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
	Windows
In-Reply-To: <AANLkTikc0vyt5=-FYC5z8UmWpswxM6sOumAHOdEQ3uqx@mail.gmail.com>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk>
	<7DA37C12-D3DA-49B3-996A-017CF304BC5C@gmail.com>
	<ihv97t$vff$1@dough.gmane.org>
	<AANLkTikcwapO5uHZH9sG98zYdePkzKiz8oJ-SgPKhAjM@mail.gmail.com>
	<AANLkTi=A9JGjy1zu88y0wUJsm4C5vf3s8Lsou2yLyGJV@mail.gmail.com>
	<AANLkTin9Om3CTQCiUQ6x5ESyJTsx0wevDoMef+NwGvjF@mail.gmail.com>
	<AANLkTi=one+Jf9OmbF1=6xyRucyGp=0GC-3YZvcK-TzX@mail.gmail.com>
	<AANLkTikc0vyt5=-FYC5z8UmWpswxM6sOumAHOdEQ3uqx@mail.gmail.com>
Message-ID: <AANLkTinm2qn+2WPsrR6v7FPtzWoEnr4VzNOiU4JKwU4D@mail.gmail.com>

On Mon, Jan 31, 2011 at 11:49 PM, Brian Curtin <brian.curtin at gmail.com> wrote:
> On Mon, Jan 31, 2011 at 15:43, anatoly techtonik <techtonik at gmail.com>
> wrote:
>>
>> On Mon, Jan 31, 2011 at 11:24 PM, Brian Curtin <brian.curtin at gmail.com>
>> wrote:
>> > On Mon, Jan 31, 2011 at 15:13, anatoly techtonik <techtonik at gmail.com>
>> > wrote:
>> >>
>> >> Ok. Here is the patch. I used Orca to reverse installer tables of
>> >> Mercurial MSI and inserted similar entry for Python.
>> >>
>> >> Also available for review at: http://codereview.appspot.com/4023055
>> >
>> > That's the easy part. It doesn't cover any of the real issues with doing
>> > this.
>>
>> Please be more specific. It will also help if you integrate this part
>> while it's still hot.
>
> There are numerous comments in the various PATH-related issues on the issue
> tracker, and many of them are duplicated in this very thread.

The master issue at http://bugs.python.org/issue3561 specifically
proposes further discussion proposals on python-dev.

From techtonik at gmail.com  Wed Feb  2 06:41:16 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 2 Feb 2011 07:41:16 +0200
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
	Windows
In-Reply-To: <4D474F7A.2090800@v.loewis.de>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk>
	<7DA37C12-D3DA-49B3-996A-017CF304BC5C@gmail.com>
	<ihv97t$vff$1@dough.gmane.org>
	<AANLkTikcwapO5uHZH9sG98zYdePkzKiz8oJ-SgPKhAjM@mail.gmail.com>
	<AANLkTi=A9JGjy1zu88y0wUJsm4C5vf3s8Lsou2yLyGJV@mail.gmail.com>
	<4D474F7A.2090800@v.loewis.de>
Message-ID: <AANLkTikGmxQ7VchA3Yk_aCqgPK_2Lvgk8vLCzBagLxNo@mail.gmail.com>

On Tue, Feb 1, 2011 at 2:10 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 31.01.2011 22:13, schrieb anatoly techtonik:
>> Ok. Here is the patch. I used Orca to reverse installer tables of
>> Mercurial MSI and inserted similar entry for Python.
>
> This doesn't do uninstallation correctly.

I do not know where did you get this info, but I assure you that it
does, and I've stressed this in the first post of this thread.
You may repeat the experiment yourself. Here is the patched installer:

https://docs.google.com/leaf?id=0Bwu0AJeJuth_MWJjMTgzNmQtYWIzOS00ODhlLTk3YjAtYWJiYTdmYWQwNzU5&sort=name&layout=list&num=50

From rrr at ronadam.com  Wed Feb  2 07:27:43 2011
From: rrr at ronadam.com (Ron Adam)
Date: Wed, 02 Feb 2011 00:27:43 -0600
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
References: <20cf30434772fe60a6049b2a7f9a@google.com>	<4D4724FC.1040705@stoneleaf.us>	<AANLkTikFHNNpt96sSp5Kcz8K=o7RXaT0XsG8MS4PmH4z@mail.gmail.com>	<AANLkTi=aWyAo8Y8z_p-95Q+e-8A0BwBw2yhkxXmqUxBK@mail.gmail.com>
	<AANLkTikYaw0gTVVFDOE_MZ1BWpdSRRxMAc9iOUAJmtmQ@mail.gmail.com>
Message-ID: <iiath0$k19$1@dough.gmane.org>



On 02/01/2011 09:51 AM, anatoly techtonik wrote:

> So far only Georg explained what patches sent to mailing list will not
> be reviewed, because there is too much volume. But bugtracker is not a
> patch tracker. It doesn't allow to monitor incoming patches by module,
> its search is very poor. Of course mailing lists are even worse in
> this regard, but there is nothing Python community can't deal with.
> The problem is to keep non-core people outside motivated, and the
> biggest problem with current "documented process" is that nobody even
> thinks about it.

I've seen quite a bit of changes over the years.  Yes, it's happens over 
years because the release schedule is fairly long.  They try not to 
interrupt the current schedule too much, so bigger changes to the 
development process are usually made after a major release is done, rather 
than during the middle.

Lately (the last two years) things have been quite a bit busier with the 
addition of python3.x.  Once we get to where we are (mostly) only 
concentrating on one major version again, then it will be easer to make 
process changes.  (Less things to mess up if it goes wrong.)

I think after this next release is completed you will see more efforts 
turning to improving the process.  Some of the vary things you have been 
trying to pointed out I think.

As far as patches getting attention, it's getting better there too.  Every 
time you make a comment or update an issue with a patch change, it gets 
reported to the bugs list.  Many of the core developers watch that and will 
add them self to the nosey list on that issue if it has something to do 
with the parts of python they know.  If you have a patch that you feel is 
complete and is ready to go into the next release or a bug fix for the 
current one, post a comment on the issue asking for a review.  Chances are 
you will get a reply in a few days.

I've found searching for other patches related to my patches helps. I can 
search the tracker or the bug list for the module or problem I'm working 
on.  It's really not that hard to find related issues.  Then I can post a 
comment on those issues when I can be of help, and also post on that issue 
a link to the related issue I'm working on.

Python is a large project with a *huge* user base.  So changes are 
considered very carefully. Probably the hardest part is making changes in a 
way that is very unlikely to break someone's program.  Mess up someone's 
pay role process some place (even by the smallest change) and people will 
get very unhappy really quick.  It's also not good to crash space shuttles 
or google. ;-)

Cheers,
   Ron








From techtonik at gmail.com  Wed Feb  2 08:14:18 2011
From: techtonik at gmail.com (techtonik at gmail.com)
Date: Wed, 02 Feb 2011 07:14:18 +0000
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
Message-ID: <20cf3043474cb32a67049b47657c@google.com>

On 2011/02/01 19:50:23, Martin v. L?wis wrote:
> On 2011/02/01 07:22:57, techtonik wrote:
> > It removes the dependency from msi.py making it easier to do the
rest in
> > subsequent patches.

> What rest specifically? Why are the msilib changes needed for that?

The rest is to use ctypes, so that no external packages will be required
to build Python installer.

http://codereview.appspot.com/4080047/

From martin at v.loewis.de  Wed Feb  2 08:18:33 2011
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Wed, 02 Feb 2011 07:18:33 +0000
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
Message-ID: <90e6ba6e8f34f0e1ae049b477417@google.com>

On 2011/02/02 07:14:17, techtonik wrote:
> On 2011/02/01 19:50:23, Martin v. L?wis wrote:
> > On 2011/02/01 07:22:57, techtonik wrote:
> > > It removes the dependency from msi.py making it easier to do the
rest in
> > > subsequent patches.
> >
> > What rest specifically? Why are the msilib changes needed for that?

> The rest is to use ctypes, so that no external packages will be
required to
> build Python installer.

Ah. That shouldn't be done. If anything is to be done, the builtin
msilib can be considered, instead. Given the choice of using either
ctypes or an external package, I prefer the external package.


http://codereview.appspot.com/4080047/

From techtonik at gmail.com  Wed Feb  2 08:32:03 2011
From: techtonik at gmail.com (techtonik at gmail.com)
Date: Wed, 02 Feb 2011 07:32:03 +0000
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
Message-ID: <20cf3056445d2d4dd5049b47a512@google.com>

On 2011/02/02 07:18:33, Martin v. L?wis wrote:
> Ah. That shouldn't be done. If anything is to be done, the builtin
msilib can be
> considered, instead. Given the choice of using either ctypes or an
external
> package, I prefer the external package.

It is a surprise to find builtin msilib. Why isn't it used? Is an
incremental transition to builtin possible?

http://codereview.appspot.com/4080047/

From georg.brandl at gmail.com  Wed Feb  2 08:36:47 2011
From: georg.brandl at gmail.com (georg.brandl at gmail.com)
Date: Wed, 02 Feb 2011 07:36:47 +0000
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
Message-ID: <90e6ba6e8a0e225e1d049b47b6ea@google.com>

On 2011/02/02 07:32:02, techtonik wrote:

[...]

Can you PLEASE take this off python-dev and move to an issue at
bugs.python.org?  At least remove python-dev from the CC, or we'll
have to temporarily block messages from codereview.

http://codereview.appspot.com/4080047/

From techtonik at gmail.com  Wed Feb  2 09:33:05 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 2 Feb 2011 10:33:05 +0200
Subject: [Python-Dev] devguide: Generate patches without code checkout (Was:
 devguide: Write a guide to committing a patch.)
Message-ID: <AANLkTikbGXppMSgoT=4FYECaDsRAxSLBKc4rsisPB5NE@mail.gmail.com>

On Tue, Jan 18, 2011 at 2:35 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 18 Jan 2011 07:14:51 +0100
> Ezio Melotti <ezio.melotti at gmail.com> wrote:
>> > +
>> > +Committing Patches
>> > +==================
> [...]
>> > +
>> > + ? ?svnmerge.py merge -r 42
>> > +
>> > +This will try to apply the patch to the current patch and generate a
>> > commit
>
> Do we want to spend so much time explaining how to use SVN for core
> developers while we're supposed to switch to Mercurial Real Soon Now?
> (current core devs already know how to use it, and we don't get many
> new ones every month)

How about patches sent by users who track and fix bugs directly in
codebase of their Python installation?

Making and testing a patch from Python checkout requires compiling
Python, which is not possible for Windows users. We should add less
hardcore instructions how to use bundled diff.py for creating simple
patches like docstring, comment fixes or generating new testcases.
This will greatly reduce the barrier for starting with development.
-- 
anatoly t.

From martin at v.loewis.de  Wed Feb  2 09:36:37 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Feb 2011 09:36:37 +0100
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <20cf3056445d2d4dd5049b47a512@google.com>
References: <20cf3056445d2d4dd5049b47a512@google.com>
Message-ID: <4D491795.2020008@v.loewis.de>


> It is a surprise to find builtin msilib. Why isn't it used?

Originally, because Python needs to be packaged with an older
release (in particular one that isn't itself maintained anymore).
Today, the problem is that the msilib package doesn't support
merge modules (and if such support was added, we would have to
wait until the version containing it isn't maintained anymore).

I don't consider the dependency on win32com a serious issue at
all; it's just a mild annoyance (much less than reliance on ctypes
would be, or hard-coding of symbolic constants).

Regards,
Martin

From ncoghlan at gmail.com  Wed Feb  2 11:27:24 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 2 Feb 2011 20:27:24 +1000
Subject: [Python-Dev] devguide: Generate patches without code checkout
 (Was: devguide: Write a guide to committing a patch.)
In-Reply-To: <AANLkTikbGXppMSgoT=4FYECaDsRAxSLBKc4rsisPB5NE@mail.gmail.com>
References: <AANLkTikbGXppMSgoT=4FYECaDsRAxSLBKc4rsisPB5NE@mail.gmail.com>
Message-ID: <AANLkTi=ZmZF9XjZ=wYy97dod_w-hb_C12ghSLW80eUFx@mail.gmail.com>

On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> Making and testing a patch from Python checkout requires compiling
> Python, which is not possible for Windows users.

That latter comment hasn't been true since Microsoft started releasing
the Visual Studio Express editions.

> We should add less
> hardcore instructions how to use bundled diff.py for creating simple
> patches like docstring, comment fixes or generating new testcases.
> This will greatly reduce the barrier for starting with development.

Given the length of Python's release cycles, diffs against released
versions are far too likely to be out of date. We want diffs against
the head of the relevant branch.

People that can't check out and build their own version of Python are
quite welcome to simply report issues without trying to fix them
themselves.

Cheers,
Nick.

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

From techtonik at gmail.com  Wed Feb  2 12:03:05 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 2 Feb 2011 13:03:05 +0200
Subject: [Python-Dev] MSI: Remove dependency from win32com.client module
	(issue4080047)
In-Reply-To: <4D491795.2020008@v.loewis.de>
References: <20cf3056445d2d4dd5049b47a512@google.com>
	<4D491795.2020008@v.loewis.de>
Message-ID: <AANLkTikuT1wZ5pzauLpLimbB1y9ihkKcXjqQU_jaKn_5@mail.gmail.com>

On Wed, Feb 2, 2011 at 10:36 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
>> It is a surprise to find builtin msilib. Why isn't it used?
>
> Originally, because Python needs to be packaged with an older
> release (in particular one that isn't itself maintained anymore).

That doesn't answer the question why Python could not be packaged with
a newer release of 'msilib' at that time?

> Today, the problem is that the msilib package doesn't support
> merge modules (and if such support was added, we would have to
> wait until the version containing it isn't maintained anymore).

I don't understand the phrase in (). What for do we need to wait after
adding support for merge modules to builtin msilib?
I imagine we've added support for merge modules to msilib, and then
waiting until new msilib version with merge support isn't maintained
anymore. And only then we can use it to create installer. Sounds like
a nonsense.

Anyways, is it possible to reuse builtin msilib to the max and add
required 'merge modules' functionality inside msi.py or extension
module?

> I don't consider the dependency on win32com a serious issue at
> all; it's just a mild annoyance (much less than reliance on ctypes
> would be, or hard-coding of symbolic constants).

There is nothing wrong with hardcoded symbolic constants - Microsoft
specifically provides values for them in their MSDN materials to be
used with scripting languages which doesn't have include files. They
just need to be validated one time, and won't change in future.

Why don't you like ctypes solution? I find it strange that Python
build process avoids using its own modules.

-- 
anatoly t.

From sandro.tosi at gmail.com  Wed Feb  2 12:04:44 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Wed, 2 Feb 2011 12:04:44 +0100
Subject: [Python-Dev] [Python-checkins] devguide: Add a document
 discussing the development cycle typically followed for
In-Reply-To: <E1PiDib-0004cD-TP@dinsdale.python.org>
References: <E1PiDib-0004cD-TP@dinsdale.python.org>
Message-ID: <AANLkTikQzR+_0hgMd3qiQXR3-SoDXt7Yfq8rk__wkxLC@mail.gmail.com>

On Wed, Jan 26, 2011 at 23:20, brett.cannon <python-checkins at python.org> wrote:
> +The in-development branch is where new functionality and semantic changes

new functionalities (dunno if it's plural in english or not)?

> +occur. Currently this branch is known as the "py3k" branch. The next minor
> +release of Python will come from this branch (major releases are once a decade
> +and so have no specific rules on how they are started). All changes land in this
> +branch and then trickle down to other branches.
> +
> +Once a Final_ release is made from the in-development branch, a branch is made
> +to represent the minor version of Python and it goes into maintenance mode.
> +Typically a minor version of Python is under development for about 18 months.
> +
> +
> +Maintenance
> +-----------
> +The branch currently being maintained for bug fixes.
> +
> +The branch under maintenance is the last minor version of Python to be released
> +as Final_. This means that the latest release of Python was 3.1.2, then the

if the latest release ?

> +branch representing Python 3.1 is in maintenance mode.
> +
> +The only changes allowed to occur in a maintenance branch without debate are bug
> +fixes.
> +Semantic changes **must** be carefully considered as code out in the world will
> +have already been developed that will rely on the released semantics. Changes
> +related to semantics should be discussed on python-dev before being made.
> +
> +A branch stays in maintenance mode as long as a new minor release has not been
> +made. For example, this means that Python 2.6 stayed in maintenance mode until
> +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and
> +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18
> +month schedule, a branch stays in mainteance mode for the same amount of time.

s/mainteance/maintenance/

> +
> +A micro release of a maintenance branch is made about every six months.
> +Typically when a new minor release is made one more release of the new-old
> +version of Python is made.
> +
> +
> +Security
> +--------
> +A branch less than five years old but no longer in maintenance mode.
> +
> +The only changes made to a branch that is being maintained for security
> +purposes are somewhat obviously those related to security, e.g., privilege
> +escalation. Crashers and other behaviorial issues are **not** considered a

s/Crashers/Crashes/
s/behaviorial/behavioral/

> +security risk and thus not backported to a branch being maintained for
> +security. Any releases made for a branch under security maintenance is

s/releases/release/ ?
s/for/from/

> +source-only and done only when actual security patches have been applied to the
> +branch.
> +
> +
> +Stages
> +''''''
> +
> +Based on what stage the in-development version of Python is in, the
> +responsibilities of a core developer change in regards to commits to the VCS.
> +
> +
> +Pre-alpha
> +---------
> +This is the stage a branch is in from the last final release until the first
> +alpha (a1). There are no special restrictions placed on commits beyond those
> +imposed by the type of branch being worked on (e.g., in-development vs.
> +maintenance).
> +
> +
> +Alpha
> +-----
> +Alphas typically serve as a reminder to core developers that they need to start
> +getting in changes that change semantics or add something to Python as such
> +things should not be added during a Beta_. Otherwise no new restrictions are in
> +place while in alpha.
> +
> +
> +Beta
> +----
> +A branch in beta means that no new additions to Python are accepted. Bugfixes
> +and the like are still fine. Being in beta can be viewed much like being in RC_
> +but without the extra overhead of needing commit reviews.
> +
> +
> +.. _RC:
> +
> +Release Candidate (RC)
> +----------------------
> +A branch preparing for an RC release can only have bugfixes applied that have
> +been reviewed by other core developers. That reviewer should make a post to the
> +issue related to the change and be mentioned in the commit message.
> +
> +You **cannot** skip the peer review during an RC, no matter how small! Even if
> +it is a simple copy-and-paste change, **everything** requires peer review from
> +a core developer.
> +
> +
> +Final
> +-----
> +When a final release is being cut, only the release manager (RM) can make
> +changes to the branch.
> diff --git a/index.rst b/index.rst
> --- a/index.rst
> +++ b/index.rst
> @@ -20,6 +20,7 @@
> ? ?coredev
> ? ?developers
> ? ?committing
> + ? devcycle
>
> ? ?stdlibchanges
> ? ?langchanges
> @@ -64,6 +65,7 @@
> ?* :ref:`coredev`
> ? ? * :ref:`developers`
> ? ? * :ref:`committing`
> + ? ?* :ref:`devcycle`
>
>
> ?Proposing changes to Python itself
>
> --
> Repository URL: http://hg.python.org/devguide
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
>



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

From fuzzyman at voidspace.org.uk  Wed Feb  2 12:22:24 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 02 Feb 2011 11:22:24 +0000
Subject: [Python-Dev] [Python-checkins] devguide: Add a document
 discussing the development cycle typically followed for
In-Reply-To: <AANLkTikQzR+_0hgMd3qiQXR3-SoDXt7Yfq8rk__wkxLC@mail.gmail.com>
References: <E1PiDib-0004cD-TP@dinsdale.python.org>
	<AANLkTikQzR+_0hgMd3qiQXR3-SoDXt7Yfq8rk__wkxLC@mail.gmail.com>
Message-ID: <4D493E70.9050606@voidspace.org.uk>

On 02/02/2011 11:04, Sandro Tosi wrote:
> On Wed, Jan 26, 2011 at 23:20, brett.cannon<python-checkins at python.org>  wrote:
>> +The in-development branch is where new functionality and semantic changes
> new functionalities (dunno if it's plural in english or not)?

It's an odd one. Functionality can be implicitly plural (include several 
individual features that comprise new functionality) but can also be 
pluralised; several functionalities where each new functionality 
comprises plural features. I would say that Brett's wording reads 
correctly here.

Michael

>> +occur. Currently this branch is known as the "py3k" branch. The next minor
>> +release of Python will come from this branch (major releases are once a decade
>> +and so have no specific rules on how they are started). All changes land in this
>> +branch and then trickle down to other branches.
>> +
>> +Once a Final_ release is made from the in-development branch, a branch is made
>> +to represent the minor version of Python and it goes into maintenance mode.
>> +Typically a minor version of Python is under development for about 18 months.
>> +
>> +
>> +Maintenance
>> +-----------
>> +The branch currently being maintained for bug fixes.
>> +
>> +The branch under maintenance is the last minor version of Python to be released
>> +as Final_. This means that the latest release of Python was 3.1.2, then the
> if the latest release ?
>
>> +branch representing Python 3.1 is in maintenance mode.
>> +
>> +The only changes allowed to occur in a maintenance branch without debate are bug
>> +fixes.
>> +Semantic changes **must** be carefully considered as code out in the world will
>> +have already been developed that will rely on the released semantics. Changes
>> +related to semantics should be discussed on python-dev before being made.
>> +
>> +A branch stays in maintenance mode as long as a new minor release has not been
>> +made. For example, this means that Python 2.6 stayed in maintenance mode until
>> +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and
>> +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18
>> +month schedule, a branch stays in mainteance mode for the same amount of time.
> s/mainteance/maintenance/
>
>> +
>> +A micro release of a maintenance branch is made about every six months.
>> +Typically when a new minor release is made one more release of the new-old
>> +version of Python is made.
>> +
>> +
>> +Security
>> +--------
>> +A branch less than five years old but no longer in maintenance mode.
>> +
>> +The only changes made to a branch that is being maintained for security
>> +purposes are somewhat obviously those related to security, e.g., privilege
>> +escalation. Crashers and other behaviorial issues are **not** considered a
> s/Crashers/Crashes/
> s/behaviorial/behavioral/
>
>> +security risk and thus not backported to a branch being maintained for
>> +security. Any releases made for a branch under security maintenance is
> s/releases/release/ ?
> s/for/from/
>
>> +source-only and done only when actual security patches have been applied to the
>> +branch.
>> +
>> +
>> +Stages
>> +''''''
>> +
>> +Based on what stage the in-development version of Python is in, the
>> +responsibilities of a core developer change in regards to commits to the VCS.
>> +
>> +
>> +Pre-alpha
>> +---------
>> +This is the stage a branch is in from the last final release until the first
>> +alpha (a1). There are no special restrictions placed on commits beyond those
>> +imposed by the type of branch being worked on (e.g., in-development vs.
>> +maintenance).
>> +
>> +
>> +Alpha
>> +-----
>> +Alphas typically serve as a reminder to core developers that they need to start
>> +getting in changes that change semantics or add something to Python as such
>> +things should not be added during a Beta_. Otherwise no new restrictions are in
>> +place while in alpha.
>> +
>> +
>> +Beta
>> +----
>> +A branch in beta means that no new additions to Python are accepted. Bugfixes
>> +and the like are still fine. Being in beta can be viewed much like being in RC_
>> +but without the extra overhead of needing commit reviews.
>> +
>> +
>> +.. _RC:
>> +
>> +Release Candidate (RC)
>> +----------------------
>> +A branch preparing for an RC release can only have bugfixes applied that have
>> +been reviewed by other core developers. That reviewer should make a post to the
>> +issue related to the change and be mentioned in the commit message.
>> +
>> +You **cannot** skip the peer review during an RC, no matter how small! Even if
>> +it is a simple copy-and-paste change, **everything** requires peer review from
>> +a core developer.
>> +
>> +
>> +Final
>> +-----
>> +When a final release is being cut, only the release manager (RM) can make
>> +changes to the branch.
>> diff --git a/index.rst b/index.rst
>> --- a/index.rst
>> +++ b/index.rst
>> @@ -20,6 +20,7 @@
>>     coredev
>>     developers
>>     committing
>> +   devcycle
>>
>>     stdlibchanges
>>     langchanges
>> @@ -64,6 +65,7 @@
>>   * :ref:`coredev`
>>      * :ref:`developers`
>>      * :ref:`committing`
>> +    * :ref:`devcycle`
>>
>>
>>   Proposing changes to Python itself
>>
>> --
>> Repository URL: http://hg.python.org/devguide
>> _______________________________________________
>> Python-checkins mailing list
>> Python-checkins at python.org
>> http://mail.python.org/mailman/listinfo/python-checkins
>>
>>
>
>


-- 
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  Wed Feb  2 13:50:22 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 2 Feb 2011 14:50:22 +0200
Subject: [Python-Dev] devguide: Generate patches without code checkout
 (Was: devguide: Write a guide to committing a patch.)
In-Reply-To: <AANLkTi=ZmZF9XjZ=wYy97dod_w-hb_C12ghSLW80eUFx@mail.gmail.com>
References: <AANLkTikbGXppMSgoT=4FYECaDsRAxSLBKc4rsisPB5NE@mail.gmail.com>
	<AANLkTi=ZmZF9XjZ=wYy97dod_w-hb_C12ghSLW80eUFx@mail.gmail.com>
Message-ID: <AANLkTikofQsY9NtWDUqcx2syU3GvgD=HSLgz8i_A=sbu@mail.gmail.com>

On Wed, Feb 2, 2011 at 12:27 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik <techtonik at gmail.com> wrote:
>> Making and testing a patch from Python checkout requires compiling
>> Python, which is not possible for Windows users.
>
> That latter comment hasn't been true since Microsoft started releasing
> the Visual Studio Express editions.

"not possible" here means that practically only a very small percent
of Python users will go through the hurdles of getting code checkout,
downloading and installing Visual Studio, compiling project, switching
their code to use compiled version and finally submitting a patch.

BTW, what is the size of Mercurial clone right now?

>> We should add less
>> hardcore instructions how to use bundled diff.py for creating simple
>> patches like docstring, comment fixes or generating new testcases.
>> This will greatly reduce the barrier for starting with development.
>
> Given the length of Python's release cycles, diffs against released
> versions are far too likely to be out of date. We want diffs against
> the head of the relevant branch.

I only see that you want the contribution entry barrier to stay at the
height of core developer.

> People that can't check out and build their own version of Python are
> quite welcome to simply report issues without trying to fix them
> themselves.

But if they really want for an issue to be fixed, they will need to
think about preparing a patch. The first time they ask about plans to
fix the issue, they will be asked to send a patch anyway. This person
will look into devguide how to send a patch. There will be
instructions to download Visual Studio, clone repository, compile,
etc. I doubt this person will have time to do this, but next time the
person will think twice before reporting.

From hodgestar+pythondev at gmail.com  Wed Feb  2 13:59:02 2011
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Wed, 2 Feb 2011 14:59:02 +0200
Subject: [Python-Dev] devguide: Generate patches without code checkout
 (Was: devguide: Write a guide to committing a patch.)
In-Reply-To: <AANLkTikbGXppMSgoT=4FYECaDsRAxSLBKc4rsisPB5NE@mail.gmail.com>
References: <AANLkTikbGXppMSgoT=4FYECaDsRAxSLBKc4rsisPB5NE@mail.gmail.com>
Message-ID: <AANLkTi=X9Kdog-9x1R9L9Fv4WTkpEXS4RVH75qCbu6oW@mail.gmail.com>

On Wed, Feb 2, 2011 at 10:33 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> How about patches sent by users who track and fix bugs directly in
> codebase of their Python installation?

While I don't personally endorse the above approach, if you're going
to develop inside your installed site-packages folder it seems like a
good idea to at least version control that code by running "hg init"
or similar in the site-packages folder. Then you can create diffs
against older versions using "hg diff".

If one is going to do something crazy one might as well go the whole
hog I guess. :)

Schiavo
Simon

From solipsis at pitrou.net  Wed Feb  2 14:51:56 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 2 Feb 2011 14:51:56 +0100
Subject: [Python-Dev] [Python-checkins] devguide: Add a document
 discussing the development cycle typically followed for
References: <E1PiDib-0004cD-TP@dinsdale.python.org>
	<AANLkTikQzR+_0hgMd3qiQXR3-SoDXt7Yfq8rk__wkxLC@mail.gmail.com>
Message-ID: <20110202145156.6f62d39b@pitrou.net>

On Wed, 2 Feb 2011 12:04:44 +0100
Sandro Tosi <sandro.tosi at gmail.com> wrote:
> > +Security
> > +--------
> > +A branch less than five years old but no longer in maintenance mode.
> > +
> > +The only changes made to a branch that is being maintained for security
> > +purposes are somewhat obviously those related to security, e.g., privilege
> > +escalation. Crashers and other behaviorial issues are **not** considered a
> 
> s/Crashers/Crashes/
> s/behaviorial/behavioral/
> 
> > +security risk

By the way, crashers *are* a security risk.
See http://code.python.org/hg/branches/release2.6-maint/

Regards

Antoine.



From erez27 at gmail.com  Wed Feb  2 14:52:17 2011
From: erez27 at gmail.com (Erez Sh)
Date: Wed, 2 Feb 2011 15:52:17 +0200
Subject: [Python-Dev] xmlrpclib and communication verbosity
Message-ID: <AANLkTimJJ70t93FaDOc-dpuw-jK0ocQ5T4vGxG+w06UV@mail.gmail.com>

In an attempt to record the xml exchange in an xmlrpclib.ServerProxy
connection, I set its verbose flag to 1.
This is the whole premise, and the rest of this message contains a bug
report, and general complaints about the API.

ServerProxy, or to be a bit more specific, the Transport class (which does
all the actual printing), provides very little control over where the output
goes.
By very little, I mean it only outputs to stdout, which is limiting in a
server environment where many a prints occur.

That, however, turned out to be the least of my worries: xmlrpclib depends
on httplib.HTTP to print the outgoing data, but prints its own incoming
data,
and they tend to collide, in what I permit myself to call a "race
condition", though it's mostly just simple lack of management of a shared
resource (stdout).
The resulting output is mostly well-formed, with the occasional nonsense
produced by an interjection of one string to the middle of the other.

Also, there's the nasty business of Transport.request accepting a 'verbose'
param, and then setting it as an instance attribute and using *that*, for no
apparent reason except to cause yet another potential race condition.

I suggest that httplib.HTTP's verbosity will be controlled by a separate
flag, if controlled at all.
The outgoing communication can easily be printed by transport, allowing for
better control of synchrony.
Also, ServerProxy should accept an optional output file (=a class with
write,writelines methods), which will be the target of all prints.

Would Python be interested in such a patch?

Best Regards,
  Erez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110202/3b234a70/attachment.html>

From brian.curtin at gmail.com  Wed Feb  2 16:52:55 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Wed, 2 Feb 2011 09:52:55 -0600
Subject: [Python-Dev] curtin-win2008-amd64 build slave down for a while
Message-ID: <AANLkTin4F-UTb5AfwPF1U6OfRYAuMuFRjgZ5ScKkDuAB@mail.gmail.com>

I'm having some power issues due to a major snow storm so my build slave is
turned off.

Don't worry, everyone's favorite OS will be back to work within the next few
days.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110202/2578d864/attachment.html>

From osirius at gmail.com  Wed Feb  2 16:55:03 2011
From: osirius at gmail.com (Sam Bull)
Date: Wed, 2 Feb 2011 10:55:03 -0500
Subject: [Python-Dev] alternate fix for urllib2 bug #8797
Message-ID: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com>

Hello all,

This is my first stab at contributing to this list. I'm writing to lobby for bug #8797's fix to be removed and for my fix to put in in its place. I'm probably doing this wrong, so please bear with me. I will embrace whatever scathing criticism I get.

The ticket covers all the details (http://bugs.python.org/issue8797#) but I'll try to summarize here:

In 2.6.5, urllib2 had a small regression that caused HTTP 401 errors to trigger an infinite recursion when the request handler had HTTP Auth credentials that the server was rejecting.

Previously, urllib2 avoided this loop by checking the previous request's headers to see if it had already tried the credentials it was about to try. If it had, it would re-raise the exception instead of trying again.

The current fix adds a "max retries" concept to urllib2's handling of HTTP 401 errors so that the code will only retry a certain number of times.

To me, the original logic of only trying once for each set of credentials was sound, and it looks like the only reason this stopped working was that in 2.6.5 the auth header wasn't being stored in the same place as the code was expecting to find it.

I think it makes sense to revisit this issue and swap out the existing fix for my fix because it's tidier and doesn't introduce this new "max retries" functionality.

Please let me know what you think.

Thanks,

Sam Bull
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110202/cd0c799d/attachment-0001.html>

From alexander.belopolsky at gmail.com  Wed Feb  2 17:13:14 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 2 Feb 2011 11:13:14 -0500
Subject: [Python-Dev] alternate fix for urllib2 bug #8797
In-Reply-To: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com>
References: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com>
Message-ID: <AANLkTikOycAQiXpw5cTwwSHr86PjoY3D_=zoarhnOHMA@mail.gmail.com>

On Wed, Feb 2, 2011 at 10:55 AM, Sam Bull <osirius at gmail.com> wrote:
>..  I'm writing to lobby for bug #8797's fix to be removed and for my fix to put in in its place.

Please open a separate issue for your patch.  Patches attached to
closed issues will be lost.

From hodgestar+pythondev at gmail.com  Wed Feb  2 17:25:45 2011
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Wed, 2 Feb 2011 18:25:45 +0200
Subject: [Python-Dev] alternate fix for urllib2 bug #8797
In-Reply-To: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com>
References: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com>
Message-ID: <AANLkTikuM-gPKgVEi7ovQYt=Riq88XjUPrkdR0J4=vfe@mail.gmail.com>

Hi Sam

On Wed, Feb 2, 2011 at 5:55 PM, Sam Bull <osirius at gmail.com> wrote:
> This is my first stab at contributing to this list. I'm writing to lobby for
> bug #8797's fix to be removed and for my fix to put in in its place.

For what it's worth, I was already about to include your patch as a
workaround for the bug in 2.6. See Bitten issue
http://bitten.edgewall.org/ticket/658.

I also consider Sam's patch to be a cleaner patch than the one that
ended up being applied in Python. See my comments in the Bitten
mailing list thread:
https://groups.google.com/forum/#!topic/bitten/niJENqEGuus.

Schiavo
Simon

From hoyt6 at llnl.gov  Wed Feb  2 20:01:06 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Wed, 2 Feb 2011 11:01:06 -0800
Subject: [Python-Dev] Python merge module
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>

Is there or will there be support for python merge modules so we can include python in our installer?

Also, the discussions I saw about windows installers not removing the path on uninstall is completely false as regards the installers that wix creates, at least. I've modified the path many times and explicitly tested that it was removed on uninstall. I can't speak for the msilib package and what it does - perhaps it's doing the wrong thing?

But has there been thought towards migrating away from msilib and using platform standard tools such as wix (used by ms office, visual studio, etc.)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110202/7eeea791/attachment.html>

From g.brandl at gmx.net  Wed Feb  2 20:29:15 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 02 Feb 2011 20:29:15 +0100
Subject: [Python-Dev] devguide: Generate patches without code checkout
 (Was: devguide: Write a guide to committing a patch.)
In-Reply-To: <AANLkTikofQsY9NtWDUqcx2syU3GvgD=HSLgz8i_A=sbu@mail.gmail.com>
References: <AANLkTikbGXppMSgoT=4FYECaDsRAxSLBKc4rsisPB5NE@mail.gmail.com>	<AANLkTi=ZmZF9XjZ=wYy97dod_w-hb_C12ghSLW80eUFx@mail.gmail.com>
	<AANLkTikofQsY9NtWDUqcx2syU3GvgD=HSLgz8i_A=sbu@mail.gmail.com>
Message-ID: <iicbag$66u$1@dough.gmane.org>

Am 02.02.2011 13:50, schrieb anatoly techtonik:

>>> We should add less
>>> hardcore instructions how to use bundled diff.py for creating simple
>>> patches like docstring, comment fixes or generating new testcases.
>>> This will greatly reduce the barrier for starting with development.
>>
>> Given the length of Python's release cycles, diffs against released
>> versions are far too likely to be out of date. We want diffs against
>> the head of the relevant branch.
> 
> I only see that you want the contribution entry barrier to stay at the
> height of core developer.

Because only core developers are allowed to have a checkout of trunk?

Georg


From merwok at netwok.org  Wed Feb  2 20:48:03 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 02 Feb 2011 20:48:03 +0100
Subject: [Python-Dev] Moving stuff out of Misc and over to the devguide
In-Reply-To: <ih767d$vao$1@dough.gmane.org>
References: <AANLkTi=OKb7S1U+AsW9nz69WPDD0CPF5hTb23sQpC4_S@mail.gmail.com>	<20110117215440.122bef7b@pitrou.net>	<AANLkTi=MTbCgJs7znKN+SLLLiM==yrX0nJ5t-dQ8Y4yt@mail.gmail.com>	<4D36E118.40008@netwok.org>	<7e9e0831fbf09c304e9f358b406f43b8.squirrel@mail.trueblade.com>
	<ih767d$vao$1@dough.gmane.org>
Message-ID: <4D49B4F3.9000503@netwok.org>

Le 19/01/2011 18:04, Georg Brandl a ?crit :
> Am 19.01.2011 16:25, schrieb Eric Smith:
>>> Bonus question: if we remove maintainers.rst from py3k, what do we do in
>>> 3.1 and 2.7?  I?d favor removing them over keeping outdated versions.
>>
>> Is there not some advantage to knowing who was the maintainer (or expert)
>> of a given module at the time of a release?
> 
> I don't see much advantage.  And if you need the version of maintainers.rst
> in another repo, it's not hard to find the revision that corresponds to the
> release date.

Ping.  Do we remove maintainers.rst or do we add a note advising people
to look at the up-to-date version on docs.python.org/devguide?

(And yes, by ?we? I mean I?m volunteering to do either. :)

Regards

From brian.curtin at gmail.com  Wed Feb  2 21:17:22 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Wed, 2 Feb 2011 14:17:22 -0600
Subject: [Python-Dev] devguide: Generate patches without code checkout
 (Was: devguide: Write a guide to committing a patch.)
In-Reply-To: <AANLkTikofQsY9NtWDUqcx2syU3GvgD=HSLgz8i_A=sbu@mail.gmail.com>
References: <AANLkTikbGXppMSgoT=4FYECaDsRAxSLBKc4rsisPB5NE@mail.gmail.com>
	<AANLkTi=ZmZF9XjZ=wYy97dod_w-hb_C12ghSLW80eUFx@mail.gmail.com>
	<AANLkTikofQsY9NtWDUqcx2syU3GvgD=HSLgz8i_A=sbu@mail.gmail.com>
Message-ID: <AANLkTimoVX9yXgXGSRU6KgsGf2nYhqS-=orZzA5-QANy@mail.gmail.com>

On Wed, Feb 2, 2011 at 06:50, anatoly techtonik <techtonik at gmail.com> wrote:

> On Wed, Feb 2, 2011 at 12:27 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik <techtonik at gmail.com>
> wrote:
> >> Making and testing a patch from Python checkout requires compiling
> >> Python, which is not possible for Windows users.
> >
> > That latter comment hasn't been true since Microsoft started releasing
> > the Visual Studio Express editions.
>
> "not possible" here means that practically only a very small percent
> of Python users will go through the hurdles of getting code checkout,
> downloading and installing Visual Studio, compiling project, switching
> their code to use compiled version and finally submitting a patch.
>

In reality this doesn't seem to be the case. In all of the Windows-related
Python issues I've looked at in a year and a half, only a small handful of
the patches or analysis have been based on installed versions or from users
who don't have the capability or interest in setting up the environment. Of
course we welcome those users, but my experience shows them to be the
minority.

Installing Visual Studio is probably one of the more rare steps in the
process, as many Windows-using software developers tend to use it for other
things.

> People that can't check out and build their own version of Python are
> > quite welcome to simply report issues without trying to fix them
> > themselves.
>
> But if they really want for an issue to be fixed, they will need to
> think about preparing a patch.


This is not true at all. It's perfectly acceptable to report an issue and do
nothing further. It certainly helps the process to contribute more, but
we're happy to just get valid bug reports. Someone even made it easy enough
to email report at bugs.python.org so you don't even have to create an account.


> The first time they ask about plans to
> fix the issue, they will be asked to send a patch anyway.


We don't want bugs to linger, but there's only so many developers and so
little time. If you want to know when something will be fixed, a lot of
people will say something like "I won't be able to get to this next week,
unless you have a patch of your own". I don't see anything wrong with that.
In fact, it's pretty common in open source.

This person
> will look into devguide how to send a patch. There will be
> instructions to download Visual Studio, clone repository, compile,
> etc. I doubt this person will have time to do this, but next time the
> person will think twice before reporting.


I've found quite the opposite to be true. The dev guide I wrote for PSF
Sprints, most of which was absorbed into the recently created
http://docs.python.org/devguide/, got many people happily setup to
contribute and I expect the new one to do the same. In fact, I've heard
comments from a number of people that the setup was much easier than they
thought, especially compared to other projects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110202/da09d159/attachment.html>

From phd at phdru.name  Wed Feb  2 21:34:13 2011
From: phd at phdru.name (Oleg Broytman)
Date: Wed, 2 Feb 2011 23:34:13 +0300
Subject: [Python-Dev] xmlrpclib and communication verbosity
In-Reply-To: <AANLkTimJJ70t93FaDOc-dpuw-jK0ocQ5T4vGxG+w06UV@mail.gmail.com>
References: <AANLkTimJJ70t93FaDOc-dpuw-jK0ocQ5T4vGxG+w06UV@mail.gmail.com>
Message-ID: <20110202203413.GE16949@iskra.aviel.ru>

On Wed, Feb 02, 2011 at 03:52:17PM +0200, Erez Sh wrote:
> Also, ServerProxy should accept an optional output file (=a class with
> write,writelines methods), which will be the target of all prints.

   Why not logging?

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From martin at v.loewis.de  Wed Feb  2 22:07:31 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Feb 2011 22:07:31 +0100
Subject: [Python-Dev] Python merge module
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <4D49C793.40507@v.loewis.de>

Am 02.02.2011 20:01, schrieb Hoyt, David:
> Is there or will there be support for python merge modules so we can
> include python in our installer?

I haven't planned any. Contributions are welcome.

> But has there been thought towards migrating away from msilib and using
> platform standard tools such as wix (used by ms office, visual studio,
> etc.)?

Are you sure visual studio uses wix? I wouldn't call it a "platform
standard tool". The Installer COM object is the platform standard
mechanism, and that's what msilib uses. I really see no need to move
away from that - it can create arbitrary MSI files.

Regards,
Martin

From hoyt6 at llnl.gov  Wed Feb  2 22:27:07 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Wed, 2 Feb 2011 13:27:07 -0800
Subject: [Python-Dev] Python merge module
In-Reply-To: <4D49C793.40507@v.loewis.de>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>

>> Is there or will there be support for python merge modules so we can
>> include python in our installer?
>
>I haven't planned any. Contributions are welcome.
>
>> But has there been thought towards migrating away from msilib and using
>> platform standard tools such as wix (used by ms office, visual studio,
>> etc.)?
>
>Are you sure visual studio uses wix? 

The visual studio regularly contributes to the wix toolset. They and the .net framework team contributed a lot of the wix bootstrapper (burn) foundational code.

> I wouldn't call it a "platform standard tool". 

It's becoming that as more and more projects are adopting it. It was considered to be shipped w/ VS 2010 but didn't make it due to management/time issues.

> The Installer COM object is the platform standard mechanism, and that's what msilib uses. 

Why maintain a lib when there's (better), free alternatives out there that are maintained by Microsoft itself? (okay, a group at Microsoft that works on their free time, but has significant contributions by many teams at Microsoft -- thus they have a vested interested in its success).

> I really see no need to move away from that - it can create arbitrary MSI files.

Can it create merge modules? Transform files (e.g. localization)? Bootstrappers? There's a lot more to ms installers than the msi itself. Wouldn't it be easier to maintain an XML file than an entire lib dedicated to something that someone else has already solved?

From merwok at netwok.org  Wed Feb  2 23:01:24 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 02 Feb 2011 23:01:24 +0100
Subject: [Python-Dev] [Python-checkins] r88323 - in
 python/branches/release31-maint: Lib/configparser.py Misc/NEWS
In-Reply-To: <20110202213549.1CE8BEEA55@mail.python.org>
References: <20110202213549.1CE8BEEA55@mail.python.org>
Message-ID: <4D49D434.4070400@netwok.org>

Hello,

> --- python/branches/release31-maint/Lib/configparser.py	(original)
> +++ python/branches/release31-maint/Lib/configparser.py	Wed Feb  2 22:35:48 2011
> @@ -88,7 +88,7 @@
>  """
>  
>  try:
> -    from collections import OrderedDict as _default_dict
> +    from collections import Mapping, OrderedDict as _default_dict
>  except ImportError:
>      # fallback for setup.py which hasn't yet built _collections
>      _default_dict = dict

Buildbots can?t compile after that change, because Mapping is not found.
 I suggest aliasing Mapping to dict in the except block (untested).

Regards

From murman at gmail.com  Wed Feb  2 23:16:33 2011
From: murman at gmail.com (Michael Urman)
Date: Wed, 2 Feb 2011 16:16:33 -0600
Subject: [Python-Dev] Python merge module
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>

On Wed, Feb 2, 2011 at 15:27, Hoyt, David <hoyt6 at llnl.gov> wrote:
>> The Installer COM object is the platform standard mechanism, and that's what msilib uses.
>
> Why maintain a lib when there's (better), free alternatives out there that are maintained by Microsoft itself? (okay, a group at Microsoft that works on their free time, but has significant contributions by many teams at Microsoft -- thus they have a vested interested in its success).
>
>> I really see no need to move away from that - it can create arbitrary MSI files.
>
> Can it create merge modules? Transform files (e.g. localization)? Bootstrappers? There's a lot more to ms installers than the msi itself. Wouldn't it be easier to maintain an XML file than an entire lib dedicated to something that someone else has already solved?

If Python was starting at ground zero, and the choices were to create
a library or to use WiX, the answer might have been different. However
with a mature enough library to suit all the needs that anyone has
been willing to author, it's certainly more work to create the WiX
install and maintain it than it is to merely maintain the existing
scripts.

As far as the possibility of distributing Python as a merge module?
I'd recommend against it. Shared location merge modules are a
maintenance nightmare, and private location merge modules may not
offer the benefit you need. Better to just install the main Python msi
as part of a suite with your installer, whether you build that
installer in WiX and burn, or not.

Michael

From ncoghlan at gmail.com  Thu Feb  3 00:00:11 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 3 Feb 2011 09:00:11 +1000
Subject: [Python-Dev] alternate fix for urllib2 bug #8797
In-Reply-To: <AANLkTikOycAQiXpw5cTwwSHr86PjoY3D_=zoarhnOHMA@mail.gmail.com>
References: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com>
	<AANLkTikOycAQiXpw5cTwwSHr86PjoY3D_=zoarhnOHMA@mail.gmail.com>
Message-ID: <AANLkTinVUwGRXYqBf3jTmvVX3d=jwn9F8Ms7r5zPQAQu@mail.gmail.com>

On Thu, Feb 3, 2011 at 2:13 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Wed, Feb 2, 2011 at 10:55 AM, Sam Bull <osirius at gmail.com> wrote:
>>.. ?I'm writing to lobby for bug #8797's fix to be removed and for my fix to put in in its place.
>
> Please open a separate issue for your patch. ?Patches attached to
> closed issues will be lost.

Antoine reopened it, so that shouldn't be an issue.

Cheers,
Nick.

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

From martin at v.loewis.de  Thu Feb  3 00:01:36 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Feb 2011 00:01:36 +0100
Subject: [Python-Dev] Python merge module
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <4D49E250.2070207@v.loewis.de>

>> The Installer COM object is the platform standard mechanism, and
>> that's what msilib uses.
> 
> Why maintain a lib when there's (better), free alternatives out there
> that are maintained by Microsoft itself?

Using msilib is easier than using Wix. It's also more flexible.
All you have to know is how the MSI schema works.

>> I really see no need to move away from that - it can create
>> arbitrary MSI files.
> 
> Can it create merge modules? Transform files (e.g. localization)?

It could easily be extended to do so, in a straight-forward manner.

> Bootstrappers?

Not sure what this is - if it is what I think it is, there is no
need to (actually, there is no need to create the other two types
of files, either, as it stands).

> There's a lot more to ms installers than the msi
> itself. Wouldn't it be easier to maintain an XML file than an entire
> lib dedicated to something that someone else has already solved?

Definitely not. Python is easier than XML.

If you think otherwise, feel free to provide a proof in the form of
a Wix installation generator for Python.

Regards,
Martin


From brett at python.org  Thu Feb  3 00:05:36 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 2 Feb 2011 15:05:36 -0800
Subject: [Python-Dev] Moving stuff out of Misc and over to the devguide
In-Reply-To: <4D49B4F3.9000503@netwok.org>
References: <AANLkTi=OKb7S1U+AsW9nz69WPDD0CPF5hTb23sQpC4_S@mail.gmail.com>
	<20110117215440.122bef7b@pitrou.net>
	<AANLkTi=MTbCgJs7znKN+SLLLiM==yrX0nJ5t-dQ8Y4yt@mail.gmail.com>
	<4D36E118.40008@netwok.org>
	<7e9e0831fbf09c304e9f358b406f43b8.squirrel@mail.trueblade.com>
	<ih767d$vao$1@dough.gmane.org> <4D49B4F3.9000503@netwok.org>
Message-ID: <AANLkTingwAVkR70sO+FE3Hr4J8QZB+6pk=pw4c4=rJe-@mail.gmail.com>

On Wed, Feb 2, 2011 at 11:48, ?ric Araujo <merwok at netwok.org> wrote:
> Le 19/01/2011 18:04, Georg Brandl a ?crit :
>> Am 19.01.2011 16:25, schrieb Eric Smith:
>>>> Bonus question: if we remove maintainers.rst from py3k, what do we do in
>>>> 3.1 and 2.7? ?I?d favor removing them over keeping outdated versions.
>>>
>>> Is there not some advantage to knowing who was the maintainer (or expert)
>>> of a given module at the time of a release?
>>
>> I don't see much advantage. ?And if you need the version of maintainers.rst
>> in another repo, it's not hard to find the revision that corresponds to the
>> release date.
>
> Ping. ?Do we remove maintainers.rst or do we add a note advising people
> to look at the up-to-date version on docs.python.org/devguide?
>
> (And yes, by ?we? I mean I?m volunteering to do either. :)

You're a little late, Eric; I already moved it. =)

From ncoghlan at gmail.com  Thu Feb  3 00:07:31 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 3 Feb 2011 09:07:31 +1000
Subject: [Python-Dev] [Python-checkins] r88324 - in
 python/branches/release31-maint: Doc/library/trace.rst
 Lib/distutils/tests/__init__.py Lib/distutils/tests/test_archive_util.py
 Lib/distutils/tests/test_bdist.py Lib/distutils/tests/test_bdist_dumb.py
 Lib/distutils/t
Message-ID: <AANLkTik=Aq3LadVH37UkY9Utr-fyDH8d38Lz-6NdSOOB@mail.gmail.com>

On Thu, Feb 3, 2011 at 7:38 AM, eric.araujo <python-checkins at python.org> wrote:
> Author: eric.araujo
> Date: Wed Feb ?2 22:38:37 2011
> New Revision: 88324
>
> Log:
> Merged revisions 86236,86240,86332,86340,87271,87273,87447 via svnmerge from
> svn+ssh://pythondev at svn.python.org/python/branches/py3k
>
> The missing NEWS entries correspond to changes that were made before 3.1.3, but
> I think it?s not usual to edit entries of released versions, so I put them at
> the top.

The only reason it isn't usual is because the change normally goes in
at roughly the same time as the NEWS update, so it is very rare to
have a change in a release without the corresponding NEWS entry. If
NEWS entries get missed for the release, better to add them in the
right place afterwards (it's easy enough to tell which entries were
originally missing by comparing the NEWS file from source control with
the one from the release).

Cheers,
Nick.

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

From janssen at parc.com  Thu Feb  3 00:28:23 2011
From: janssen at parc.com (Bill Janssen)
Date: Wed, 2 Feb 2011 15:28:23 PST
Subject: [Python-Dev] Python merge module
In-Reply-To: <4D49C793.40507@v.loewis.de>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
Message-ID: <16245.1296689303@parc.com>

Martin v. L?wis <martin at v.loewis.de> wrote:

> The Installer COM object is the platform standard
> mechanism, and that's what msilib uses. I really see no need to move
> away from that - it can create arbitrary MSI files.

I've used it to package UpLib for Windows -- see
http://uplib.parc.com/hg/uplib/file/e29e36f751f7/win32/build-msi-installer.py.
I've generalized some of Martin's code to create a Packager class which
supports non-Python pre and post install scripts.  I found it much easier
to use than WiX, which I also tried.

Bill

From merwok at netwok.org  Thu Feb  3 00:34:16 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 03 Feb 2011 00:34:16 +0100
Subject: [Python-Dev] [Python-checkins] r88324 - in
 python/branches/release31-maint: Doc/library/trace.rst
 Lib/distutils/tests/__init__.py Lib/distutils/tests/test_archive_util.py
 Lib/distutils/tests/test_bdist.py Lib/distutils/tests/test_bdist_dumb.py
 Lib/distutils/t
In-Reply-To: <AANLkTik=Aq3LadVH37UkY9Utr-fyDH8d38Lz-6NdSOOB@mail.gmail.com>
References: <AANLkTik=Aq3LadVH37UkY9Utr-fyDH8d38Lz-6NdSOOB@mail.gmail.com>
Message-ID: <4D49E9F8.8010900@netwok.org>

Thanks Nick, I moved the entries.

Cheers

From brett at python.org  Thu Feb  3 01:37:43 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 2 Feb 2011 16:37:43 -0800
Subject: [Python-Dev] [Python-checkins] devguide: Add a document
 discussing the development cycle typically followed for
In-Reply-To: <AANLkTikQzR+_0hgMd3qiQXR3-SoDXt7Yfq8rk__wkxLC@mail.gmail.com>
References: <E1PiDib-0004cD-TP@dinsdale.python.org>
	<AANLkTikQzR+_0hgMd3qiQXR3-SoDXt7Yfq8rk__wkxLC@mail.gmail.com>
Message-ID: <AANLkTik6HNuOPcTvG-y2KK9A3yn4RspFyvGBTM4ANnoz@mail.gmail.com>

all fixed

On Wed, Feb 2, 2011 at 03:04, Sandro Tosi <sandro.tosi at gmail.com> wrote:
> On Wed, Jan 26, 2011 at 23:20, brett.cannon <python-checkins at python.org> wrote:
>> +The in-development branch is where new functionality and semantic changes
>
> new functionalities (dunno if it's plural in english or not)?
>
>> +occur. Currently this branch is known as the "py3k" branch. The next minor
>> +release of Python will come from this branch (major releases are once a decade
>> +and so have no specific rules on how they are started). All changes land in this
>> +branch and then trickle down to other branches.
>> +
>> +Once a Final_ release is made from the in-development branch, a branch is made
>> +to represent the minor version of Python and it goes into maintenance mode.
>> +Typically a minor version of Python is under development for about 18 months.
>> +
>> +
>> +Maintenance
>> +-----------
>> +The branch currently being maintained for bug fixes.
>> +
>> +The branch under maintenance is the last minor version of Python to be released
>> +as Final_. This means that the latest release of Python was 3.1.2, then the
>
> if the latest release ?
>
>> +branch representing Python 3.1 is in maintenance mode.
>> +
>> +The only changes allowed to occur in a maintenance branch without debate are bug
>> +fixes.
>> +Semantic changes **must** be carefully considered as code out in the world will
>> +have already been developed that will rely on the released semantics. Changes
>> +related to semantics should be discussed on python-dev before being made.
>> +
>> +A branch stays in maintenance mode as long as a new minor release has not been
>> +made. For example, this means that Python 2.6 stayed in maintenance mode until
>> +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and
>> +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18
>> +month schedule, a branch stays in mainteance mode for the same amount of time.
>
> s/mainteance/maintenance/
>
>> +
>> +A micro release of a maintenance branch is made about every six months.
>> +Typically when a new minor release is made one more release of the new-old
>> +version of Python is made.
>> +
>> +
>> +Security
>> +--------
>> +A branch less than five years old but no longer in maintenance mode.
>> +
>> +The only changes made to a branch that is being maintained for security
>> +purposes are somewhat obviously those related to security, e.g., privilege
>> +escalation. Crashers and other behaviorial issues are **not** considered a
>
> s/Crashers/Crashes/
> s/behaviorial/behavioral/
>
>> +security risk and thus not backported to a branch being maintained for
>> +security. Any releases made for a branch under security maintenance is
>
> s/releases/release/ ?
> s/for/from/
>
>> +source-only and done only when actual security patches have been applied to the
>> +branch.
>> +
>> +
>> +Stages
>> +''''''
>> +
>> +Based on what stage the in-development version of Python is in, the
>> +responsibilities of a core developer change in regards to commits to the VCS.
>> +
>> +
>> +Pre-alpha
>> +---------
>> +This is the stage a branch is in from the last final release until the first
>> +alpha (a1). There are no special restrictions placed on commits beyond those
>> +imposed by the type of branch being worked on (e.g., in-development vs.
>> +maintenance).
>> +
>> +
>> +Alpha
>> +-----
>> +Alphas typically serve as a reminder to core developers that they need to start
>> +getting in changes that change semantics or add something to Python as such
>> +things should not be added during a Beta_. Otherwise no new restrictions are in
>> +place while in alpha.
>> +
>> +
>> +Beta
>> +----
>> +A branch in beta means that no new additions to Python are accepted. Bugfixes
>> +and the like are still fine. Being in beta can be viewed much like being in RC_
>> +but without the extra overhead of needing commit reviews.
>> +
>> +
>> +.. _RC:
>> +
>> +Release Candidate (RC)
>> +----------------------
>> +A branch preparing for an RC release can only have bugfixes applied that have
>> +been reviewed by other core developers. That reviewer should make a post to the
>> +issue related to the change and be mentioned in the commit message.
>> +
>> +You **cannot** skip the peer review during an RC, no matter how small! Even if
>> +it is a simple copy-and-paste change, **everything** requires peer review from
>> +a core developer.
>> +
>> +
>> +Final
>> +-----
>> +When a final release is being cut, only the release manager (RM) can make
>> +changes to the branch.
>> diff --git a/index.rst b/index.rst
>> --- a/index.rst
>> +++ b/index.rst
>> @@ -20,6 +20,7 @@
>> ? ?coredev
>> ? ?developers
>> ? ?committing
>> + ? devcycle
>>
>> ? ?stdlibchanges
>> ? ?langchanges
>> @@ -64,6 +65,7 @@
>> ?* :ref:`coredev`
>> ? ? * :ref:`developers`
>> ? ? * :ref:`committing`
>> + ? ?* :ref:`devcycle`
>>
>>
>> ?Proposing changes to Python itself
>>
>> --
>> Repository URL: http://hg.python.org/devguide
>> _______________________________________________
>> Python-checkins mailing list
>> Python-checkins at python.org
>> http://mail.python.org/mailman/listinfo/python-checkins
>>
>>
>
>
>
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
> _______________________________________________
> 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
>

From hoyt6 at llnl.gov  Thu Feb  3 02:30:43 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Wed, 2 Feb 2011 17:30:43 -0800
Subject: [Python-Dev] Python merge module
In-Reply-To: <4D49E250.2070207@v.loewis.de>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49E250.2070207@v.loewis.de>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF0A@NSPEXMBX-C.the-lab.llnl.gov>

> Using msilib is easier than using Wix. It's also more flexible.

IMO, no. It's simply not.

> All you have to know is how the MSI schema works.

Same with WiX.

> It could easily be extended to do so, in a straight-forward manner.

Other packaging apps already have it - no work needed.

> (actually, there is no need to create the other two types of files, either, as it stands).

Sure there is. Transform files + bootstrappers give you localizable installs in one flat file.

> Definitely not. Python is easier than XML.

I disagree.

> If you think otherwise, feel free to provide a proof in the form of a Wix installation generator for Python.

If you think otherwise, why don't you provide proof and get the WiX guys to switch to Python and use your msilib package? The point is that your argument is nonsensical.

I'm really not trying to start a flame war here (my original post only asked if there was "thought towards migrating away from msilib"). There's legitimate need/desire for a merge module to make it easier to package a specific Python version. I can (and am) including it in the bootstrapper, but it would make things much cleaner to simply have a merge module available. If the answer's "no and we don't ever intend to", then that's perfectly fine. (c: I really don't care to argue the merits or virtues of WiX vs. msilib and I apologize if I came across as doing that -- I simply was interested to know if there's any serious thought in the matter and it turns out that people are perfectly happy w/ msilib.


From hoyt6 at llnl.gov  Thu Feb  3 02:40:49 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Wed, 2 Feb 2011 17:40:49 -0800
Subject: [Python-Dev] Python merge module
In-Reply-To: <AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>

> If Python was starting at ground zero, and the choices were to create
> a library or to use WiX, the answer might have been different. 
> However with a mature enough library to suit all the needs that anyone 
> has been willing to author, it's certainly more work to create the WiX 
> install and maintain it than it is to merely maintain the existing
> scripts.

Sounds reasonable.

> As far as the possibility of distributing Python as a merge module?
> I'd recommend against it. Shared location merge modules are a
> maintenance nightmare, and private location merge modules may not
> offer the benefit you need. Better to just install the main Python msi
> as part of a suite with your installer, whether you build that
> installer in WiX and burn, or not.

I'm not familiar w/ shared location merge modules vs. private location merge modules. Are you referring to the possibility of having multiple python apps trying to use their own python versions? How relocatable is python? The maintenance nightmare isn't on your end (in my case), it would be on me to provide patches/upgrades. I do agree that patches w/ merge modules are a pain/nightmare. But what about providing both a merge module and msi so developers have a choice? I work on open source projects myself, and we always provide both a merge module and a normal msi installer. It's very little extra work (in WiX at least) to create both. But I can tell from this discussion that it would require changes in msilib and since I don't have the time to work on it, it would most likely not happen. Perhaps I could generate enough fervor in the community for a merge module, though, to drive msilib development. :p

At any rate, where could I find the script used to generate the msi package? Perhaps I can translate it into WiX if I thought it'd be used (but why bother if no one's interested?).

From hoyt6 at llnl.gov  Thu Feb  3 02:43:50 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Wed, 2 Feb 2011 17:43:50 -0800
Subject: [Python-Dev] Python merge module
In-Reply-To: <16245.1296689303@parc.com>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de> <16245.1296689303@parc.com>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF15@NSPEXMBX-C.the-lab.llnl.gov>

>  I found it much easier to use than WiX, which I also tried.

I also used to use the Visual Studio installer projects until I needed something a lot more robust (e.g., customized UI + localizable strings). msilib does the job people need it to do and that's fine. I'm really not trying to argue the merits of WiX vs. msilib. Was just wondering if it had been considered...

From rdmurray at bitdance.com  Thu Feb  3 03:43:09 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 02 Feb 2011 21:43:09 -0500
Subject: [Python-Dev] Python merge module
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF0A@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49E250.2070207@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF0A@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <20110203024309.CE186242900@kimball.webabinitio.net>

On Wed, 02 Feb 2011 17:30:43 -0800, "Hoyt, David" <hoyt6 at llnl.gov> wrote:
> > Definitely not. Python is easier than XML.
> 
> I disagree.

Just as an FYI, I believe that most people in the Python community find
XML much more of a pain than Python.  Many of us (especially those of
us who are not web developers) avoid XML whenever possible, and when
we do have to deal with it we tend to abstract it behind easier to work
with Python code.  The obvious exception to that would be web templating
languages, but I personally prefer to avoid those, as well :)

--
R. David Murray                                      www.bitdance.com

From martin at v.loewis.de  Thu Feb  3 07:10:26 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Feb 2011 07:10:26 +0100
Subject: [Python-Dev] Python merge module
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF0A@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49E250.2070207@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF0A@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <4D4A46D2.8090304@v.loewis.de>

> I'm really not trying to start a flame war here (my original post
> only asked if there was "thought towards migrating away from
> msilib"). There's legitimate need/desire for a merge module to make
> it easier to package a specific Python version.

Please recognize that this question is entirely independent of the
question whether Wix is used or not.

I'm personally +0 on providing a merge module (although others are
apparently opposed to that idea).

As for msilib vs. Wix: yes, I did put thought into this (actually
originally also when writing msilib, which slightly predates Wix in
time). However, I don't see any need to switch, and I actually do
believe that Wix couldn't provide a feature-by-feature full
replacement of the current packaging code (but I might be wrong).

Regards,
Martin

From martin at v.loewis.de  Thu Feb  3 07:30:40 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Feb 2011 07:30:40 +0100
Subject: [Python-Dev] Python merge module
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>	<4D49C793.40507@v.loewis.de>	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <4D4A4B90.8030700@v.loewis.de>

>> As far as the possibility of distributing Python as a merge
>> module? I'd recommend against it. Shared location merge modules are
>> a maintenance nightmare, and private location merge modules may
>> not offer the benefit you need. Better to just install the main
>> Python msi as part of a suite with your installer, whether you
>> build that installer in WiX and burn, or not.
> 
> I'm not familiar w/ shared location merge modules vs. private
> location merge modules. Are you referring to the possibility of
> having multiple python apps trying to use their own python versions?
> How relocatable is python?

Fairly relocatable. If there is was a merge module, I'd really prefer
it to be shared. The challenge here is site-packages: different users
of the merge module would need different copies of site-packages
(or else installing additional packages might break existing software).

Another challenge with shared location merge modules is upgrades:
the Python installer currently doesn't use stable component IDs;
I think this would cause problems for users of the merge module.
Providing stable component IDs is a challenge since it's difficult
to version the files on disk.

Not sure why Michael thinks that a private location merge module
would provide no benefits to the user of the merge module.

> The maintenance nightmare isn't on your
> end (in my case), it would be on me to provide patches/upgrades. I do
> agree that patches w/ merge modules are a pain/nightmare. But what
> about providing both a merge module and msi so developers have a
> choice?

I certainly wouldn't stop providing an MSI. The next question would
be whether the MSI then also installs into the shared location, or
whether it would have a private copy of Python.

> I work on open source projects myself, and we always provide
> both a merge module and a normal msi installer. It's very little
> extra work (in WiX at least) to create both.

But what's the quality of these? Ideally, I'd like to create a single
merge module which, at the option of the user of the merge module,
produces either a shared or a private installation. Is that still
only little extra work in Wix?

> At any rate, where could I find the script used to generate the msi
> package? Perhaps I can translate it into WiX if I thought it'd be
> used (but why bother if no one's interested?). 

It's in Tools/msi/msi.py.

Regards,
Martin

From erez27 at gmail.com  Thu Feb  3 10:32:17 2011
From: erez27 at gmail.com (Erez Sh)
Date: Thu, 3 Feb 2011 11:32:17 +0200
Subject: [Python-Dev] xmlrpclib and communication verbosity
Message-ID: <AANLkTimnbK_7rkmbMSCv3hwgq3u_WfsOx0MYO6LiMQY_@mail.gmail.com>

Oleg wrote:


>   Why not logging?
>

It seems to me that most of python's library modules don't use the logging
module, and I didn't want to make style judgments.
I actually prefer logging.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110203/a053dd1c/attachment.html>

From victor.stinner at haypocalc.com  Thu Feb  3 14:05:06 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 03 Feb 2011 14:05:06 +0100
Subject: [Python-Dev] News of the faulthandler project
Message-ID: <1296738306.19440.20.camel@marge>

Hi,

Since the end of last december, I'm still working on my fault handler
project:
https://github.com/haypo/faulthandler

You can use it to get more information after a crash or if you program
hangs somewhere. It helps if you don't have access to other debugging
tool (eg. install gdb7+python-gdb.py on Windows is not trivial today) or
if you cannot interact with your program (eg. on a buildbot).

The last version works on Python 2.5, 2.6, 2.7, 3.1 and 3.2, on Windows,
Linux and FreeBSD. It can display the Python backtrace on a fatal fault
(SIGSEGV, SIGFPE, SIGILL, SIGBUS), after a delay in seconds, when an
user signal is received (eg. SIGUSR1) or explicitly (call directly the
dumpbacktrace() function).

By default, it is disabled: you have to call faulthandler.enable() to
install the signal handlers. You can choose in which file the backtrace
is written (sys.stderr by default) and if it displays the backtrace of
the current thread or of all threads. If you use the delay: you can
choose to repeat the operation (dump the backtrace each delay seconds).

The project is now a module, so it is no more enabled by default. It is
more configurable, and has more features. It has a better API (so it was
a good idea to not include it in Python 3.2).

I plan to integrate this project into Python 3.3. I hope that it can
help to debug some buildbots issues, but also any segfault in your
programs.

Note: faulthandler.register() (dump the backtrace when an user signal is
raised) is only available in the development version.

--

The project is not perfect yet:

 - I have to write something to be able to enable the faulthandler
before starting your program (write a program for that?)
 - faulthandler.dumpbacktrace_later() uses alarm() which interrupts the
current system call when SIGALARM is raised: it may be a problem (it's
maybe not a problem if you try to debug a program hang)
 - I don't know if something should be done on a fork()
 - SIGABRT is not handled
 - The module is unloaded using Py_AtExit(): it cannot release
references because the unload function is called too late

--

There are similar projects, tipper and crier, using a signal handler
implemented in Python or a signal handler implemented in Python. These
projects give more information (eg. local variables) and more control on
how the informations are written, but I think that there are less
reliable: it doesn't work if Python hangs (eg. deadlock) and signal
handlers implemented in Python are asynchronous. And there are unable to
catch fatal faults (eg. SIGSEGV).

http://pypi.python.org/pypi/tipper/
https://gist.github.com/737056

Victor


From ncoghlan at gmail.com  Thu Feb  3 15:14:30 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Feb 2011 00:14:30 +1000
Subject: [Python-Dev] News of the faulthandler project
In-Reply-To: <1296738306.19440.20.camel@marge>
References: <1296738306.19440.20.camel@marge>
Message-ID: <AANLkTikG2RAEV5ALfKFBM01wxB7G9nA=4nzG47xnCip1@mail.gmail.com>

On Thu, Feb 3, 2011 at 11:05 PM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> ?- I have to write something to be able to enable the faulthandler
> before starting your program (write a program for that?)

I don't know enough about signal handling to help with your other
remaining concerns, but an appropriate "-X" command line option seem
like a reasonable way to activate it before main starts running (-X is
currently documented as reserved for use by other implementations, but
it's really more a "implementation dependent options" marker)

(+1 on the general idea, though)

Cheers,
Nick.

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

From murman at gmail.com  Thu Feb  3 16:38:28 2011
From: murman at gmail.com (Michael Urman)
Date: Thu, 3 Feb 2011 09:38:28 -0600
Subject: [Python-Dev] Python merge module
In-Reply-To: <4D4A4B90.8030700@v.loewis.de>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>
	<4D4A4B90.8030700@v.loewis.de>
Message-ID: <AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>

On Thu, Feb 3, 2011 at 00:30, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Another challenge with shared location merge modules is upgrades:
> the Python installer currently doesn't use stable component IDs;
> I think this would cause problems for users of the merge module.
> Providing stable component IDs is a challenge since it's difficult
> to version the files on disk.
>
> Not sure why Michael thinks that a private location merge module
> would provide no benefits to the user of the merge module.

I hadn't thought it through fully, but the preceding paragraph really
gets to the core of the problem. The maintenance nightmare is security
updates for private location installations by third parties. The only
MSI-friendly way to update that code is through releasing an updated
merge module and having the consuming application also release an
update that uses it. Since Python's components use fresh GUIDs each
time, this would require a "major" upgrade; "minor" upgrades would
cause Windows Installer to throw fits.

Technically this is a problem with the component generation in Python,
and for that in particular, a move to WiX could be very helpful. They
have stable component code generation which keys off of location,
name, platform, etc., but only works for single-file components.

For contrast, I don't see a shared-location merge module as offering
benefits beyond a silently redistributable msi package. The shared
location is better about following component code rules (re-use in
private areas is an allowed gray area), and there are people out there
who consider the reference counting through merge modules to be
superior. I find the resulting complexity in the consuming package's
installation to be more of a down-side.

>> I work on open source projects myself, and we always provide
>> both a merge module and a normal msi installer. It's very little
>> extra work (in WiX at least) to create both.
>
> But what's the quality of these? Ideally, I'd like to create a single
> merge module which, at the option of the user of the merge module,
> produces either a shared or a private installation. Is that still
> only little extra work in Wix?

I've never tried to make a configurable merge module in WiX, but I
think that's the only option if you want a single merge module to
allow both. It should be a one-time authoring overhead with [1]. Using
them is pretty straightforward within the Merge elements [2].

[1] http://wix.sourceforge.net/manual-wix3/wix_xsd_configuration.htm
[2] http://wix.sourceforge.net/manual-wix2/wix_xsd_configurationdata.htm

Michael

From smiwa.egon at googlemail.com  Thu Feb  3 16:43:20 2011
From: smiwa.egon at googlemail.com (Egon Smiwa)
Date: Thu, 03 Feb 2011 16:43:20 +0100
Subject: [Python-Dev] Py_tp_getset in ABI?
Message-ID: <4D4ACD18.50603@googlemail.com>

Hi all,
I'm trying to convert my embedding code to your new ABI,
but I cannot find the ABI slot for tp_getset in typeslots.h
(while tp_methods are supported). Is the support of tp_getset
not yet determined? (Because I cannot find this in the PEP 384)

Thank you!

From reid.kleckner at gmail.com  Thu Feb  3 18:22:28 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Thu, 3 Feb 2011 12:22:28 -0500
Subject: [Python-Dev] News of the faulthandler project
In-Reply-To: <1296738306.19440.20.camel@marge>
References: <1296738306.19440.20.camel@marge>
Message-ID: <AANLkTimJKFOAHesc=95dmUzr9FBC8DEV+fY2zfVOkba5@mail.gmail.com>

On Thu, Feb 3, 2011 at 8:05 AM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> ?- SIGABRT is not handled

Why not?  That seems useful for debugging assertion failures, although
most C code in Python raises exceptions rather than asserting.

I'm guessing it's because it aborts the process after printing the
backtrace.  You could just clear the signal handler before aborting.

Reid

From flub at devork.be  Thu Feb  3 18:58:31 2011
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 3 Feb 2011 17:58:31 +0000
Subject: [Python-Dev] Python merge module
In-Reply-To: <AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>
	<4D4A4B90.8030700@v.loewis.de>
	<AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
Message-ID: <AANLkTimt64b+zWzrboQBpuOgPUpPb2WAUcionHdH1Gah@mail.gmail.com>

On 3 February 2011 15:38, Michael Urman <murman at gmail.com> wrote:
> Technically this is a problem with the component generation in Python,
> and for that in particular, a move to WiX could be very helpful. They
> have stable component code generation which keys off of location,
> name, platform, etc., but only works for single-file components.

At work we keep the required stable UUIDs in an ConfigParser-format
file checked in to the VCS for that purpose.

FWIW our build system uses WiX (v2) currently and if I where to redo
it, I'd change to msilib and not WiX v3.  But never change working
systems.

Python.org supplied merge modules would be nice though, if the
upgrade/security issue can be resolved.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From victor.stinner at haypocalc.com  Thu Feb  3 21:52:40 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 03 Feb 2011 21:52:40 +0100
Subject: [Python-Dev] News of the faulthandler project
In-Reply-To: <AANLkTimJKFOAHesc=95dmUzr9FBC8DEV+fY2zfVOkba5@mail.gmail.com>
References: <1296738306.19440.20.camel@marge>
	<AANLkTimJKFOAHesc=95dmUzr9FBC8DEV+fY2zfVOkba5@mail.gmail.com>
Message-ID: <1296766360.27124.15.camel@marge>

Le jeudi 03 f?vrier 2011 ? 12:22 -0500, Reid Kleckner a ?crit :
> On Thu, Feb 3, 2011 at 8:05 AM, Victor Stinner
> <victor.stinner at haypocalc.com> wrote:
> >  - SIGABRT is not handled
> 
> Why not?

Just because I forgot to handle it. But I don't know if it is a good
thing to display the Python backtrace on abort() or not. Python uses
abort() on Py_FatalError().

Victor


From hoyt6 at llnl.gov  Thu Feb  3 22:03:13 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Thu, 3 Feb 2011 13:03:13 -0800
Subject: [Python-Dev] Python merge module
In-Reply-To: <AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>
	<4D4A4B90.8030700@v.loewis.de>
	<AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9D10D@NSPEXMBX-C.the-lab.llnl.gov>

> I hadn't thought it through fully, but the preceding paragraph really
> gets to the core of the problem. The maintenance nightmare is security
> updates for private location installations by third parties. The only
> MSI-friendly way to update that code is through releasing an updated
> merge module and having the consuming application also release an
> update that uses it. Since Python's components use fresh GUIDs each
> time, this would require a "major" upgrade; "minor" upgrades would
> cause Windows Installer to throw fits.

That's exactly right and why I said earlier that patches w/ merge modules are a pain/nightmare. But I also said that the security patching w/ a merge module would then depend on the party who has integrated the merge module into their product -- not on you guys. I don't think most (or any) parties are trying to do incremental minor updates w/ python right now anyway. With us, we just want a single, well-tested and known python implementation installed w/ our product -- we basically don't trust the user to get the right version and install it correctly. You obviously can't hold their hand every step of the way, at some point you have to let go -- but this is one thing that we could possibly control.

> Technically this is a problem with the component generation in Python,
> and for that in particular, a move to WiX could be very helpful. They
> have stable component code generation which keys off of location,
> name, platform, etc., but only works for single-file components.

The general recommendation regarding msi packages is that you always, always do single-file components (one of the major reasons being for patching purposes). If you use WiX' heat application to autogenerate WiX files from directories, you'll see that it always produces single-file components.

> For contrast, I don't see a shared-location merge module as offering
> benefits beyond a silently redistributable msi package. The shared
> location is better about following component code rules (re-use in
> private areas is an allowed gray area), and there are people out there
> who consider the reference counting through merge modules to be
> superior. I find the resulting complexity in the consuming package's
> installation to be more of a down-side.

I think a merge module (shared or private) generally reduces complexity unless you already have a bootstrapper for other packages. Including one in WiX is very simple (if you're already familiar w/ msi's):

<Feature Id="Full">
    <MergeRef Id="Python" />
</Feature>

<Directory Id="TARGETDIR">
    <Merge Id="Python" SourceFile="python.msm" Language="1033" DiskId="1" />
</Directory>

If you use something like the VS installer projects, you just have to use the GUI to add a reference to it and you're done.

A shared merge module might pose a problem if you want to have multiple python versions installed. At the least, you'd need to change the component guid w/ each major release (e.g. 2.x -> 3.x, but not 2.7 -> 2.8 -> 2.9, etc.). I'd recommend w/ sticking to a private one that doesn't modify the PATH (should you choose to create one) and then you're free to keep or change the component guids.

Can python operate inside a sandboxed C:\Program Files\<My Product Here>\ directory?

> I've never tried to make a configurable merge module in WiX, but I
> think that's the only option if you want a single merge module to
> allow both. It should be a one-time authoring overhead with [1]. Using
> them is pretty straightforward within the Merge elements [2].
>
> [1] http://wix.sourceforge.net/manual-wix3/wix_xsd_configuration.htm
> [2] http://wix.sourceforge.net/manual-wix2/wix_xsd_configurationdata.htm

I wouldn't try to make it configurable (nor does it really need to be) beyond what it already should do -- that is, just be able to set the base target directory, which is already done for you. And as I just suggested, I wouldn't go for both -- declare the merge module to be private and that's that.

From hoyt6 at llnl.gov  Thu Feb  3 22:15:28 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Thu, 3 Feb 2011 13:15:28 -0800
Subject: [Python-Dev] Python merge module
In-Reply-To: <AANLkTimt64b+zWzrboQBpuOgPUpPb2WAUcionHdH1Gah@mail.gmail.com>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>
	<4D4A4B90.8030700@v.loewis.de>
	<AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
	<AANLkTimt64b+zWzrboQBpuOgPUpPb2WAUcionHdH1Gah@mail.gmail.com>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9D114@NSPEXMBX-C.the-lab.llnl.gov>

> At work we keep the required stable UUIDs in an ConfigParser-format
> file checked in to the VCS for that purpose.
>
> FWIW our build system uses WiX (v2) currently and if I where to redo
> it, I'd change to msilib and not WiX v3.  But never change working
> systems.

No need to do that if you're using heat -- I haven't used WiX v2 so I can't speak to its relative merits, but v3.5 (which was just officially released) is pretty good and much more feature complete (according to rob mensching's blog). I'd recommend re-evaluating it. I'm not a Microsoft fanboy, btw. But I am getting my group (or trying to, at least) to migrate away from older, stale installer projects (e.g. Visual Studio will be dropping support for any further installer project improvements in the future) and into WiX because that's where the momentum is and it also keeps up-to-date w/ the latest msi changes. That and I was tired of the install looking like an intern did it (no offense to interns -- I was one once. (c: ). A good, polished product should (IMO) also have a good, polished installer. Especially since that's one of the customer's first views/impressions of your product.

> Python.org supplied merge modules would be nice though, if the
> upgrade/security issue can be resolved.

Good to know I'm not entirely alone. (c:

From martin at v.loewis.de  Thu Feb  3 22:18:37 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 03 Feb 2011 22:18:37 +0100
Subject: [Python-Dev] Python merge module
In-Reply-To: <AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>	<4D49C793.40507@v.loewis.de>	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>	<4D4A4B90.8030700@v.loewis.de>
	<AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
Message-ID: <4D4B1BAD.8050308@v.loewis.de>

> Technically this is a problem with the component generation in Python,
> and for that in particular, a move to WiX could be very helpful. They
> have stable component code generation which keys off of location,
> name, platform, etc., but only works for single-file components.

That would be no reason to move to Wix. Integrating the same algorithm
in msilib is trivial.

Regards,
Martin

From martin at v.loewis.de  Thu Feb  3 22:22:32 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 03 Feb 2011 22:22:32 +0100
Subject: [Python-Dev] Python merge module
In-Reply-To: <AANLkTimt64b+zWzrboQBpuOgPUpPb2WAUcionHdH1Gah@mail.gmail.com>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>	<4D49C793.40507@v.loewis.de>	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>	<4D4A4B90.8030700@v.loewis.de>	<AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
	<AANLkTimt64b+zWzrboQBpuOgPUpPb2WAUcionHdH1Gah@mail.gmail.com>
Message-ID: <4D4B1C98.90208@v.loewis.de>

Am 03.02.2011 18:58, schrieb Floris Bruynooghe:
> On 3 February 2011 15:38, Michael Urman <murman at gmail.com> wrote:
>> Technically this is a problem with the component generation in Python,
>> and for that in particular, a move to WiX could be very helpful. They
>> have stable component code generation which keys off of location,
>> name, platform, etc., but only works for single-file components.
> 
> At work we keep the required stable UUIDs in an ConfigParser-format
> file checked in to the VCS for that purpose.

That's also the path I'd take. But I'm unsure how versioning would work,
in particular if I have per-directory components, and files get added
(which typically shouldn't, but might happen in bugfix releases).

Regards,
Martin

From solipsis at pitrou.net  Thu Feb  3 22:25:46 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 3 Feb 2011 22:25:46 +0100
Subject: [Python-Dev] News of the faulthandler project
References: <1296738306.19440.20.camel@marge>
	<AANLkTimJKFOAHesc=95dmUzr9FBC8DEV+fY2zfVOkba5@mail.gmail.com>
	<1296766360.27124.15.camel@marge>
Message-ID: <20110203222546.61e24fda@pitrou.net>

On Thu, 03 Feb 2011 21:52:40 +0100
Victor Stinner <victor.stinner at haypocalc.com> wrote:
> Le jeudi 03 f?vrier 2011 ? 12:22 -0500, Reid Kleckner a ?crit :
> > On Thu, Feb 3, 2011 at 8:05 AM, Victor Stinner
> > <victor.stinner at haypocalc.com> wrote:
> > >  - SIGABRT is not handled
> > 
> > Why not?
> 
> Just because I forgot to handle it. But I don't know if it is a good
> thing to display the Python backtrace on abort() or not. Python uses
> abort() on Py_FatalError().

I think that precisely makes it a good idea.  It's much better to know
where a fatal error was triggered from if you want to have a chance of
at least working around it.

Regards

Antoine.



From martin at v.loewis.de  Thu Feb  3 22:33:14 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Feb 2011 22:33:14 +0100
Subject: [Python-Dev] Python merge module
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9D10D@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>	<4D49C793.40507@v.loewis.de>	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>	<4D4A4B90.8030700@v.loewis.de>	<AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9D10D@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <4D4B1F1A.6030405@v.loewis.de>

> The general recommendation regarding msi packages is that you always,
> always do single-file components (one of the major reasons being for
> patching purposes).

Can you please cite a source for that recommendation? Preferably
some MSDN documentation.

Regards,
Martin

From martin at v.loewis.de  Thu Feb  3 22:46:52 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Feb 2011 22:46:52 +0100
Subject: [Python-Dev] Py_tp_getset in ABI?
In-Reply-To: <4D4ACD18.50603@googlemail.com>
References: <4D4ACD18.50603@googlemail.com>
Message-ID: <4D4B224C.9070100@v.loewis.de>

Am 03.02.2011 16:43, schrieb Egon Smiwa:
> Hi all,
> I'm trying to convert my embedding code to your new ABI,
> but I cannot find the ABI slot for tp_getset in typeslots.h
> (while tp_methods are supported). Is the support of tp_getset
> not yet determined? 

Not sure what I thought - it seems that tp_getset and tp_members
is plain missing. This is puzzling because I clearly meant to include
PyMemberDef and PyGetSetDef (and they are included).

Unless somebody reminds me why they would have to be excluded, I
would like to add them still.

Adding them after 3.2 would be forward-compatible (?), i.e.
all modules build for 3.2 would continue to work in 3.2.1.
However, modules using them would work in 3.2.1, but fail in
3.2.0 (with a RuntimeError exception)

So I think I would preferably add these before 3.2 is released.

Regards,
Martin

From hoyt6 at llnl.gov  Thu Feb  3 22:48:09 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Thu, 3 Feb 2011 13:48:09 -0800
Subject: [Python-Dev] Python merge module
In-Reply-To: <4D4B1F1A.6030405@v.loewis.de>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CD57@NSPEXMBX-C.the-lab.llnl.gov>
	<4D49C793.40507@v.loewis.de>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CDF3@NSPEXMBX-C.the-lab.llnl.gov>
	<AANLkTinKpxRuO3ti6mwL-kAupKa8BYy4p=z3e-jhMnCj@mail.gmail.com>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9CF12@NSPEXMBX-C.the-lab.llnl.gov>
	<4D4A4B90.8030700@v.loewis.de>
	<AANLkTik5A3kxfV+3prcFkAR7RUTX_QesU0HKvnw84YUW@mail.gmail.com>
	<B288BDCCFC5B874BBC7D22117EDFB6F9F245D9D10D@NSPEXMBX-C.the-lab.llnl.gov>
	<4D4B1F1A.6030405@v.loewis.de>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9F245D9D141@NSPEXMBX-C.the-lab.llnl.gov>

> Can you please cite a source for that recommendation? Preferably
> some MSDN documentation.

http://msdn.microsoft.com/en-us/library/aa368269(v=vs.85).aspx 
http://wix.sourceforge.net/manual-wix3/add_a_file.htm

Specifically, starting in bold, where it says "In general, you should restrict yourself to a single file per component. The Windows Installer is designed to support thousands of components in a single installer, so unless you have a very good reason, keep to one file per component. Every component must have its own unique GUID. Failure to follow these two basic rules can lead to many problems down the road when it comes to servicing."

A little before that, it states: "The component element describes a set of resources (usually files, registry entries, and shortcuts) that need to be installed as a single unit. This is separate from whether the set of items consist of a logical feature the user can select to install ... While it may not seem like a big deal when you are first authoring your installer, components play a critical role when you decide to build patches at a later date."

I didn't say it's a must, but experience lends you to following the recommendation.

From g.brandl at gmx.net  Thu Feb  3 22:56:36 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 03 Feb 2011 22:56:36 +0100
Subject: [Python-Dev] Py_tp_getset in ABI?
In-Reply-To: <4D4B224C.9070100@v.loewis.de>
References: <4D4ACD18.50603@googlemail.com> <4D4B224C.9070100@v.loewis.de>
Message-ID: <iif8aq$2it$3@dough.gmane.org>

Am 03.02.2011 22:46, schrieb "Martin v. L?wis":
> Am 03.02.2011 16:43, schrieb Egon Smiwa:
>> Hi all,
>> I'm trying to convert my embedding code to your new ABI,
>> but I cannot find the ABI slot for tp_getset in typeslots.h
>> (while tp_methods are supported). Is the support of tp_getset
>> not yet determined? 
> 
> Not sure what I thought - it seems that tp_getset and tp_members
> is plain missing. This is puzzling because I clearly meant to include
> PyMemberDef and PyGetSetDef (and they are included).
> 
> Unless somebody reminds me why they would have to be excluded, I
> would like to add them still.
> 
> Adding them after 3.2 would be forward-compatible (?), i.e.
> all modules build for 3.2 would continue to work in 3.2.1.
> However, modules using them would work in 3.2.1, but fail in
> 3.2.0 (with a RuntimeError exception)
> 
> So I think I would preferably add these before 3.2 is released.

I'm okay with you making this fix (and the one for #11067) before
3.2.0 is released.

Georg


From ncoghlan at gmail.com  Fri Feb  4 00:05:03 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Feb 2011 09:05:03 +1000
Subject: [Python-Dev] [Python-checkins] r88331 - in
 python/branches/py3k/Doc/howto: index.rst pyporting.rst
In-Reply-To: <20110203220155.419E3EEA35@mail.python.org>
References: <20110203220155.419E3EEA35@mail.python.org>
Message-ID: <AANLkTi=s+bX07x02_DCkpX31+67ferpyYqq+M5VY689i@mail.gmail.com>

On Fri, Feb 4, 2011 at 8:01 AM, brett.cannon <python-checkins at python.org> wrote:
> +Capturing the Currently Raised Exception
> +----------------------------------------
> +One change between Python 2 and 3 that will require changing how you code is
> +accessing the currently raised exception. ?In Python 2 the syntax to access the
> +current exception is::
> +
> + ? ?try:
> + ? ? ? ?raise Exception()
> + ? ?except Exception, exc:
> + ? ? ? ?# Current exception is 'exc'
> + ? ? ? ?pass
> +
> +This syntax changed in Python 3 to::
> +
> + ? ?try:
> + ? ? ? ?raise Exception()
> + ? ?except Exception as exc:
> + ? ? ? ?# Current exception is 'exc'
> + ? ? ? ?pass

Note that you can write it the Python 3 way in 2.6+ as well (this was
new syntax, so there weren't any backwards compatibility issues with
adding it). You only need to do the sys.exc_info dance if you need to
support 2.5 or earlier.

Other notes:
- explicit relative imports work in 2.6+ without needing a future import
- absolute imports are the default in 2.7

Cheers,
Nick.

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

From ncoghlan at gmail.com  Fri Feb  4 00:10:07 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 4 Feb 2011 09:10:07 +1000
Subject: [Python-Dev] [Python-checkins] r88331 - in
 python/branches/py3k/Doc/howto: index.rst pyporting.rst
In-Reply-To: <20110203220155.419E3EEA35@mail.python.org>
References: <20110203220155.419E3EEA35@mail.python.org>
Message-ID: <AANLkTik2xAJsOCyoyKwgP3tndF4ONkACKPy6K5Tb+L3s@mail.gmail.com>

On Fri, Feb 4, 2011 at 8:01 AM, brett.cannon <python-checkins at python.org> wrote:
> +Stop Using :mod:`doctest`
> +'''''''''''''''''''''''''
> +While 2to3 tries to port doctests properly, it's a rather tough thing to do. It
> +is probably best to simply convert your critical doctests to :mod:`unittest`.

This advice strikes me as being *way* too strong. Perhaps something like:

Consider limiting use of :mod:`doctest`
===============================

While 2to3 tries to port doctests properly, it's a rather tough thing
to do. If your test suite is heavily doctest dependent, then you may
end up spending a lot of time manually fixing doctests. The two major
avenues for dealing with this are to either port doctest based tests
over to the unittest module (making them significantly easier for 2to3
to handle) or else to follow the guidelines below for writing 2/3
compatible source code in all doctests (making it so they should run
unmodified on both Python versions).


Cheers,
Nick.

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

From steve at pearwood.info  Fri Feb  4 00:32:20 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Fri, 04 Feb 2011 10:32:20 +1100
Subject: [Python-Dev] [Python-checkins] r88331 - in
 python/branches/py3k/Doc/howto: index.rst pyporting.rst
In-Reply-To: <AANLkTi=s+bX07x02_DCkpX31+67ferpyYqq+M5VY689i@mail.gmail.com>
References: <20110203220155.419E3EEA35@mail.python.org>
	<AANLkTi=s+bX07x02_DCkpX31+67ferpyYqq+M5VY689i@mail.gmail.com>
Message-ID: <4D4B3B04.3070209@pearwood.info>

Nick Coghlan wrote:
> On Fri, Feb 4, 2011 at 8:01 AM, brett.cannon <python-checkins at python.org> wrote:
>> +Capturing the Currently Raised Exception
>> +----------------------------------------
>> +One change between Python 2 and 3 that will require changing how you code is
>> +accessing the currently raised exception.  In Python 2 the syntax to access the
>> +current exception is::

I think that the semantic change is *much* more important that the 
syntax change.

In 2.6:

 >>> try:
...     len(None)
... except TypeError as e:
...     pass
...
 >>> e
TypeError("object of type 'NoneType' has no len()",)


In 3.1:

 >>> try:
...     len(None)
... except TypeError as e:
...     pass
...
 >>> e
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
NameError: name 'e' is not defined



-- 
Steven


From brett at python.org  Fri Feb  4 00:56:58 2011
From: brett at python.org (Brett Cannon)
Date: Thu, 3 Feb 2011 15:56:58 -0800
Subject: [Python-Dev] [Python-checkins] r88331 - in
 python/branches/py3k/Doc/howto: index.rst pyporting.rst
In-Reply-To: <AANLkTik2xAJsOCyoyKwgP3tndF4ONkACKPy6K5Tb+L3s@mail.gmail.com>
References: <20110203220155.419E3EEA35@mail.python.org>
	<AANLkTik2xAJsOCyoyKwgP3tndF4ONkACKPy6K5Tb+L3s@mail.gmail.com>
Message-ID: <AANLkTin=nfokucspZA0MX7n29iCcbJSYPfgYyAyuhWd2@mail.gmail.com>

On Thu, Feb 3, 2011 at 15:10, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Feb 4, 2011 at 8:01 AM, brett.cannon <python-checkins at python.org> wrote:
>> +Stop Using :mod:`doctest`
>> +'''''''''''''''''''''''''
>> +While 2to3 tries to port doctests properly, it's a rather tough thing to do. It
>> +is probably best to simply convert your critical doctests to :mod:`unittest`.
>
> This advice strikes me as being *way* too strong. Perhaps something like:

I will change it to make sure that it states that you may want to port
your doctests if all you have is one massive set, but I do not think
it is "*way* too strong". Massive doctest inputs are bad enough as it
is to edit when you don't have a shift in syntax (e.g., I have a patch
waiting for 3.3 which causes entire test suites to skip because they
are a massive doctest and it is not reasonable nor easy to make
something conditional based on whether a trace function is set).
Trying to port them to new syntax is just that much harder (and a
complaint I came across online while researching the HOWTO).

-Brett

>
> Consider limiting use of :mod:`doctest`
> ===============================
>
> While 2to3 tries to port doctests properly, it's a rather tough thing
> to do. If your test suite is heavily doctest dependent, then you may
> end up spending a lot of time manually fixing doctests. The two major
> avenues for dealing with this are to either port doctest based tests
> over to the unittest module (making them significantly easier for 2to3
> to handle) or else to follow the guidelines below for writing 2/3
> compatible source code in all doctests (making it so they should run
> unmodified on both Python versions).
>
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>

From rian at dropbox.com  Fri Feb  4 06:10:33 2011
From: rian at dropbox.com (Rian Hunter)
Date: Thu, 3 Feb 2011 21:10:33 -0800
Subject: [Python-Dev] Issue #11051: system calls per import
In-Reply-To: <20110131134300.2babc577@pitrou.net>
References: <1296377778.24415.4.camel@marge> <4D452E71.6070401@python.org>
	<AANLkTikgN53=j+_t6_D3rcwADEYxwdrS2wjdnV3rWLOF@mail.gmail.com>
	<1296405345.24507.9.camel@marge>
	<4D45D6E1.6030906@canterbury.ac.nz> <4D4665B9.9000108@v.loewis.de>
	<AANLkTi=AtFMMhkEzsCf3i-J4Xte+bx+YD2TqLRkvm1RB@mail.gmail.com>
	<20110131134300.2babc577@pitrou.net>
Message-ID: <4945B802-AEF8-4528-BE53-293FBEF83A5C@dropbox.com>

Hello

Speaking from experience from my observations on millions of machines the stat() call is *very slow* when compared to readdir(), FindNextFile(), getdirentriesattr(), etc. When we switched from a file system indexer that stat()ed every file to one that read directories we noticed an average speedup of about 10x.

You can probably attribute this to the fact that in file system indexing the raw system call volume is much lower (not having to stat() each file, just read the directories) but also due to the fact that there is much less HD seeking (stat() has to jump around the HD, usually all directory entries fit in one block). If you only need to test for the existence of multiple files and don't need the extra information that stat() gives you, it might make sense to avoid the context switch/IO overhead.  

Rian

On Jan 31, 2011, at 4:43 AM, Antoine Pitrou wrote:

> On Mon, 31 Jan 2011 00:08:25 -0800
> Guido van Rossum <guido at python.org> wrote:
>> 
>> (Basically I am biased to believe that stat() is a pretty slow system
>> call -- this may just be old NFS lore though.)
> 
> I don't know about NFS, but starting a Python interpreter located on a
> Samba share from a Windows VM is quite slow too.
> I think Martin is right for the common case: on a local filesystem on a
> modern Unix, stat() is certainly very fast. Remote or
> distributed filesystems seem to be more of a problem.
> 
> 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/rian%40dropbox.com


From jcea at jcea.es  Fri Feb  4 16:30:01 2011
From: jcea at jcea.es (Jesus Cea)
Date: Fri, 04 Feb 2011 16:30:01 +0100
Subject: [Python-Dev] Support for async read/write
In-Reply-To: <1287529122.3488.9.camel@localhost.localdomain>
References: <4CBDCC52.8080209@jcea.es>
	<20101019235627.3812bd24@pitrou.net>	<4CBE202E.8060409@v.loewis.de>
	<1287529122.3488.9.camel@localhost.localdomain>
Message-ID: <4D4C1B79.20507@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20/10/10 00:58, Antoine Pitrou wrote:
> It would be nice to know about the use case Jesus has in mind.

I am thinking about the cases where a request come, you do some disk
read in behalf of it and you reply.

If the read is "slow" (if not cached, you have to deal with a physical
harddisk), you stop the main-loop for a while, unless you use threads.

If, instead, I can schedule a read and keep processing other requests
(possibly queueing new reads), be notified when the read is done and
complete the reply, I think this is more simple and performing (and far
less memory hungry) that using threads.

I just opened a issue, assigned to me. I plan to do the implementation
myself, at least for Solaris and possibly (recent) Linux:
<http://bugs.python.o rg/issue11117>.

Some people say AIO OS implementations are flaky. Well, you must deal
with it, like you deal with other flaky OS corners, like exhausting
memory or whatever.

I would suppose that if Python exposes AIO and in some OS support is
underpar, the exposing would incentivate a better support for OS. Like
happened to threads and linux years ago.

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

iQCVAwUBTUwbeZlgi5GaxT1NAQK4uwP+J3PwGY1dvBi+OyBo9M9UWsma0khgzdUS
6ewHhCrCK+U5HK0e/g9cLbesBSsYvVfNjPe+fb9cQuwMBK0lpF3kOzfsEf82RIxR
NlsqOba31CE1tW9uS4wja0TddFDob3IImqgwSB7NptBOZTNVjDvB6k0V7KHqvPWX
9g01GqaQ9uQ=
=hx6M
-----END PGP SIGNATURE-----

From status at bugs.python.org  Fri Feb  4 18:07:06 2011
From: status at bugs.python.org (Python tracker)
Date: Fri,  4 Feb 2011 18:07:06 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20110204170706.2E7D61CDDC@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2011-01-28 - 2011-02-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    2585 (+18)
  closed 20314 (+52)
  total  22899 (+70)

Open issues with patches: 1102 


Issues opened (49)
==================

#10918: **kwargs unnecessarily restricted in concurrent.futures 'submi
http://bugs.python.org/issue10918  reopened by bquinlan

#11023: pep 227 missing text
http://bugs.python.org/issue11023  reopened by r.david.murray

#11048: "import ctypes" causes segfault on read-only filesystem
http://bugs.python.org/issue11048  opened by Arach

#11049: add tests for test.support
http://bugs.python.org/issue11049  opened by brett.cannon

#11050: email.utils.getaddresses behavior contradicts RFC2822
http://bugs.python.org/issue11050  opened by Ivan.Egorov

#11051: system calls per import
http://bugs.python.org/issue11051  opened by pitrou

#11055: OS X IDLE 3.2 Save As menu accelerator opens two Save windows
http://bugs.python.org/issue11055  opened by ned.deily

#11056: 2to3 fails for inner __metaclass__ class definition
http://bugs.python.org/issue11056  opened by nw

#11062: mailbox fails to round-trip a file to a Babyl mailbox
http://bugs.python.org/issue11062  opened by r.david.murray

#11063: uuid.py module import has heavy side effects
http://bugs.python.org/issue11063  opened by Keith.Dart

#11067: Py_LIMITED_API breaks most PySomething_Check() functions
http://bugs.python.org/issue11067  opened by petere

#11071: What's New review comments
http://bugs.python.org/issue11071  opened by ncoghlan

#11072: Add MLSD command support to ftplib
http://bugs.python.org/issue11072  opened by giampaolo.rodola

#11074: fix tokenize so it can be reloaded
http://bugs.python.org/issue11074  opened by brett.cannon

#11076: Iterable argparse Namespace
http://bugs.python.org/issue11076  opened by vdupras

#11077: Tkinter is not thread safe
http://bugs.python.org/issue11077  opened by PythonInTheGrass

#11078: Have test___all__ check for duplicates
http://bugs.python.org/issue11078  opened by r.david.murray

#11079: Make OS X entry in Applications like that in Windows
http://bugs.python.org/issue11079  opened by rhettinger

#11085: expose _abcoll as collections.abc
http://bugs.python.org/issue11085  opened by rhettinger

#11086: add lib2to3/__main__.py
http://bugs.python.org/issue11086  opened by brett.cannon

#11087: Speeding up the interpreter with a few lines of code
http://bugs.python.org/issue11087  opened by jneb

#11088: IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input / raw
http://bugs.python.org/issue11088  opened by ned.deily

#11089: ConfigParser 50x slower in 2.7
http://bugs.python.org/issue11089  opened by vlachoudis

#11090: Doc errors for unittest in Python 3.1
http://bugs.python.org/issue11090  opened by michael.foord

#11092: Setup.cfg isn't packaged when running sdist
http://bugs.python.org/issue11092  opened by Julien.Miotte

#11093: test_future - rename not-unittest files to make regrtest.NOTTE
http://bugs.python.org/issue11093  opened by sandro.tosi

#11096: Multiple turtle tracers
http://bugs.python.org/issue11096  opened by amcnerney13

#11097: MSI: Remove win32com dependency from installer generator
http://bugs.python.org/issue11097  opened by techtonik

#11100: test_fdopen: close failed in file object destructor
http://bugs.python.org/issue11100  opened by ekrauss

#11101: plistlib has no graceful way of handing None values
http://bugs.python.org/issue11101  opened by bobveznat

#11102: configure doesn't find "major()" on HP-UX v11.31
http://bugs.python.org/issue11102  opened by Oren_Held

#11103: Python 3.2 installer doesn't register file extensions on Windo
http://bugs.python.org/issue11103  opened by darren

#11104: distutils sdist ignores MANIFEST
http://bugs.python.org/issue11104  opened by jdennis

#11105: Compiling evil ast crashes interpreter
http://bugs.python.org/issue11105  opened by benjamin.peterson

#11107: Cache constant "slice" instances
http://bugs.python.org/issue11107  opened by scoder

#11109: socketserver.ForkingMixIn leaves zombies
http://bugs.python.org/issue11109  opened by jwark

#11110: Py_DECREF->Py_XDECREF in Module/_sqlite/module.c
http://bugs.python.org/issue11110  opened by brett.cannon

#11112: UDPTimeoutTest derives from SocketTCPTest
http://bugs.python.org/issue11112  opened by rmtew

#11113: html.entities mapping dicts need updating?
http://bugs.python.org/issue11113  opened by Brian.Jones

#11114: TextIOWrapper.tell extremely slow
http://bugs.python.org/issue11114  opened by Laurens

#11116: mailbox and email errors
http://bugs.python.org/issue11116  opened by sdaoden

#11117: Implementing Async IO
http://bugs.python.org/issue11117  opened by jcea

#1103350: send/recv SEGMENT_SIZE should be used more in socketmodule
http://bugs.python.org/issue1103350  reopened by r.david.murray

#11060: distutils2 sdist does not complain about version that is not P
http://bugs.python.org/issue11060  opened by gotcha

#11061: Verify command option before parsing config file
http://bugs.python.org/issue11061  opened by sdouche

#11066: cgi.py proposals : sys.stdout encoding + rewriting of parsing 
http://bugs.python.org/issue11066  opened by quentel

#11082: ValueError: Content-Length should be specified
http://bugs.python.org/issue11082  opened by William.Wu

#11084: Serialization of decimal.Decimal to XML-RPC
http://bugs.python.org/issue11084  opened by gdr

#1252236: Simplying Tkinter's event loop
http://bugs.python.org/issue1252236  reopened by belopolsky



Most recent 15 issues with no replies (15)
==========================================

#11109: socketserver.ForkingMixIn leaves zombies
http://bugs.python.org/issue11109

#11101: plistlib has no graceful way of handing None values
http://bugs.python.org/issue11101

#11100: test_fdopen: close failed in file object destructor
http://bugs.python.org/issue11100

#11097: MSI: Remove win32com dependency from installer generator
http://bugs.python.org/issue11097

#11093: test_future - rename not-unittest files to make regrtest.NOTTE
http://bugs.python.org/issue11093

#11088: IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input / raw
http://bugs.python.org/issue11088

#11074: fix tokenize so it can be reloaded
http://bugs.python.org/issue11074

#11072: Add MLSD command support to ftplib
http://bugs.python.org/issue11072

#11066: cgi.py proposals : sys.stdout encoding + rewriting of parsing 
http://bugs.python.org/issue11066

#11063: uuid.py module import has heavy side effects
http://bugs.python.org/issue11063

#11062: mailbox fails to round-trip a file to a Babyl mailbox
http://bugs.python.org/issue11062

#11060: distutils2 sdist does not complain about version that is not P
http://bugs.python.org/issue11060

#11056: 2to3 fails for inner __metaclass__ class definition
http://bugs.python.org/issue11056

#11055: OS X IDLE 3.2 Save As menu accelerator opens two Save windows
http://bugs.python.org/issue11055

#11050: email.utils.getaddresses behavior contradicts RFC2822
http://bugs.python.org/issue11050



Most recent 15 issues waiting for review (15)
=============================================

#11116: mailbox and email errors
http://bugs.python.org/issue11116

#11110: Py_DECREF->Py_XDECREF in Module/_sqlite/module.c
http://bugs.python.org/issue11110

#11109: socketserver.ForkingMixIn leaves zombies
http://bugs.python.org/issue11109

#11104: distutils sdist ignores MANIFEST
http://bugs.python.org/issue11104

#11102: configure doesn't find "major()" on HP-UX v11.31
http://bugs.python.org/issue11102

#11101: plistlib has no graceful way of handing None values
http://bugs.python.org/issue11101

#11093: test_future - rename not-unittest files to make regrtest.NOTTE
http://bugs.python.org/issue11093

#11090: Doc errors for unittest in Python 3.1
http://bugs.python.org/issue11090

#11089: ConfigParser 50x slower in 2.7
http://bugs.python.org/issue11089

#11086: add lib2to3/__main__.py
http://bugs.python.org/issue11086

#11082: ValueError: Content-Length should be specified
http://bugs.python.org/issue11082

#11079: Make OS X entry in Applications like that in Windows
http://bugs.python.org/issue11079

#11078: Have test___all__ check for duplicates
http://bugs.python.org/issue11078

#11076: Iterable argparse Namespace
http://bugs.python.org/issue11076

#11074: fix tokenize so it can be reloaded
http://bugs.python.org/issue11074



Top 10 most discussed issues (10)
=================================

#11071: What's New review comments
http://bugs.python.org/issue11071  20 msgs

#10845: test_multiprocessing failure under Windows
http://bugs.python.org/issue10845  12 msgs

#7111: abort when stderr is closed
http://bugs.python.org/issue7111  11 msgs

#10227: Improve performance of MemoryView slicing
http://bugs.python.org/issue10227  11 msgs

#11114: TextIOWrapper.tell extremely slow
http://bugs.python.org/issue11114   9 msgs

#11082: ValueError: Content-Length should be specified
http://bugs.python.org/issue11082   9 msgs

#8914: Run clang's static analyzer
http://bugs.python.org/issue8914   8 msgs

#11037: State of PEP 382 or How does distutils2 handle	namespaces?
http://bugs.python.org/issue11037   8 msgs

#11024: imaplib: Time2Internaldate() returns localized strings
http://bugs.python.org/issue11024   8 msgs

#2193: Cookie Colon Name Bug
http://bugs.python.org/issue2193   7 msgs



Issues closed (53)
==================

#6045: Add more dict methods to dbm interfaces
http://bugs.python.org/issue6045  closed by eric.araujo

#6465: email.feedparser regular expression bug (NLCRE_crack)
http://bugs.python.org/issue6465  closed by sandro.tosi

#7074: Turtle module crashes python
http://bugs.python.org/issue7074  closed by belopolsky

#8275: callback function on win64 results in bad behavior. mem corrup
http://bugs.python.org/issue8275  closed by pitrou

#9124: Mailbox module should use binary I/O, not text I/O
http://bugs.python.org/issue9124  closed by r.david.murray

#9127: subprocess.Popen.communicate() and SIGCHLD handlers
http://bugs.python.org/issue9127  closed by ned.deily

#9418: Move _formatter_* methods from string type into _string module
http://bugs.python.org/issue9418  closed by eric.smith

#9763: Crashes upon run after syntax error encountered in OSX 10.5.8
http://bugs.python.org/issue9763  closed by ned.deily

#9884: The 4th parameter of method always None or 0 on x64 Windows.
http://bugs.python.org/issue9884  closed by owenl

#10480: cgi.py should document the need for binary stdin/stdout
http://bugs.python.org/issue10480  closed by v+python

#10573: Consistency in unittest assert methods: order of actual, expec
http://bugs.python.org/issue10573  closed by michael.foord

#10847: Distutils drops -fno-strict-aliasing when CFLAGS are set
http://bugs.python.org/issue10847  closed by eric.araujo

#10939: imaplib: Internaldate2tuple raises KeyError parsing month and 
http://bugs.python.org/issue10939  closed by belopolsky

#10940: IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with 64-bit inst
http://bugs.python.org/issue10940  closed by ned.deily

#10961: Pydoc touchups in new browser for 3.2
http://bugs.python.org/issue10961  closed by georg.brandl

#10989: ssl.SSLContext(True).load_verify_locations(None, True) segfaul
http://bugs.python.org/issue10989  closed by haypo

#11025: Distutils2 install command without setup.py or setup.cfg creat
http://bugs.python.org/issue11025  closed by eric.araujo

#11032: _string: formatter_field_name_split() and formatter_parser() d
http://bugs.python.org/issue11032  closed by eric.smith

#11035: Segmentation fault
http://bugs.python.org/issue11035  closed by brett.cannon

#11038: Some commands should stop if Name and Version are missing
http://bugs.python.org/issue11038  closed by eric.araujo

#11040: After registering a project to PyPI, classifiers fields aren't
http://bugs.python.org/issue11040  closed by eric.araujo

#11042: [PyPI CSS] Adding project urls onto a project page using regis
http://bugs.python.org/issue11042  closed by eric.araujo

#11043: On GNU/Linux (Ubuntu) distutils2.mkcfg shouldn't create an exe
http://bugs.python.org/issue11043  closed by eric.araujo

#11044: The description-file isn't handled by distutils2
http://bugs.python.org/issue11044  closed by Julien.Miotte

#11052: Fix OS X IDLE menu accelerators for Save As and Save Copy
http://bugs.python.org/issue11052  closed by ned.deily

#11053: OS X IDLE 3 with Tk 8.4 appears to hang with syntax error
http://bugs.python.org/issue11053  closed by ned.deily

#11054: OS X installer build script for 3.2 can no longer build with s
http://bugs.python.org/issue11054  closed by ned.deily

#11057: Missing import of DistutilsOptionError
http://bugs.python.org/issue11057  closed by eric.araujo

#11064: abc documentation version conflict
http://bugs.python.org/issue11064  closed by dustin.farris

#11065: Fatal "can't locate locale" errors when zip file with director
http://bugs.python.org/issue11065  closed by ned.deily

#11068: Python 2.7.1 Idle traceback on OS X (10.6.6)
http://bugs.python.org/issue11068  closed by r.david.murray

#11069: IDLE crashes when Stack Viewer opened
http://bugs.python.org/issue11069  closed by georg.brandl

#11070: test_capi crashes and fails
http://bugs.python.org/issue11070  closed by brian.curtin

#11073: threading.Thread documentation can be improved
http://bugs.python.org/issue11073  closed by pitrou

#11075: Using Turtle with IDLE on Mac OS X
http://bugs.python.org/issue11075  closed by amcnerney13

#11080: Win32Serial.read coding error for non-blocking read
http://bugs.python.org/issue11080  closed by brian.curtin

#11081: from struct import * misses pack_into
http://bugs.python.org/issue11081  closed by belopolsky

#11083: threading.Thread - start() rises RuntimeException?
http://bugs.python.org/issue11083  closed by brian.curtin

#11091: Bug with reimport in pkg_resources
http://bugs.python.org/issue11091  closed by brett.cannon

#11094: Runtime error
http://bugs.python.org/issue11094  closed by amaury.forgeotdarc

#11095: subprocess popen broken for bytes and backslash
http://bugs.python.org/issue11095  closed by eric.smith

#11098: syntax error at end of line in interactive python -u
http://bugs.python.org/issue11098  closed by r.david.murray

#11099: Bytes pickled with 3.1 not unpickled with 2.7 correctly
http://bugs.python.org/issue11099  closed by r.david.murray

#11106: python 2.6.6 and python 2.7.1 cannot be built successfully bec
http://bugs.python.org/issue11106  closed by skrah

#11108: Intermittent AttributeError when using time.strptime in thread
http://bugs.python.org/issue11108  closed by amaury.forgeotdarc

#11111: See "Gmail" on your Google homepage
http://bugs.python.org/issue11111  closed by belopolsky

#11115: csv readers and writers should be context managers
http://bugs.python.org/issue11115  closed by r.david.murray

#1613479: pydoc info for a package doesn't list all package contents
http://bugs.python.org/issue1613479  closed by eric.araujo

#10947: imaplib: Internaldate2tuple and ParseFlags require (and latter
http://bugs.python.org/issue10947  closed by lavajoe

#11036: Allow multiple files in the description-file metadata
http://bugs.python.org/issue11036  closed by eric.araujo

#11058: dist directory not created when running sdist command
http://bugs.python.org/issue11058  closed by kelseyhightower

#11059: Mercurial fails on code.python.org repo
http://bugs.python.org/issue11059  closed by sdaoden

#1647654: No obvious and correct way to get the time zone offset
http://bugs.python.org/issue1647654  closed by belopolsky

From chris at simplistix.co.uk  Fri Feb  4 18:43:21 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 04 Feb 2011 17:43:21 +0000
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
 Windows
In-Reply-To: <4D431724.4010002@voidspace.org.uk>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk>
Message-ID: <4D4C3AB9.3020300@simplistix.co.uk>

On 28/01/2011 19:21, Michael Foord wrote:
> I've helped quite a few "python newbies" on Windows who are also
> surprised / frustrated on learning that "python" on the command line
> doesn't work after installing python.

Yes, I've always found it a surprising disappointment that I have to 
manually munge the PATH and the installer doesn't *even* offer to do it 
for me.

But, since I don't know how to help fix the installer, I've just 
generally stfu'd on this issue...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From p.f.moore at gmail.com  Sat Feb  5 19:39:21 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 5 Feb 2011 18:39:21 +0000
Subject: [Python-Dev] Test - Are there problems with the list?
Message-ID: <AANLkTikdaGJT2diJviEtNTZuZ-GU+FudHsr_UNdg=y3m@mail.gmail.com>

I've not seen any python-dev mails for a day or so. Is there a problem
with the list?
Paul.

From solipsis at pitrou.net  Sat Feb  5 20:02:02 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 5 Feb 2011 20:02:02 +0100
Subject: [Python-Dev] Test - Are there problems with the list?
References: <AANLkTikdaGJT2diJviEtNTZuZ-GU+FudHsr_UNdg=y3m@mail.gmail.com>
Message-ID: <20110205200202.20164431@pitrou.net>

On Sat, 5 Feb 2011 18:39:21 +0000
Paul Moore <p.f.moore at gmail.com> wrote:
> I've not seen any python-dev mails for a day or so. Is there a problem
> with the list?

I think it's just that nobody posted.

Regards

Antoine.



From techtonik at gmail.com  Sun Feb  6 11:14:52 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 6 Feb 2011 12:14:52 +0200
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
	Windows
In-Reply-To: <4D4C3AB9.3020300@simplistix.co.uk>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk>
Message-ID: <AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>

On Fri, Feb 4, 2011 at 7:43 PM, Chris Withers <chris at simplistix.co.uk> wrote:
>>
>> I've helped quite a few "python newbies" on Windows who are also
>> surprised / frustrated on learning that "python" on the command line
>> doesn't work after installing python.
>
> Yes, I've always found it a surprising disappointment that I have to
> manually munge the PATH and the installer doesn't *even* offer to do it for
> me.
>
> But, since I don't know how to help fix the installer, I've just generally
> stfu'd on this issue...

This is how to fix an installer.
http://codereview.appspot.com/4023055/diff/1/Tools/msi/msi.py

Right now I am waiting for Martin's decision (and probably not only
me). He is responsible for MSI stuff and the only one, who can
integrate the patch. I don't want to put too much pressure on him, but
it would be more comfortable for all of us to know what is he up to.
I'd like to see this in 3.2 release, of course.

-- 
anatoly t.

From ncoghlan at gmail.com  Sun Feb  6 14:59:33 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Feb 2011 23:59:33 +1000
Subject: [Python-Dev] [Python-checkins] devguide: Describe the Rdiff
 extension for remote diffs
In-Reply-To: <E1Ply4V-0001B3-He@dinsdale.python.org>
References: <E1Ply4V-0001B3-He@dinsdale.python.org>
Message-ID: <AANLkTim-9CmfRg-3uX8x9eO+w9iW6mpMu=aJq6QTRTux@mail.gmail.com>

On Sun, Feb 6, 2011 at 4:26 PM, nick.coghlan <python-checkins at python.org> wrote:
> +How do I compare my working copy to a remote repository?
> +-------------------------------------------------------------------------------

To save anyone else pointing this out, I'm now aware that "hg
incoming" and "hg outgoing" are the actual commands I want. Still,
that kind of mistake is why I want to keep the dev FAQ around - to
help people that don't know enough to avoid the misleading answers a
web search will sometimes give back.

Cheers,
Nick.

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

From merwok at netwok.org  Sun Feb  6 15:06:05 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 06 Feb 2011 15:06:05 +0100
Subject: [Python-Dev] [Python-checkins] devguide: Describe the Rdiff
 extension for remote diffs
In-Reply-To: <AANLkTim-9CmfRg-3uX8x9eO+w9iW6mpMu=aJq6QTRTux@mail.gmail.com>
References: <AANLkTim-9CmfRg-3uX8x9eO+w9iW6mpMu=aJq6QTRTux@mail.gmail.com>
Message-ID: <4D4EAACD.3010903@netwok.org>

>> +How do I compare my working copy to a remote repository?
> 
> To save anyone else pointing this out, I'm now aware that "hg
> incoming" and "hg outgoing" are the actual commands I want.

incoming and outgoing compare your repository to a remote repository,
not your working copy.

Regards

From ncoghlan at gmail.com  Sun Feb  6 15:42:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Feb 2011 00:42:17 +1000
Subject: [Python-Dev] [Python-checkins] devguide: Describe the Rdiff
 extension for remote diffs
In-Reply-To: <4D4EAACD.3010903@netwok.org>
References: <AANLkTim-9CmfRg-3uX8x9eO+w9iW6mpMu=aJq6QTRTux@mail.gmail.com>
	<4D4EAACD.3010903@netwok.org>
Message-ID: <AANLkTimEgEsO_PpGoQMdG7vU3UavFm92UhbN-2RiC37J@mail.gmail.com>

On Mon, Feb 7, 2011 at 12:06 AM, ?ric Araujo <merwok at netwok.org> wrote:
>>> +How do I compare my working copy to a remote repository?
>>
>> To save anyone else pointing this out, I'm now aware that "hg
>> incoming" and "hg outgoing" are the actual commands I want.
>
> incoming and outgoing compare your repository to a remote repository,
> not your working copy.

Yeah, I know, but for the use case I actually had in mind with that
new FAQ entry ("When I type this next push command, what is it going
to do?"), it's the committed changes that are important. I had my
terminology wrong, so Google led me astray.

Cheers,
Nick.

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

From brian.curtin at gmail.com  Sun Feb  6 16:20:41 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Sun, 6 Feb 2011 09:20:41 -0600
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
	Windows
In-Reply-To: <AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk>
	<4D4C3AB9.3020300@simplistix.co.uk>
	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
Message-ID: <AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>

On Sun, Feb 6, 2011 at 04:14, anatoly techtonik <techtonik at gmail.com> wrote:

> On Fri, Feb 4, 2011 at 7:43 PM, Chris Withers <chris at simplistix.co.uk>
> wrote:
> >>
> >> I've helped quite a few "python newbies" on Windows who are also
> >> surprised / frustrated on learning that "python" on the command line
> >> doesn't work after installing python.
> >
> > Yes, I've always found it a surprising disappointment that I have to
> > manually munge the PATH and the installer doesn't *even* offer to do it
> for
> > me.
> >
> > But, since I don't know how to help fix the installer, I've just
> generally
> > stfu'd on this issue...
>
> This is how to fix an installer.
> http://codereview.appspot.com/4023055/diff/1/Tools/msi/msi.py
>
> Right now I am waiting for Martin's decision (and probably not only
> me). He is responsible for MSI stuff and the only one, who can
> integrate the patch. I don't want to put too much pressure on him, but
> it would be more comfortable for all of us to know what is he up to.
> I'd like to see this in 3.2 release, of course.


We're one week from the 3.2 final release, so adding a feature such as this
is definitely out of the question. Sorry to speak for Martin, but I'm
certain he would agree.

There are still outstanding considerations in the various issues on the
tracker, so it would be best to address them before requesting integration.
Example: What should happen when there is another Python installation on the
path?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110206/3073c61c/attachment.html>

From chris at simplistix.co.uk  Sun Feb  6 16:22:44 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Sun, 06 Feb 2011 15:22:44 +0000
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
 Windows
In-Reply-To: <AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>	<4D431724.4010002@voidspace.org.uk>	<4D4C3AB9.3020300@simplistix.co.uk>	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
	<AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>
Message-ID: <4D4EBCC4.1090003@simplistix.co.uk>

On 06/02/2011 15:20, Brian Curtin wrote:
> There are still outstanding considerations in the various issues on the
> tracker, so it would be best to address them before requesting
> integration. Example: What should happen when there is another Python
> installation on the path?

Same as happens with most Windows apps: last one installed wins.

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From brian.curtin at gmail.com  Sun Feb  6 16:25:08 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Sun, 6 Feb 2011 09:25:08 -0600
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
	Windows
In-Reply-To: <4D4EBCC4.1090003@simplistix.co.uk>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk>
	<4D4C3AB9.3020300@simplistix.co.uk>
	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
	<AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>
	<4D4EBCC4.1090003@simplistix.co.uk>
Message-ID: <AANLkTinhzYMo7PJJv8ZwPtc_BDbMELvKgKdPy6QSNm8d@mail.gmail.com>

On Sun, Feb 6, 2011 at 09:22, Chris Withers <chris at simplistix.co.uk> wrote:

> On 06/02/2011 15:20, Brian Curtin wrote:
>
>> There are still outstanding considerations in the various issues on the
>> tracker, so it would be best to address them before requesting
>> integration. Example: What should happen when there is another Python
>> installation on the path?
>>
>
> Same as happens with most Windows apps: last one installed wins.
>
>
> Chris
>

So put the new path before the old path, or replace it? The current patch
appends to the end.

Anyways, this is the type of discussion for the existing issues on the
tracker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110206/b6ea84c0/attachment.html>

From chris at simplistix.co.uk  Sun Feb  6 16:27:03 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Sun, 06 Feb 2011 15:27:03 +0000
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
 Windows
In-Reply-To: <AANLkTinhzYMo7PJJv8ZwPtc_BDbMELvKgKdPy6QSNm8d@mail.gmail.com>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>	<4D431724.4010002@voidspace.org.uk>	<4D4C3AB9.3020300@simplistix.co.uk>	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>	<AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>	<4D4EBCC4.1090003@simplistix.co.uk>
	<AANLkTinhzYMo7PJJv8ZwPtc_BDbMELvKgKdPy6QSNm8d@mail.gmail.com>
Message-ID: <4D4EBDC7.9000301@simplistix.co.uk>

On 06/02/2011 15:25, Brian Curtin wrote:
> So put the new path before the old path, or replace it? The current
> patch appends to the end.

I believe the last path wins in Windows land, so that would be fine.

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From ncoghlan at gmail.com  Sun Feb  6 16:35:13 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Feb 2011 01:35:13 +1000
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
	Windows
In-Reply-To: <4D4EBDC7.9000301@simplistix.co.uk>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk>
	<4D4C3AB9.3020300@simplistix.co.uk>
	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
	<AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>
	<4D4EBCC4.1090003@simplistix.co.uk>
	<AANLkTinhzYMo7PJJv8ZwPtc_BDbMELvKgKdPy6QSNm8d@mail.gmail.com>
	<4D4EBDC7.9000301@simplistix.co.uk>
Message-ID: <AANLkTi=hrFaWa0QQe5dEU3nRvYKoctJ0ua6ixUexeLnd@mail.gmail.com>

On Mon, Feb 7, 2011 at 1:27 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> On 06/02/2011 15:25, Brian Curtin wrote:
>>
>> So put the new path before the old path, or replace it? The current
>> patch appends to the end.
>
> I believe the last path wins in Windows land, so that would be fine.

Not that I've ever experienced. Most installers just make sure to
insert entries at the beginning so "last installed" wins.

Cheers,
Nick.

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

From solipsis at pitrou.net  Sun Feb  6 17:15:42 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Feb 2011 17:15:42 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for	non-committers.
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
Message-ID: <20110206171542.3859df07@pitrou.net>

On Sun, 06 Feb 2011 02:10:15 +0100
brett.cannon <python-checkins at python.org> wrote:
>  
>  To create your patch, you should generate a unified diff from your checkout's
>  top-level directory::
>  
> -    svn diff > patch.diff
> +    hg outgoing --path > patch.diff

Should be --patch.
The problem is that it will show one several patch per changeset, which
is normally not what you want (it's a pity "hg out" doesn't have an
option to collapse them all).

>  If your work needs some new files to be added to the source tree, remember
> -to ``svn add`` them before generating the patch::
> +to ``hg add`` them before generating the patch::
>  
> -   svn add Lib/newfile.py
> -   svn diff > patch.diff
> +   hg add Lib/newfile.py
> +   hg outgoing --patch > patch.diff

You should commit before using "outgoing", otherwise the added file is
not in the repo (and therefore not in the patch).

The problem with hg (and other DVCSes) is that allows for *several*
local workflows, and therefore it's harder to advocate one of them in
such tutorial docs. I wonder what Georg and Dirkjan suggest.

We could perhaps present SVN-like "work in the working copy" workflow
(without local commits), and let seasoned hg users choose other
workflows they like more (they don't need our help anyway).

>  To undo a patch, you can revert **all** changes made in your checkout::
>  
> -    svn revert -R .
> +    hg revert --all
> +

Or "hg revert -a", which is nicer to type.




From p.f.moore at gmail.com  Sun Feb  6 17:17:23 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 6 Feb 2011 16:17:23 +0000
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
	Windows
In-Reply-To: <AANLkTi=hrFaWa0QQe5dEU3nRvYKoctJ0ua6ixUexeLnd@mail.gmail.com>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk>
	<4D4C3AB9.3020300@simplistix.co.uk>
	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
	<AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>
	<4D4EBCC4.1090003@simplistix.co.uk>
	<AANLkTinhzYMo7PJJv8ZwPtc_BDbMELvKgKdPy6QSNm8d@mail.gmail.com>
	<4D4EBDC7.9000301@simplistix.co.uk>
	<AANLkTi=hrFaWa0QQe5dEU3nRvYKoctJ0ua6ixUexeLnd@mail.gmail.com>
Message-ID: <AANLkTin9iOgZo-1gydV312C8=WPFtCTvmrynx=NTDuF2@mail.gmail.com>

On 6 February 2011 15:35, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Feb 7, 2011 at 1:27 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>> On 06/02/2011 15:25, Brian Curtin wrote:
>>>
>>> So put the new path before the old path, or replace it? The current
>>> patch appends to the end.
>>
>> I believe the last path wins in Windows land, so that would be fine.
>
> Not that I've ever experienced. Most installers just make sure to
> insert entries at the beginning so "last installed" wins.

... and "at the beginning" can be a pain due to unintended overriding
of existing user commands (not likely in the case of Python, where
there's only python, pythonw, w9xpopen and various bdist_wininst
"RemoveXXX" commands, but still possible).

"Before any existing Python directories, otherwise at the end" is the
closest to what I suspect most users want (certainly it matches my
preferences, and anything else would have me manually editing PATH
anyway, so is of no use to me in practice).

Paul.

From stephen at xemacs.org  Sun Feb  6 18:07:26 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 07 Feb 2011 02:07:26 +0900
Subject: [Python-Dev] Finally fix installer to add Python to %PATH%
	on	Windows
In-Reply-To: <AANLkTin9iOgZo-1gydV312C8=WPFtCTvmrynx=NTDuF2@mail.gmail.com>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk>
	<4D4C3AB9.3020300@simplistix.co.uk>
	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
	<AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>
	<4D4EBCC4.1090003@simplistix.co.uk>
	<AANLkTinhzYMo7PJJv8ZwPtc_BDbMELvKgKdPy6QSNm8d@mail.gmail.com>
	<4D4EBDC7.9000301@simplistix.co.uk>
	<AANLkTi=hrFaWa0QQe5dEU3nRvYKoctJ0ua6ixUexeLnd@mail.gmail.com>
	<AANLkTin9iOgZo-1gydV312C8=WPFtCTvmrynx=NTDuF2@mail.gmail.com>
Message-ID: <8762sx148h.fsf@uwakimon.sk.tsukuba.ac.jp>

Paul Moore writes:

 > "Before any existing Python directories, otherwise at the end" is the
 > closest to what I suspect most users want (certainly it matches my
 > preferences, and anything else would have me manually editing PATH
 > anyway, so is of no use to me in practice).

Unfortunately, what is "no use to person X in practice" is a function
of X.  I suspect that's why this hasn't been done.

Specifically, it seems to me that there are use cases for each of

1.  Append (eg, if both python3 and python2 provide "python.exe", for
    experimental use of python3).
2.  Prepend (actually, not a use case; just common, and therefore
    "intuitive", practice).
3.  "Moore's rule" (put latest and greatest ahead of other versions
    but not interfere with previously installed apps).

Maybe it should be user-configurable.

From merwok at netwok.org  Sun Feb  6 19:10:37 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 06 Feb 2011 19:10:37 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for	non-committers.
In-Reply-To: <20110206171542.3859df07@pitrou.net>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
Message-ID: <4D4EE41D.30003@netwok.org>

Le 06/02/2011 17:15, Antoine Pitrou a ?crit :
> On Sun, 06 Feb 2011 02:10:15 +0100
> brett.cannon <python-checkins at python.org> wrote:
>>  To create your patch, you should generate a unified diff from your checkout's
>>  top-level directory::
>>  
>> -    svn diff > patch.diff
>> +    hg outgoing --path > patch.diff
> 
> Should be --patch.
> The problem is that it will show one several patch per changeset, which
> is normally not what you want (it's a pity "hg out" doesn't have an
> option to collapse them all).

I suggest you request that feature upstream.

In the meantime, one can use hg diff -r $upstream-tip:tip to diff two
anonymous branches.  Using a named branch or local tags helps
identifying $upstream-tip.

Regards

From p.f.moore at gmail.com  Sun Feb  6 19:13:30 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 6 Feb 2011 18:13:30 +0000
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
	Windows
In-Reply-To: <8762sx148h.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk>
	<4D4C3AB9.3020300@simplistix.co.uk>
	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
	<AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>
	<4D4EBCC4.1090003@simplistix.co.uk>
	<AANLkTinhzYMo7PJJv8ZwPtc_BDbMELvKgKdPy6QSNm8d@mail.gmail.com>
	<4D4EBDC7.9000301@simplistix.co.uk>
	<AANLkTi=hrFaWa0QQe5dEU3nRvYKoctJ0ua6ixUexeLnd@mail.gmail.com>
	<AANLkTin9iOgZo-1gydV312C8=WPFtCTvmrynx=NTDuF2@mail.gmail.com>
	<8762sx148h.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTi=RxbOW5mO-JotSc5P6+b_21v2++-f-SGQM0i_n@mail.gmail.com>

On 6 February 2011 17:07, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Paul Moore writes:
>
> ?> "Before any existing Python directories, otherwise at the end" is the
> ?> closest to what I suspect most users want (certainly it matches my
> ?> preferences, and anything else would have me manually editing PATH
> ?> anyway, so is of no use to me in practice).
>
> Unfortunately, what is "no use to person X in practice" is a function
> of X. ?I suspect that's why this hasn't been done.

Absolutely :-) And it's also why I'm reluctant to support it - even
though I agree that not having "python" just work is a PITA.

> Specifically, it seems to me that there are use cases for each of
>
> 1. ?Append (eg, if both python3 and python2 provide "python.exe", for
> ? ?experimental use of python3).
> 2. ?Prepend (actually, not a use case; just common, and therefore
> ? ?"intuitive", practice).
> 3. ?"Moore's rule" (put latest and greatest ahead of other versions
> ? ?but not interfere with previously installed apps).

Fame at last :-)

I've seen both (1) and (2) in common use. Both have disadvantages,
particularly if you try to support multiple versions being installed
at once (something which is nearly unheard of in Windows, and hence
why no commonly used solution really does a good job of it).

I've never seen (3), and in all honesty I don't expect it to be
practical - too many special cases to consider. It was more of a straw
man example of what "do it right" might really mean...

> Maybe it should be user-configurable.

-1. Too much complexity. What I *have* seen is Oracle's "Home
Selector", which is a program installed with Oracle's software which
keeps track of which versions of Oracle you have installed, and gives
you a GUI to move them up & down in priority, or disable versions. It
then updates PATH appropriately. Ultimately, all it is in Python's
terms, is a GUI means of editing PATH, so I'm not sure it's of any
real use to us. (For Oracle, I think it fiddles with some other
registry values, so it does have some value there...)

One point - no matter what we do, we only need to consider 3.3 and
later. People using 3.2 or earlier still have to manually fix up PATH
how they want. So if we do add python to PATH in 3.3, we don't
actually have a "what if people want to install multiple versions"
issue until 3.4 comes out. I'm assuming we don't try to support
multiple maintenance releases (3.3.1 and 3.3.2) being installed at
once...

Paul.

From martin at v.loewis.de  Sun Feb  6 19:26:49 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Feb 2011 19:26:49 +0100
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
 Windows
In-Reply-To: <AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>	<4D431724.4010002@voidspace.org.uk>
	<4D4C3AB9.3020300@simplistix.co.uk>
	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
Message-ID: <4D4EE7E9.5030008@v.loewis.de>

> I'd like to see this in 3.2 release, of course.

As Brian already asserted: that's not feasible. I still haven't
managed to test your installer, and may not be able to for the
next few weeks. It's also against the policy for release candidates
to add such a change at this point. I believe the change, if
implemented, needs to be optional (which I believe your change is not).

Regards,
Martin


From solipsis at pitrou.net  Sun Feb  6 19:39:05 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Feb 2011 19:39:05 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for	non-committers.
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net> <4D4EE41D.30003@netwok.org>
Message-ID: <20110206193905.442ab7ce@pitrou.net>

On Sun, 06 Feb 2011 19:10:37 +0100
?ric Araujo <merwok at netwok.org> wrote:
> Le 06/02/2011 17:15, Antoine Pitrou a ?crit :
> > On Sun, 06 Feb 2011 02:10:15 +0100
> > brett.cannon <python-checkins at python.org> wrote:
> >>  To create your patch, you should generate a unified diff from your checkout's
> >>  top-level directory::
> >>  
> >> -    svn diff > patch.diff
> >> +    hg outgoing --path > patch.diff
> > 
> > Should be --patch.
> > The problem is that it will show one several patch per changeset, which
> > is normally not what you want (it's a pity "hg out" doesn't have an
> > option to collapse them all).
> 
> I suggest you request that feature upstream.
> 
> In the meantime, one can use hg diff -r $upstream-tip:tip to diff two
> anonymous branches.  Using a named branch or local tags helps
> identifying $upstream-tip.

Yes. But that's where we start advocating a particular local workflow
over another (why named branches rather than mercurial queues or
bookmarks, for example?). That's why I think that part of the devguide
should stick to a trivial SVN-like use, letting people learn about more
powerful options in other resources.

Regards

Antoine.




From brett at python.org  Sun Feb  6 21:13:08 2011
From: brett at python.org (Brett Cannon)
Date: Sun, 6 Feb 2011 12:13:08 -0800
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <20110206171542.3859df07@pitrou.net>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
Message-ID: <AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>

On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 06 Feb 2011 02:10:15 +0100
> brett.cannon <python-checkins at python.org> wrote:
>>
>> ?To create your patch, you should generate a unified diff from your checkout's
>> ?top-level directory::
>>
>> - ? ?svn diff > patch.diff
>> + ? ?hg outgoing --path > patch.diff
>
> Should be --patch.
> The problem is that it will show one several patch per changeset, which
> is normally not what you want (it's a pity "hg out" doesn't have an
> option to collapse them all).

Yeah, that is a perk of mq.

>
>> ?If your work needs some new files to be added to the source tree, remember
>> -to ``svn add`` them before generating the patch::
>> +to ``hg add`` them before generating the patch::
>>
>> - ? svn add Lib/newfile.py
>> - ? svn diff > patch.diff
>> + ? hg add Lib/newfile.py
>> + ? hg outgoing --patch > patch.diff
>
> You should commit before using "outgoing", otherwise the added file is
> not in the repo (and therefore not in the patch).
>
> The problem with hg (and other DVCSes) is that allows for *several*
> local workflows, and therefore it's harder to advocate one of them in
> such tutorial docs. I wonder what Georg and Dirkjan suggest.

Well, I wouldn't say harder. We just choose one we like the most and
advocate that while stating upfront this is just one of many different
ways someone can choose to work.

>
> We could perhaps present SVN-like "work in the working copy" workflow
> (without local commits), and let seasoned hg users choose other
> workflows they like more (they don't need our help anyway).

I would rather give people some simple workflow that has some benefit
over svn. Basically whatever is the easiest to comprehend and work
with should be what we start people with.

>
>> ?To undo a patch, you can revert **all** changes made in your checkout::
>>
>> - ? ?svn revert -R .
>> + ? ?hg revert --all
>> +
>
> Or "hg revert -a", which is nicer to type.

I prefer being explicit over implicit in the tutorial.

From brendan at kublai.com  Sun Feb  6 21:36:17 2011
From: brendan at kublai.com (Brendan Cully)
Date: Sun, 6 Feb 2011 12:36:17 -0800
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
Message-ID: <20110206203616.GA6168@zanzibar.quuxuum.com>

On Sunday, 06 February 2011 at 12:13, Brett Cannon wrote:
> On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Sun, 06 Feb 2011 02:10:15 +0100
> > brett.cannon <python-checkins at python.org> wrote:
> >>
> >> ?To create your patch, you should generate a unified diff from your checkout's
> >> ?top-level directory::
> >>
> >> - ? ?svn diff > patch.diff
> >> + ? ?hg outgoing --path > patch.diff
> >
> > Should be --patch.
> > The problem is that it will show one several patch per changeset, which
> > is normally not what you want (it's a pity "hg out" doesn't have an
> > option to collapse them all).
> 
> Yeah, that is a perk of mq.
> 
> >
> >> ?If your work needs some new files to be added to the source tree, remember
> >> -to ``svn add`` them before generating the patch::
> >> +to ``hg add`` them before generating the patch::
> >>
> >> - ? svn add Lib/newfile.py
> >> - ? svn diff > patch.diff
> >> + ? hg add Lib/newfile.py
> >> + ? hg outgoing --patch > patch.diff
> >
> > You should commit before using "outgoing", otherwise the added file is
> > not in the repo (and therefore not in the patch).
> >
> > The problem with hg (and other DVCSes) is that allows for *several*
> > local workflows, and therefore it's harder to advocate one of them in
> > such tutorial docs. I wonder what Georg and Dirkjan suggest.

I just happened to see this message and don't really know the
context -- you may not want to use any extensions here. But my 'rdiff'
extension does let you create diffs between your working directory and
upstream, and collapses your changesets into a single diff.

http://mercurial.selenic.com/wiki/RdiffExtension

From brett at python.org  Sun Feb  6 21:53:43 2011
From: brett at python.org (Brett Cannon)
Date: Sun, 6 Feb 2011 12:53:43 -0800
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <20110206203616.GA6168@zanzibar.quuxuum.com>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
	<20110206203616.GA6168@zanzibar.quuxuum.com>
Message-ID: <AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>

On Sun, Feb 6, 2011 at 12:36, Brendan Cully <brendan at kublai.com> wrote:
> On Sunday, 06 February 2011 at 12:13, Brett Cannon wrote:
>> On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > On Sun, 06 Feb 2011 02:10:15 +0100
>> > brett.cannon <python-checkins at python.org> wrote:
>> >>
>> >> ?To create your patch, you should generate a unified diff from your checkout's
>> >> ?top-level directory::
>> >>
>> >> - ? ?svn diff > patch.diff
>> >> + ? ?hg outgoing --path > patch.diff
>> >
>> > Should be --patch.
>> > The problem is that it will show one several patch per changeset, which
>> > is normally not what you want (it's a pity "hg out" doesn't have an
>> > option to collapse them all).
>>
>> Yeah, that is a perk of mq.
>>
>> >
>> >> ?If your work needs some new files to be added to the source tree, remember
>> >> -to ``svn add`` them before generating the patch::
>> >> +to ``hg add`` them before generating the patch::
>> >>
>> >> - ? svn add Lib/newfile.py
>> >> - ? svn diff > patch.diff
>> >> + ? hg add Lib/newfile.py
>> >> + ? hg outgoing --patch > patch.diff
>> >
>> > You should commit before using "outgoing", otherwise the added file is
>> > not in the repo (and therefore not in the patch).
>> >
>> > The problem with hg (and other DVCSes) is that allows for *several*
>> > local workflows, and therefore it's harder to advocate one of them in
>> > such tutorial docs. I wonder what Georg and Dirkjan suggest.
>
> I just happened to see this message and don't really know the
> context -- you may not want to use any extensions here. But my 'rdiff'
> extension does let you create diffs between your working directory and
> upstream, and collapses your changesets into a single diff.

I would rather not have new hg users have to install an extension just
to get a simple workflow going.

From ncoghlan at gmail.com  Mon Feb  7 00:21:02 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Feb 2011 09:21:02 +1000
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
	<20110206203616.GA6168@zanzibar.quuxuum.com>
	<AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>
Message-ID: <AANLkTikRs145Nznnc72ai5QTmO287bO+y7wEOUDoQ8Lh@mail.gmail.com>

On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon <brett at python.org> wrote:
> I would rather not have new hg users have to install an extension just
> to get a simple workflow going.

I may still keep my Rdiff-based FAQ entry around as an example of how
to get a collapsed diff regardless of personal workflow, though.

Installing Rdiff was actually pretty easy, and I get the impression
that becoming comfortable with adding the extensions that suit your
personal workflow is a key part in getting Mercurial to really work
for you. We won't do people any favours if we try to pretend that
isn't the case.

Cheers,
Nick.

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

From ncoghlan at gmail.com  Mon Feb  7 00:28:22 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Feb 2011 09:28:22 +1000
Subject: [Python-Dev] [Python-checkins] r88359 -
	python/branches/py3k/Doc/whatsnew/3.2.rst
In-Reply-To: <20110206200857.A3046EE98D@mail.python.org>
References: <20110206200857.A3046EE98D@mail.python.org>
Message-ID: <AANLkTin0-2OmgVVmbzri_UmuY6nkKCCra5WZcLGRPbtQ@mail.gmail.com>

On Mon, Feb 7, 2011 at 6:08 AM, raymond.hettinger
<python-checkins at python.org> wrote:
> +In addition, the :func:`~dis.dis` function now accepts string arguments
> +so that the common idiom ``dis(compile(s, '', 'eval'))`` can be shortened
> +to ``dis(compile(s))``::

That should be ``dis(s)``.

Cheers,
Nick.

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

From g.brandl at gmx.net  Mon Feb  7 13:25:26 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 07 Feb 2011 13:25:26 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <AANLkTikRs145Nznnc72ai5QTmO287bO+y7wEOUDoQ8Lh@mail.gmail.com>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>	<20110206171542.3859df07@pitrou.net>	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>	<20110206203616.GA6168@zanzibar.quuxuum.com>	<AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>
	<AANLkTikRs145Nznnc72ai5QTmO287bO+y7wEOUDoQ8Lh@mail.gmail.com>
Message-ID: <iioo1v$hm3$1@dough.gmane.org>

Am 07.02.2011 00:21, schrieb Nick Coghlan:
> On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon <brett at python.org> wrote:
>> I would rather not have new hg users have to install an extension just
>> to get a simple workflow going.
> 
> I may still keep my Rdiff-based FAQ entry around as an example of how
> to get a collapsed diff regardless of personal workflow, though.
> 
> Installing Rdiff was actually pretty easy, and I get the impression
> that becoming comfortable with adding the extensions that suit your
> personal workflow is a key part in getting Mercurial to really work
> for you. We won't do people any favours if we try to pretend that
> isn't the case.

This is quite true.  (And after a while, the same goes for creating your
own extensions, BTW.)

Georg


From g.brandl at gmx.net  Mon Feb  7 13:26:28 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 07 Feb 2011 13:26:28 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
Message-ID: <iioo3t$hm3$2@dough.gmane.org>

Am 06.02.2011 21:13, schrieb Brett Cannon:

>>>  To undo a patch, you can revert **all** changes made in your checkout::
>>>
>>> -    svn revert -R .
>>> +    hg revert --all
>>> +
>>
>> Or "hg revert -a", which is nicer to type.
> 
> I prefer being explicit over implicit in the tutorial.

BTW, the exact equivalent of "svn revert -R ." is "hg revert ."; the two
differ if you're not in the working dir root.

However, considering the preceding text, the SVN command was faulty in
the first place.

Georg


From fuzzyman at voidspace.org.uk  Mon Feb  7 14:27:31 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Feb 2011 13:27:31 +0000
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <iioo1v$hm3$1@dough.gmane.org>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>	<20110206171542.3859df07@pitrou.net>	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>	<20110206203616.GA6168@zanzibar.quuxuum.com>	<AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>	<AANLkTikRs145Nznnc72ai5QTmO287bO+y7wEOUDoQ8Lh@mail.gmail.com>
	<iioo1v$hm3$1@dough.gmane.org>
Message-ID: <4D4FF343.5030703@voidspace.org.uk>

On 07/02/2011 12:25, Georg Brandl wrote:
> Am 07.02.2011 00:21, schrieb Nick Coghlan:
>> On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon<brett at python.org>  wrote:
>>> I would rather not have new hg users have to install an extension just
>>> to get a simple workflow going.
>> I may still keep my Rdiff-based FAQ entry around as an example of how
>> to get a collapsed diff regardless of personal workflow, though.
>>
>> Installing Rdiff was actually pretty easy, and I get the impression
>> that becoming comfortable with adding the extensions that suit your
>> personal workflow is a key part in getting Mercurial to really work
>> for you. We won't do people any favours if we try to pretend that
>> isn't the case.
> This is quite true.  (And after a while, the same goes for creating your
> own extensions, BTW.)
>

And from the description it sounds like rdiff will be very useful for 
our usecase.

Michael

> 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 solipsis at pitrou.net  Mon Feb  7 15:24:59 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Feb 2011 15:24:59 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
	<iioo3t$hm3$2@dough.gmane.org>
Message-ID: <20110207152459.02cb2bcb@pitrou.net>

On Mon, 07 Feb 2011 13:26:28 +0100
Georg Brandl <g.brandl at gmx.net> wrote:
> Am 06.02.2011 21:13, schrieb Brett Cannon:
> 
> >>>  To undo a patch, you can revert **all** changes made in your checkout::
> >>>
> >>> -    svn revert -R .
> >>> +    hg revert --all
> >>> +
> >>
> >> Or "hg revert -a", which is nicer to type.
> > 
> > I prefer being explicit over implicit in the tutorial.
> 
> BTW, the exact equivalent of "svn revert -R ." is "hg revert ."; the two
> differ if you're not in the working dir root.

Using hg commands from somewhere else that the dir root is too
confusing. Sometimes they display WC-relative paths, sometimes they
display current dir-relative paths. I would not recommend it.

Regards

Antoine.



From solipsis at pitrou.net  Mon Feb  7 15:28:00 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Feb 2011 15:28:00 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
	<20110206203616.GA6168@zanzibar.quuxuum.com>
	<AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>
	<AANLkTikRs145Nznnc72ai5QTmO287bO+y7wEOUDoQ8Lh@mail.gmail.com>
	<iioo1v$hm3$1@dough.gmane.org> <4D4FF343.5030703@voidspace.org.uk>
Message-ID: <20110207152800.67e05fd9@pitrou.net>

On Mon, 07 Feb 2011 13:27:31 +0000
Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 07/02/2011 12:25, Georg Brandl wrote:
> > Am 07.02.2011 00:21, schrieb Nick Coghlan:
> >> On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon<brett at python.org>  wrote:
> >>> I would rather not have new hg users have to install an extension just
> >>> to get a simple workflow going.
> >> I may still keep my Rdiff-based FAQ entry around as an example of how
> >> to get a collapsed diff regardless of personal workflow, though.
> >>
> >> Installing Rdiff was actually pretty easy, and I get the impression
> >> that becoming comfortable with adding the extensions that suit your
> >> personal workflow is a key part in getting Mercurial to really work
> >> for you. We won't do people any favours if we try to pretend that
> >> isn't the case.
> > This is quite true.  (And after a while, the same goes for creating your
> > own extensions, BTW.)
> >
> 
> And from the description it sounds like rdiff will be very useful for 
> our usecase.

I'm not sure it is really. When you commit multiple changesets
locally you really want to use something like named branches or mq to
track them. Advocating rdiff is advocating something SVN-like, it's not
very helpful IMO.

Regards

Antoine.



From fuzzyman at voidspace.org.uk  Mon Feb  7 15:34:35 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 07 Feb 2011 14:34:35 +0000
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <20110207152800.67e05fd9@pitrou.net>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>	<20110206171542.3859df07@pitrou.net>	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>	<20110206203616.GA6168@zanzibar.quuxuum.com>	<AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>	<AANLkTikRs145Nznnc72ai5QTmO287bO+y7wEOUDoQ8Lh@mail.gmail.com>	<iioo1v$hm3$1@dough.gmane.org>
	<4D4FF343.5030703@voidspace.org.uk>
	<20110207152800.67e05fd9@pitrou.net>
Message-ID: <4D5002FB.2050504@voidspace.org.uk>

On 07/02/2011 14:28, Antoine Pitrou wrote:
> On Mon, 07 Feb 2011 13:27:31 +0000
> Michael Foord<fuzzyman at voidspace.org.uk>  wrote:
>> On 07/02/2011 12:25, Georg Brandl wrote:
>>> Am 07.02.2011 00:21, schrieb Nick Coghlan:
>>>> On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon<brett at python.org>   wrote:
>>>>> I would rather not have new hg users have to install an extension just
>>>>> to get a simple workflow going.
>>>> I may still keep my Rdiff-based FAQ entry around as an example of how
>>>> to get a collapsed diff regardless of personal workflow, though.
>>>>
>>>> Installing Rdiff was actually pretty easy, and I get the impression
>>>> that becoming comfortable with adding the extensions that suit your
>>>> personal workflow is a key part in getting Mercurial to really work
>>>> for you. We won't do people any favours if we try to pretend that
>>>> isn't the case.
>>> This is quite true.  (And after a while, the same goes for creating your
>>> own extensions, BTW.)
>>>
>> And from the description it sounds like rdiff will be very useful for
>> our usecase.
> I'm not sure it is really. When you commit multiple changesets
> locally you really want to use something like named branches or mq to
> track them. Advocating rdiff is advocating something SVN-like, it's not
> very helpful IMO.
>

Although often you want to merge in a single commit and erase the commit 
history of the branch you worked in (as discussed previously). So are 
you advocating rebasing before merge as the alternative?

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  Mon Feb  7 15:46:45 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Feb 2011 15:46:45 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <4D5002FB.2050504@voidspace.org.uk>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
	<20110206203616.GA6168@zanzibar.quuxuum.com>
	<AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>
	<AANLkTikRs145Nznnc72ai5QTmO287bO+y7wEOUDoQ8Lh@mail.gmail.com>
	<iioo1v$hm3$1@dough.gmane.org> <4D4FF343.5030703@voidspace.org.uk>
	<20110207152800.67e05fd9@pitrou.net>
	<4D5002FB.2050504@voidspace.org.uk>
Message-ID: <20110207154645.790d02a6@pitrou.net>

On Mon, 07 Feb 2011 14:34:35 +0000
Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> >>>
> >> And from the description it sounds like rdiff will be very useful for
> >> our usecase.
> > I'm not sure it is really. When you commit multiple changesets
> > locally you really want to use something like named branches or mq to
> > track them. Advocating rdiff is advocating something SVN-like, it's not
> > very helpful IMO.
> >
> 
> Although often you want to merge in a single commit and erase the commit 
> history of the branch you worked in (as discussed previously).

Yes, but apparently rdiff compares the *working copy* rather than the
local repository. Also, AFAIU rdiff will compare against the tip of the
remote, which is probably not what you based your work on. And if you
have to specify revisions by hand, it kind of defeats the point (you
want hg to track changes by itself, which is why you want to use one
of named branches / bookmarks / mq / etc.).

> So are 
> you advocating rebasing before merge as the alternative?

I'm not advocating anything in particular really. I think creating a
named branch "foo" (or a bookmark? I've never used them but it sounds
like they might do the trick) and then using "hg di -r py3k" to get the
diff against upstream is very reasonable. That's without any hg
extension activated.

Throwaway clones are good too, since they avoid the issues with
"rebasing" or "erasing commit history".

But if we suggest people use some extension, I'd rather see us advocate
mq (or shelve or any equivalent) rather than something low-level such
as rdiff.

Regards

Antoine.

From dirkjan at ochtman.nl  Mon Feb  7 15:54:31 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Mon, 7 Feb 2011 15:54:31 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <20110207154645.790d02a6@pitrou.net>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
	<20110206203616.GA6168@zanzibar.quuxuum.com>
	<AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>
	<AANLkTikRs145Nznnc72ai5QTmO287bO+y7wEOUDoQ8Lh@mail.gmail.com>
	<iioo1v$hm3$1@dough.gmane.org> <4D4FF343.5030703@voidspace.org.uk>
	<20110207152800.67e05fd9@pitrou.net>
	<4D5002FB.2050504@voidspace.org.uk>
	<20110207154645.790d02a6@pitrou.net>
Message-ID: <AANLkTik7O=wLhRb6XjL-RrzhJJ7K3+Xn66go5wOThCsw@mail.gmail.com>

On Mon, Feb 7, 2011 at 15:46, Antoine Pitrou <solipsis at pitrou.net> wrote:
> I'm not advocating anything in particular really. I think creating a
> named branch "foo" (or a bookmark? I've never used them but it sounds
> like they might do the trick) and then using "hg di -r py3k" to get the
> diff against upstream is very reasonable. That's without any hg
> extension activated.

Yeah, I don't think we need rdiff. IIRC it isn't really maintained,
either, just the basics to keep it working with new versions of hg.

Cheers,

Dirkjan

From brendan at kublai.com  Mon Feb  7 15:58:47 2011
From: brendan at kublai.com (Brendan Cully)
Date: Mon, 7 Feb 2011 06:58:47 -0800
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <20110207154645.790d02a6@pitrou.net>
References: <20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
	<20110206203616.GA6168@zanzibar.quuxuum.com>
	<AANLkTik0F1t6Z0e_qVEr9QC6VadXm6xSg2Fjd+7Y79=D@mail.gmail.com>
	<AANLkTikRs145Nznnc72ai5QTmO287bO+y7wEOUDoQ8Lh@mail.gmail.com>
	<iioo1v$hm3$1@dough.gmane.org> <4D4FF343.5030703@voidspace.org.uk>
	<20110207152800.67e05fd9@pitrou.net>
	<4D5002FB.2050504@voidspace.org.uk>
	<20110207154645.790d02a6@pitrou.net>
Message-ID: <20110207145846.GA18266@zanzibar.quuxuum.com>

On Monday, 07 February 2011 at 15:46, Antoine Pitrou wrote:
> On Mon, 07 Feb 2011 14:34:35 +0000
> Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> > >>>
> > >> And from the description it sounds like rdiff will be very useful for
> > >> our usecase.
> > > I'm not sure it is really. When you commit multiple changesets
> > > locally you really want to use something like named branches or mq to
> > > track them. Advocating rdiff is advocating something SVN-like, it's not
> > > very helpful IMO.
> > >
> > 
> > Although often you want to merge in a single commit and erase the commit 
> > history of the branch you worked in (as discussed previously).
> 
> Yes, but apparently rdiff compares the *working copy* rather than the
> local repository. Also, AFAIU rdiff will compare against the tip of the

Rdiff is meant to make diff work against remote repositories the way
it already does on local ones. So it *can* produce a diff between the
working directory and a remote revision, just as regular diff can do
for a local revision. But it can also produce diffs between any local
revision and any remote revision.

> remote, which is probably not what you based your work on. And if you

If you're talking about named branches, I think I agree (rdiff
predates a lot of the work done in hg to support named branches). I
assume you think the right target is the most recent remote revision
on the named branch you're working against? (rdiff does accept
symbolic names for remote revisions, including branch names)

> have to specify revisions by hand, it kind of defeats the point (you
> want hg to track changes by itself, which is why you want to use one
> of named branches / bookmarks / mq / etc.).

rdiff is somewhat orthogonal to bookmarks/mq/etc. It's really just a
convenient wrapper for outgoing.

From ethan at stoneleaf.us  Mon Feb  7 21:16:35 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 07 Feb 2011 12:16:35 -0800
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
 Windows
In-Reply-To: <4D4EBDC7.9000301@simplistix.co.uk>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>	<4D431724.4010002@voidspace.org.uk>	<4D4C3AB9.3020300@simplistix.co.uk>	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>	<AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>	<4D4EBCC4.1090003@simplistix.co.uk>	<AANLkTinhzYMo7PJJv8ZwPtc_BDbMELvKgKdPy6QSNm8d@mail.gmail.com>
	<4D4EBDC7.9000301@simplistix.co.uk>
Message-ID: <4D505323.5020909@stoneleaf.us>

Chris Withers wrote:
> On 06/02/2011 15:25, Brian Curtin wrote:
>> So put the new path before the old path, or replace it? The current
>> patch appends to the end.
> 
> I believe the last path wins in Windows land, so that would be fine.

Actually, first one wins, as Windows starts at the beginning and stops 
looking once it finds a match.

~Ethan~


From wesleymesquita at gmail.com  Mon Feb  7 23:38:28 2011
From: wesleymesquita at gmail.com (Wesley Mesquita)
Date: Mon, 7 Feb 2011 20:38:28 -0200
Subject: [Python-Dev] Python Unit Tests
Message-ID: <AANLkTi=btEr1bRKq=LL6qS9qcSctggz6WNA1OXVjpAa4@mail.gmail.com>

Hi all,

I starting to explore python 3k core development environment. So, sorry in
advance for any mistakes, but I really don't know what is the best list to
post this, since it not a "use of python" issue, and probably is not a dev
issue, it is more like a "dev env" question.

I have ran the test suit, and got the messages below.

~/python_dev/python$ make testall

./python -Wd -E -bb  ./Lib/test/regrtest.py -uall -l
== CPython 3.2rc2+ (py3k:88376, Feb 7 2011, 18:31:28) [GCC 4.4.5]
==   Linux-2.6.35-24-generic-x86_64-with-debian-squeeze-sid little-endian
==   /home/wesley/python_dev/python/build/test_python_3387
Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0,
interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0,
ignore_environment=1, verbose=0, bytes_warning=2, quiet=0)

[...]

[198/349] test_ossaudiodev
test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp'

[...]

[200/349] test_parser
Expecting 's_push: parser stack overflow' in next line
s_push: parser stack overflow

[...]

[321/349] test_urllib2net
/home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
<socket.socket object, fd=8, family=2, type=2049, proto=6>
  self._sock = None
/home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning:
unclosed <socket.socket object, fd=7, family=2, type=2049, proto=6>
  sys.exc_info()[2])
/home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning:
unclosed <socket.socket object, fd=8, family=2, type=2049, proto=6>
  sys.exc_info()[2])
/home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
<socket.socket object, fd=8, family=2, type=1, proto=6>
  self._sock = None
/home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
<socket.socket object, fd=9, family=2, type=1, proto=6>
  self._sock = None
/home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
<socket.socket object, fd=9, family=2, type=2049, proto=6>
  self._sock = None
/home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
<socket.socket object, fd=7, family=2, type=2049, proto=6>
  self._sock = None
[323/349] test_urllibnet
/home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
<socket.socket object, fd=7, family=2, type=1, proto=6>
  self._sock = None


24 tests skipped:
    test_bz2 test_curses test_dbm_gnu test_dbm_ndbm test_gdb
    test_kqueue test_ossaudiodev test_readline test_smtpnet
    test_socketserver test_sqlite test_ssl test_startfile test_tcl
    test_timeout test_tk test_ttk_guionly test_ttk_textonly
    test_urllib2net test_urllibnet test_winreg test_winsound
    test_xmlrpc_net test_zipfile64
9 skips unexpected on linux2:
    test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl
    test_tcl test_tk test_ttk_guionly test_ttk_textonly
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null'
mode='a' encoding='UTF-8'>


But running each of them individually:

:~/python_dev/python$ ./python Lib/test/regrtest.py  test_ossaudiodev
[1/1] test_ossaudiodev
test_ossaudiodev skipped -- Use of the `audio' resource not enabled
1 test skipped:
    test_ossaudiodev
Those skips are all expected on linux2.

./python Lib/test/regrtest.py test_parser
[1/1] test_parser
Expecting 's_push: parser stack overflow' in next line
s_push: parser stack overflow
1 test OK.

./python Lib/test/regrtest.py test_urllib2net[1/1] test_urllib2net
test_urllib2net skipped -- Use of the `network' resource not enabled
1 test skipped:
    test_urllib2net
Those skips are all expected on linux2.

Is there any reason for the different results?

Regards,

Wesley

-- 
Wesley Mesquita
Computer Engineer
http://www.wesleymesquita.com
Mobile: +55 11 95249272
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110207/a93ef776/attachment-0001.html>

From rdmurray at bitdance.com  Tue Feb  8 02:00:49 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 07 Feb 2011 20:00:49 -0500
Subject: [Python-Dev] Python Unit Tests
In-Reply-To: <AANLkTi=btEr1bRKq=LL6qS9qcSctggz6WNA1OXVjpAa4@mail.gmail.com>
References: <AANLkTi=btEr1bRKq=LL6qS9qcSctggz6WNA1OXVjpAa4@mail.gmail.com>
Message-ID: <20110208010049.52B58225404@kimball.webabinitio.net>

On Mon, 07 Feb 2011 20:38:28 -0200, Wesley Mesquita <wesleymesquita at gmail.com> wrote:
> [198/349] test_ossaudiodev
> test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp'

This is normal since you don't have a /dev/dsp.  That's what the
skip message means.

> [200/349] test_parser
> Expecting 's_push: parser stack overflow' in next line
> s_push: parser stack overflow

"Expecting" means the next message is expected.  Someone should
probably check to see if this test can (in Python3) be rewritten so that
message isn't generated, but for now it is Expected and completely
normal.

> [321/349] test_urllib2net
> /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
> <socket.socket object, fd=8, family=2, type=2049, proto=6>
>   self._sock = None

There are some ResourceWarnings we haven't cured yet (the ResourceWarning is
a fairly new innovation).  I'm not sure why they don't show up when
you run the tests individually.

> 9 skips unexpected on linux2:
>     test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl
>     test_tcl test_tk test_ttk_guionly test_ttk_textonly

These would be because you don't have the correct system/development
libraries installed for bz2, gnudbm, ndbm, readline, openssl,
tcl, and tk when you compiled your Python.  So, these skips are
actually expected if you don't have those libraries, but if you want
a complete development/test environment you should install the
necessary packages and recompile.

I imagine at least some of this is already covered in the dev guide
(I haven't made time to review it yet).  If any of it is unclear
to you, please provide feedback so we can improve the guide (which
is new).

--
R. David Murray                                      www.bitdance.com

From mal at egenix.com  Tue Feb  8 09:32:50 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 08 Feb 2011 09:32:50 +0100
Subject: [Python-Dev] Python Unit Tests
In-Reply-To: <AANLkTi=btEr1bRKq=LL6qS9qcSctggz6WNA1OXVjpAa4@mail.gmail.com>
References: <AANLkTi=btEr1bRKq=LL6qS9qcSctggz6WNA1OXVjpAa4@mail.gmail.com>
Message-ID: <4D50FFB2.8070209@egenix.com>

Wesley Mesquita wrote:
> Hi all,
> 
> I starting to explore python 3k core development environment. So, sorry in
> advance for any mistakes, but I really don't know what is the best list to
> post this, since it not a "use of python" issue, and probably is not a dev
> issue, it is more like a "dev env" question.
> 
> I have ran the test suit, and got the messages below.
> 
> ~/python_dev/python$ make testall
> 
> ./python -Wd -E -bb  ./Lib/test/regrtest.py -uall -l
> == CPython 3.2rc2+ (py3k:88376, Feb 7 2011, 18:31:28) [GCC 4.4.5]
> ==   Linux-2.6.35-24-generic-x86_64-with-debian-squeeze-sid little-endian
> ==   /home/wesley/python_dev/python/build/test_python_3387
> Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0,
> interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0,
> ignore_environment=1, verbose=0, bytes_warning=2, quiet=0)
> 
> [...]
> 
> [198/349] test_ossaudiodev
> test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp'
> 
> [...]
> 
> [200/349] test_parser
> Expecting 's_push: parser stack overflow' in next line
> s_push: parser stack overflow
> 
> [...]
> 
> [321/349] test_urllib2net
> /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
> <socket.socket object, fd=8, family=2, type=2049, proto=6>
>   self._sock = None
> /home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning:
> unclosed <socket.socket object, fd=7, family=2, type=2049, proto=6>
>   sys.exc_info()[2])
> /home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning:
> unclosed <socket.socket object, fd=8, family=2, type=2049, proto=6>
>   sys.exc_info()[2])
> /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
> <socket.socket object, fd=8, family=2, type=1, proto=6>
>   self._sock = None
> /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
> <socket.socket object, fd=9, family=2, type=1, proto=6>
>   self._sock = None
> /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
> <socket.socket object, fd=9, family=2, type=2049, proto=6>
>   self._sock = None
> /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
> <socket.socket object, fd=7, family=2, type=2049, proto=6>
>   self._sock = None
> [323/349] test_urllibnet
> /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed
> <socket.socket object, fd=7, family=2, type=1, proto=6>
>   self._sock = None
> 
> 
> 24 tests skipped:
>     test_bz2 test_curses test_dbm_gnu test_dbm_ndbm test_gdb
>     test_kqueue test_ossaudiodev test_readline test_smtpnet
>     test_socketserver test_sqlite test_ssl test_startfile test_tcl
>     test_timeout test_tk test_ttk_guionly test_ttk_textonly
>     test_urllib2net test_urllibnet test_winreg test_winsound
>     test_xmlrpc_net test_zipfile64
> 9 skips unexpected on linux2:
>     test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl
>     test_tcl test_tk test_ttk_guionly test_ttk_textonly
> sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null'
> mode='a' encoding='UTF-8'>
> 
> 
> But running each of them individually:
> 
> :~/python_dev/python$ ./python Lib/test/regrtest.py  test_ossaudiodev
> [1/1] test_ossaudiodev
> test_ossaudiodev skipped -- Use of the `audio' resource not enabled
> 1 test skipped:
>     test_ossaudiodev
> Those skips are all expected on linux2.
> 
> ./python Lib/test/regrtest.py test_parser
> [1/1] test_parser
> Expecting 's_push: parser stack overflow' in next line
> s_push: parser stack overflow
> 1 test OK.
> 
> ./python Lib/test/regrtest.py test_urllib2net[1/1] test_urllib2net
> test_urllib2net skipped -- Use of the `network' resource not enabled
> 1 test skipped:
>     test_urllib2net
> Those skips are all expected on linux2.
> 
> Is there any reason for the different results?

Yes: you are not using the same options on the stand-alone
tests as you are on the suite run. Most importantly, you
are not enabling all resources (-uall).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 08 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 solipsis at pitrou.net  Tue Feb  8 14:26:59 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 8 Feb 2011 14:26:59 +0100
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
Message-ID: <20110208142659.07f8b515@pitrou.net>

On Sun, 6 Feb 2011 12:13:08 -0800
Brett Cannon <brett at python.org> wrote:
> >
> > We could perhaps present SVN-like "work in the working copy" workflow
> > (without local commits), and let seasoned hg users choose other
> > workflows they like more (they don't need our help anyway).
> 
> I would rather give people some simple workflow that has some benefit
> over svn. Basically whatever is the easiest to comprehend and work
> with should be what we start people with.

Ok, I've updated the devguide to present a simple named branch-based
approach. I'm not sure it is our job to *explain* hg features, so I've
just given a couple of minimal instructions to get people on track.

Regards

Antoine.

From ncoghlan at gmail.com  Tue Feb  8 15:17:51 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 9 Feb 2011 00:17:51 +1000
Subject: [Python-Dev] Python Unit Tests
In-Reply-To: <20110208010049.52B58225404@kimball.webabinitio.net>
References: <AANLkTi=btEr1bRKq=LL6qS9qcSctggz6WNA1OXVjpAa4@mail.gmail.com>
	<20110208010049.52B58225404@kimball.webabinitio.net>
Message-ID: <AANLkTimSXQ5mcSUWSVmw0MgtrWUYM904HHPKk61jsJiY@mail.gmail.com>

On Tue, Feb 8, 2011 at 11:00 AM, R. David Murray <rdmurray at bitdance.com> wrote:
> There are some ResourceWarnings we haven't cured yet (the ResourceWarning is
> a fairly new innovation). ?I'm not sure why they don't show up when
> you run the tests individually.

Almost certainly the missing "-uall" meant the relevant tests didn't
actually run the second time around.

>> 9 skips unexpected on linux2:
>> ? ? test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl
>> ? ? test_tcl test_tk test_ttk_guionly test_ttk_textonly
>
> These would be because you don't have the correct system/development
> libraries installed for bz2, gnudbm, ndbm, readline, openssl,
> tcl, and tk when you compiled your Python. ?So, these skips are
> actually expected if you don't have those libraries, but if you want
> a complete development/test environment you should install the
> necessary packages and recompile.

I put together a list a while back of the minimal set of dev packages
needed to do a full Python build on Kubuntu:
http://www.boredomandlaziness.org/2010/01/kubuntu-dev-packages-to-build-python.html

The apt-get build dependencies command added as a comment to that post
should work on any apt-based Linux variant (although, at least on
Kubuntu, it brings down quite a lot of stuff you don't actually need
in order to build Python). Presumably there's something similar
available for other packaging systems (if not, the minimal package
list may still provide a useful starting point)

I don't believe anything that platform specific is in the dev guide,
though (it wasn't in the old README files, that's why I made my own
list for later reference).

Cheers,
Nick.

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

From guido at python.org  Tue Feb  8 19:15:54 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Feb 2011 10:15:54 -0800
Subject: [Python-Dev] http://www.pythonlabs.com/logos.html is gone
In-Reply-To: <hatgav$t8m$1@ger.gmane.org>
References: <hatdd2$kpo$1@ger.gmane.org>
	<ca471dc20910111321ia683d29naae39a3192fffaed@mail.gmail.com>
	<hatgav$t8m$1@ger.gmane.org>
Message-ID: <AANLkTi=x6ujhtSiFzWX+oaXcC4WjZEgmUpJP-djPCzOg@mail.gmail.com>

As a late follow-up to this thread, I still get a bunch of hits a day
on this URL (and also on www.pythonlabs.com/talks.html -- I have no
idea what popular page *that* is still linked from).

I don't suppose we can *ever* delete that link from the LICENSE file?

On Sun, Oct 11, 2009 at 1:46 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> Guido van Rossum schrieb:
>> On Sun, Oct 11, 2009 at 12:55 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>>> Which I noticed since it's cited in the BeOpen license we still refer
>>> to in LICENSE. ?Since pythonlabs.com itself is still up, it probably
>>> isn't much work to make the logos.html URI work again, but I don't know
>>> who maintains that page.
>>
>> I own the domain. I don't know what was on logos.html and
>> http://web.archive.org won't show it to me because of a robots.txt
>> file. I think it's fine to let it be a 404.
>
> Okay. ?Though I am fairly sure that Tim *would* remember ;)
>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> _______________________________________________
> 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 brett at python.org  Tue Feb  8 19:33:05 2011
From: brett at python.org (Brett Cannon)
Date: Tue, 8 Feb 2011 10:33:05 -0800
Subject: [Python-Dev] devguide: Basic instructions on how to generate a
 patch with hg for non-committers.
In-Reply-To: <20110208142659.07f8b515@pitrou.net>
References: <E1Plt8p-0000pM-QA@dinsdale.python.org>
	<20110206171542.3859df07@pitrou.net>
	<AANLkTimtuJ6u+AAutthQquOrGGxUNudMihNfmbPHR4sk@mail.gmail.com>
	<20110208142659.07f8b515@pitrou.net>
Message-ID: <AANLkTinL3oOH4h7FtmkU_dNVRhaUGF3fkbVTv6FcdtW5@mail.gmail.com>

On Tue, Feb 8, 2011 at 05:26, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 6 Feb 2011 12:13:08 -0800
> Brett Cannon <brett at python.org> wrote:
>> >
>> > We could perhaps present SVN-like "work in the working copy" workflow
>> > (without local commits), and let seasoned hg users choose other
>> > workflows they like more (they don't need our help anyway).
>>
>> I would rather give people some simple workflow that has some benefit
>> over svn. Basically whatever is the easiest to comprehend and work
>> with should be what we start people with.
>
> Ok, I've updated the devguide to present a simple named branch-based
> approach. I'm not sure it is our job to *explain* hg features, so I've
> just given a couple of minimal instructions to get people on track.

Yep, what you wrote is what I was thinking. Enough so people can get
up and going and at least a taste of what hg can do for them w/o
devolving into an hg tutorial.

-Brett

>
> 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/brett%40python.org
>

From brett at python.org  Wed Feb  9 01:53:43 2011
From: brett at python.org (Brett Cannon)
Date: Tue, 8 Feb 2011 16:53:43 -0800
Subject: [Python-Dev] [Python-checkins] devguide: Try to explain the two
 most common approaches to hg workflow: feature
In-Reply-To: <4D51C335.10306@udel.edu>
References: <E1Pmvte-0003Uw-Rt@dinsdale.python.org> <4D51C335.10306@udel.edu>
Message-ID: <AANLkTikav-OZTVo6dwbwWSfBNM3=DUbQN-5NVONPZm03@mail.gmail.com>

fixed

On Tue, Feb 8, 2011 at 14:27, Terry Reedy <tjreedy at udel.edu> wrote:
>
>> +While non-committers can use named branches without issue, as a core
>> developer
>> +you should limit their use to only those branches to be used to
>> collaborate
>
> either /their/your/
> or /as a core developer you/core developers/
> I prefer latter as parallel to 'non-committers'.
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>

From marks at dcs.gla.ac.uk  Wed Feb  9 10:09:08 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Wed, 09 Feb 2011 09:09:08 +0000
Subject: [Python-Dev] API bloat
Message-ID: <4D5259B4.8030205@dcs.gla.ac.uk>

At sometime between versions 3.1 and the current version, 3.1.3,
the API  grew considerably.
See
http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling
and
http://docs.python.org/py3k/c-api/exceptions.html#exception-handling

The Unicode Exception Objects section is new and seemingly redundant:
http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
Should this be in the public API?

Is there any kind of review system (like PEPs) for modifying the C API?

Are bug-fix updates really the place to modify the API?

Could the API be reverted to the 3.1 version plus any *necessary* 
changes in time for the 3.2 release?

Remember the C API is a promise to support these functions for years to 
come and a burden on other implementations, including future CPythons.

So could the CPython internal APIs be kept out of the public API?
Please.

Cheers,
Mark.

From g.brandl at gmx.net  Wed Feb  9 10:44:49 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 09 Feb 2011 10:44:49 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D5259B4.8030205@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk>
Message-ID: <iitn7u$tpj$1@dough.gmane.org>

Am 09.02.2011 10:09, schrieb Mark Shannon:
> At sometime between versions 3.1 and the current version, 3.1.3,
> the API  grew considerably.
> See
> http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling
> and
> http://docs.python.org/py3k/c-api/exceptions.html#exception-handling
> 
> The Unicode Exception Objects section is new and seemingly redundant:

Why redundant?

> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
> Should this be in the public API?

While this question is valid, it *should* have been asked 8 years ago, when
the functions were actually added.

They are new in the docs because they weren't documented before.  Otherwise
they would have a "New in version 3.2" tag.

> Is there any kind of review system (like PEPs) for modifying the C API?

No, but python-dev is involved by either a thread here or an issue that
is then OK'd by several developers.

> Are bug-fix updates really the place to modify the API?

No, but that's not relevant here.

> Could the API be reverted to the 3.1 version plus any *necessary* 
> changes in time for the 3.2 release?

Any changes in API are definitely forbidden before 3.2.

Georg


From marks at dcs.gla.ac.uk  Wed Feb  9 11:37:11 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Wed, 09 Feb 2011 10:37:11 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <iitn7u$tpj$1@dough.gmane.org>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
Message-ID: <4D526E57.9030206@dcs.gla.ac.uk>

Georg Brandl wrote:
> Am 09.02.2011 10:09, schrieb Mark Shannon:
>> At sometime between versions 3.1 and the current version, 3.1.3,
>> the API  grew considerably.
>> See
>> http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling
>> and
>> http://docs.python.org/py3k/c-api/exceptions.html#exception-handling
>>
>> The Unicode Exception Objects section is new and seemingly redundant:
> 
> Why redundant?

Because they are all attribute getter and setters. For example:

PyUnicodeDecodeError_GetStart(exc, x) <=>
PyObject_GetAttr(exc, "start", x)

This sort of redundancy seems sensible for list, tuple and such.
It just seems like bloat for classes like UnicodeDecodeError.

> 
>> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
>> Should this be in the public API?
> 
> While this question is valid, it *should* have been asked 8 years ago, when
> the functions were actually added.

The functions may have been add to CPython 8 years ago, but they were
added to the API when they appeared in the docs, between 3.1 and 3.1.3.

How is the API defined, if not by the documentation?
The header files do not specify what is API and what is implementation
specific.

> 
> They are new in the docs because they weren't documented before.  Otherwise
> they would have a "New in version 3.2" tag.
> 
>> Is there any kind of review system (like PEPs) for modifying the C API?
> 
> No, but python-dev is involved by either a thread here or an issue that
> is then OK'd by several developers.
> 
>> Are bug-fix updates really the place to modify the API?
> 
> No, but that's not relevant here.
> 
>> Could the API be reverted to the 3.1 version plus any *necessary* 
>> changes in time for the 3.2 release?
> 
> Any changes in API are definitely forbidden before 3.2.

If that is the case then the API, as defined by
http://docs.python.org/py3k/c-api/index.html
should be same for 3.2 as for 3.1, plus a few functions,
that are explicitly marked as "New in version 3.2".

Unfortunately, that is not currently the case.

> 
> 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/marks%40dcs.gla.ac.uk
> 



From georg at python.org  Wed Feb  9 11:49:34 2011
From: georg at python.org (Georg Brandl)
Date: Wed, 09 Feb 2011 11:49:34 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D5266B0.6030701@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D5266B0.6030701@dcs.gla.ac.uk>
Message-ID: <4D52713E.5040405@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(Not sure if your message went to python-dev too.)

Am 09.02.2011 11:04, schrieb Mark Shannon:
> Georg Brandl wrote:
>> Am 09.02.2011 10:09, schrieb Mark Shannon:
>>> At sometime between versions 3.1 and the current version, 3.1.3,
>>> the API  grew considerably.
>>> See
>>> http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling
>>> and
>>> http://docs.python.org/py3k/c-api/exceptions.html#exception-handling
>>>
>>> The Unicode Exception Objects section is new and seemingly redundant:
>> 
>> Why redundant?
> 
> Because they are all attribute getter and setters. For example:
> 
> PyUnicodeDecodeError_GetStart(exc, x) <=>
> PyObject_GetAttr(exc, "start", x)
> 
> This sort of redundancy seems sensible for list, tuple and such.
> It just seems like bloat for classes like UnicodeDecodeError.

Have you looked at the implementation?  They do some more, e.g. make sure the
returned value is within the boundaries of the offending string.  (Yes, that
probably should be in the docs too.)

>>> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
>>> Should this be in the public API?
>> 
>> While this question is valid, it *should* have been asked 8 years ago, when
>> the functions were actually added.
> 
> The functions may have been add to CPython 8 years ago, but they were 
> added to the API when they appeared in the docs, between 3.1 and 3.1.3.
>
> How is the API defined, if not by the documentation?
> The header files do not specify what is API and what is implementation 
> specific.

The API is defined by all functions (and macros, and types) defined by the
headers starting with a "Py" prefix.  Implementation specific functions have
a "_Py" prefix.

- From 3.2, we also have a "Limited API" (see PEP 384) that defines a set of
API that will not change, and is guaranteed to have a consistent ABI between
Python minor versions.

>>> Could the API be reverted to the 3.1 version plus any *necessary* 
>>> changes in time for the 3.2 release?
>> 
>> Any changes in API are definitely forbidden before 3.2.
> 
> If that is the case then the API, as defined by
> http://docs.python.org/py3k/c-api/index.html
> should be same for 3.2 as for 3.1, plus a few functions,
> that are explicitly marked as "New in version 3.2".
> 
> Unfortunately, that is not currently the case.

In any case, these are doc bugs.  In the past, many additions to the C API
were made without proper documentation changes, and we are still working
to clean this up.

So, yes: modulo doc bugs, any function that newly appears in the 3.2 docs
either has a "New in version 3.2" tag, or has been present in 3.1 already.

Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk1ScT4ACgkQN9GcIYhpnLDEjwCggMLnpWoeL7Vpg3SiZlfJvJ0H
2isAn0hhBmbUelr4Of+kAqPopWc5s5ro
=xYhv
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Wed Feb  9 11:56:00 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 9 Feb 2011 11:56:00 +0100
Subject: [Python-Dev] API bloat
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk>
Message-ID: <20110209115600.39719cd3@pitrou.net>

On Wed, 09 Feb 2011 10:37:11 +0000
Mark Shannon <marks at dcs.gla.ac.uk> wrote:
> > 
> > Why redundant?
> 
> Because they are all attribute getter and setters. For example:
> 
> PyUnicodeDecodeError_GetStart(exc, x) <=>
> PyObject_GetAttr(exc, "start", x)
> 
> This sort of redundancy seems sensible for list, tuple and such.
> It just seems like bloat for classes like UnicodeDecodeError.

It's not exactly the same thing, still. PyObject_GetAttr()
will do a full blown attribute access, while I guess (I didn't check) 
PyUnicodeDecodeError_GetStart() accesses the C struct member directly.

Also, the latter gives you a Py_ssize_t object, which relieves you from
having to do a conversion explicitly.

I do agree that it doesn't seem widely used, according to Google Code
Search :)

> >> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
> >> Should this be in the public API?
> > 
> > While this question is valid, it *should* have been asked 8 years ago, when
> > the functions were actually added.
> 
> The functions may have been add to CPython 8 years ago, but they were
> added to the API when they appeared in the docs, between 3.1 and 3.1.3.
> 
> How is the API defined, if not by the documentation?
> The header files do not specify what is API and what is implementation
> specific.

True. But if they were added to the documentation, it's certainly
because they were *intended* to be part of the API from the start.
(after all, core CPython code can just access the C struct fields
directly rather than go through a function call)

Take it as acknowledging that it has *always* been part of the intended
API.

These days, we try to follow a stricter naming convention: when we want
an API to remain explicitly private, we often prefix it with an
underscore. But that has not been the case in the past, I admit.

> > Any changes in API are definitely forbidden before 3.2.
> 
> If that is the case then the API, as defined by
> http://docs.python.org/py3k/c-api/index.html
> should be same for 3.2 as for 3.1, plus a few functions,
> that are explicitly marked as "New in version 3.2".
> 
> Unfortunately, that is not currently the case.

How so? Can you give an example?

Regards

Antoine.



From mal at egenix.com  Wed Feb  9 12:00:44 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 09 Feb 2011 12:00:44 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D5259B4.8030205@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk>
Message-ID: <4D5273DC.3020409@egenix.com>

Mark Shannon wrote:
> The Unicode Exception Objects section is new and seemingly redundant:
> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
> Should this be in the public API?

Those function have been in the public API since we introduced
Unicode callbak error handlers.

It was an oversight that these were not documented in the Python
documentation. They have been documented part of the unicodeobject.h
ever since they were introduced.

Note that these APIs are needed by codecs supporting the
callback error handlers, and since performance matters a lot
for codecs, the C APIs were introduced.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 09 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 marks at dcs.gla.ac.uk  Wed Feb  9 13:11:43 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Wed, 09 Feb 2011 12:11:43 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <4D5273DC.3020409@egenix.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com>
Message-ID: <4D52847F.10006@dcs.gla.ac.uk>

M.-A. Lemburg wrote:
> Mark Shannon wrote:
>> The Unicode Exception Objects section is new and seemingly redundant:
>> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
>> Should this be in the public API?
> 
> Those function have been in the public API since we introduced
> Unicode callbak error handlers.
> 
> It was an oversight that these were not documented in the Python
> documentation. They have been documented part of the unicodeobject.h
> ever since they were introduced.
> 
> Note that these APIs are needed by codecs supporting the
> callback error handlers, and since performance matters a lot
> for codecs, the C APIs were introduced.
> 

OK, so UnicodeError_xxx is important for codecs, but surely this sort of 
argument could be made for lots of things.
Don't forget that for each function added to the API,
all other implementations have to support it forever.

Unfortunately, UnicodeError_xxx are not the only new functions.

Various others have been added:

int Py_EnterRecursiveCall(char *where)
void Py_LeaveRecursiveCall()
int Py_ReprEnter(PyObject *object)
void Py_ReprLeave(PyObject *object)

HotPyModule_GetFilenameObject
HotPy_CompileStringExFlags

and a few others.

Individual functions are not the problem,
I'm sure all of these can be justified,
its lack of process and review that bothers me.

Mark.

From ncoghlan at gmail.com  Wed Feb  9 13:43:12 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 9 Feb 2011 22:43:12 +1000
Subject: [Python-Dev] API bloat
In-Reply-To: <4D52847F.10006@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com>
	<4D52847F.10006@dcs.gla.ac.uk>
Message-ID: <AANLkTimhRFDfhvSR4vnKeqiy+5vnA=CjSecO5bV4-54v@mail.gmail.com>

On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon <marks at dcs.gla.ac.uk> wrote:
> OK, so UnicodeError_xxx is important for codecs, but surely this sort of
> argument could be made for lots of things.
> Don't forget that for each function added to the API,
> all other implementations have to support it forever.

Other implementations that want to support CPython extensions should
focus their efforts on the limited API defined in PEP 384. That will
not only be a lot easier, it will also be less of a moving target.

Cheers,
Nick.

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

From exarkun at twistedmatrix.com  Wed Feb  9 14:03:39 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Wed, 09 Feb 2011 13:03:39 -0000
Subject: [Python-Dev] API bloat
In-Reply-To: <AANLkTimhRFDfhvSR4vnKeqiy+5vnA=CjSecO5bV4-54v@mail.gmail.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com>
	<4D52847F.10006@dcs.gla.ac.uk>
	<AANLkTimhRFDfhvSR4vnKeqiy+5vnA=CjSecO5bV4-54v@mail.gmail.com>
Message-ID: <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain>

On 12:43 pm, ncoghlan at gmail.com wrote:
>On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon <marks at dcs.gla.ac.uk> 
>wrote:
>>OK, so UnicodeError_xxx is important for codecs, but surely this sort 
>>of
>>argument could be made for lots of things.
>>Don't forget that for each function added to the API,
>>all other implementations have to support it forever.
>
>Other implementations that want to support CPython extensions should
>focus their efforts on the limited API defined in PEP 384. That will
>not only be a lot easier, it will also be less of a moving target.

And will produce what kind of results?  How many extension libraries 
work with this subset?

Jean-Paul

From benjamin at python.org  Wed Feb  9 14:58:55 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 9 Feb 2011 07:58:55 -0600
Subject: [Python-Dev] API bloat
In-Reply-To: <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com>
	<4D52847F.10006@dcs.gla.ac.uk>
	<AANLkTimhRFDfhvSR4vnKeqiy+5vnA=CjSecO5bV4-54v@mail.gmail.com>
	<20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain>
Message-ID: <AANLkTikW8Kyfj7sHRtCpHrY0uUYy2PAHFoPBMbz_yity@mail.gmail.com>

2011/2/9  <exarkun at twistedmatrix.com>:
> On 12:43 pm, ncoghlan at gmail.com wrote:
>>
>> On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon <marks at dcs.gla.ac.uk> wrote:
>>>
>>> OK, so UnicodeError_xxx is important for codecs, but surely this sort of
>>> argument could be made for lots of things.
>>> Don't forget that for each function added to the API,
>>> all other implementations have to support it forever.
>>
>> Other implementations that want to support CPython extensions should
>> focus their efforts on the limited API defined in PEP 384. That will
>> not only be a lot easier, it will also be less of a moving target.
>
> And will produce what kind of results? ?How many extension libraries work
> with this subset?

Probably none because it hasn't been released. That's the goal.


-- 
Regards,
Benjamin

From ncoghlan at gmail.com  Wed Feb  9 14:59:48 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 9 Feb 2011 23:59:48 +1000
Subject: [Python-Dev] API bloat
In-Reply-To: <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com>
	<4D52847F.10006@dcs.gla.ac.uk>
	<AANLkTimhRFDfhvSR4vnKeqiy+5vnA=CjSecO5bV4-54v@mail.gmail.com>
	<20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain>
Message-ID: <AANLkTimXRLnWS38bmFcLaqdmAS=VRXomjHNCKFMuOLsv@mail.gmail.com>

On Wed, Feb 9, 2011 at 11:03 PM,  <exarkun at twistedmatrix.com> wrote:
> On 12:43 pm, ncoghlan at gmail.com wrote:
>>
>> On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon <marks at dcs.gla.ac.uk> wrote:
>>>
>>> OK, so UnicodeError_xxx is important for codecs, but surely this sort of
>>> argument could be made for lots of things.
>>> Don't forget that for each function added to the API,
>>> all other implementations have to support it forever.
>>
>> Other implementations that want to support CPython extensions should
>> focus their efforts on the limited API defined in PEP 384. That will
>> not only be a lot easier, it will also be less of a moving target.
>
> And will produce what kind of results? ?How many extension libraries work
> with this subset?

Right now? Very few, given the changes to the way types need to be
created. But prioritising it will speed convergence over time as more
extension modules cut over to it for the stable ABI benefits.

And, since the C API has never been anywhere near as tightly
controlled as the language definition, alternative implementations are
going to garner more sympathy if they restrict their concerns to the
growth of the stable ABI rather than worrying about an implementation
detail of CPython.

Cheers,
Nick.

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

From benjamin at python.org  Wed Feb  9 15:00:49 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 9 Feb 2011 08:00:49 -0600
Subject: [Python-Dev] API bloat
In-Reply-To: <4D52847F.10006@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com>
	<4D52847F.10006@dcs.gla.ac.uk>
Message-ID: <AANLkTimnafeU9zPJJdK7+6=u_DL=0PVLpwMCWOKV7ncd@mail.gmail.com>

2011/2/9 Mark Shannon <marks at dcs.gla.ac.uk>:
> OK, so UnicodeError_xxx is important for codecs, but surely this sort of
> argument could be made for lots of things.
> Don't forget that for each function added to the API,
> all other implementations have to support it forever.

The C-API is about the biggest implementation detail of CPython, so
no, they don't have to.

>
> Unfortunately, UnicodeError_xxx are not the only new functions.
>
> Various others have been added:
>
> int Py_EnterRecursiveCall(char *where)
> void Py_LeaveRecursiveCall()
> int Py_ReprEnter(PyObject *object)
> void Py_ReprLeave(PyObject *object)
>
> HotPyModule_GetFilenameObject
> HotPy_CompileStringExFlags
>
> and a few others.
>
> Individual functions are not the problem,
> I'm sure all of these can be justified,
> its lack of process and review that bothers me.


If they can be justified, what is the process lacking?

-- 
Regards,
Benjamin

From fuzzyman at voidspace.org.uk  Wed Feb  9 15:11:51 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 09 Feb 2011 14:11:51 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <AANLkTimnafeU9zPJJdK7+6=u_DL=0PVLpwMCWOKV7ncd@mail.gmail.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk>
	<4D5273DC.3020409@egenix.com>	<4D52847F.10006@dcs.gla.ac.uk>
	<AANLkTimnafeU9zPJJdK7+6=u_DL=0PVLpwMCWOKV7ncd@mail.gmail.com>
Message-ID: <4D52A0A7.2000507@voidspace.org.uk>

On 09/02/2011 14:00, Benjamin Peterson wrote:
> 2011/2/9 Mark Shannon<marks at dcs.gla.ac.uk>:
>> OK, so UnicodeError_xxx is important for codecs, but surely this sort of
>> argument could be made for lots of things.
>> Don't forget that for each function added to the API,
>> all other implementations have to support it forever.
> The C-API is about the biggest implementation detail of CPython, so
> no, they don't have to.
>

Alternative implementations that want C extensions to work (like 
Ironclad for IronPython and cpyext for pypy) do implement the parts of 
the C API that are most widely used though. Of course they don't *have 
to*, but c extension compatibility is one of the biggest problems for 
users of alternative implementations.

Hopefully the stable ABI will improve this situation for the future, but 
realistically its going to be a few years before it has an appreciable 
effect.

Michael
>> Unfortunately, UnicodeError_xxx are not the only new functions.
>>
>> Various others have been added:
>>
>> int Py_EnterRecursiveCall(char *where)
>> void Py_LeaveRecursiveCall()
>> int Py_ReprEnter(PyObject *object)
>> void Py_ReprLeave(PyObject *object)
>>
>> HotPyModule_GetFilenameObject
>> HotPy_CompileStringExFlags
>>
>> and a few others.
>>
>> Individual functions are not the problem,
>> I'm sure all of these can be justified,
>> its lack of process and review that bothers me.
>
> If they can be justified, what is the process lacking?
>


-- 
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  Wed Feb  9 15:13:08 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 09 Feb 2011 14:13:08 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <AANLkTimXRLnWS38bmFcLaqdmAS=VRXomjHNCKFMuOLsv@mail.gmail.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk>
	<4D5273DC.3020409@egenix.com>	<4D52847F.10006@dcs.gla.ac.uk>	<AANLkTimhRFDfhvSR4vnKeqiy+5vnA=CjSecO5bV4-54v@mail.gmail.com>	<20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain>
	<AANLkTimXRLnWS38bmFcLaqdmAS=VRXomjHNCKFMuOLsv@mail.gmail.com>
Message-ID: <4D52A0F4.3010801@voidspace.org.uk>

On 09/02/2011 13:59, Nick Coghlan wrote:
> [snip...]
> And, since the C API has never been anywhere near as tightly
> controlled as the language definition, alternative implementations are
> going to garner more sympathy if they restrict their concerns to the
> growth of the stable ABI rather than worrying about an implementation
> detail of CPython.

Actually the opposite. Users tend to be very unsympathetic when 
extensions they depend on don't work with alternative implementations (I 
speak from experience).

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 exarkun at twistedmatrix.com  Wed Feb  9 15:13:11 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Wed, 09 Feb 2011 14:13:11 -0000
Subject: [Python-Dev] API bloat
In-Reply-To: <AANLkTimXRLnWS38bmFcLaqdmAS=VRXomjHNCKFMuOLsv@mail.gmail.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com>
	<4D52847F.10006@dcs.gla.ac.uk>
	<AANLkTimhRFDfhvSR4vnKeqiy+5vnA=CjSecO5bV4-54v@mail.gmail.com>
	<20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain>
	<AANLkTimXRLnWS38bmFcLaqdmAS=VRXomjHNCKFMuOLsv@mail.gmail.com>
Message-ID: <20110209141311.1699.1389612648.divmod.xquotient.1404@localhost.localdomain>

On 01:59 pm, ncoghlan at gmail.com wrote:
>On Wed, Feb 9, 2011 at 11:03 PM,  <exarkun at twistedmatrix.com> wrote:
>>On 12:43 pm, ncoghlan at gmail.com wrote:
>>>
>>>On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon <marks at dcs.gla.ac.uk> 
>>>wrote:
>>>>
>>>>OK, so UnicodeError_xxx is important for codecs, but surely this 
>>>>sort of
>>>>argument could be made for lots of things.
>>>>Don't forget that for each function added to the API,
>>>>all other implementations have to support it forever.
>>>
>>>Other implementations that want to support CPython extensions should
>>>focus their efforts on the limited API defined in PEP 384. That will
>>>not only be a lot easier, it will also be less of a moving target.
>>
>>And will produce what kind of results? ?How many extension libraries 
>>work
>>with this subset?
>
>Right now? Very few, given the changes to the way types need to be
>created. But prioritising it will speed convergence over time as more
>extension modules cut over to it for the stable ABI benefits.
>
>And, since the C API has never been anywhere near as tightly
>controlled as the language definition, alternative implementations are
>going to garner more sympathy if they restrict their concerns to the
>growth of the stable ABI rather than worrying about an implementation
>detail of CPython.

Sympathy, perhaps.  But that doesn't mean people will drop everything 
and rewrite their extension modules.

Jean-Paul

From solipsis at pitrou.net  Wed Feb  9 15:41:33 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 9 Feb 2011 15:41:33 +0100
Subject: [Python-Dev] API bloat
References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com>
	<4D52847F.10006@dcs.gla.ac.uk>
Message-ID: <20110209154133.3dc754e5@pitrou.net>

On Wed, 09 Feb 2011 12:11:43 +0000
Mark Shannon <marks at dcs.gla.ac.uk> wrote:
> Various others have been added:
> 
> int Py_EnterRecursiveCall(char *where)
> void Py_LeaveRecursiveCall()
> int Py_ReprEnter(PyObject *object)
> void Py_ReprLeave(PyObject *object)

Again, they haven't been "added". They have been there for a long time;
it's just that they weren't documented before (either because it was
overlooked or out of laziness, I don't know).

And these 4 functions are definitely useful for extension modules.

> HotPyModule_GetFilenameObject
> HotPy_CompileStringExFlags

Judging by the "HotPy" prefix, these aren't CPython functions ;)

> I'm sure all of these can be justified,
> its lack of process and review that bothers me.

Process and review of new APIs usually go through the issue tracker.
We also have a ton of new stdlib APIs in 3.2:
http://docs.python.org/dev/whatsnew/3.2.html
If each of these new APIs went through a python-dev discussion, this
mailing-list would become a huge mess.

Regards

Antoine.



From solipsis at pitrou.net  Wed Feb  9 15:45:31 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 9 Feb 2011 15:45:31 +0100
Subject: [Python-Dev] API bloat
References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com>
	<4D52847F.10006@dcs.gla.ac.uk>
	<AANLkTimhRFDfhvSR4vnKeqiy+5vnA=CjSecO5bV4-54v@mail.gmail.com>
	<20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain>
	<AANLkTimXRLnWS38bmFcLaqdmAS=VRXomjHNCKFMuOLsv@mail.gmail.com>
	<20110209141311.1699.1389612648.divmod.xquotient.1404@localhost.localdomain>
Message-ID: <20110209154531.25117bd3@pitrou.net>

On Wed, 09 Feb 2011 14:13:11 -0000
exarkun at twistedmatrix.com wrote:
> >And, since the C API has never been anywhere near as tightly
> >controlled as the language definition, alternative implementations are
> >going to garner more sympathy if they restrict their concerns to the
> >growth of the stable ABI rather than worrying about an implementation
> >detail of CPython.
> 
> Sympathy, perhaps.  But that doesn't mean people will drop everything 
> and rewrite their extension modules.

Using the stable ABI should have maintenance advantages, since you
don't have to compile a separate package for each Python version.
How far distutils goes to support version-independent binary
distributions I don't know, though. But at least the stable ABI is a
step in that direction.

And of course you don't need to "rewrite your extension modules".
Apparently type definitions have to be adapted, and you have to make
sure you aren't using functions that are not in the limited API, but
otherwise things should work fine.

Regards

Antoine.



From skip at pobox.com  Wed Feb  9 18:32:38 2011
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 9 Feb 2011 11:32:38 -0600
Subject: [Python-Dev] python 3.2 (fwd)
Message-ID: <19794.53174.766166.195523@montanaro.dyndns.org>

Passing this along from webmaster.

S

-------------- next part --------------
An embedded message was scrubbed...
From: "Mayur Patel" <mayur at percy3d.com>
Subject: python 3.2
Date: Wed, 9 Feb 2011 10:55:34 -0500
Size: 8564
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110209/15d497e4/attachment-0001.mht>

From tjreedy at udel.edu  Wed Feb  9 20:21:35 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 09 Feb 2011 14:21:35 -0500
Subject: [Python-Dev] python 3.2 (fwd)
In-Reply-To: <19794.53174.766166.195523@montanaro.dyndns.org>
References: <19794.53174.766166.195523@montanaro.dyndns.org>
Message-ID: <4D52E93F.3020108@udel.edu>

On 2/9/2011 12:32 PM, skip at pobox.com wrote:
> Passing this along from webmaster.

It is hard to reply to an attachment rather than inline forwarded 
message.  However, with rc1

 >>> import sqlite3
 >>> sqlite3.version
'2.6.0'
 >>> sqlite3.sqlite_version
'3.7.4'

I added 'pysqlite' to the "What's new" entry.

-- 
Terry Jan Reedy


From martin at v.loewis.de  Wed Feb  9 20:55:19 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 09 Feb 2011 20:55:19 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D526E57.9030206@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk>
Message-ID: <4D52F127.4050906@v.loewis.de>

> The functions may have been add to CPython 8 years ago, but they were
> added to the API when they appeared in the docs, between 3.1 and 3.1.3.
> 
> How is the API defined, if not by the documentation?

Just to stress and support Georg's explanation: the API is *not* defined
through the documentation, but instead primarily through the header
files. All functions declared as PyAPI_FUNC and not starting with _Py
are public API. There used to be a lot of undocumented API (up to 1.4,
there was no API documentation at all, only the extension module
tutorial); these days, more and more API gets documented.

HTH,
Martin

From solipsis at pitrou.net  Wed Feb  9 21:29:19 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 9 Feb 2011 21:29:19 +0100
Subject: [Python-Dev] devguide: More clarifications: use the term
 'working copy' and mention 'hg update'.
References: <E1PnGU3-00039s-2R@dinsdale.python.org>
Message-ID: <20110209212919.1a8f3fe1@pitrou.net>

On Wed, 09 Feb 2011 21:17:51 +0100
brett.cannon <python-checkins at python.org> wrote:
>  
>  
> -One should always work from a checkout of the CPython source code. While it may
> +One should always work from a working copy of the CPython source code.
> +While it may
>  be tempting to work from the downloaded copy you already have installed on your

The difference between "downloaded copy" and "working copy" isn't very
clear. The important difference here is between "official stable
version" and "latest development sources".

> -To get a read-only checkout of CPython's source, you need to checkout the source
> -code. To get a read-only checkout of
> +To get a read-only checkout of CPython's source, you need a working copy the
> +source code. To get a read-only checkout of

Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not
mistaken (even though it may occasionally be used with hg, it's a
synonym of "working copy" there).

Regards

Antoine.



From brett at python.org  Wed Feb  9 23:49:40 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 9 Feb 2011 14:49:40 -0800
Subject: [Python-Dev] devguide: More clarifications: use the term
 'working copy' and mention 'hg update'.
In-Reply-To: <20110209212919.1a8f3fe1@pitrou.net>
References: <E1PnGU3-00039s-2R@dinsdale.python.org>
	<20110209212919.1a8f3fe1@pitrou.net>
Message-ID: <AANLkTimBJak3Lb65fkao_MM4yeBGXhsDtcmumZEHe9xK@mail.gmail.com>

On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 09 Feb 2011 21:17:51 +0100
> brett.cannon <python-checkins at python.org> wrote:
>>
>>
>> -One should always work from a checkout of the CPython source code. While it may
>> +One should always work from a working copy of the CPython source code.
>> +While it may
>> ?be tempting to work from the downloaded copy you already have installed on your
>
> The difference between "downloaded copy" and "working copy" isn't very
> clear. The important difference here is between "official stable
> version" and "latest development sources".

I'll clarify.

>
>> -To get a read-only checkout of CPython's source, you need to checkout the source
>> -code. To get a read-only checkout of
>> +To get a read-only checkout of CPython's source, you need a working copy the
>> +source code. To get a read-only checkout of
>
> Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not
> mistaken (even though it may occasionally be used with hg, it's a
> synonym of "working copy" there).

Since it's a synonym I didn't worry about it. I honestly just thought
it flowed better.

-Brett

>
> 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/brett%40python.org
>

From solipsis at pitrou.net  Wed Feb  9 23:51:49 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 09 Feb 2011 23:51:49 +0100
Subject: [Python-Dev] devguide: More clarifications: use the term
 'working copy' and mention 'hg update'.
In-Reply-To: <AANLkTimBJak3Lb65fkao_MM4yeBGXhsDtcmumZEHe9xK@mail.gmail.com>
References: <E1PnGU3-00039s-2R@dinsdale.python.org>
	<20110209212919.1a8f3fe1@pitrou.net>
	<AANLkTimBJak3Lb65fkao_MM4yeBGXhsDtcmumZEHe9xK@mail.gmail.com>
Message-ID: <1297291909.3731.15.camel@localhost.localdomain>


> >
> >> -To get a read-only checkout of CPython's source, you need to checkout the source
> >> -code. To get a read-only checkout of
> >> +To get a read-only checkout of CPython's source, you need a working copy the
> >> +source code. To get a read-only checkout of
> >
> > Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not
> > mistaken (even though it may occasionally be used with hg, it's a
> > synonym of "working copy" there).
> 
> Since it's a synonym I didn't worry about it. I honestly just thought
> it flowed better.

What I meant is that "To get a read-only checkout, you need a working
copy" is kind of tautologic then.

Regards

Antoine.



From merwok at netwok.org  Wed Feb  9 23:57:48 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 09 Feb 2011 23:57:48 +0100
Subject: [Python-Dev] devguide: More clarifications: use the term
 'working copy' and mention 'hg update'.
In-Reply-To: <AANLkTimBJak3Lb65fkao_MM4yeBGXhsDtcmumZEHe9xK@mail.gmail.com>
References: <E1PnGU3-00039s-2R@dinsdale.python.org>	<20110209212919.1a8f3fe1@pitrou.net>
	<AANLkTimBJak3Lb65fkao_MM4yeBGXhsDtcmumZEHe9xK@mail.gmail.com>
Message-ID: <4D531BEC.1030609@netwok.org>

Le 09/02/2011 23:49, Brett Cannon a ?crit :
> On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> -To get a read-only checkout of CPython's source, you need to checkout the source
>>> -code. To get a read-only checkout of
>>> +To get a read-only checkout of CPython's source, you need a working copy the
>>> +source code. To get a read-only checkout of

?you need a working copy the source code? ? ?you need to clone the
source code repository? (see below for more)

>> Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not
>> mistaken (even though it may occasionally be used with hg, it's a
>> synonym of "working copy" there).
> Since it's a synonym I didn't worry about it. I honestly just thought
> it flowed better.

Agreed.  The problem is that the terms do not map 1:1 from Subversion.
When Subversion docs talk about getting a checkout, Mercurial tells to
make a clone (which includes the working copy); in other cases, a strict
distinction between repository and working copy is needed.  I see no
problems in using checkout when it flows better than working copy
(especially as a verb).

Sincerely hoping I don?t make things more confusing,
Regards

From g.brandl at gmx.net  Thu Feb 10 08:10:02 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 10 Feb 2011 08:10:02 +0100
Subject: [Python-Dev] devguide: Fix a silly statement.
In-Reply-To: <E1PnIzO-0007bi-1c@dinsdale.python.org>
References: <E1PnIzO-0007bi-1c@dinsdale.python.org>
Message-ID: <ij02gf$v9v$1@dough.gmane.org>

Am 09.02.2011 23:58, schrieb brett.cannon:
> brett.cannon pushed 7101df1bd817 to devguide:
> 
> http://hg.python.org/devguide/rev/7101df1bd817
> changeset:   291:7101df1bd817
> branch:      hg_transition
> tag:         tip
> user:        Brett Cannon <brett at python.org>
> date:        Wed Feb 09 14:58:17 2011 -0800
> summary:
>   Fix a silly statement.
> 
> files:
>   setup.rst
> 
> diff --git a/setup.rst b/setup.rst
> --- a/setup.rst
> +++ b/setup.rst
> @@ -34,8 +34,7 @@
>  :abbr:`VCS`. It also means you will have better tool
>  support through the VCS as it will provide a diff tool, etc.
>  
> -To get a read-only checkout of CPython's source, you need a working copy the
> -source code. To get a read-only checkout of
> +To get a read-only checkout of
>  the :ref:`in-development <indevbranch>` branch of Python, run::
>  
>      hg clone http://hg.python.org/cpython

This statement is still somewhat silly, as a) you get a clone, not a checkout
and b) it is not read only in any way: you can commit just fine.  The only
difference will be the entry in .hg/hgrc pointing the default repo to something
you can't push to.

Skimming through, the whole section "Checking out the code" is still way too
SVN-point of viewy (e.g. you always get all branches anyway).

Georg


From tjreedy at udel.edu  Thu Feb 10 08:13:00 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 10 Feb 2011 02:13:00 -0500
Subject: [Python-Dev] devguide: More clarifications: use the term
 'working copy' and mention 'hg update'.
In-Reply-To: <20110209212919.1a8f3fe1@pitrou.net>
References: <E1PnGU3-00039s-2R@dinsdale.python.org>
	<20110209212919.1a8f3fe1@pitrou.net>
Message-ID: <ij035s$3em$1@dough.gmane.org>

On 2/9/2011 3:29 PM, Antoine Pitrou wrote:

> Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not
> mistaken (even though it may occasionally be used with hg, it's a
> synonym of "working copy" there).

I believe it harkens back to early source code control systems where one 
person literally 'checked out' a file and got a write lock on it, 
similar to checking out a particular volume from the library )except 
that others could still read, unlike with the library).

yes. good riddance (already done).

-- 
Terry Jan Reedy


From marks at dcs.gla.ac.uk  Thu Feb 10 11:16:04 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Thu, 10 Feb 2011 10:16:04 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <4D52F127.4050906@v.loewis.de>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de>
Message-ID: <4D53BAE4.9070000@dcs.gla.ac.uk>

Thanks to everyone for all their comments so far.

Martin v. L?wis wrote:
>> The functions may have been add to CPython 8 years ago, but they were
>> added to the API when they appeared in the docs, between 3.1 and 3.1.3.
>>
>> How is the API defined, if not by the documentation?
> 
> Just to stress and support Georg's explanation: the API is *not* defined
> through the documentation, but instead primarily through the header
> files. All functions declared as PyAPI_FUNC and not starting with _Py
> are public API. There used to be a lot of undocumented API (up to 1.4,
> there was no API documentation at all, only the extension module
> tutorial); these days, more and more API gets documented.

Doing a search for the regex:  "PyAPI_FUNC\([^)]*\) *Py" in .h files,
which should match API functions (functions starting _Py are excluded) 
gives the following result:

Version  matches
3.0       717
3.1.3     728
3.2b2     743

It would appear the API  bloat is real,
not just an artefact of updated docs.

The "what's new for 3.2" API section:
http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes
lists 6 new functions, yet according to my search, 15 have been added
between 3.1.3 and 3.2b2.

Of course 743 functions is about 700 too many,
but that's a discussion for Python-ideas and PEP 384.

Mark.

> 
> HTH,
> Martin
> 


From ncoghlan at gmail.com  Thu Feb 10 13:22:49 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 10 Feb 2011 22:22:49 +1000
Subject: [Python-Dev] API bloat
In-Reply-To: <4D53BAE4.9070000@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de>
	<4D53BAE4.9070000@dcs.gla.ac.uk>
Message-ID: <AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>

On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon <marks at dcs.gla.ac.uk> wrote:
> Doing a search for the regex: ?"PyAPI_FUNC\([^)]*\) *Py" in .h files,
> which should match API functions (functions starting _Py are excluded) gives
> the following result:
>
> Version ?matches
> 3.0 ? ? ? 717
> 3.1.3 ? ? 728
> 3.2b2 ? ? 743
>
> It would appear the API ?bloat is real,
> not just an artefact of updated docs.

Since it doesn't account for #ifdef, a naive count like that isn't a
valid basis for comparison.

I would hazard a guess that a substantial amount of the additional
numbers there are going to be from new alternative definitions of
Py_hash_t and some of the Py_UNICODE macros.

Cheers,
Nick.

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

From stefan_ml at behnel.de  Thu Feb 10 13:51:16 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 10 Feb 2011 13:51:16 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D53BAE4.9070000@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk>
	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>
	<4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk>
Message-ID: <ij0n05$879$1@dough.gmane.org>

Mark Shannon, 10.02.2011 11:16:
> Of course 743 functions is about 700 too many,

Sorry, but that's so wrong, it's just being mean.

What do you expect from a platform that has grown for more than 20 years? 
And which has been the only (real) Python implementation for most of that time.

I'm sure it'll be easy to find, say, 200 functions that are not really 
required (PySequence_Fast?), but many of those make the life easier for C 
programmers and/or have helped with portability in the past. Most of those 
"C helper functions" long predate the dedicated extension writer tools that 
bring relieve from calling them. Mind you, even the Cython project is only 
some 4 years old, and even there you will still want to call a C-API 
function or two from time to time.

Seriously, CPython's C-API has always been a *reason* for it to be popular. 
Many important tools wouldn't even exist without it, and sure wouldn't be 
in their current state if the C-API had not evolved together with them. 
Just think of NumPy, which is one (if not *the* one) of the main attractors 
for other Python implementations to get their view of the C-API implemented.

Stefan



From ncoghlan at gmail.com  Thu Feb 10 14:00:08 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 10 Feb 2011 23:00:08 +1000
Subject: [Python-Dev] [Python-checkins] r88385 -
	python/branches/py3k/Doc/whatsnew/3.2.rst
In-Reply-To: <20110210092026.60330EEAD7@mail.python.org>
References: <20110210092026.60330EEAD7@mail.python.org>
Message-ID: <AANLkTikwBPXOfHnPBr3DWwYVs7-dpBMRTOKunQ_RPjci@mail.gmail.com>

On Thu, Feb 10, 2011 at 7:20 PM, raymond.hettinger
<python-checkins at python.org> wrote:
> +The :func:`logging.basicConfig` set-up function gained a *style* argument to
> +support three different types of string formatting. ?It defaults to "%" for
> +traditional %-formatting, can be set to "{" for the new :meth:`str.format` style, or
> +can be set to "$" for the shell-style formatting provided by
> +:class:`string.Template`. ?The following three configurations are equivalent::
> +
> + ? ?>>> from logging import basicConfig
> + ? ?>>> basicConfig(style='%', format="%(name)s -> %(levelname)s: %(message)s")
> + ? ?>>> basicConfig(style='{', format="{name} -> {levelname} {message}")
> + ? ?>>> basicConfig(style='$', format="$name -> $levelname: $message")

It may be worth noting here that:
1. the "style" parameter also exists for logging.Formatter objects
2. it only applies to the output formatting for output, individual
logging calls are still constrained to using %-formatting by backwards
compatibility issues

(Especially point 2 - I briefly forgot that distinction myself, and I
helped review this feature when Vinay added it)

Cheers,
Nick.

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

From marks at dcs.gla.ac.uk  Thu Feb 10 14:37:36 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Thu, 10 Feb 2011 13:37:36 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>
	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
Message-ID: <4D53EA20.80403@dcs.gla.ac.uk>

Nick Coghlan wrote:
> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon <marks at dcs.gla.ac.uk> wrote:
>> Doing a search for the regex:  "PyAPI_FUNC\([^)]*\) *Py" in .h files,
>> which should match API functions (functions starting _Py are excluded) gives
>> the following result:
>>
>> Version  matches
>> 3.0       717
>> 3.1.3     728
>> 3.2b2     743
>>
>> It would appear the API  bloat is real,
>> not just an artefact of updated docs.
> 
> Since it doesn't account for #ifdef, a naive count like that isn't a
> valid basis for comparison.
> 
OK. How about this:

egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h
finds no matches.

egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u

This finds all matches and removes duplicates, so anything defined
multiple time in branches of #ifdef blocks, will only be counted once.

Version  matches
3.0       714
3.1.3     725
3.2b2     739

So given, the revised numbers;

The "what's new for 3.2" API section:
http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes
lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2.


> I would hazard a guess that a substantial amount of the additional
> numbers there are going to be from new alternative definitions of
> Py_hash_t and some of the Py_UNICODE macros.

Unless there is a PyAPI_FUNC involved, these won't match the regex.

> 
> Cheers,
> Nick.
> 



From mal at egenix.com  Thu Feb 10 14:51:59 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 10 Feb 2011 14:51:59 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D53EA20.80403@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
	<4D53EA20.80403@dcs.gla.ac.uk>
Message-ID: <4D53ED7F.1050300@egenix.com>

Mark Shannon wrote:
> Nick Coghlan wrote:
>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon <marks at dcs.gla.ac.uk>
>> wrote:
>>> Doing a search for the regex:  "PyAPI_FUNC\([^)]*\) *Py" in .h files,
>>> which should match API functions (functions starting _Py are
>>> excluded) gives
>>> the following result:
>>>
>>> Version  matches
>>> 3.0       717
>>> 3.1.3     728
>>> 3.2b2     743
>>>
>>> It would appear the API  bloat is real,
>>> not just an artefact of updated docs.
>>
>> Since it doesn't account for #ifdef, a naive count like that isn't a
>> valid basis for comparison.
>>
> OK. How about this:
> 
> egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h
> finds no matches.
> 
> egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u
> 
> This finds all matches and removes duplicates, so anything defined
> multiple time in branches of #ifdef blocks, will only be counted once.
> 
> Version  matches
> 3.0       714
> 3.1.3     725
> 3.2b2     739

Given these numbers, I don't think the subject line really
captures the problem accurately enough ... a 2% increase
in number of API function per release can hardly be called
API bloat :-)

> So given, the revised numbers;
> 
> The "what's new for 3.2" API section:
> http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes
> lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2.

Could you identify the ones that are not yet documented ?

That would be useful.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 10 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 ncoghlan at gmail.com  Thu Feb 10 15:09:11 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Feb 2011 00:09:11 +1000
Subject: [Python-Dev] API bloat
In-Reply-To: <4D53ED7F.1050300@egenix.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de>
	<4D53BAE4.9070000@dcs.gla.ac.uk>
	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
	<4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com>
Message-ID: <AANLkTi=WqJam=AvDtZhPvN+pbs+V8femMKwsiUwgbnMq@mail.gmail.com>

On Thu, Feb 10, 2011 at 11:51 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> The "what's new for 3.2" API section:
>> http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes
>> lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2.
>
> Could you identify the ones that are not yet documented ?

>From Misc/NEWS:

PyUnicode_TransformDecimalToASCII
PyErr_SyntaxLocationEx
PyArg_ValidateKeywordArguments
PyFrame_GetLineNumber
PyCode_NewEmpty

I would guess that a lot of the other ones that aren't explicitly
documented in NEWS or What's New are the assorted utilities Victor
added in order to properly support non-ASCII entries in sys.path, as
well as all the additional APIs to handle both bytes and unicode
interfaces to the external environment.

In scanning NEWS, I also noticed that there were quite a few ancient
APIs that were finally killed off in 3.2, so the number of new
functions is likely to actually exceed the 14 picked up by Mark's
measurements.

Cheers,
Nick.

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

From marks at dcs.gla.ac.uk  Thu Feb 10 15:26:26 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Thu, 10 Feb 2011 14:26:26 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <4D53ED7F.1050300@egenix.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
	<4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com>
Message-ID: <4D53F592.2080401@dcs.gla.ac.uk>

M.-A. Lemburg wrote:
> Mark Shannon wrote:
>> Nick Coghlan wrote:
>>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon <marks at dcs.gla.ac.uk>
>>> wrote:
>>>> Doing a search for the regex:  "PyAPI_FUNC\([^)]*\) *Py" in .h files,
>>>> which should match API functions (functions starting _Py are
>>>> excluded) gives
>>>> the following result:
>>>>
>>>> Version  matches
>>>> 3.0       717
>>>> 3.1.3     728
>>>> 3.2b2     743
>>>>
>>>> It would appear the API  bloat is real,
>>>> not just an artefact of updated docs.
>>> Since it doesn't account for #ifdef, a naive count like that isn't a
>>> valid basis for comparison.
>>>
>> OK. How about this:
>>
>> egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h
>> finds no matches.
>>
>> egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u
>>
>> This finds all matches and removes duplicates, so anything defined
>> multiple time in branches of #ifdef blocks, will only be counted once.
>>
>> Version  matches
>> 3.0       714
>> 3.1.3     725
>> 3.2b2     739
> 
> Given these numbers, I don't think the subject line really
> captures the problem accurately enough ... a 2% increase
> in number of API function per release can hardly be called
> API bloat :-)
> 
>> So given, the revised numbers;
>>
>> The "what's new for 3.2" API section:
>> http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes
>> lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2.
> 
> Could you identify the ones that are not yet documented ?
> 
> That would be useful.

Here's the details:

The following API functions were removed from 3.1.3:

PyAST_Compile
PyCObject_AsVoidPtr
PyCObject_FromVoidPtr
PyCObject_FromVoidPtrAndDesc
PyCObject_GetDesc
PyCObject_Import
PyCObject_SetVoidPtr
PyCode_CheckLineNumber
Py_CompileStringFlags
PyEval_CallObject
PyOS_ascii_atof
PyOS_ascii_formatd
PyOS_ascii_strtod
PyThread_exit_prog
PyThread__PyThread_exit_prog
PyThread__PyThread_exit_thread
PyUnicode_SetDefaultEncoding

And the following were added to 3.2,
of which only 2 are documented:

PyArg_ValidateKeywordArguments
PyAST_CompileEx
Py_CompileString
Py_CompileStringExFlags
PyErr_NewExceptionWithDoc    (documented)
PyErr_SyntaxLocationEx
PyErr_WarnFormat
PyFrame_GetLineNumber
PyImport_ExecCodeModuleWithPathnames
PyImport_GetMagicTag
PyLong_AsLongLongAndOverflow    (documented)
PyModule_GetFilenameObject
Py_SetPath
PyStructSequence_GetItem
PyStructSequence_NewType
PyStructSequence_SetItem
PySys_AddWarnOptionUnicode
PySys_AddXOption
PySys_FormatStderr
PySys_FormatStdout
PySys_GetXOptions
PyThread_acquire_lock_timed
PyType_FromSpec
PyUnicode_AsUnicodeCopy
PyUnicode_AsWideCharString
PyUnicode_EncodeFSDefault
PyUnicode_FSDecoder
Py_UNICODE_strcat
Py_UNICODE_strncmp
Py_UNICODE_strrchr
PyUnicode_TransformDecimalToASCII

For added confusion PySys_SetArgvEx is documented as
new in 3.2, but exists in 3.1.3

That should keep someone busy ;)

Note that this only include functions.
The API also includes a number of macros such as
Py_False and Py_RETURN_FALSE, types ,
and data like PyBool_Type.

I've not tried to analyse any of these.

Mark.

> 
> Thanks,


From mal at egenix.com  Thu Feb 10 16:19:56 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 10 Feb 2011 16:19:56 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D53F592.2080401@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>	<4D53EA20.80403@dcs.gla.ac.uk>
	<4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk>
Message-ID: <4D54021C.9000304@egenix.com>

Mark Shannon wrote:
> M.-A. Lemburg wrote:
>> Mark Shannon wrote:
>>> Nick Coghlan wrote:
>>>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon <marks at dcs.gla.ac.uk>
>>>> wrote:
>>>>> Doing a search for the regex:  "PyAPI_FUNC\([^)]*\) *Py" in .h files,
>>>>> which should match API functions (functions starting _Py are
>>>>> excluded) gives
>>>>> the following result:
>>>>>
>>>>> Version  matches
>>>>> 3.0       717
>>>>> 3.1.3     728
>>>>> 3.2b2     743
>>>>>
>>>>> It would appear the API  bloat is real,
>>>>> not just an artefact of updated docs.
>>>> Since it doesn't account for #ifdef, a naive count like that isn't a
>>>> valid basis for comparison.
>>>>
>>> OK. How about this:
>>>
>>> egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h
>>> finds no matches.
>>>
>>> egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u
>>>
>>> This finds all matches and removes duplicates, so anything defined
>>> multiple time in branches of #ifdef blocks, will only be counted once.
>>>
>>> Version  matches
>>> 3.0       714
>>> 3.1.3     725
>>> 3.2b2     739
>>
>> Given these numbers, I don't think the subject line really
>> captures the problem accurately enough ... a 2% increase
>> in number of API function per release can hardly be called
>> API bloat :-)
>>
>>> So given, the revised numbers;
>>>
>>> The "what's new for 3.2" API section:
>>> http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes
>>>
>>> lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2.
>>
>> Could you identify the ones that are not yet documented ?
>>
>> That would be useful.
> 
> Here's the details:
> 
> The following API functions were removed from 3.1.3:
> 
> PyAST_Compile
> PyCObject_AsVoidPtr
> PyCObject_FromVoidPtr
> PyCObject_FromVoidPtrAndDesc
> PyCObject_GetDesc
> PyCObject_Import
> PyCObject_SetVoidPtr
> PyCode_CheckLineNumber
> Py_CompileStringFlags
> PyEval_CallObject
> PyOS_ascii_atof
> PyOS_ascii_formatd
> PyOS_ascii_strtod
> PyThread_exit_prog
> PyThread__PyThread_exit_prog
> PyThread__PyThread_exit_thread
> PyUnicode_SetDefaultEncoding
> 
> And the following were added to 3.2,
> of which only 2 are documented:
> 
> PyArg_ValidateKeywordArguments
> PyAST_CompileEx
> Py_CompileString
> Py_CompileStringExFlags
> PyErr_NewExceptionWithDoc    (documented)
> PyErr_SyntaxLocationEx
> PyErr_WarnFormat
> PyFrame_GetLineNumber
> PyImport_ExecCodeModuleWithPathnames
> PyImport_GetMagicTag
> PyLong_AsLongLongAndOverflow    (documented)
> PyModule_GetFilenameObject
> Py_SetPath
> PyStructSequence_GetItem
> PyStructSequence_NewType
> PyStructSequence_SetItem
> PySys_AddWarnOptionUnicode
> PySys_AddXOption
> PySys_FormatStderr
> PySys_FormatStdout
> PySys_GetXOptions
> PyThread_acquire_lock_timed
> PyType_FromSpec
> PyUnicode_AsUnicodeCopy
> PyUnicode_AsWideCharString
> PyUnicode_EncodeFSDefault
> PyUnicode_FSDecoder
> Py_UNICODE_strcat
> Py_UNICODE_strncmp
> Py_UNICODE_strrchr
> PyUnicode_TransformDecimalToASCII
> 
> For added confusion PySys_SetArgvEx is documented as
> new in 3.2, but exists in 3.1.3
> 
> That should keep someone busy ;)
> 
> Note that this only include functions.
> The API also includes a number of macros such as
> Py_False and Py_RETURN_FALSE, types ,
> and data like PyBool_Type.
> 
> I've not tried to analyse any of these.

Thanks.

I opened http://bugs.python.org/issue11173 for this.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 10 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 Feb 10 16:49:51 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 10 Feb 2011 16:49:51 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D54021C.9000304@egenix.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>
	<4D53BAE4.9070000@dcs.gla.ac.uk>
	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
	<4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com>
	<4D53F592.2080401@dcs.gla.ac.uk>  <4D54021C.9000304@egenix.com>
Message-ID: <1297352991.5203.3.camel@marge>

Le jeudi 10 f?vrier 2011 ? 16:19 +0100, M.-A. Lemburg a ?crit :
> > And the following were added to 3.2,
> > of which only 2 are documented:
> > 
> > PyArg_ValidateKeywordArguments
> > PyAST_CompileEx
> > Py_CompileString
> > Py_CompileStringExFlags
> > PyErr_NewExceptionWithDoc    (documented)
> > PyErr_SyntaxLocationEx
> > PyErr_WarnFormat
> > PyFrame_GetLineNumber
> > PyImport_ExecCodeModuleWithPathnames
> > PyImport_GetMagicTag
> > PyLong_AsLongLongAndOverflow    (documented)
> > PyModule_GetFilenameObject
> > Py_SetPath
> > PyStructSequence_GetItem
> > PyStructSequence_NewType
> > PyStructSequence_SetItem
> > PySys_AddWarnOptionUnicode
> > PySys_AddXOption
> > PySys_FormatStderr
> > PySys_FormatStdout
> > PySys_GetXOptions
> > PyThread_acquire_lock_timed
> > PyType_FromSpec
> > PyUnicode_AsUnicodeCopy
> > PyUnicode_AsWideCharString
> > PyUnicode_EncodeFSDefault
> > PyUnicode_FSDecoder
> > Py_UNICODE_strcat
> > Py_UNICODE_strncmp
> > Py_UNICODE_strrchr
> > PyUnicode_TransformDecimalToASCII

PyErr_WarnFormat, PyImport_ExecCodeModuleWithPathnames,
PyModule_GetFilenameObject, PySys_AddWarnOptionUnicode,
PySys_FormatStderr, PySys_FormatStdout, PyUnicode_AsUnicodeCopy,
PyUnicode_AsWideCharString, PyUnicode_EncodeFSDefault and
PyUnicode_FSDecoder are documented (I wrote most of these functions). I
added references in the issue #11173.

So there are a little bit less than 29/31 of new undocumented functions.

But yes, most Py_UNICODE_* functions are not documented: see issue
#10435 (which has a patch).

victor


From marks at dcs.gla.ac.uk  Thu Feb 10 17:21:28 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Thu, 10 Feb 2011 16:21:28 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <4D54021C.9000304@egenix.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>	<4D53EA20.80403@dcs.gla.ac.uk>
	<4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk>
	<4D54021C.9000304@egenix.com>
Message-ID: <4D541088.8090301@dcs.gla.ac.uk>

<snip>
>> And the following were added to 3.2,
>> of which only 2 are documented:
>>
>> PyArg_ValidateKeywordArguments
>> PyAST_CompileEx
>> Py_CompileString
>> Py_CompileStringExFlags
>> PyErr_NewExceptionWithDoc    (documented)
>> PyErr_SyntaxLocationEx
>> PyErr_WarnFormat
>> PyFrame_GetLineNumber
>> PyImport_ExecCodeModuleWithPathnames
>> PyImport_GetMagicTag
>> PyLong_AsLongLongAndOverflow    (documented)
>> PyModule_GetFilenameObject
>> Py_SetPath
>> PyStructSequence_GetItem
>> PyStructSequence_NewType
>> PyStructSequence_SetItem
>> PySys_AddWarnOptionUnicode
>> PySys_AddXOption
>> PySys_FormatStderr
>> PySys_FormatStdout
>> PySys_GetXOptions
>> PyThread_acquire_lock_timed
>> PyType_FromSpec
>> PyUnicode_AsUnicodeCopy
>> PyUnicode_AsWideCharString
>> PyUnicode_EncodeFSDefault
>> PyUnicode_FSDecoder
>> Py_UNICODE_strcat
>> Py_UNICODE_strncmp
>> Py_UNICODE_strrchr
>> PyUnicode_TransformDecimalToASCII
>>
>> For added confusion PySys_SetArgvEx is documented as
>> new in 3.2, but exists in 3.1.3
>>
>> That should keep someone busy ;)
>>
>> Note that this only include functions.
>> The API also includes a number of macros such as
>> Py_False and Py_RETURN_FALSE, types ,
>> and data like PyBool_Type.
>>
>> I've not tried to analyse any of these.
> 
> Thanks.
> 
> I opened http://bugs.python.org/issue11173 for this.
> 

Please, don't just document all these.
Don't add them to the API, unless they are really needed.

For example,
PySys_FormatStdout and PySys_FormatStderr
get exactly zero hits between them on google code search.
PySys_FormatStdout doesn't even get used in the 3.2 source.

I'm not picking on PySys_FormatStderr, or its author here,
I'm just using it as an example, it seems fairly typical.

According to http://bugs.python.org/issue9599
"I only need PySys_FormatStderr(), but I added also PySys_FormatStdout() 
just to be consistent with PySys_Write*() and because it only costs a 
few line of code."

This seems a little cavalier to me.
That little PyAPI_FUNC() macro carries a lot of obligation in terms of
documentation, future support, and the cost to other implementations.

Cheers,
Mark.



From marks at dcs.gla.ac.uk  Thu Feb 10 17:30:31 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Thu, 10 Feb 2011 16:30:31 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <1297352991.5203.3.camel@marge>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>	<4D53EA20.80403@dcs.gla.ac.uk>
	<4D53ED7F.1050300@egenix.com>	<4D53F592.2080401@dcs.gla.ac.uk>
	<4D54021C.9000304@egenix.com> <1297352991.5203.3.camel@marge>
Message-ID: <4D5412A7.1030309@dcs.gla.ac.uk>

Victor Stinner wrote:
> Le jeudi 10 f?vrier 2011 ? 16:19 +0100, M.-A. Lemburg a ?crit :
>>> And the following were added to 3.2,
>>> of which only 2 are documented:
>>>
>>> PyArg_ValidateKeywordArguments
>>> PyAST_CompileEx
>>> Py_CompileString
>>> Py_CompileStringExFlags
>>> PyErr_NewExceptionWithDoc    (documented)
>>> PyErr_SyntaxLocationEx
>>> PyErr_WarnFormat
>>> PyFrame_GetLineNumber
>>> PyImport_ExecCodeModuleWithPathnames
>>> PyImport_GetMagicTag
>>> PyLong_AsLongLongAndOverflow    (documented)
>>> PyModule_GetFilenameObject
>>> Py_SetPath
>>> PyStructSequence_GetItem
>>> PyStructSequence_NewType
>>> PyStructSequence_SetItem
>>> PySys_AddWarnOptionUnicode
>>> PySys_AddXOption
>>> PySys_FormatStderr
>>> PySys_FormatStdout
>>> PySys_GetXOptions
>>> PyThread_acquire_lock_timed
>>> PyType_FromSpec
>>> PyUnicode_AsUnicodeCopy
>>> PyUnicode_AsWideCharString
>>> PyUnicode_EncodeFSDefault
>>> PyUnicode_FSDecoder
>>> Py_UNICODE_strcat
>>> Py_UNICODE_strncmp
>>> Py_UNICODE_strrchr
>>> PyUnicode_TransformDecimalToASCII
> 
> PyErr_WarnFormat, PyImport_ExecCodeModuleWithPathnames,
> PyModule_GetFilenameObject, PySys_AddWarnOptionUnicode,
> PySys_FormatStderr, PySys_FormatStdout, PyUnicode_AsUnicodeCopy,
> PyUnicode_AsWideCharString, PyUnicode_EncodeFSDefault and
> PyUnicode_FSDecoder are documented (I wrote most of these functions). I
> added references in the issue #11173.

I meant documented in the "What's new in 3.2" section.
Gathering all these in one place might make the extent of the changes 
clearer for all.

> 
> So there are a little bit less than 29/31 of new undocumented functions.
> 
> But yes, most Py_UNICODE_* functions are not documented: see issue
> #10435 (which has a patch).
> 
> 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/marks%40dcs.gla.ac.uk


From solipsis at pitrou.net  Thu Feb 10 17:36:47 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 10 Feb 2011 17:36:47 +0100
Subject: [Python-Dev] API bloat
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de>
	<4D53BAE4.9070000@dcs.gla.ac.uk>
	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
	<4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com>
	<4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com>
	<4D541088.8090301@dcs.gla.ac.uk>
Message-ID: <20110210173647.31b0a4ac@pitrou.net>


> 
> Please, don't just document all these.
> Don't add them to the API, unless they are really needed.

We only add functions when they are actually needed (by us, usually).

> I'm not picking on PySys_FormatStderr, or its author here,
> I'm just using it as an example, it seems fairly typical.

You've found an exception.

Antoine.



From marks at dcs.gla.ac.uk  Thu Feb 10 18:25:54 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Thu, 10 Feb 2011 17:25:54 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <20110210173647.31b0a4ac@pitrou.net>
References: <4D5259B4.8030205@dcs.gla.ac.uk>
	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>
	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>	<4D53EA20.80403@dcs.gla.ac.uk>
	<4D53ED7F.1050300@egenix.com>	<4D53F592.2080401@dcs.gla.ac.uk>
	<4D54021C.9000304@egenix.com>	<4D541088.8090301@dcs.gla.ac.uk>
	<20110210173647.31b0a4ac@pitrou.net>
Message-ID: <4D541FA2.4090801@dcs.gla.ac.uk>

Antoine Pitrou wrote:
>> Please, don't just document all these.
>> Don't add them to the API, unless they are really needed.
> 
> We only add functions when they are actually needed (by us, usually).
If only you (I presume you mean the CPython devs) need them,
why put them in the API.
That underscore prefix saves a lot of trouble in the long run ;)

> 
>> I'm not picking on PySys_FormatStderr, or its author here,
>> I'm just using it as an example, it seems fairly typical.
> 
> You've found an exception.

What about this one then,

PyFrame_GetLineNumber was added because people were using 
PyCode_Addr2Line to get the current line number.

The API will contain then both
PyFrame_GetLineNumber *and* PyCode_Addr2Line.
The API then has even more redundancy.

PyObject_GetAttrString(frame, "f_lineno") should do the job.

Mark.

> 
> 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/marks%40dcs.gla.ac.uk
> 


From g.brandl at gmx.net  Thu Feb 10 19:07:38 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 10 Feb 2011 19:07:38 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D53F592.2080401@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>	<4D53EA20.80403@dcs.gla.ac.uk>
	<4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk>
Message-ID: <ij191f$h94$1@dough.gmane.org>

Am 10.02.2011 15:26, schrieb Mark Shannon:
> M.-A. Lemburg wrote:
>> Mark Shannon wrote:
>>> Nick Coghlan wrote:
>>>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon <marks at dcs.gla.ac.uk>
>>>> wrote:
>>>>> Doing a search for the regex:  "PyAPI_FUNC\([^)]*\) *Py" in .h files,
>>>>> which should match API functions (functions starting _Py are
>>>>> excluded) gives
>>>>> the following result:
>>>>>
>>>>> Version  matches
>>>>> 3.0       717
>>>>> 3.1.3     728
>>>>> 3.2b2     743
>>>>>
>>>>> It would appear the API  bloat is real,
>>>>> not just an artefact of updated docs.
>>>> Since it doesn't account for #ifdef, a naive count like that isn't a
>>>> valid basis for comparison.
>>>>
>>> OK. How about this:
>>>
>>> egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h
>>> finds no matches.
>>>
>>> egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u
>>>
>>> This finds all matches and removes duplicates, so anything defined
>>> multiple time in branches of #ifdef blocks, will only be counted once.
>>>
>>> Version  matches
>>> 3.0       714
>>> 3.1.3     725
>>> 3.2b2     739
>> 
>> Given these numbers, I don't think the subject line really
>> captures the problem accurately enough ... a 2% increase
>> in number of API function per release can hardly be called
>> API bloat :-)
>> 
>>> So given, the revised numbers;
>>>
>>> The "what's new for 3.2" API section:
>>> http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes
>>> lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2.
>> 
>> Could you identify the ones that are not yet documented ?
>> 
>> That would be useful.
> 
> Here's the details:
> 
> The following API functions were removed from 3.1.3:
> 
> PyAST_Compile

This is not correct, for example: this function is still present as
a #define (and there is also a stub implementation so that extensions
compiled against earlier versions can import the symbol).

Georg


From brett at python.org  Thu Feb 10 19:27:32 2011
From: brett at python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 10:27:32 -0800
Subject: [Python-Dev] devguide: Fix a silly statement.
In-Reply-To: <ij02gf$v9v$1@dough.gmane.org>
References: <E1PnIzO-0007bi-1c@dinsdale.python.org>
	<ij02gf$v9v$1@dough.gmane.org>
Message-ID: <AANLkTikNHJ0W=_6CG4KtnbUiRT_hvMzfo-5gV7i=-jUT@mail.gmail.com>

On Wed, Feb 9, 2011 at 23:10, Georg Brandl <g.brandl at gmx.net> wrote:
> Am 09.02.2011 23:58, schrieb brett.cannon:
>> brett.cannon pushed 7101df1bd817 to devguide:
>>
>> http://hg.python.org/devguide/rev/7101df1bd817
>> changeset: ? 291:7101df1bd817
>> branch: ? ? ?hg_transition
>> tag: ? ? ? ? tip
>> user: ? ? ? ?Brett Cannon <brett at python.org>
>> date: ? ? ? ?Wed Feb 09 14:58:17 2011 -0800
>> summary:
>> ? Fix a silly statement.
>>
>> files:
>> ? setup.rst
>>
>> diff --git a/setup.rst b/setup.rst
>> --- a/setup.rst
>> +++ b/setup.rst
>> @@ -34,8 +34,7 @@
>> ?:abbr:`VCS`. It also means you will have better tool
>> ?support through the VCS as it will provide a diff tool, etc.
>>
>> -To get a read-only checkout of CPython's source, you need a working copy the
>> -source code. To get a read-only checkout of
>> +To get a read-only checkout of
>> ?the :ref:`in-development <indevbranch>` branch of Python, run::
>>
>> ? ? ?hg clone http://hg.python.org/cpython
>
> This statement is still somewhat silly, as a) you get a clone, not a checkout
> and b) it is not read only in any way: you can commit just fine. ?The only
> difference will be the entry in .hg/hgrc pointing the default repo to something
> you can't push to.
>
> Skimming through, the whole section "Checking out the code" is still way too
> SVN-point of viewy (e.g. you always get all branches anyway).

I'll take another pass, but do realize this needs to be something that
can easily be understood by someone who has never used hg before, so I
can't get too technically accurate while ignoring a possible base
ignorance of hg and DVCSs as a whole.

From g.brandl at gmx.net  Thu Feb 10 21:08:30 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 10 Feb 2011 21:08:30 +0100
Subject: [Python-Dev] devguide: Fix a silly statement.
In-Reply-To: <AANLkTikNHJ0W=_6CG4KtnbUiRT_hvMzfo-5gV7i=-jUT@mail.gmail.com>
References: <E1PnIzO-0007bi-1c@dinsdale.python.org>	<ij02gf$v9v$1@dough.gmane.org>
	<AANLkTikNHJ0W=_6CG4KtnbUiRT_hvMzfo-5gV7i=-jUT@mail.gmail.com>
Message-ID: <ij1g43$r0t$1@dough.gmane.org>

Am 10.02.2011 19:27, schrieb Brett Cannon:
> On Wed, Feb 9, 2011 at 23:10, Georg Brandl <g.brandl at gmx.net> wrote:
>> Am 09.02.2011 23:58, schrieb brett.cannon:
>>> brett.cannon pushed 7101df1bd817 to devguide:
>>>
>>> http://hg.python.org/devguide/rev/7101df1bd817
>>> changeset:   291:7101df1bd817
>>> branch:      hg_transition
>>> tag:         tip
>>> user:        Brett Cannon <brett at python.org>
>>> date:        Wed Feb 09 14:58:17 2011 -0800
>>> summary:
>>>   Fix a silly statement.
>>>
>>> files:
>>>   setup.rst
>>>
>>> diff --git a/setup.rst b/setup.rst
>>> --- a/setup.rst
>>> +++ b/setup.rst
>>> @@ -34,8 +34,7 @@
>>>  :abbr:`VCS`. It also means you will have better tool
>>>  support through the VCS as it will provide a diff tool, etc.
>>>
>>> -To get a read-only checkout of CPython's source, you need a working copy the
>>> -source code. To get a read-only checkout of
>>> +To get a read-only checkout of
>>>  the :ref:`in-development <indevbranch>` branch of Python, run::
>>>
>>>      hg clone http://hg.python.org/cpython
>>
>> This statement is still somewhat silly, as a) you get a clone, not a checkout
>> and b) it is not read only in any way: you can commit just fine.  The only
>> difference will be the entry in .hg/hgrc pointing the default repo to something
>> you can't push to.
>>
>> Skimming through, the whole section "Checking out the code" is still way too
>> SVN-point of viewy (e.g. you always get all branches anyway).
> 
> I'll take another pass, but do realize this needs to be something that
> can easily be understood by someone who has never used hg before, so I
> can't get too technically accurate while ignoring a possible base
> ignorance of hg and DVCSs as a whole.

Well, it's no good to keep using CVCS terms and mislead users.  That the
"checkout" is not a checkout but a full repository is about the most important
fact about a hg (or any DVCS) clone.

Georg


From sandro.tosi at gmail.com  Thu Feb 10 21:01:35 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 10 Feb 2011 21:01:35 +0100
Subject: [Python-Dev] [Python-checkins] devguide: Move to using mq for
	basic usage.
In-Reply-To: <E1PnINf-0004aR-Fm@dinsdale.python.org>
References: <E1PnINf-0004aR-Fm@dinsdale.python.org>
Message-ID: <AANLkTi=Ghs6Mkqr15h9gyTiBAmRtRmHmEqVaa2CgoccB@mail.gmail.com>

Hi,

On Wed, Feb 9, 2011 at 23:19, brett.cannon <python-checkins at python.org> wrote:
> +project's preference. ?We present here a very simple solution based on mq_
> +(Mercurial Queue) non-core developers.

for non-core devs (ok, this is not the last patch applied to the file,
but it's still there after the next changes).

> +This will update the patch to contain all of the changes you have made up to
> +this point. If you have any you have added or removed, use ``hg add`` or ``hg
> +remove``, respectively, before running ``hg qrefresh``.

If you have any <what's missing?>

> ?This will check and/or fix various common things people forget to do for
> -patches, such as adding any new files needing for the patch to work.
> +patches, such as adding any new files needing for the patch to work (do not

(do note

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

From steveth45 at gmail.com  Thu Feb 10 21:30:02 2011
From: steveth45 at gmail.com (Steve Goss)
Date: Thu, 10 Feb 2011 12:30:02 -0800
Subject: [Python-Dev] Proposal / Questions about OrderedDict literals and/or
	faster C implementation
Message-ID: <AANLkTi=t_kA4jwffSN20tVsycEoNRTFa4pMC0ndzkBef@mail.gmail.com>

I have a proposal for a literal syntax for OrderedDicts which is just
replacing the braces with square brackets:

['a': 1,'b': 2] == OrderedDict([('a', 1),('b', 2)])

OrderedDict literals would follow:

[x : x for x in foo()] == OrderedDict([(x,x) for x in foo()])

The rationale for the syntax is that it follows the set / list /
dict precedent of curly braces for unordered collections, square brackets
for ordered collections, and otherwise aping the normal dict syntax.

OrderedDict is arguable one of the best recent additions to the Python
standard library. Looking at the py3k codebase, it seems like adding
OrderedDicts as a native C implementation at the same time as introducing a
literal syntax with all the additions to the grammar and ast makes sense. A
native implementation would make the memory usage closer to normal dicts
(plus two pointers per element) but be potentially faster for many
operations than even regular dictionaries and certainly much, much faster
than the current Python-only implementation of OrderedDict.

I've started working on this in my free time, but I'm not a seasoned CPython
hacker. Any feedback or pointers would be helpful. Originally, I was
planning on creating a patch first before suggesting this to the mailing
list, but given the scope of the feature and the number of concerns I figure
I might as well test the waters first.

Even if the idea of a literal syntax is dismissed, I think a C
implementation of OrderedDict would be a great addition and I'd love to
help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110210/b4bebc12/attachment.html>

From merwok at netwok.org  Thu Feb 10 21:47:33 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 10 Feb 2011 21:47:33 +0100
Subject: [Python-Dev] Proposal / Questions about OrderedDict literals
 and/or faster C implementation
In-Reply-To: <AANLkTi=t_kA4jwffSN20tVsycEoNRTFa4pMC0ndzkBef@mail.gmail.com>
References: <AANLkTi=t_kA4jwffSN20tVsycEoNRTFa4pMC0ndzkBef@mail.gmail.com>
Message-ID: <4D544EE5.1060504@netwok.org>

Hello,

Thanks for wanting to contribute and welcome to python-dev :)

Ideas are usually discussed first on python-ideas to assess usefulness,
get the pulse of the community, beat the API into shape and such things
before coming up to python-dev.  (A number of core devs are on both lists.)

You may want to search the mail archive for all the previous threads
about adding a C version and literal notation for ordered dicts.

Regards

From victor.stinner at haypocalc.com  Thu Feb 10 22:57:39 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 10 Feb 2011 22:57:39 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D541FA2.4090801@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de>
	<4D53BAE4.9070000@dcs.gla.ac.uk>
	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
	<4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com>
	<4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com>
	<4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net>
	<4D541FA2.4090801@dcs.gla.ac.uk>
Message-ID: <1297375059.9928.0.camel@marge>

Le jeudi 10 f?vrier 2011 ? 17:25 +0000, Mark Shannon a ?crit :
> What about this one then,
> 
> PyFrame_GetLineNumber was added because people were using 
> PyCode_Addr2Line to get the current line number.
> 
> The API will contain then both
> PyFrame_GetLineNumber *and* PyCode_Addr2Line.
> The API then has even more redundancy.
> 
> PyObject_GetAttrString(frame, "f_lineno") should do the job.

Not exactly:

int
PyFrame_GetLineNumber(PyFrameObject *f)
{
    if (f->f_trace)
        return f->f_lineno;
    else
        return PyCode_Addr2Line(f->f_code, f->f_lasti);
}

Victor


From ncoghlan at gmail.com  Fri Feb 11 00:21:22 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Feb 2011 09:21:22 +1000
Subject: [Python-Dev] API bloat
In-Reply-To: <4D541FA2.4090801@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de>
	<4D53BAE4.9070000@dcs.gla.ac.uk>
	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
	<4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com>
	<4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com>
	<4D541088.8090301@dcs.gla.ac.uk>
	<20110210173647.31b0a4ac@pitrou.net>
	<4D541FA2.4090801@dcs.gla.ac.uk>
Message-ID: <AANLkTikp1Y2u5LoCRXXsig4b7_dU74xOhVk7nsGb09no@mail.gmail.com>

On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon <marks at dcs.gla.ac.uk> wrote:
> Antoine Pitrou wrote:
>>>
>>> Please, don't just document all these.
>>> Don't add them to the API, unless they are really needed.
>>
>> We only add functions when they are actually needed (by us, usually).
>
> If only you (I presume you mean the CPython devs) need them,
> why put them in the API.
> That underscore prefix saves a lot of trouble in the long run ;)

Keep in mind that you're asking us to change our audience here. When
we modify the C API, we have precisely *three* audiences in mind:

1. CPython developers
2. authors of CPython extensions
3. developers embedding a CPython interpreter (or interpreters) into
their application

So if we find something that makes life easier for us in group 1, our
natural inclination is to make it available to the people in groups 2
and 3 as well, rather than selfishly reserving it for ourselves. We
will also take aesthetics and obvious symmetries into account when
providing convenience functions (as in the case of
PySys_FormatStdout). It's only when we consider something to be an
ugly hack, or have some other reason to think we may want to change it
in the future, that we opt to make it a private implementation detail.

The audience consisting of "authors of other implementations trying to
mimic the CPython C API" has never even been on the radar. That's
quite a significant philosophical shift, so coming in and asking us to
apply it retroactively to a release in its RC phase comes across as
being *very* presumptuous.

Now that the issue has been brought up, it can certainly be taken into
consideration for 3.3. The idea of defining a Py_PORTABLE_API that is
even more restrictive than PEP 384 (e.g. eliminating lots of old cruft
that is a legacy of CPython's long history of development when it was
the *only* viable Python implementation) may also be worth exploring.
But no, at this late stage nothing significant is going to be done in
the context of 3.2, except perhaps describing the C API changes in
more detail in the What's New document (whether or not that happens is
up to Raymond - the C API is of very little interest to most Python
users, who will either use pre-existing C extensions, or else use
something like ctypes, Cython, Pyrex, Boost or SWIG to deal with the
details of the C/Python boundary).

Cheers,
Nick.

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

From ncoghlan at gmail.com  Fri Feb 11 00:25:19 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Feb 2011 09:25:19 +1000
Subject: [Python-Dev] [Python-checkins] r88387 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110210184236.F1834EEB4E@mail.python.org>
References: <20110210184236.F1834EEB4E@mail.python.org>
Message-ID: <AANLkTi=6qLH3Pp3teEVaNDeXVRx4hHtfASnkP5CRz=xx@mail.gmail.com>

On Fri, Feb 11, 2011 at 4:42 AM, giampaolo.rodola
<python-checkins at python.org> wrote:
> Author: giampaolo.rodola
> Date: Thu Feb 10 19:42:36 2011
> New Revision: 88387
>
> Log:
> get rid of asyncore.dispatcher's debug attribute, which is no longer used (assuming it ever was).

Reviewer? NEWS entry? RM approval? Tracker issue?

Removing a public attribute seems like an odd change to be making at
this stage of a release. What if there is third party code that uses
that attribute to enable additional debugging info in asyncore?

Cheers,
Nick.

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

From catch-all at masklinn.net  Fri Feb 11 10:06:57 2011
From: catch-all at masklinn.net (Xavier Morel)
Date: Fri, 11 Feb 2011 10:06:57 +0100
Subject: [Python-Dev] Proposal / Questions about OrderedDict literals
	and/or faster C implementation
In-Reply-To: <4D544EE5.1060504@netwok.org>
References: <AANLkTi=t_kA4jwffSN20tVsycEoNRTFa4pMC0ndzkBef@mail.gmail.com>
	<4D544EE5.1060504@netwok.org>
Message-ID: <CB59C51B-8302-4780-A896-7ADA26887224@masklinn.net>

On 2011-02-10, at 21:47 , ?ric Araujo wrote:
> Ideas are usually discussed first on python-ideas to assess usefulness,
> get the pulse of the community, beat the API into shape and such things
> before coming up to python-dev.  (A number of core devs are on both lists.)
> 
> You may want to search the mail archive for all the previous threads
> about adding a C version and literal notation for ordered dicts.

Indeed, there's been a discussion on this very subject not three weeks ago: http://mail.python.org/pipermail/python-ideas/2011-January/009037.html

I'm guessing this request is going to get more common for some time, as people are getting aware Ruby switched its Hash implementation to an ordered dict in 1.9 (well they didn't exactly switch anything around, they added back and next pointers to their dict cells)

From marks at dcs.gla.ac.uk  Fri Feb 11 10:29:50 2011
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Fri, 11 Feb 2011 09:29:50 +0000
Subject: [Python-Dev] API bloat
In-Reply-To: <AANLkTikp1Y2u5LoCRXXsig4b7_dU74xOhVk7nsGb09no@mail.gmail.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>	<4D53EA20.80403@dcs.gla.ac.uk>	<4D53ED7F.1050300@egenix.com>	<4D53F592.2080401@dcs.gla.ac.uk>	<4D54021C.9000304@egenix.com>	<4D541088.8090301@dcs.gla.ac.uk>	<20110210173647.31b0a4ac@pitrou.net>	<4D541FA2.4090801@dcs.gla.ac.uk>
	<AANLkTikp1Y2u5LoCRXXsig4b7_dU74xOhVk7nsGb09no@mail.gmail.com>
Message-ID: <4D55018E.3030608@dcs.gla.ac.uk>

Nick Coghlan wrote:
> On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon <marks at dcs.gla.ac.uk> wrote:
>> Antoine Pitrou wrote:
>>>> Please, don't just document all these.
>>>> Don't add them to the API, unless they are really needed.
>>> We only add functions when they are actually needed (by us, usually).
>> If only you (I presume you mean the CPython devs) need them,
>> why put them in the API.
>> That underscore prefix saves a lot of trouble in the long run ;)
> 
> Keep in mind that you're asking us to change our audience here. When
> we modify the C API, we have precisely *three* audiences in mind:
> 
> 1. CPython developers
> 2. authors of CPython extensions
> 3. developers embedding a CPython interpreter (or interpreters) into
> their application

This makes me wonder who `owns' the API.
Is the CPython developers, the Python community as a whole, the PSF?
(Another one for Python-ideas)

> 
> So if we find something that makes life easier for us in group 1, our
> natural inclination is to make it available to the people in groups 2
> and 3 as well, rather than selfishly reserving it for ourselves. We
> will also take aesthetics and obvious symmetries into account when
> providing convenience functions (as in the case of
> PySys_FormatStdout). It's only when we consider something to be an
> ugly hack, or have some other reason to think we may want to change it
> in the future, that we opt to make it a private implementation detail.
> 
> The audience consisting of "authors of other implementations trying to
> mimic the CPython C API" has never even been on the radar. That's
> quite a significant philosophical shift, so coming in and asking us to
> apply it retroactively to a release in its RC phase comes across as
> being *very* presumptuous.

Sorry to leave it the RC stage,
I just didn't pick up the changes until now.
Don't forget that `other implementations' include future versions of 
CPython.

> 
> Now that the issue has been brought up, it can certainly be taken into
> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is
> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft
> that is a legacy of CPython's long history of development when it was
> the *only* viable Python implementation) may also be worth exploring.

Absolutely. I intend to do just that.

> But no, at this late stage nothing significant is going to be done in
> the context of 3.2, except perhaps describing the C API changes in
> more detail in the What's New document (whether or not that happens is
> up to Raymond - the C API is of very little interest to most Python
> users, who will either use pre-existing C extensions, or else use
> something like ctypes, Cython, Pyrex, Boost or SWIG to deal with the
> details of the C/Python boundary).

I do realise that its rather late in the release process,
so I'll leave it that.

Thanks,
Mark.

> 
> Cheers,
> Nick.
> 


From ncoghlan at gmail.com  Fri Feb 11 14:25:10 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Feb 2011 23:25:10 +1000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110211130418.5D6F4EE9CE@mail.python.org>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
Message-ID: <AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>

On Fri, Feb 11, 2011 at 11:04 PM, giampaolo.rodola
<python-checkins at python.org> wrote:
> Author: giampaolo.rodola
> Date: Fri Feb 11 14:04:18 2011
> New Revision: 88395
>
> Log:
> asyncore: introduce a new 'closed' attribute to make sure that dispatcher gets closed only once.
> In different occasions close() might be called more than once, causing problems with already disconnected sockets/dispatchers.

Giampaolo,

This checkin and the previous one are not appropriate for the release
candidate phase of the 3.2 release. At the very least, they need to
identify the second core dev that reviewed them, as well as a
reference to the tracker issue where the RM approved them for
inclusion.

Regards,
Nick.

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

From g.rodola at gmail.com  Fri Feb 11 14:52:21 2011
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Fri, 11 Feb 2011 14:52:21 +0100
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
Message-ID: <AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>

I'm sorry, I'm going to revert those checkins.
They are very minor changes which I'm sure don't break anything, but I
understand your complain.


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


2011/2/11 Nick Coghlan <ncoghlan at gmail.com>:
> On Fri, Feb 11, 2011 at 11:04 PM, giampaolo.rodola
> <python-checkins at python.org> wrote:
>> Author: giampaolo.rodola
>> Date: Fri Feb 11 14:04:18 2011
>> New Revision: 88395
>>
>> Log:
>> asyncore: introduce a new 'closed' attribute to make sure that dispatcher gets closed only once.
>> In different occasions close() might be called more than once, causing problems with already disconnected sockets/dispatchers.
>
> Giampaolo,
>
> This checkin and the previous one are not appropriate for the release
> candidate phase of the 3.2 release. At the very least, they need to
> identify the second core dev that reviewed them, as well as a
> reference to the tracker issue where the RM approved them for
> inclusion.
>
> Regards,
> Nick.
>
> --
> Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
>

From victor.stinner at haypocalc.com  Fri Feb 11 15:28:01 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 11 Feb 2011 15:28:01 +0100
Subject: [Python-Dev] [Python-checkins] r88395 -
 python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
Message-ID: <1297434481.3175.6.camel@marge>

Le vendredi 11 f?vrier 2011 ? 14:52 +0100, Giampaolo Rodol? a ?crit :
> >> New Revision: 88395
> >>
> >> Log:
> >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher gets closed only once.
> >> In different occasions close() might be called more than once, causing problems with already disconnected sockets/dispatchers.
> > (...)
> I'm sorry, I'm going to revert those checkins.
> They are very minor changes which I'm sure don't break anything, but I
> understand your complain.

dispatcher.closing is a public attribute: some programs my rely on it. I
checked mine: it uses "connected", but not closing :-)

I think that it will be fine for Python 3.3, but not for 3.2 (too late).
And you should document your change, because it is the public API.

Victor


From guido at python.org  Fri Feb 11 17:06:23 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 11 Feb 2011 08:06:23 -0800
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <1297434481.3175.6.camel@marge>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
Message-ID: <AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>

On Fri, Feb 11, 2011 at 6:28 AM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> Le vendredi 11 f?vrier 2011 ? 14:52 +0100, Giampaolo Rodol? a ?crit :
>> >> New Revision: 88395
>> >>
>> >> Log:
>> >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher gets closed only once.
>> >> In different occasions close() might be called more than once, causing problems with already disconnected sockets/dispatchers.
>> > (...)
>> I'm sorry, I'm going to revert those checkins.
>> They are very minor changes which I'm sure don't break anything, but I
>> understand your complain.
>
> dispatcher.closing is a public attribute: some programs my rely on it. I
> checked mine: it uses "connected", but not closing :-)
>
> I think that it will be fine for Python 3.3, but not for 3.2 (too late).
> And you should document your change, because it is the public API.

And finally remember that asyncore is the most monkey-patched module
in the world. :-)

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

From status at bugs.python.org  Fri Feb 11 18:07:06 2011
From: status at bugs.python.org (Python tracker)
Date: Fri, 11 Feb 2011 18:07:06 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20110211170706.3CE971CC5D@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2011-02-04 - 2011-02-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    2627 (+42)
  closed 20348 (+34)
  total  22975 (+76)

Open issues with patches: 1119 


Issues opened (56)
==================

#6378: Patch to make 'idle.bat' run idle.pyw using appropriate Python
http://bugs.python.org/issue6378  reopened by srid

#7074: Turtle module crashes python
http://bugs.python.org/issue7074  reopened by terry.reedy

#9920: test_cmath on atan fails on AIX
http://bugs.python.org/issue9920  reopened by mark.dickinson

#11120: threading.Thread.daemon Documentation Incomplete
http://bugs.python.org/issue11120  opened by cardinalbiggles

#11122: bdist_rpm fails
http://bugs.python.org/issue11122  opened by purpleidea

#11123: problem with packaged dependency extracter script, pdeps
http://bugs.python.org/issue11123  opened by $$Coffeepot$$

#11126: Wave.py does not always write proper length in header
http://bugs.python.org/issue11126  opened by jtidman

#11127: sockets should not be pickleable
http://bugs.python.org/issue11127  opened by pitrou

#11128: decimal.py: to_integral() corner cases
http://bugs.python.org/issue11128  opened by skrah

#11131: decimal.py: plus/minus with ROUND_FLOOR
http://bugs.python.org/issue11131  opened by skrah

#11133: inspect.getattr_static code execution
http://bugs.python.org/issue11133  opened by durban

#11134: Add missing type slots
http://bugs.python.org/issue11134  opened by loewis

#11135: Redundant doc field in TypeSpec
http://bugs.python.org/issue11135  opened by loewis

#11140: threading.Lock().release() raises _thread.error, not RuntimeEr
http://bugs.python.org/issue11140  opened by aaugustin

#11142: xmlrpclib.ServerProxy with verbosity produces bad output
http://bugs.python.org/issue11142  opened by Erez.Sh

#11144: int(float) may return a long for no reason
http://bugs.python.org/issue11144  opened by arigo

#11145: '%o' % user-defined instance
http://bugs.python.org/issue11145  opened by arigo

#11147: _Py_ANNOTATE_MEMORY_ORDER has unused argument, effects code wh
http://bugs.python.org/issue11147  opened by ideasman42

#11148: Crash and error message from Python VM
http://bugs.python.org/issue11148  opened by pcdinh

#11149: [PATCH] Configure should enable -fwrapv for clang
http://bugs.python.org/issue11149  opened by cartman

#11151: Arguments to various types not specified in types module
http://bugs.python.org/issue11151  opened by noufal

#11152: pb in zipfile module
http://bugs.python.org/issue11152  opened by Emmanuel LAB

#11153: urllib2 basic auth parser handle unquoted realm in WWW-Authent
http://bugs.python.org/issue11153  opened by mmb

#11155: multiprocessing.Queue's put() signature differs from docs
http://bugs.python.org/issue11155  opened by Erik.Cederstrand

#11158: Python VM deadlock
http://bugs.python.org/issue11158  opened by pcdinh

#11159: Sax parser crashes if given unicode file name
http://bugs.python.org/issue11159  opened by ricli85

#11160: ZipFile.comment expects bytes
http://bugs.python.org/issue11160  opened by xuanji

#11161: futures.ProcessPoolExecutor hangs
http://bugs.python.org/issue11161  opened by pclinch

#11163: iter() documentation code doesn't work
http://bugs.python.org/issue11163  opened by mgrazebrook

#11164: xml shouldn't use _xmlplus
http://bugs.python.org/issue11164  opened by Arfrever

#11165: Document PyEval_Call* functions
http://bugs.python.org/issue11165  opened by ncoghlan

#11166: No exit when daemon thread is running.
http://bugs.python.org/issue11166  opened by dmahn

#11168: UnicodeEncodeError on recusion limit if the script filename is
http://bugs.python.org/issue11168  opened by haypo

#11169: compileall doesn't support the PEP 383 (undecodable paths/file
http://bugs.python.org/issue11169  opened by haypo

#11171: Python 2.7.1 does not start when "./configure" is used with  "
http://bugs.python.org/issue11171  opened by hoel

#11172: Avoid '.' as runpath on AIX
http://bugs.python.org/issue11172  opened by haubi

#11173: Undocumented public APIs in Python 3.2
http://bugs.python.org/issue11173  opened by lemburg

#11174: add argparse formatting option to display type names for metav
http://bugs.python.org/issue11174  opened by bethard

#11175: allow argparse FileType to accept encoding and errors argument
http://bugs.python.org/issue11175  opened by bethard

#11176: give more meaningful argument names in argparse documentation
http://bugs.python.org/issue11176  opened by bethard

#11177: Set asyncore create_socket default argument
http://bugs.python.org/issue11177  opened by giampaolo.rodola

#11178: Running tests inside a package by module name fails
http://bugs.python.org/issue11178  opened by michael.foord

#11179: ccbench doesn't work on 3.1/2.7
http://bugs.python.org/issue11179  opened by pitrou

#11181: TLS end connection not detected properly in retrbinary
http://bugs.python.org/issue11181  opened by adiroiban

#11182: pydoc.Scanner class not used by anything
http://bugs.python.org/issue11182  opened by ron_adam

#11183: Finer-grained exceptions for the ssl module
http://bugs.python.org/issue11183  opened by pitrou

#11184: Broken large file support on AIX
http://bugs.python.org/issue11184  opened by sable

#11185: test_wait4 error on AIX
http://bugs.python.org/issue11185  opened by sable

#11186: pydoc: HTMLDoc.index() doesn't support PEP 383
http://bugs.python.org/issue11186  opened by haypo

#11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede
http://bugs.python.org/issue11187  opened by haypo

#11188: test_time error on AIX
http://bugs.python.org/issue11188  opened by sable

#11190: test_locale error on AIX
http://bugs.python.org/issue11190  opened by sable

#11191: test_search_cpp error on AIX (with xlc)
http://bugs.python.org/issue11191  opened by sable

#11192: test_socket error on AIX
http://bugs.python.org/issue11192  opened by sable

#11193: test_subprocess error on AIX
http://bugs.python.org/issue11193  opened by sable

#940286: pydoc.Helper.help() ignores input/output init parameters
http://bugs.python.org/issue940286  reopened by eric.araujo



Most recent 15 issues with no replies (15)
==========================================

#11192: test_socket error on AIX
http://bugs.python.org/issue11192

#11191: test_search_cpp error on AIX (with xlc)
http://bugs.python.org/issue11191

#11188: test_time error on AIX
http://bugs.python.org/issue11188

#11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede
http://bugs.python.org/issue11187

#11185: test_wait4 error on AIX
http://bugs.python.org/issue11185

#11183: Finer-grained exceptions for the ssl module
http://bugs.python.org/issue11183

#11182: pydoc.Scanner class not used by anything
http://bugs.python.org/issue11182

#11179: ccbench doesn't work on 3.1/2.7
http://bugs.python.org/issue11179

#11178: Running tests inside a package by module name fails
http://bugs.python.org/issue11178

#11174: add argparse formatting option to display type names for metav
http://bugs.python.org/issue11174

#11172: Avoid '.' as runpath on AIX
http://bugs.python.org/issue11172

#11171: Python 2.7.1 does not start when "./configure" is used with  "
http://bugs.python.org/issue11171

#11169: compileall doesn't support the PEP 383 (undecodable paths/file
http://bugs.python.org/issue11169

#11168: UnicodeEncodeError on recusion limit if the script filename is
http://bugs.python.org/issue11168

#11166: No exit when daemon thread is running.
http://bugs.python.org/issue11166



Most recent 15 issues waiting for review (15)
=============================================

#11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede
http://bugs.python.org/issue11187

#11184: Broken large file support on AIX
http://bugs.python.org/issue11184

#11177: Set asyncore create_socket default argument
http://bugs.python.org/issue11177

#11172: Avoid '.' as runpath on AIX
http://bugs.python.org/issue11172

#11171: Python 2.7.1 does not start when "./configure" is used with  "
http://bugs.python.org/issue11171

#11169: compileall doesn't support the PEP 383 (undecodable paths/file
http://bugs.python.org/issue11169

#11168: UnicodeEncodeError on recusion limit if the script filename is
http://bugs.python.org/issue11168

#11155: multiprocessing.Queue's put() signature differs from docs
http://bugs.python.org/issue11155

#11153: urllib2 basic auth parser handle unquoted realm in WWW-Authent
http://bugs.python.org/issue11153

#11149: [PATCH] Configure should enable -fwrapv for clang
http://bugs.python.org/issue11149

#11144: int(float) may return a long for no reason
http://bugs.python.org/issue11144

#11135: Redundant doc field in TypeSpec
http://bugs.python.org/issue11135

#11134: Add missing type slots
http://bugs.python.org/issue11134

#11131: decimal.py: plus/minus with ROUND_FLOOR
http://bugs.python.org/issue11131

#11123: problem with packaged dependency extracter script, pdeps
http://bugs.python.org/issue11123



Top 10 most discussed issues (10)
=================================

#9334: argparse does not accept options taking arguments beginning wi
http://bugs.python.org/issue9334  16 msgs

#11116: mailbox and email errors
http://bugs.python.org/issue11116  15 msgs

#11063: uuid.py module import has heavy side effects
http://bugs.python.org/issue11063  14 msgs

#10966: eliminate use of ImportError implicitly representing SkipTest
http://bugs.python.org/issue10966  13 msgs

#11184: Broken large file support on AIX
http://bugs.python.org/issue11184  11 msgs

#4681: mmap offset should be off_t instead of ssize_t, and size calcu
http://bugs.python.org/issue4681  10 msgs

#11077: Tkinter is not thread safe
http://bugs.python.org/issue11077  10 msgs

#10882: Add os.sendfile()
http://bugs.python.org/issue10882   9 msgs

#11071: What's New review comments
http://bugs.python.org/issue11071   9 msgs

#11122: bdist_rpm fails
http://bugs.python.org/issue11122   9 msgs



Issues closed (38)
==================

#2228: Imaplib speedup patch
http://bugs.python.org/issue2228  closed by pitrou

#7284: optparse - display version in usage by default
http://bugs.python.org/issue7284  closed by sandro.tosi

#7678: subprocess.Popen pipeline example code in the documentation is
http://bugs.python.org/issue7678  closed by gregory.p.smith

#8691: Doc: left alignment is not the default for numbers
http://bugs.python.org/issue8691  closed by georg.brandl

#10298: zipfile: incorrect comment size will prevent extracting
http://bugs.python.org/issue10298  closed by rep

#10891: Tweak sorting howto to eliminate redundancy
http://bugs.python.org/issue10891  closed by rhettinger

#10971: python Lib/test/regrtest.py -R 3:3: test_zipimport_support fai
http://bugs.python.org/issue10971  closed by ncoghlan

#11003: os.system should be deprecated in favour of subprocess module
http://bugs.python.org/issue11003  closed by rhettinger

#11067: Py_LIMITED_API breaks most PySomething_Check() functions
http://bugs.python.org/issue11067  closed by loewis

#11079: Make OS X entry in Applications like that in Windows
http://bugs.python.org/issue11079  closed by ned.deily

#11110: Py_DECREF->Py_XDECREF in Module/_sqlite/module.c
http://bugs.python.org/issue11110  closed by brett.cannon

#11118: Fix python3 None export
http://bugs.python.org/issue11118  closed by loewis

#11119: Passing a socket to a process (multiprocessing module)
http://bugs.python.org/issue11119  closed by pitrou

#11121: libpython3.so support with --enable-shared
http://bugs.python.org/issue11121  closed by loewis

#11124: test_posix failure on the Leopard buildbot
http://bugs.python.org/issue11124  closed by ned.deily

#11125: csv documentation should not use open() without close()
http://bugs.python.org/issue11125  closed by eric.araujo

#11129: logging: allow multiple entries in qualname config
http://bugs.python.org/issue11129  closed by vinay.sajip

#11130: SocketServer: server_address is... a socket
http://bugs.python.org/issue11130  closed by orsenthil

#11132: compileall.compile_dir loses 'optimize' parameter in recursion
http://bugs.python.org/issue11132  closed by georg.brandl

#11136: imaplib IMAP4_SSL shutdown gets socket error in py 3.2
http://bugs.python.org/issue11136  closed by pitrou

#11137: clarify use of imaplib IMAP4(_SSL) shutdown
http://bugs.python.org/issue11137  closed by pitrou

#11138: Docs: incollect example: "fill" and "align"
http://bugs.python.org/issue11138  closed by georg.brandl

#11139: subprocess: Arguments to .bat scripts get interpreted by shell
http://bugs.python.org/issue11139  closed by SilentGhost

#11141: 2.x range() in 3.x shelve documentation
http://bugs.python.org/issue11141  closed by pitrou

#11143: Issue with the issue tracker
http://bugs.python.org/issue11143  closed by r.david.murray

#11146: Add a feature similar to C++ "using some_namespace"
http://bugs.python.org/issue11146  closed by r.david.murray

#11150: SVN credentials can't be provided to easy_install
http://bugs.python.org/issue11150  closed by r.david.murray

#11154: Alternate name for __pycache__
http://bugs.python.org/issue11154  closed by rhettinger

#11156: email.encoders.encode_base64 create a single long line
http://bugs.python.org/issue11156  closed by r.david.murray

#11157: Use socket.accept4 syscall under linux
http://bugs.python.org/issue11157  closed by pitrou

#11162: Add tuple/list sep to string split method
http://bugs.python.org/issue11162  closed by rhettinger

#11167: Overflow in unicode_hash
http://bugs.python.org/issue11167  closed by skrah

#11170: (MacOS X) Crash on non-english language keyboard input in Text
http://bugs.python.org/issue11170  closed by r.david.murray

#11180: More efficient nlargest()/nsmallest()
http://bugs.python.org/issue11180  closed by rhettinger

#11189: test_resource error on AIX
http://bugs.python.org/issue11189  closed by sable

#1615376: subprocess doesn\'t handle SIGPIPE
http://bugs.python.org/issue1615376  closed by gregory.p.smith

#11061: Verify command option before parsing config file
http://bugs.python.org/issue11061  closed by eric.araujo

#1704474: optparse tests fail under Jython
http://bugs.python.org/issue1704474  closed by sandro.tosi

From tjreedy at udel.edu  Fri Feb 11 19:16:12 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 11 Feb 2011 13:16:12 -0500
Subject: [Python-Dev] API bloat
In-Reply-To: <4D55018E.3030608@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>	<4D53EA20.80403@dcs.gla.ac.uk>	<4D53ED7F.1050300@egenix.com>	<4D53F592.2080401@dcs.gla.ac.uk>	<4D54021C.9000304@egenix.com>	<4D541088.8090301@dcs.gla.ac.uk>	<20110210173647.31b0a4ac@pitrou.net>	<4D541FA2.4090801@dcs.gla.ac.uk>	<AANLkTikp1Y2u5LoCRXXsig4b7_dU74xOhVk7nsGb09no@mail.gmail.com>
	<4D55018E.3030608@dcs.gla.ac.uk>
Message-ID: <ij3udb$u4r$1@dough.gmane.org>

On 2/11/2011 4:29 AM, Mark Shannon wrote:
> Nick Coghlan wrote:

>> Now that the issue has been brought up, it can certainly be taken into
>> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is
>> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft
>> that is a legacy of CPython's long history of development when it was
>> the *only* viable Python implementation) may also be worth exploring.
>
> Absolutely. I intend to do just that.

I think we should try to have deprecations and removals in the codebase 
by the first alpha release for maximal testing. GP's asyncore changes 
inspired this thought, but I would apply it generally.

-- 
Terry Jan Reedy


From stutzbach at google.com  Fri Feb 11 19:11:54 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Fri, 11 Feb 2011 10:11:54 -0800
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
Message-ID: <AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>

On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum <guido at python.org> wrote:
>
> And finally remember that asyncore is the most monkey-patched module
> in the world. :-)


I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110211/ba67a952/attachment.html>

From solipsis at pitrou.net  Fri Feb 11 19:28:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 11 Feb 2011 19:28:25 +0100
Subject: [Python-Dev] API bloat
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de>
	<4D53BAE4.9070000@dcs.gla.ac.uk>
	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
	<4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com>
	<4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com>
	<4D541088.8090301@dcs.gla.ac.uk>
	<20110210173647.31b0a4ac@pitrou.net>
	<4D541FA2.4090801@dcs.gla.ac.uk>
	<AANLkTikp1Y2u5LoCRXXsig4b7_dU74xOhVk7nsGb09no@mail.gmail.com>
	<4D55018E.3030608@dcs.gla.ac.uk> <ij3udb$u4r$1@dough.gmane.org>
Message-ID: <20110211192825.79159318@pitrou.net>

On Fri, 11 Feb 2011 13:16:12 -0500
Terry Reedy <tjreedy at udel.edu> wrote:
> On 2/11/2011 4:29 AM, Mark Shannon wrote:
> > Nick Coghlan wrote:
> 
> >> Now that the issue has been brought up, it can certainly be taken into
> >> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is
> >> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft
> >> that is a legacy of CPython's long history of development when it was
> >> the *only* viable Python implementation) may also be worth exploring.
> >
> > Absolutely. I intend to do just that.
> 
> I think we should try to have deprecations and removals in the codebase 
> by the first alpha release for maximal testing.

Why would we deprecate or remove anything? Are some functions useless?
Reducing the number of API functions is not a goal in itself.

Regards

Antoine.



From benjamin at python.org  Fri Feb 11 19:35:59 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 11 Feb 2011 12:35:59 -0600
Subject: [Python-Dev] API bloat
In-Reply-To: <20110211192825.79159318@pitrou.net>
References: <4D5259B4.8030205@dcs.gla.ac.uk> <iitn7u$tpj$1@dough.gmane.org>
	<4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de>
	<4D53BAE4.9070000@dcs.gla.ac.uk>
	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>
	<4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com>
	<4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com>
	<4D541088.8090301@dcs.gla.ac.uk>
	<20110210173647.31b0a4ac@pitrou.net>
	<4D541FA2.4090801@dcs.gla.ac.uk>
	<AANLkTikp1Y2u5LoCRXXsig4b7_dU74xOhVk7nsGb09no@mail.gmail.com>
	<4D55018E.3030608@dcs.gla.ac.uk> <ij3udb$u4r$1@dough.gmane.org>
	<20110211192825.79159318@pitrou.net>
Message-ID: <AANLkTimZYpmCWHViTuq4wD7yB4E+ORfDZKC1iG+6dF5-@mail.gmail.com>

2011/2/11 Antoine Pitrou <solipsis at pitrou.net>:
> On Fri, 11 Feb 2011 13:16:12 -0500
> Terry Reedy <tjreedy at udel.edu> wrote:
>> On 2/11/2011 4:29 AM, Mark Shannon wrote:
>> > Nick Coghlan wrote:
>>
>> >> Now that the issue has been brought up, it can certainly be taken into
>> >> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is
>> >> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft
>> >> that is a legacy of CPython's long history of development when it was
>> >> the *only* viable Python implementation) may also be worth exploring.
>> >
>> > Absolutely. I intend to do just that.
>>
>> I think we should try to have deprecations and removals in the codebase
>> by the first alpha release for maximal testing.
>
> Why would we deprecate or remove anything? Are some functions useless?
> Reducing the number of API functions is not a goal in itself.

I think he's referring to deprecations and removals in general.



-- 
Regards,
Benjamin

From solipsis at pitrou.net  Fri Feb 11 19:36:52 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 11 Feb 2011 19:36:52 +0100
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
Message-ID: <20110211193652.0395d199@pitrou.net>

On Fri, 11 Feb 2011 10:11:54 -0800
Daniel Stutzbach <stutzbach at google.com> wrote:
> On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum <guido at python.org> wrote:
> >
> > And finally remember that asyncore is the most monkey-patched module
> > in the world. :-)
> 
> 
> I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys.

Would that be a Mapping or a Sequence?



From benjamin at python.org  Fri Feb 11 19:44:19 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 11 Feb 2011 12:44:19 -0600
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110211193652.0395d199@pitrou.net>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<20110211193652.0395d199@pitrou.net>
Message-ID: <AANLkTi=eLyV=dmQn-ebb93C7v2EUs3LumeaODgNshOyT@mail.gmail.com>

2011/2/11 Antoine Pitrou <solipsis at pitrou.net>:
> On Fri, 11 Feb 2011 10:11:54 -0800
> Daniel Stutzbach <stutzbach at google.com> wrote:
>> On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum <guido at python.org> wrote:
>> >
>> > And finally remember that asyncore is the most monkey-patched module
>> > in the world. :-)
>>
>>
>> I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys.
>
> Would that be a Mapping or a Sequence?

Actually, probably Laughable.



-- 
Regards,
Benjamin

From g.rodola at gmail.com  Fri Feb 11 20:56:40 2011
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Fri, 11 Feb 2011 20:56:40 +0100
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
Message-ID: <AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>

Yeah, the original API design (which is very inflexible) and the lack
of maintenance for many years is at the base of asyncore problems.
I still think it worths some love as a stdlib module, though.
For 3.3 I have in mind to revamp asyncore/asynchat a bit by
introducing SSL support and finally add a scheduler (issue 1641).


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

2011/2/11 Daniel Stutzbach <stutzbach at google.com>:
> On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum <guido at python.org> wrote:
>>
>> And finally remember that asyncore is the most monkey-patched module
>> in the world. :-)
>
> I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys.
> --
> Daniel Stutzbach
>
> _______________________________________________
> 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 martin at v.loewis.de  Fri Feb 11 21:20:04 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 11 Feb 2011 21:20:04 +0100
Subject: [Python-Dev] API bloat
In-Reply-To: <4D55018E.3030608@dcs.gla.ac.uk>
References: <4D5259B4.8030205@dcs.gla.ac.uk>	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>	<4D53EA20.80403@dcs.gla.ac.uk>	<4D53ED7F.1050300@egenix.com>	<4D53F592.2080401@dcs.gla.ac.uk>	<4D54021C.9000304@egenix.com>	<4D541088.8090301@dcs.gla.ac.uk>	<20110210173647.31b0a4ac@pitrou.net>	<4D541FA2.4090801@dcs.gla.ac.uk>	<AANLkTikp1Y2u5LoCRXXsig4b7_dU74xOhVk7nsGb09no@mail.gmail.com>
	<4D55018E.3030608@dcs.gla.ac.uk>
Message-ID: <4D5599F4.2040500@v.loewis.de>

>> 1. CPython developers
>> 2. authors of CPython extensions
>> 3. developers embedding a CPython interpreter (or interpreters) into
>> their application
> 
> This makes me wonder who `owns' the API.
> Is the CPython developers, the Python community as a whole, the PSF?
> (Another one for Python-ideas)

Clearly the CPython contributors own the API. There are both policies
for additions and policies for removal, and so far, these policies
haven't been challenged.

The "addition" policy is that anything can be added as long as it's
reasonable that future versions support it, and that there is a
plausible use case for an embedder or extender actually making use of
the API.

The "removal" policy is that things can be removed after "proper"
deprecation. The precise requirements of deprecation depend on how
widely the API is being used.

More explicitly: while it is policy to consider alternative
implementations when changing the language or the standard library,
it is not policy to consider alternative implementations when
changing the C API.

Regards,
Martin

From tjreedy at udel.edu  Fri Feb 11 21:34:10 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 11 Feb 2011 15:34:10 -0500
Subject: [Python-Dev] API bloat
In-Reply-To: <AANLkTimZYpmCWHViTuq4wD7yB4E+ORfDZKC1iG+6dF5-@mail.gmail.com>
References: <4D5259B4.8030205@dcs.gla.ac.uk>
	<iitn7u$tpj$1@dough.gmane.org>	<4D526E57.9030206@dcs.gla.ac.uk>
	<4D52F127.4050906@v.loewis.de>	<4D53BAE4.9070000@dcs.gla.ac.uk>	<AANLkTim+NUVc9__QnrtLn7HtY3FDpC6qrGP+BnoVdbOP@mail.gmail.com>	<4D53EA20.80403@dcs.gla.ac.uk>
	<4D53ED7F.1050300@egenix.com>	<4D53F592.2080401@dcs.gla.ac.uk>
	<4D54021C.9000304@egenix.com>	<4D541088.8090301@dcs.gla.ac.uk>	<20110210173647.31b0a4ac@pitrou.net>	<4D541FA2.4090801@dcs.gla.ac.uk>	<AANLkTikp1Y2u5LoCRXXsig4b7_dU74xOhVk7nsGb09no@mail.gmail.com>	<4D55018E.3030608@dcs.gla.ac.uk>
	<ij3udb$u4r$1@dough.gmane.org>	<20110211192825.79159318@pitrou.net>
	<AANLkTimZYpmCWHViTuq4wD7yB4E+ORfDZKC1iG+6dF5-@mail.gmail.com>
Message-ID: <ij46g1$ak7$1@dough.gmane.org>

On 2/11/2011 1:35 PM, Benjamin Peterson wrote:
> 2011/2/11 Antoine Pitrou<solipsis at pitrou.net>:
>> On Fri, 11 Feb 2011 13:16:12 -0500
>> Terry Reedy<tjreedy at udel.edu>  wrote:
>>> On 2/11/2011 4:29 AM, Mark Shannon wrote:
>>>> Nick Coghlan wrote:
>>>
>>>>> Now that the issue has been brought up, it can certainly be taken into
>>>>> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is
>>>>> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft
>>>>> that is a legacy of CPython's long history of development when it was
>>>>> the *only* viable Python implementation) may also be worth exploring.
>>>>
>>>> Absolutely. I intend to do just that.
>>>
>>> I think we should try to have deprecations and removals in the codebase
>>> by the first alpha release for maximal testing.

My next sentence [snipped] was "GP's asyncore changes inspired this 
thought, but I would apply it generally."

>> Why would we deprecate or remove anything? Are some functions useless?

Shannon thinks so. I am specifically suggesting that he make any removal 
suggestion well before the alpha release.

> I think he's referring to deprecations and removals in general.

Yes, as I said. I am also thinking about 3.2 deprecations that will 
become 3.3 removals. That includes one that I am responsible for.

-- 
Terry Jan Reedy


From stutzbach at google.com  Fri Feb 11 23:09:23 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Fri, 11 Feb 2011 14:09:23 -0800
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110211193652.0395d199@pitrou.net>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<20110211193652.0395d199@pitrou.net>
Message-ID: <AANLkTinQHuAQQWbp-p9SeWSvZXYqX6q+=PYon_NZTgrg@mail.gmail.com>

On Fri, Feb 11, 2011 at 10:36 AM, Antoine Pitrou <solipsis at pitrou.net>wrote:

> Daniel Stutzbach <stutzbach at google.com> wrote:
> > I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys.
>
> Would that be a Mapping or a Sequence?


Before or after monkey-patching? :-)

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110211/0d3d726d/attachment.html>

From ncoghlan at gmail.com  Sat Feb 12 01:16:28 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Feb 2011 10:16:28 +1000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
Message-ID: <AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>

On Sat, Feb 12, 2011 at 5:56 AM, Giampaolo Rodol? <g.rodola at gmail.com> wrote:
> Yeah, the original API design (which is very inflexible) and the lack
> of maintenance for many years is at the base of asyncore problems.
> I still think it worths some love as a stdlib module, though.

Oh, definitely. It's popularity is half the problem :)

Flawed API + lack of popularity = just fix it
Flawed API + popularity = years of fun*

*For a given definition of fun, that may or may not align with any
real person's idea of fun ;)

Cheers,
Nick.

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

From turnbull at sk.tsukuba.ac.jp  Sat Feb 12 07:26:11 2011
From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Sat, 12 Feb 2011 15:26:11 +0900
Subject: [Python-Dev] [Python-checkins] r88395
	-	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110211193652.0395d199@pitrou.net>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<20110211193652.0395d199@pitrou.net>
Message-ID: <87hbc9kbuk.fsf@uwakimon.sk.tsukuba.ac.jp>

Antoine Pitrou writes:

 > Would that be a Mapping or a Sequence?

Sure it would be nowhere near as predictable as a Mapping or Sequence,
so Isuppose it would be a Container ... although the probability of
OverflowException is near 1.

From swamiyeswanth at gmail.com  Sat Feb 12 13:44:51 2011
From: swamiyeswanth at gmail.com (yeswanth swami)
Date: Sat, 12 Feb 2011 18:14:51 +0530
Subject: [Python-Dev] Gsoc 2011 ideas
Message-ID: <AANLkTikp9C4LN4u4vuwmw3wMs5_Zz+d_PcxMtuEKLpWh@mail.gmail.com>

Hi everyone,
I am planning to apply for Gsoc 2011 for the PSF . I would like to know if
any of you have any ideas which can be implemented this summer. I guess the
gsoc 2011 ideas page has not been put up as yet. So I thought maybe any of
you can suggest some ideas .

Thanks
Yeswanth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110212/7c49f342/attachment.html>

From arcriley at gmail.com  Sat Feb 12 15:52:16 2011
From: arcriley at gmail.com (Arc Riley)
Date: Sat, 12 Feb 2011 09:52:16 -0500
Subject: [Python-Dev] Gsoc 2011 ideas
In-Reply-To: <AANLkTikp9C4LN4u4vuwmw3wMs5_Zz+d_PcxMtuEKLpWh@mail.gmail.com>
References: <AANLkTikp9C4LN4u4vuwmw3wMs5_Zz+d_PcxMtuEKLpWh@mail.gmail.com>
Message-ID: <AANLkTimJbHEGQGKwTcqxF93i0NqHs9Rskd2uhjsRTV1o@mail.gmail.com>

Hey Yeswanth

Students who get involved with the projects they plan to work with early
have a definite edge over students who don't, so certainly get involved
now.  While I would highly encourage you to get involved with python-dev
(core projects are top in line), you may also want to consider 3rd party
libraries for Python 3 or to help a Python 2 library port to 3.

Python-dev has a list of bugs.  Pick one and start, submit patches, join IRC
(#python-dev on irc.freenode.net) and see if you can find someone who can
help you get started.


On Sat, Feb 12, 2011 at 7:44 AM, yeswanth swami <swamiyeswanth at gmail.com>wrote:

> Hi everyone,
> I am planning to apply for Gsoc 2011 for the PSF . I would like to know if
> any of you have any ideas which can be implemented this summer. I guess the
> gsoc 2011 ideas page has not been put up as yet. So I thought maybe any of
> you can suggest some ideas .
>
> Thanks
> Yeswanth
>
> _______________________________________________
> 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/arcriley%40gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110212/9e100c92/attachment.html>

From merwok at netwok.org  Sat Feb 12 22:42:41 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 12 Feb 2011 22:42:41 +0100
Subject: [Python-Dev] [Python-checkins] devguide: Comment out the "make
 patchcheck" advice, since it doesn't work for a
In-Reply-To: <E1PoN71-00008R-7h@dinsdale.python.org>
References: <E1PoN71-00008R-7h@dinsdale.python.org>
Message-ID: <4D56FED1.60907@netwok.org>

> antoine.pitrou pushed f22bac464e11 to devguide:
> summary:
>   Comment out the "make patchcheck" advice, since it doesn't work for a
> non-SVN workflow.

patchcheck should work after
http://svn.python.org/view?view=rev&revision=85767 (from
http://bugs.python.org/issue8999).  What specific part of ?it? doesn?t work?

Regards

From solipsis at pitrou.net  Sat Feb 12 22:50:56 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 12 Feb 2011 22:50:56 +0100
Subject: [Python-Dev] [Python-checkins] devguide: Comment out the "make
 patchcheck" advice, since it doesn't work for a
References: <E1PoN71-00008R-7h@dinsdale.python.org> <4D56FED1.60907@netwok.org>
Message-ID: <20110212225056.11f08dd4@pitrou.net>

On Sat, 12 Feb 2011 22:42:41 +0100
?ric Araujo <merwok at netwok.org> wrote:
> > antoine.pitrou pushed f22bac464e11 to devguide:
> > summary:
> >   Comment out the "make patchcheck" advice, since it doesn't work for a
> > non-SVN workflow.
> 
> patchcheck should work after
> http://svn.python.org/view?view=rev&revision=85767 (from
> http://bugs.python.org/issue8999).  What specific part of ?it? doesn?t work?

What precisely I explained in
http://bugs.python.org/issue8999#msg108477

Antoine.



From greg.ewing at canterbury.ac.nz  Sat Feb 12 23:19:06 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 13 Feb 2011 11:19:06 +1300
Subject: [Python-Dev] [Python-checkins] r88395 -
 python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
Message-ID: <4D57075A.1050108@canterbury.ac.nz>

Nick Coghlan wrote:

> Flawed API + popularity = years of fun*

So maybe it's time to design a new module with a better API
and deprecate the old one?

-- 
Greg

From solipsis at pitrou.net  Sat Feb 12 23:28:46 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 12 Feb 2011 23:28:46 +0100
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
Message-ID: <20110212232846.35b55400@pitrou.net>

On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
> 
> > Flawed API + popularity = years of fun*
> 
> So maybe it's time to design a new module with a better API
> and deprecate the old one?

That's called Twisted.



From greg.ewing at canterbury.ac.nz  Sat Feb 12 23:46:36 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 13 Feb 2011 11:46:36 +1300
Subject: [Python-Dev] [Python-checkins] r88395 -
 python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110212232846.35b55400@pitrou.net>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
Message-ID: <4D570DCC.5030903@canterbury.ac.nz>

Antoine Pitrou wrote:
> On Sun, 13 Feb 2011 11:19:06 +1300
> Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

>>So maybe it's time to design a new module with a better API
>>and deprecate the old one?
> 
> That's called Twisted.

I was thinking of something lighter-weight than that.

-- 
Greg


From exarkun at twistedmatrix.com  Sun Feb 13 00:10:46 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Sat, 12 Feb 2011 23:10:46 -0000
Subject: [Python-Dev] [Python-checkins] r88395
	-	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <4D570DCC.5030903@canterbury.ac.nz>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
Message-ID: <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>

On 10:46 pm, greg.ewing at canterbury.ac.nz wrote:
>Antoine Pitrou wrote:
>>On Sun, 13 Feb 2011 11:19:06 +1300
>>Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
>>>So maybe it's time to design a new module with a better API
>>>and deprecate the old one?
>>
>>That's called Twisted.
>
>I was thinking of something lighter-weight than that.

Twisted Core

Jean-Paul

From p.f.moore at gmail.com  Sun Feb 13 01:13:00 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 13 Feb 2011 00:13:00 +0000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
Message-ID: <AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>

On 12 February 2011 23:10,  <exarkun at twistedmatrix.com> wrote:
> On 10:46 pm, greg.ewing at canterbury.ac.nz wrote:
>>
>> Antoine Pitrou wrote:
>>>
>>> On Sun, 13 Feb 2011 11:19:06 +1300
>>> Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>
>>>> So maybe it's time to design a new module with a better API
>>>> and deprecate the old one?
>>>
>>> That's called Twisted.
>>
>> I was thinking of something lighter-weight than that.
>
> Twisted Core

Is anyone willing to package up Twisted Core for stdlib inclusion, then?
Paul.

From exarkun at twistedmatrix.com  Sun Feb 13 01:22:58 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Sun, 13 Feb 2011 00:22:58 -0000
Subject: [Python-Dev] [Python-checkins] r88395
	-	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
Message-ID: <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>

On 12:13 am, p.f.moore at gmail.com wrote:
>On 12 February 2011 23:10,  <exarkun at twistedmatrix.com> wrote:
>>On 10:46 pm, greg.ewing at canterbury.ac.nz wrote:
>>>
>>>Antoine Pitrou wrote:
>>>>
>>>>On Sun, 13 Feb 2011 11:19:06 +1300
>>>>Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>>
>>>>>So maybe it's time to design a new module with a better API
>>>>>and deprecate the old one?
>>>>
>>>>That's called Twisted.
>>>
>>>I was thinking of something lighter-weight than that.
>>
>>Twisted Core
>
>Is anyone willing to package up Twisted Core for stdlib inclusion, 
>then?
>Paul.

Do people want to seriously consider deprecating asyncore and adding a 
replacement for it to the stdlib?

(Hey, PyCon is coming up.  How convenient. :)

Jean-Paul

From stutzbach at google.com  Sun Feb 13 01:34:56 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sat, 12 Feb 2011 16:34:56 -0800
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
Message-ID: <AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>

On Sat, Feb 12, 2011 at 4:22 PM, <exarkun at twistedmatrix.com> wrote:

> Do people want to seriously consider deprecating asyncore and adding a
> replacement for it to the stdlib?
>

> (Hey, PyCon is coming up.  How convenient. :)
>

The desire is there, but it's a hard problem.  There was a similar
discussion before PyCon 2009, but not much came of it:

http://mail.python.org/pipermail/python-dev/2009-March/086678.html

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110212/0a6b9620/attachment.html>

From dcolish at gmail.com  Sun Feb 13 02:53:16 2011
From: dcolish at gmail.com (Dan Colish)
Date: Sat, 12 Feb 2011 17:53:16 -0800
Subject: [Python-Dev] PSF Sponsored Sprint in Portland, OR
Message-ID: <ADDB42048D904BDC9BA3412146D01371@gmail.com>

Hello Developers!

I'm one of the organizers of the Portland PSF Sprint. We've been working hard on our proposal to come up with a strong program for a full day of sprinting in Portland. The day will mostly focus on porting libraries to Python 3, hacking on PyPY 2.7 compatibility and testing. It'll be a great time so if you're in the area stop on by! 

The current project list includes:- Fabric
- Django
- Flatland
- PyPy
- Alfajor

Want to suggest your own? Use the signup sheet here.

Breakfast is being sponsored by Idealist.org, lunch is being sponsored by Emma and beverages will be made available by Urban Airship.

More information: http://goo.gl/XTMWv.
Signup sheet: http://goo.gl/a5Gqk.

-- 
Dan


From exarkun at twistedmatrix.com  Sun Feb 13 05:20:59 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Sun, 13 Feb 2011 04:20:59 -0000
Subject: [Python-Dev] [Python-checkins] r88395
	-	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
Message-ID: <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>

On 12:34 am, stutzbach at google.com wrote:
>On Sat, Feb 12, 2011 at 4:22 PM, <exarkun at twistedmatrix.com> wrote:
>>Do people want to seriously consider deprecating asyncore and adding a
>>replacement for it to the stdlib?
>
>>(Hey, PyCon is coming up.  How convenient. :)
>
>The desire is there, but it's a hard problem.  There was a similar
>discussion before PyCon 2009, but not much came of it:
>
>http://mail.python.org/pipermail/python-dev/2009-March/086678.html

I started working on a PEP last year, but I didn't get very far partly 
because I doubted the desire.

What part do you think is a hard problem?  Convincing people to switch 
to a new API?  *Defining* the new API doesn't seem very hard to me.

Jean-Paul

From eliben at gmail.com  Sun Feb 13 05:52:33 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Sun, 13 Feb 2011 06:52:33 +0200
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
Message-ID: <AANLkTi=5OZOcUATcL7KScd6xJABCmFH5ib=mZjzVm3yq@mail.gmail.com>

> I started working on a PEP last year, but I didn't get very far partly
> because I doubted the desire.
>
> What part do you think is a hard problem? ?Convincing people to switch to a
> new API? ?*Defining* the new API doesn't seem very hard to me.
>

I must say that the only time I needed the functionality asyncore
provides in some Python code, 5 minutes of browsing and reading
pointed me to Twisted anyway. I think that having the "ultimately
recommended" library for such programming in stdlib is a good idea, or
at least some core of it. We have a tradition of new modules replacing
old ones with the same functionality gradually (command line argument
parsing, for example) and if someone is motivated enough to prepare a
comprehensive PEP and then working on pulling it through, I think it
may work.

Eli

From ncoghlan at gmail.com  Sun Feb 13 10:18:52 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 13 Feb 2011 19:18:52 +1000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
Message-ID: <AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>

On Sun, Feb 13, 2011 at 2:20 PM,  <exarkun at twistedmatrix.com> wrote:
>> The desire is there, but it's a hard problem. ?There was a similar
>> discussion before PyCon 2009, but not much came of it:
>>
>> http://mail.python.org/pipermail/python-dev/2009-March/086678.html
>
> I started working on a PEP last year, but I didn't get very far partly
> because I doubted the desire.
>
> What part do you think is a hard problem? ?Convincing people to switch to a
> new API? ?*Defining* the new API doesn't seem very hard to me.

If there is an essential subset of the API that the Twisted devs think
would be a suitable replacement for asyncore, while providing a more
straightforward migration path into Twisted itself, then it certainly
makes sense to include it.

The other possible sticking point I can see is that I don't know how
Twisted's licensing works - is there anyone with the legal authority
to appropriately license the code to the PSF for inclusion in the
standard library?

Cheers,
Nick.

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

From solipsis at pitrou.net  Sun Feb 13 15:23:38 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 13 Feb 2011 15:23:38 +0100
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>
Message-ID: <20110213152338.46eb689b@pitrou.net>

On Sun, 13 Feb 2011 19:18:52 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> If there is an essential subset of the API that the Twisted devs think
> would be a suitable replacement for asyncore, while providing a more
> straightforward migration path into Twisted itself, then it certainly
> makes sense to include it.

That subset would be the reactor (actually, the various reactor
implementations) and its close dependencies. However, that might
already amount to a sizeable chunk of code :-) (for good reason, of
course: even Twisted Core does much, much more than asyncore).

> The other possible sticking point I can see is that I don't know how
> Twisted's licensing works - is there anyone with the legal authority
> to appropriately license the code to the PSF for inclusion in the
> standard library?

Twisted's license is MIT-like so I don't think there would be any
so-called "licensing" problem. :-)

Regards

Antoine.



From fuzzyman at voidspace.org.uk  Sun Feb 13 15:32:16 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 13 Feb 2011 14:32:16 +0000
Subject: [Python-Dev] [Python-checkins] r88395
	-	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110213152338.46eb689b@pitrou.net>
References: <20110211130418.5D6F4EE9CE@mail.python.org>	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>	<1297434481.3175.6.camel@marge>	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>	<4D57075A.1050108@canterbury.ac.nz>	<20110212232846.35b55400@pitrou.net>	<4D570DCC.5030903@canterbury.ac.nz>	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>
	<20110213152338.46eb689b@pitrou.net>
Message-ID: <4D57EB70.8080600@voidspace.org.uk>

On 13/02/2011 14:23, Antoine Pitrou wrote:
> On Sun, 13 Feb 2011 19:18:52 +1000
> Nick Coghlan<ncoghlan at gmail.com>  wrote:
>> If there is an essential subset of the API that the Twisted devs think
>> would be a suitable replacement for asyncore, while providing a more
>> straightforward migration path into Twisted itself, then it certainly
>> makes sense to include it.
> That subset would be the reactor (actually, the various reactor
> implementations) and its close dependencies. However, that might
> already amount to a sizeable chunk of code :-) (for good reason, of
> course: even Twisted Core does much, much more than asyncore).
>

It would then be subject to python-dev development policy rather than 
twisted dev policy (which is even stricter!). Would the twisted devs 
*really* want that? We could use the same processes we have for 
"externally maintained" libraries, but they have without fail caused us 
problems. This is usually due to maintainers leaving or going dark, 
which *probably* wouldn't be the case with twisted, nonetheless we've 
been burned enough times to be cautious about adding new "externally 
maintained" packages to the standard library.

Not to mention that the twisted tests have quite a few "non standard 
library" dependencies, so integrating it would be non-trivial. That's 
after it has been ported to Python 3.

The other issue is that just because we provide an alternative doesn't 
mean that everyone automatically stops using asyncore and migrates. That 
means the maintenance burden of asyncore doesn't necessarily go away, we 
just add a new maintenance burden (albeit one with lots of advantages - 
certainly in principle it would be *great* to have twisted-core in the 
standard library).

>> The other possible sticking point I can see is that I don't know how
>> Twisted's licensing works - is there anyone with the legal authority
>> to appropriately license the code to the PSF for inclusion in the
>> standard library?
> Twisted's license is MIT-like so I don't think there would be any
> so-called "licensing" problem. :-)
>
That's not sufficient (IIUC). The code *authors* (copyright owners) have 
to agree, and probably have to sign contributor agreements. :-) Twisted 
have gone through an IP management process already I believe, so it is 
certainly possible.

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  Sun Feb 13 15:51:01 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 13 Feb 2011 15:51:01 +0100
Subject: [Python-Dev] [Python-checkins] r88395 -
 python/branches/py3k/Lib/asyncore.py
In-Reply-To: <4D57EB70.8080600@voidspace.org.uk>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>
	<20110213152338.46eb689b@pitrou.net>
	<4D57EB70.8080600@voidspace.org.uk>
Message-ID: <1297608661.3802.25.camel@localhost.localdomain>


> It would then be subject to python-dev development policy rather than 
> twisted dev policy (which is even stricter!). Would the twisted devs 
> *really* want that? We could use the same processes we have for 
> "externally maintained" libraries, but they have without fail caused us 
> problems.

Oh, I agree with you. -1 on any new externally maintained library.

> The other issue is that just because we provide an alternative doesn't 
> mean that everyone automatically stops using asyncore and migrates.

Of course. asyncore's problem is not that its a maintenance burden, it's
that it's really subpar compared to everything else out there.
That said, Giampaolo has committed to taking it forward, so perhaps the
3.3 version of asyncore will be much (?) better.

> >> The other possible sticking point I can see is that I don't know how
> >> Twisted's licensing works - is there anyone with the legal authority
> >> to appropriately license the code to the PSF for inclusion in the
> >> standard library?
> > Twisted's license is MIT-like so I don't think there would be any
> > so-called "licensing" problem. :-)
> >
> That's not sufficient (IIUC). The code *authors* (copyright owners) have 
> to agree, and probably have to sign contributor agreements. :-)

Well, of course. Or at least that's the theory. In practice, the algebra
of open source licenses is quite well-known and non-copyleft code
usually can be combined freely without any worries.
(and do you think the zlib authors signed a contributor agreement for
inclusion in Python distributions? :-))

> Twisted 
> have gone through an IP management process already I believe, so it is 
> certainly possible.

"IP management process"? What is that horrible jargon supposed to
mean? :)
I don't think the Twisted people are into legalese, and I've never
signed an agreement when contributing (admittedly little) code to
Twisted. They did relicense Twisted once (from LGPL to MIT-like), but
that probably means they asked every past contributor.

Regards

Antoine.



From alexis at notmyidea.org  Sun Feb 13 15:47:01 2011
From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=)
Date: Sun, 13 Feb 2011 14:47:01 +0000
Subject: [Python-Dev] Rights on the tracker
Message-ID: <4D57EEE5.9040904@notmyidea.org>

Hi python-devs,

I'm currently working on distutils2, and I'm trying to stop having
different informations in different places. This means using the
bugs.python.org bugtracker, instead of some weird TODO-lists in the
bitbucket wiki.

Two requests then:

* Is it possible to give me the rights to edit the reports for the
distutils2 component ?
* Is it possible to automatically be in the noisy list for distutils2'
bug reports ?

Tarek co-opts this.
My roundup username is "alexis".

Thanks,
Alex

From tjreedy at udel.edu  Sun Feb 13 16:40:59 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 13 Feb 2011 10:40:59 -0500
Subject: [Python-Dev] Rights on the tracker
In-Reply-To: <4D57EEE5.9040904@notmyidea.org>
References: <4D57EEE5.9040904@notmyidea.org>
Message-ID: <ij8u29$msn$1@dough.gmane.org>

On 2/13/2011 9:47 AM, Alexis M?taireau wrote:

> Tarek co-opts this.

Do you meant that Tarek supports or approves of this?
(Co-opt means something rather different in English.)

-- 
Terry Jan Reedy



From alexis at notmyidea.org  Sun Feb 13 16:48:40 2011
From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=)
Date: Sun, 13 Feb 2011 15:48:40 +0000
Subject: [Python-Dev] Rights on the tracker
In-Reply-To: <ij8u29$msn$1@dough.gmane.org>
References: <4D57EEE5.9040904@notmyidea.org> <ij8u29$msn$1@dough.gmane.org>
Message-ID: <4D57FD58.1060108@notmyidea.org>

Le 13/02/2011 15:40, Terry Reedy a ?crit :
> Do you meant that Tarek supports or approves of this?
> (Co-opt means something rather different in English.)
Sorry, I mean that Tarek approves that :-)

From merwok at netwok.org  Sun Feb 13 17:12:15 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 13 Feb 2011 17:12:15 +0100
Subject: [Python-Dev] Rights on the tracker
In-Reply-To: <4D57EEE5.9040904@notmyidea.org>
References: <4D57EEE5.9040904@notmyidea.org>
Message-ID: <4D5802DF.1050705@netwok.org>

Hi,

I?ve wanted to move our TODO wiki page to the bug tracker for months,
thanks for doing it!  Auto-nosy is useful to catch new bugs; for
existing bugs, instead of adding yourself manually to each one and
trigger not-so-useful email, a tracker admin could add you
automatically.  I?ve asked on
http://psf.upfronthosting.co.za/roundup/meta/issue362

Regards

From alexis at notmyidea.org  Sun Feb 13 18:14:52 2011
From: alexis at notmyidea.org (=?UTF-8?B?QWxleGlzIE3DqXRhaXJlYXU=?=)
Date: Sun, 13 Feb 2011 17:14:52 +0000
Subject: [Python-Dev] Rights on the tracker
In-Reply-To: <4D5802DF.1050705@netwok.org>
References: <4D57EEE5.9040904@notmyidea.org> <4D5802DF.1050705@netwok.org>
Message-ID: <4D58118C.3040709@notmyidea.org>

Le 13/02/2011 16:12, ?ric Araujo a ?crit :
> Hi,
> 
> I?ve wanted to move our TODO wiki page to the bug tracker for months,
> thanks for doing it!  Auto-nosy is useful to catch new bugs; for
> existing bugs, instead of adding yourself manually to each one and
> trigger not-so-useful email, a tracker admin could add you
> automatically.  I?ve asked on
> http://psf.upfronthosting.co.za/roundup/meta/issue362

Great, thanks for that :)

From greg.ewing at canterbury.ac.nz  Sun Feb 13 21:06:53 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 14 Feb 2011 09:06:53 +1300
Subject: [Python-Dev] [Python-checkins] r88395 -
 python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
Message-ID: <4D5839DD.5070906@canterbury.ac.nz>

exarkun at twistedmatrix.com wrote:
> On 10:46 pm, greg.ewing at canterbury.ac.nz wrote:
>>> On Sun, 13 Feb 2011 11:19:06 +1300
>>> Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>
>> I was thinking of something lighter-weight than that.
> 
> Twisted Core

I just had a look at the docs for Twisted Core, and it lists
10 sub-modules. The only one that really looks "core" to me
is twisted.internet. Drilling into that reveals another
39 public sub-sub-modules and 10 private ones.

Sorry, but you'll have to chop it back quite a bit more than
that before it's focused enough to be a stlib module, I think.

-- 
Greg

From exarkun at twistedmatrix.com  Sun Feb 13 23:11:47 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Sun, 13 Feb 2011 22:11:47 -0000
Subject: [Python-Dev] [Python-checkins] r88395
	-	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <4D5839DD.5070906@canterbury.ac.nz>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<4D5839DD.5070906@canterbury.ac.nz>
Message-ID: <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain>

On 08:06 pm, greg.ewing at canterbury.ac.nz wrote:
>exarkun at twistedmatrix.com wrote:
>>On 10:46 pm, greg.ewing at canterbury.ac.nz wrote:
>>>>On Sun, 13 Feb 2011 11:19:06 +1300
>>>>Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>>
>>>I was thinking of something lighter-weight than that.
>>
>>Twisted Core
>
>I just had a look at the docs for Twisted Core, and it lists
>10 sub-modules. The only one that really looks "core" to me
>is twisted.internet. Drilling into that reveals another
>39 public sub-sub-modules and 10 private ones.
>
>Sorry, but you'll have to chop it back quite a bit more than
>that before it's focused enough to be a stlib module, I think.

Excluding stuff is not hard, seriously.  It's not hard to see that 
wxPython integration doesn't belong in the stdlib.  There are more 
useful aspects of the task to discuss.

Jean-Paul

From ncoghlan at gmail.com  Sun Feb 13 23:23:46 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 14 Feb 2011 08:23:46 +1000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<4D5839DD.5070906@canterbury.ac.nz>
	<20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain>
Message-ID: <AANLkTimkgEm3=QPrA5h3kmynjhg3K3evJHnNO6E15m7p@mail.gmail.com>

On Mon, Feb 14, 2011 at 8:11 AM,  <exarkun at twistedmatrix.com> wrote:
>
> Excluding stuff is not hard, seriously. ?It's not hard to see that wxPython
> integration doesn't belong in the stdlib. ?There are more useful aspects of
> the task to discuss.

I think part of the problem is that those of us that aren't Twisted
users aren't familiar enough with it to know which of the elements in
twisted.internet would be important to include in a stdlib "reactor"
package (or whatever it ended up being called). So we see the size of
twisted.internet and start to get nervous. Our fears may be unfounded
in practice, but we don't know that up front.

Cheers,
Nick.

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

From prologic at shortcircuit.net.au  Sun Feb 13 23:24:24 2011
From: prologic at shortcircuit.net.au (James Mills)
Date: Mon, 14 Feb 2011 08:24:24 +1000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<4D5839DD.5070906@canterbury.ac.nz>
	<20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain>
Message-ID: <AANLkTimxNAQJyz3Jj9SEtvk27MRPNFCYSMs7fsU0=x=-@mail.gmail.com>

On Mon, Feb 14, 2011 at 8:11 AM,  <exarkun at twistedmatrix.com> wrote:
> On 08:06 pm, greg.ewing at canterbury.ac.nz wrote:
>>
>> exarkun at twistedmatrix.com wrote:
>>>
>>> On 10:46 pm, greg.ewing at canterbury.ac.nz wrote:
>>>>>
>>>>> On Sun, 13 Feb 2011 11:19:06 +1300
>>>>> Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>>>
>>>> I was thinking of something lighter-weight than that.
>>>
>>> Twisted Core
>>
>> I just had a look at the docs for Twisted Core, and it lists
>> 10 sub-modules. The only one that really looks "core" to me
>> is twisted.internet. Drilling into that reveals another
>> 39 public sub-sub-modules and 10 private ones.
>>
>> Sorry, but you'll have to chop it back quite a bit more than
>> that before it's focused enough to be a stlib module, I think.
>
> Excluding stuff is not hard, seriously. ?It's not hard to see that wxPython
> integration doesn't belong in the stdlib. ?There are more useful aspects of
> the task to discuss.

I don't mean to but in here and I may have no business
doing so... But what about circuits.core ?

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

From fuzzyman at voidspace.org.uk  Sun Feb 13 23:36:59 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 13 Feb 2011 22:36:59 +0000
Subject: [Python-Dev] [Python-checkins] r88395
	-	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTimxNAQJyz3Jj9SEtvk27MRPNFCYSMs7fsU0=x=-@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>	<1297434481.3175.6.camel@marge>	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>	<4D57075A.1050108@canterbury.ac.nz>	<20110212232846.35b55400@pitrou.net>	<4D570DCC.5030903@canterbury.ac.nz>	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>	<4D5839DD.5070906@canterbury.ac.nz>	<20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain>
	<AANLkTimxNAQJyz3Jj9SEtvk27MRPNFCYSMs7fsU0=x=-@mail.gmail.com>
Message-ID: <4D585D0B.6010208@voidspace.org.uk>

On 13/02/2011 22:24, James Mills wrote:
> On Mon, Feb 14, 2011 at 8:11 AM,<exarkun at twistedmatrix.com>  wrote:
>> On 08:06 pm, greg.ewing at canterbury.ac.nz wrote:
>>> exarkun at twistedmatrix.com wrote:
>>>> On 10:46 pm, greg.ewing at canterbury.ac.nz wrote:
>>>>>> On Sun, 13 Feb 2011 11:19:06 +1300
>>>>>> Greg Ewing<greg.ewing at canterbury.ac.nz>  wrote:
>>>>> I was thinking of something lighter-weight than that.
>>>> Twisted Core
>>> I just had a look at the docs for Twisted Core, and it lists
>>> 10 sub-modules. The only one that really looks "core" to me
>>> is twisted.internet. Drilling into that reveals another
>>> 39 public sub-sub-modules and 10 private ones.
>>>
>>> Sorry, but you'll have to chop it back quite a bit more than
>>> that before it's focused enough to be a stlib module, I think.
>> Excluding stuff is not hard, seriously.  It's not hard to see that wxPython
>> integration doesn't belong in the stdlib.  There are more useful aspects of
>> the task to discuss.
> I don't mean to but in here and I may have no business
> doing so... But what about circuits.core ?
>

Well, what about it? The virtue of twisted is that even if we haven't 
all used it, we've all heard of it. That speaks volumes about its 
penetration into the python world.

Note  that the requirements for inclusion in the standard library (and 
at this point the conversation should really move to python-ideas) are 
*ideally*:

* well established and widely used
* well written and tested (including working on the major platforms that 
python runs on)
* solves a common problem
* the "owners" are submitting the code for conclusion and we have 
someone (preferably more than one) commited to maintaining the code in 
the core for the forseeable future
* can be integrated with python-as-it-is-at-the-moment without bringing 
in new dependencies that *shouldn't* go into python core

Twisted certainly meets the first three of those requirements, the last 
two are uncertain and still being discussed. We *don't* go around 
fishing for projects to include which is why we haven't suggested 
alternatives. There has been ongoing musing about including parts of 
twisted for many years however, and the core contributor to this 
discussion (Jean-Paul Calderone) is one of the lead developers of twisted.

I think if we *were* going to include an alternative async event loop 
into the Python standard library there would have to be very good 
reasons for it *not* to be twisted, just because of the prominence of 
twisted within the python ecosystem.

All the best,

Michael Foord
> cheers
> James
>


-- 
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 prologic at shortcircuit.net.au  Sun Feb 13 23:43:48 2011
From: prologic at shortcircuit.net.au (James Mills)
Date: Mon, 14 Feb 2011 08:43:48 +1000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <4D585D0B.6010208@voidspace.org.uk>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<4D5839DD.5070906@canterbury.ac.nz>
	<20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain>
	<AANLkTimxNAQJyz3Jj9SEtvk27MRPNFCYSMs7fsU0=x=-@mail.gmail.com>
	<4D585D0B.6010208@voidspace.org.uk>
Message-ID: <AANLkTimKR9Ukj5MN5HEMMg6nRWs3NdH0GPxrY5fDV0oC@mail.gmail.com>

On Mon, Feb 14, 2011 at 8:36 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Well, what about it? The virtue of twisted is that even if we haven't all
> used it, we've all heard of it. That speaks volumes about its penetration
> into the python world.

Just a mere suggestion. The fact that this discussion exists means that
Twisted may end up being in the std. lib in the end because no-one can
come up with a better? solution that meets "all" requirements.

In any case, there are other alternatives. I realize we're not discussing them
but it's nice to know what is and can be included in the std. lib, etc.

I'll just follow and keep quiet now :)

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

From solipsis at pitrou.net  Mon Feb 14 00:16:05 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Feb 2011 00:16:05 +0100
Subject: [Python-Dev] Rights on the tracker
References: <4D57EEE5.9040904@notmyidea.org>
Message-ID: <20110214001605.42150d08@pitrou.net>

On Sun, 13 Feb 2011 14:47:01 +0000
Alexis M?taireau <alexis at notmyidea.org> wrote:
> 
> * Is it possible to give me the rights to edit the reports for the
> distutils2 component ?

Done. Actually, you have general developer rights, since there doesn't
seem to be a way (in the GUI) to restrict those to a specific component.

> * Is it possible to automatically be in the noisy list for distutils2'
> bug reports ?

Someone else with the right knowledge and power will have to do that.

Regards

Antoine.



From alexis at notmyidea.org  Mon Feb 14 00:50:08 2011
From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=)
Date: Sun, 13 Feb 2011 23:50:08 +0000
Subject: [Python-Dev] Rights on the tracker
In-Reply-To: <20110214001605.42150d08@pitrou.net>
References: <4D57EEE5.9040904@notmyidea.org>
	<20110214001605.42150d08@pitrou.net>
Message-ID: <4D586E30.2060306@notmyidea.org>

Le 13/02/2011 23:16, Antoine Pitrou a ?crit :
> On Sun, 13 Feb 2011 14:47:01 +0000
> Alexis M?taireau <alexis at notmyidea.org> wrote:
>>
>> * Is it possible to give me the rights to edit the reports for the
>> distutils2 component ?
> 
> Done. Actually, you have general developer rights, since there doesn't
> seem to be a way (in the GUI) to restrict those to a specific component.

Thanks !

> Someone else with the right knowledge and power will have to do that.

Okay, there is an issue on the tracker's tracker, as ?ric told.

Cheers,
Alex

From tjreedy at udel.edu  Mon Feb 14 01:55:06 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 13 Feb 2011 19:55:06 -0500
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTimkgEm3=QPrA5h3kmynjhg3K3evJHnNO6E15m7p@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>	<1297434481.3175.6.camel@marge>	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>	<4D57075A.1050108@canterbury.ac.nz>	<20110212232846.35b55400@pitrou.net>	<4D570DCC.5030903@canterbury.ac.nz>	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>	<4D5839DD.5070906@canterbury.ac.nz>	<20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain>
	<AANLkTimkgEm3=QPrA5h3kmynjhg3K3evJHnNO6E15m7p@mail.gmail.com>
Message-ID: <ij9uh8$civ$1@dough.gmane.org>

On 2/13/2011 5:23 PM, Nick Coghlan wrote:
> On Mon, Feb 14, 2011 at 8:11 AM,<exarkun at twistedmatrix.com>  wrote:
>>
>> Excluding stuff is not hard, seriously.  It's not hard to see that wxPython
>> integration doesn't belong in the stdlib.  There are more useful aspects of
>> the task to discuss.
>
> I think part of the problem is that those of us that aren't Twisted
> users aren't familiar enough with it to know which of the elements in
> twisted.internet would be important to include in a stdlib "reactor"
> package (or whatever it ended up being called).

To me, this is what a PEP would be for -- to present a concrete proposal 
listing inclusions that could be evaluated. The someone familiar with 
asyncore could compare feature lists to decide if the new module would 
have everything needed without too much other stuff.

-- 
Terry Jan Reedy


From georg at python.org  Mon Feb 14 07:40:00 2011
From: georg at python.org (Georg Brandl)
Date: Mon, 14 Feb 2011 07:40:00 +0100
Subject: [Python-Dev] [RELEASED] Python 3.2 rc 3
Message-ID: <4D58CE40.1010408@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On behalf of the Python development team, I'm happy to announce
the third release candidate of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
  hostname matching
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
  for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations

For a more extensive list of changes in 3.2, see

    http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

    http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

    http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk1YzkAACgkQN9GcIYhpnLAggwCfQ92djMinrmNkGI4Ma3VRqrcX
EWIAn16kTEJtvEH/7DJApp7YdhnmIRBd
=NJ1B
-----END PGP SIGNATURE-----

From victor.stinner at haypocalc.com  Mon Feb 14 11:05:52 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Mon, 14 Feb 2011 11:05:52 +0100
Subject: [Python-Dev] [RELEASED] Python 3.2 rc 3
In-Reply-To: <4D58CE40.1010408@python.org>
References: <4D58CE40.1010408@python.org>
Message-ID: <1297677952.15296.60.camel@marge>

Le lundi 14 f?vrier 2011 ? 07:40 +0100, Georg Brandl a ?crit :
> On behalf of the Python development team, I'm happy to announce
> the third release candidate of Python 3.2.

Oh, the RC3 changelog is still very long. And sorry, because I
contributed to this long list of changes! I hope that the list will be
shorter for the final version.

I don't have any pending patch :-)

Victor


From list at qtrac.plus.com  Mon Feb 14 12:58:42 2011
From: list at qtrac.plus.com (Mark Summerfield)
Date: Mon, 14 Feb 2011 11:58:42 +0000
Subject: [Python-Dev] [python-committers] [RELEASED] Python 3.2 rc 3
In-Reply-To: <4D58CE40.1010408@python.org>
References: <4D58CE40.1010408@python.org>
Message-ID: <20110214115842.3c98a68e@dino>

On Mon, 14 Feb 2011 07:40:00 +0100
Georg Brandl <georg at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On behalf of the Python development team, I'm happy to announce
> the third release candidate of Python 3.2.
> 
> Python 3.2 is a continuation of the efforts to improve and stabilize
> the Python 3.x line.  Since the final release of Python 2.7, the 2.x
> line will only receive bugfixes, and new features are developed for
> 3.x only.
[snip]

It looks good:-)

V. small suggestion: how about putting the "New, Improved, and
Deprecated Modules" in What's New in alphabetical order?


-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
	Programming in Python 3" - ISBN 0321680561
            http://www.qtrac.eu/py3book.html

From g.rodola at gmail.com  Mon Feb 14 13:18:55 2011
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Mon, 14 Feb 2011 13:18:55 +0100
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <1297608661.3802.25.camel@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>
	<20110213152338.46eb689b@pitrou.net>
	<4D57EB70.8080600@voidspace.org.uk>
	<1297608661.3802.25.camel@localhost.localdomain>
Message-ID: <AANLkTimc568MA4WzFx9V936cQL7ESxT2n2hZk0vVpTaM@mail.gmail.com>

2011/2/13 Antoine Pitrou <solipsis at pitrou.net>:
>
>> It would then be subject to python-dev development policy rather than
>> twisted dev policy (which is even stricter!). Would the twisted devs
>> *really* want that? We could use the same processes we have for
>> "externally maintained" libraries, but they have without fail caused us
>> problems.
>
> Oh, I agree with you. -1 on any new externally maintained library.
>
>> The other issue is that just because we provide an alternative doesn't
>> mean that everyone automatically stops using asyncore and migrates.
>
> Of course. asyncore's problem is not that its a maintenance burden, it's
> that it's really subpar compared to everything else out there.
> That said, Giampaolo has committed to taking it forward, so perhaps the
> 3.3 version of asyncore will be much (?) better.

I must say that asyncore can surely be improved but not so that it can
reach the flexibility offered by Twisted.
Or at least, not without changing some aspects of the current API and
break backward compatibility.
I'll try to summarize what I think is wrong with asyncore so that
maybe someone can chime in and propose ideas.

Guido was right when he stated that providing a future-proof and
maximally flexible design of such an API is not easy, and this is
exactly the problem with asyncore.
It provides a subclass-based API which doesn't work well in all those
cases where I want to mix different functionallities as in:

- I want a base TCP dispatcher
- ...with buffered output capabilities a-la asynchat
- ...which is able to limit the speed for incoming data
- ...and that can also switch to SSL

Although I don't use it, it seems that Twisted managed to do this by
splitting the concepts of "transport" and "protocol" / "application"
and by using zope.interface.
At the current state, asyncore is not able to do this flexibly. It
should at least separate transport and protocol, but again, I can't
imagine how exactly and it would surely have a cost in terms of
backward compatibility.

Another problem is that asyncore is pretty low-level, and this is why
the outcome is a code which looks monkey patched.

Where Twisted provides a dataReceived() method, asyncore provides
handle_read(): the user is supposed to override handle_read() and
manually call recv() which might either fail (e.g. "retry later" or
"disconnected") or succeed.
The same applies for all other aspects of a TCP connection:
handle_accept() -> accept(), handle_connect() -> connect() and
handle_write -> send().
They all might fail and all need to be handled with care individually
(see for example: http://bugs.python.org/issue6706 ).

This aspect might be mitigated by providing a serie of higher lever
classes (e.g. TCPServer, UDPServer, TCPConnection, UDPConnection,
SSLTCPConnection) providing an API similar to:
http://twistedmatrix.com/documents/8.2.0/api/twisted.internet.interfaces.IProtocol.html
...but the need of a separation between transport and protocol layers
is still needed.

Last but not least, the asyncore "reactor" (asyncore.loop()) is not
tied with the dispatcher.
>From the dispatcher we have no reference to the reactor, hence we
cannot register/unregister file descriptors, forcing the main loop to
iterate over all dispatcher instances and making impossible to benefit
of epoll() and kqueue(), which are crucial for scalable servers
handling thousands simultaneous requests:
http://bugs.python.org/issue6692

As for what we can *currently* do without going into too much trouble
I can mention:
http://bugs.python.org/issue10084
http://bugs.python.org/issue1641

As for Twisted core, I think it would be a nice addition for the
stdlib, but for me it should also fit one crucial requirement: it
should be *simple* and reflect the simplicity and "taste" of all other
stdlib modules, and to fulfill such a requirement I think Twisted
probably needs to be "adapted" a bit.
The main reason why I decided to use asyncore is that, despite it's
huge gaps and lack of base functionnalities, I can read its source
code, understand what's going on and extend it via monkey patching.
It might seem a poor approach but it worked for me and couldn't do the
same when I tried to use Twisted.


Regards,

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

From rdmurray at bitdance.com  Mon Feb 14 14:48:38 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 14 Feb 2011 08:48:38 -0500
Subject: [Python-Dev] Rights on the tracker
In-Reply-To: <20110214001605.42150d08@pitrou.net>
References: <4D57EEE5.9040904@notmyidea.org>
	<20110214001605.42150d08@pitrou.net>
Message-ID: <20110214134838.5DBBD236C65@kimball.webabinitio.net>

On Mon, 14 Feb 2011 00:16:05 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 13 Feb 2011 14:47:01 +0000 Alexis M??taireau <alexis at notmyidea.org> wrote:
> > * Is it possible to automatically be in the noisy list for distutils2'
> > bug reports ?
> 
> Someone else with the right knowledge and power will have to do that.

Done.  I hope.  This is the first one we (currently) have where more
than one person is being auto-nosied, so I hope I got the syntax right.
Someone should test it.

This is separate from the meta-tracker issue ??ric mentioned, it applies
only to issues where the distutils2 component is newly added.

(Antoine: FYI, the place this is edited is http://bugs.python.org/component,
and I don't know anything more than what is explained on that scree :).

--
R. David Murray                                      www.bitdance.com

From janssen at parc.com  Mon Feb 14 21:08:25 2011
From: janssen at parc.com (Bill Janssen)
Date: Mon, 14 Feb 2011 12:08:25 PST
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTimc568MA4WzFx9V936cQL7ESxT2n2hZk0vVpTaM@mail.gmail.com>
Message-ID: <85871.1297714105@parc.com>

Giampaolo Rodol? <g.rodola at gmail.com> wrote:

> Although I don't use it, it seems that Twisted managed to do this by
> splitting the concepts of "transport" and "protocol" / "application"
> and by using zope.interface.

You might want to look at the ILU core, too, just for ideas.  Somewhat
to my surprise, the link http://www2.parc.com/istl/projects/ILU/ still
works.  The protocol/transport distinction is at
<ftp://ftp.parc.xerox.com/pub/ilu/2.0b1/manual-html/manual_14.html#SEC475>.

The key requirements for an async loop, IMO, are the normal file
descriptor state change notifications, support for timer events, and
support for time-bounded work tasks (that get run when nothing is
happening).

The Tornado IOLoop does all three of these; also worth taking a look at:
<http://www.tornadoweb.org/>.

Bill

From greg.ewing at canterbury.ac.nz  Mon Feb 14 23:15:59 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 15 Feb 2011 11:15:59 +1300
Subject: [Python-Dev] [Python-checkins] r88395 -
 python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTimc568MA4WzFx9V936cQL7ESxT2n2hZk0vVpTaM@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>
	<20110213152338.46eb689b@pitrou.net>
	<4D57EB70.8080600@voidspace.org.uk>
	<1297608661.3802.25.camel@localhost.localdomain>
	<AANLkTimc568MA4WzFx9V936cQL7ESxT2n2hZk0vVpTaM@mail.gmail.com>
Message-ID: <4D59A99F.90106@canterbury.ac.nz>

Giampaolo Rodol? wrote:

> for me it should also fit one crucial requirement: it
> should be *simple* and reflect the simplicity and "taste" of all other
> stdlib modules, and to fulfill such a requirement I think Twisted
> probably needs to be "adapted" a bit.

My thoughts exactly -- from a bird's eye view, Twisted appears
to be very far from simple. While there may be some good ideas
to adopt from it, I suspect that finding them will require just
as much careful thought as designing an API from scratch.

-- 
Greg

From martin at v.loewis.de  Mon Feb 14 23:21:15 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 14 Feb 2011 23:21:15 +0100
Subject: [Python-Dev] Rights on the tracker
In-Reply-To: <20110214134838.5DBBD236C65@kimball.webabinitio.net>
References: <4D57EEE5.9040904@notmyidea.org>	<20110214001605.42150d08@pitrou.net>
	<20110214134838.5DBBD236C65@kimball.webabinitio.net>
Message-ID: <4D59AADB.1070109@v.loewis.de>

> Done.  I hope.  This is the first one we (currently) have where more
> than one person is being auto-nosied, so I hope I got the syntax right.

It should be fine:

roundup_tracker=> select * from component_add_as_nosy where nodeid = 25;
 linkid | nodeid
--------+--------
   7641 |     25
  12434 |     25
(2 Zeilen)

It might still be useful to test it, since actually evaluating the
property might also go wrong, but that should be fine as well:

    for component in components:
        users = db.component.get(component, 'add_as_nosy')
        nosy |= set(users)

Regards,
Martin

From exarkun at twistedmatrix.com  Tue Feb 15 01:45:21 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Tue, 15 Feb 2011 00:45:21 -0000
Subject: [Python-Dev] [Python-checkins] r88395
	-	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <4D59A99F.90106@canterbury.ac.nz>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>
	<20110213152338.46eb689b@pitrou.net>
	<4D57EB70.8080600@voidspace.org.uk>
	<1297608661.3802.25.camel@localhost.localdomain>
	<AANLkTimc568MA4WzFx9V936cQL7ESxT2n2hZk0vVpTaM@mail.gmail.com>
	<4D59A99F.90106@canterbury.ac.nz>
Message-ID: <20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain>

On 14 Feb, 10:15 pm, greg.ewing at canterbury.ac.nz wrote:
>Giampaolo Rodol? wrote:
>>for me it should also fit one crucial requirement: it
>>should be *simple* and reflect the simplicity and "taste" of all other
>>stdlib modules, and to fulfill such a requirement I think Twisted
>>probably needs to be "adapted" a bit.
>
>My thoughts exactly -- from a bird's eye view, Twisted appears
>to be very far from simple. While there may be some good ideas
>to adopt from it, I suspect that finding them will require just
>as much careful thought as designing an API from scratch.

Can you try to be more constructive?  Generalizations like this don't 
help the process at all.  They don't explain why Twisted's APIs 
shouldn't be adopted in the stdlib and they don't explain what APIs 
_should_ be adopted.  It's basically just stop energy.

I'm not picking on Giampaolo because despite the small portion of his 
message you quoted, his full email actually contained quite a bit of 
useful technical information.  It wasn't just an unsupported snipe.

As far as the difficulties of "finding" the good ideas in Twisted goes, 
there are several people familiar with Twisted already contributing to 
this thread.  Between us all, I'm sure we can dig out the insidiously 
buried secrets.  As I mentioned before, I've also started a PEP myself 
to lay bare the mysteries.  I may try working on it some more, since 
there seems to be some interest.

Jean-Paul

From eric at trueblade.com  Tue Feb 15 01:52:59 2011
From: eric at trueblade.com (Eric Smith)
Date: Mon, 14 Feb 2011 19:52:59 -0500
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <4D59A99F.90106@canterbury.ac.nz>
References: <20110211130418.5D6F4EE9CE@mail.python.org>	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>	<4D57075A.1050108@canterbury.ac.nz>	<20110212232846.35b55400@pitrou.net>	<4D570DCC.5030903@canterbury.ac.nz>	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>	<20110213152338.46eb689b@pitrou.net>	<4D57EB70.8080600@voidspace.org.uk>	<1297608661.3802.25.camel@localhost.localdomain>	<AANLkTimc568MA4WzFx9V936cQL7ESxT2n2hZk0vVpTaM@mail.gmail.com>
	<4D59A99F.90106@canterbury.ac.nz>
Message-ID: <4D59CE6B.7010400@trueblade.com>

On 2/14/2011 5:15 PM, Greg Ewing wrote:
> Giampaolo Rodol? wrote:
>
>> for me it should also fit one crucial requirement: it
>> should be *simple* and reflect the simplicity and "taste" of all other
>> stdlib modules, and to fulfill such a requirement I think Twisted
>> probably needs to be "adapted" a bit.
>
> My thoughts exactly -- from a bird's eye view, Twisted appears
> to be very far from simple. While there may be some good ideas
> to adopt from it, I suspect that finding them will require just
> as much careful thought as designing an API from scratch.

I find this hard to believe, given the brainpower behind Twisted and the 
willingness of the Twisted devs to help with this. Starting from scratch 
seems like a very bad idea.

From stutzbach at google.com  Tue Feb 15 02:09:22 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Mon, 14 Feb 2011 17:09:22 -0800
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
Message-ID: <AANLkTimz8AK5N5_4GYhmvV6=AuQE=aZxYcMZvJ6RScZ5@mail.gmail.com>

On Sat, Feb 12, 2011 at 8:20 PM, <exarkun at twistedmatrix.com> wrote:

> What part do you think is a hard problem?  Convincing people to switch to a
> new API?
>

I think the hard parts is coming up with an API that's simple enough to
learn quickly but powerful enough for to cover most use-cases and cleanly
extendable to cover use-cases we haven't thought of.

If we go with something based on or inspired by Twisted, that solves some
problems, but creates others.  Will users be able to later migrate to using
Twisted proper?  Will the standard library module and Twisted go out of
sync?  What happens if a user tries to use both the standard library module
and Twisted?

Please understand that I'm not saying these are insurmountable problems.
 I'm just suggesting things that might be good to address in a PEP.


> *Defining* the new API doesn't seem very hard to me.
>

If you have the skills and experience so that designing a async API is not
as hard for you, please run with it.  :-)  Personally, I would love to see
asyncore deprecated in favor of something better.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110214/f74a2071/attachment.html>

From prologic at shortcircuit.net.au  Tue Feb 15 02:15:52 2011
From: prologic at shortcircuit.net.au (James Mills)
Date: Tue, 15 Feb 2011 11:15:52 +1000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>
	<20110213152338.46eb689b@pitrou.net>
	<4D57EB70.8080600@voidspace.org.uk>
	<1297608661.3802.25.camel@localhost.localdomain>
	<AANLkTimc568MA4WzFx9V936cQL7ESxT2n2hZk0vVpTaM@mail.gmail.com>
	<4D59A99F.90106@canterbury.ac.nz>
	<20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain>
Message-ID: <AANLkTimGZO1qcnmTjfgh5D97LZmh3KxSQNASCUfdjPbY@mail.gmail.com>

On Tue, Feb 15, 2011 at 10:45 AM,  <exarkun at twistedmatrix.com> wrote:
> As far as the difficulties of "finding" the good ideas in Twisted goes,
> there are several people familiar with Twisted already contributing to this
> thread. ?Between us all, I'm sure we can dig out the insidiously buried
> secrets. ?As I mentioned before, I've also started a PEP myself to lay bare
> the mysteries. ?I may try working on it some more, since there seems to be
> some interest.

So far in this discussion (I'm not really contributing very much) I agree
with several things:

a) We should have a PEP outlining the proposed new "async" lib.
b) It should be general purpose enough to use without Twisted (for example)

I like the idea of having an "async" core in the std. lib that takes care
of cross-platform polling of I/O descriptors, notifications and timers.

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

From prologic at shortcircuit.net.au  Tue Feb 15 02:18:00 2011
From: prologic at shortcircuit.net.au (James Mills)
Date: Tue, 15 Feb 2011 11:18:00 +1000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTimz8AK5N5_4GYhmvV6=AuQE=aZxYcMZvJ6RScZ5@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTinbZfYAyxKgkHCmuif5RRygR9NxikSck+6-Rxbp@mail.gmail.com>
	<AANLkTimz_kd+fAFFsk9o8js5nPf9ev-j_MVHDdqXmKSz@mail.gmail.com>
	<1297434481.3175.6.camel@marge>
	<AANLkTi=3nyJFXz4-Z7URRuzVoRY_3YiEdjUZZFne7Yho@mail.gmail.com>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
	<AANLkTimz8AK5N5_4GYhmvV6=AuQE=aZxYcMZvJ6RScZ5@mail.gmail.com>
Message-ID: <AANLkTikFtLM-p50cp69h=WHQKnybQeU06b62H6V0UXqD@mail.gmail.com>

On Tue, Feb 15, 2011 at 11:09 AM, Daniel Stutzbach <stutzbach at google.com> wrote:
> If we go with something based on or inspired by Twisted, that solves some
> problems, but creates others. ?Will users be able to later migrate to using
> Twisted proper? ?Will the standard library module and Twisted go out of
> sync? ?What happens if a user tries to use both the standard library module
> and Twisted?

Or any other async / application framework.

--JamesMills

From p.f.moore at gmail.com  Tue Feb 15 08:54:40 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 15 Feb 2011 07:54:40 +0000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>
	<20110213152338.46eb689b@pitrou.net>
	<4D57EB70.8080600@voidspace.org.uk>
	<1297608661.3802.25.camel@localhost.localdomain>
	<AANLkTimc568MA4WzFx9V936cQL7ESxT2n2hZk0vVpTaM@mail.gmail.com>
	<4D59A99F.90106@canterbury.ac.nz>
	<20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain>
Message-ID: <AANLkTinXbiB=+8k7YDHDZg6j++-ZO5-kgA1Bj-zxjkw4@mail.gmail.com>

On 15 February 2011 00:45,  <exarkun at twistedmatrix.com> wrote:
> As far as the difficulties of "finding" the good ideas in Twisted goes,
> there are several people familiar with Twisted already contributing to this
> thread. ?Between us all, I'm sure we can dig out the insidiously buried
> secrets. ?As I mentioned before, I've also started a PEP myself to lay bare
> the mysteries. ?I may try working on it some more, since there seems to be
> some interest.

FWIW,

I am +1 on seeing a PEP for a twisted-based async framework. Probably
targeted at 3.3, that should be plenty of time.

I'd like it to be upward compatible with Twisted proper. If I'm
expanding the scope of my code anywhere, it will be to full twisted,
and I'd rather not have to rewrite what's already there. I've no
reason to criticise any of the other async frameworks out there, but
it seems clear to me that Twisted is well established as the "best of
breed" in this area.

The PEP should address what will happen with the dependency on
zope.interface. Getting interfaces into the stdlib has *also* been
discussed often in the past, and has never happened. It might even be
contentious enough to warrant a second sub-PEP covering just that
area.

While I'm sure there's still plenty of technical issues we can cover
in this thread, I think that a PEP would focus discussion a lot more
clearly.

Paul.

From martin at v.loewis.de  Tue Feb 15 09:30:08 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 15 Feb 2011 09:30:08 +0100
Subject: [Python-Dev] svn outage on Friday
Message-ID: <4D5A3990.4040902@v.loewis.de>

I'm going to perform a Debian upgrade of svn.python.org on Friday,
between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
that time. The outage shouldn't be longer than an hour.

Regards,
Martin

From victor.stinner at haypocalc.com  Tue Feb 15 10:25:06 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Tue, 15 Feb 2011 10:25:06 +0100
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <4D5A3990.4040902@v.loewis.de>
References: <4D5A3990.4040902@v.loewis.de>
Message-ID: <1297761906.31674.0.camel@marge>

Le mardi 15 f?vrier 2011 ? 09:30 +0100, "Martin v. L?wis" a ?crit :
> I'm going to perform a Debian upgrade of svn.python.org on Friday,
> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
> that time. The outage shouldn't be longer than an hour.

It's time to move to Mercurial! :-)

Victor


From phd at phdru.name  Tue Feb 15 10:32:12 2011
From: phd at phdru.name (Oleg Broytman)
Date: Tue, 15 Feb 2011 12:32:12 +0300
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <1297761906.31674.0.camel@marge>
References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge>
Message-ID: <20110215093210.GA25546@iskra.aviel.ru>

On Tue, Feb 15, 2011 at 10:25:06AM +0100, Victor Stinner wrote:
> Le mardi 15 f??vrier 2011 ?? 09:30 +0100, "Martin v. L??wis" a ??crit :
> > I'm going to perform a Debian upgrade of svn.python.org on Friday,
> > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
> > that time. The outage shouldn't be longer than an hour.
> 
> It's time to move to Mercurial! :-)

   Never do two upgrades at once! Especially on Fridays!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From ncoghlan at gmail.com  Tue Feb 15 13:52:18 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Feb 2011 22:52:18 +1000
Subject: [Python-Dev] [Python-checkins] r88395 -
	python/branches/py3k/Lib/asyncore.py
In-Reply-To: <AANLkTinXbiB=+8k7YDHDZg6j++-ZO5-kgA1Bj-zxjkw4@mail.gmail.com>
References: <20110211130418.5D6F4EE9CE@mail.python.org>
	<AANLkTimeCDjcrR0yHwSs4BfE-=W-_3FbrB-sknN_4Moe@mail.gmail.com>
	<AANLkTimeUbSk99_23Bz4pGCyFMf_AGDMpS==xJayXYnd@mail.gmail.com>
	<AANLkTinE=r4780sJ-9GC3nNb3xGSDPD0V1_aPrNu=gAg@mail.gmail.com>
	<4D57075A.1050108@canterbury.ac.nz>
	<20110212232846.35b55400@pitrou.net>
	<4D570DCC.5030903@canterbury.ac.nz>
	<20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain>
	<AANLkTikqq-ms0WRMRGrz11eteqUcRONZZhDpR550uFjx@mail.gmail.com>
	<20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain>
	<AANLkTik9YRsg=8PViqNtihiU2obhCc+5pKQgtqAZk8uy@mail.gmail.com>
	<20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain>
	<AANLkTi=-M670wN54YnU=v7UOBWtauwmyUU1FuCeOkTue@mail.gmail.com>
	<20110213152338.46eb689b@pitrou.net>
	<4D57EB70.8080600@voidspace.org.uk>
	<1297608661.3802.25.camel@localhost.localdomain>
	<AANLkTimc568MA4WzFx9V936cQL7ESxT2n2hZk0vVpTaM@mail.gmail.com>
	<4D59A99F.90106@canterbury.ac.nz>
	<20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain>
	<AANLkTinXbiB=+8k7YDHDZg6j++-ZO5-kgA1Bj-zxjkw4@mail.gmail.com>
Message-ID: <AANLkTinnamV8pNYRzKdHKfebOeapDB+zdA2qhCqNVwJA@mail.gmail.com>

On Tue, Feb 15, 2011 at 5:54 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> The PEP should address what will happen with the dependency on
> zope.interface. Getting interfaces into the stdlib has *also* been
> discussed often in the past, and has never happened. It might even be
> contentious enough to warrant a second sub-PEP covering just that
> area.

The equivalent functionality was subsumed by the inclusion of ABC
support (which is what a "standalone" core event loop should probably
use instead of zope interfaces).

Definitely a PEP worth pursuing.

Cheers,
Nick.

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

From benjamin at python.org  Tue Feb 15 15:03:16 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 15 Feb 2011 08:03:16 -0600
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <1297761906.31674.0.camel@marge>
References: <4D5A3990.4040902@v.loewis.de>
	<1297761906.31674.0.camel@marge>
Message-ID: <AANLkTim2QNW1tzQCfCVjuwB6SB8sofUFgQUrR8vx_4YX@mail.gmail.com>

2011/2/15 Victor Stinner <victor.stinner at haypocalc.com>:
> Le mardi 15 f?vrier 2011 ? 09:30 +0100, "Martin v. L?wis" a ?crit :
>> I'm going to perform a Debian upgrade of svn.python.org on Friday,
>> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
>> that time. The outage shouldn't be longer than an hour.
>
> It's time to move to Mercurial! :-)

And doubtless there will be times when Mercurial must be upgraded, too...



-- 
Regards,
Benjamin

From john.arbash.meinel at gmail.com  Tue Feb 15 17:32:25 2011
From: john.arbash.meinel at gmail.com (John Arbash Meinel)
Date: Tue, 15 Feb 2011 10:32:25 -0600
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <AANLkTim2QNW1tzQCfCVjuwB6SB8sofUFgQUrR8vx_4YX@mail.gmail.com>
References: <4D5A3990.4040902@v.loewis.de>	<1297761906.31674.0.camel@marge>
	<AANLkTim2QNW1tzQCfCVjuwB6SB8sofUFgQUrR8vx_4YX@mail.gmail.com>
Message-ID: <4D5AAA99.8010600@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/15/2011 8:03 AM, Benjamin Peterson wrote:
> 2011/2/15 Victor Stinner <victor.stinner at haypocalc.com>:
>> Le mardi 15 f?vrier 2011 ? 09:30 +0100, "Martin v. L?wis" a ?crit :
>>> I'm going to perform a Debian upgrade of svn.python.org on Friday,
>>> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
>>> that time. The outage shouldn't be longer than an hour.
>>
>> It's time to move to Mercurial! :-)
> 
> And doubtless there will be times when Mercurial must be upgraded, too...
> 

True, but on those days you just keep committing locally...

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1aqpkACgkQJdeBCYSNAAMW3gCgt/Ea75R/HfKM4KlmGmCmfjtL
BBYAoI89GYsxrsa4/Eefifg3i6+Euv+T
=Kz3A
-----END PGP SIGNATURE-----

From techtonik at gmail.com  Wed Feb 16 11:51:21 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 16 Feb 2011 12:51:21 +0200
Subject: [Python-Dev] python 3.2 (fwd)
In-Reply-To: <4D52E93F.3020108@udel.edu>
References: <19794.53174.766166.195523@montanaro.dyndns.org>
	<4D52E93F.3020108@udel.edu>
Message-ID: <AANLkTineTUsXhdNX6ABMYpx7vTqzx-6e4=k5XnSzktzn@mail.gmail.com>

On Wed, Feb 9, 2011 at 9:21 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 2/9/2011 12:32 PM, skip at pobox.com wrote:
>>
>> Passing this along from webmaster.
>
> It is hard to reply to an attachment rather than inline forwarded message.
> ?However, with rc1
>
>>>> import sqlite3
>>>> sqlite3.version
> '2.6.0'
>>>> sqlite3.sqlite_version
> '3.7.4'

That's not intuitive. It is better to point sqlite3.version to the
actual version of sqlite3 used.

--
anatoly t.

From techtonik at gmail.com  Wed Feb 16 11:53:34 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 16 Feb 2011 12:53:34 +0200
Subject: [Python-Dev] devguide: Fix a silly statement.
In-Reply-To: <ij1g43$r0t$1@dough.gmane.org>
References: <E1PnIzO-0007bi-1c@dinsdale.python.org>
	<ij02gf$v9v$1@dough.gmane.org>
	<AANLkTikNHJ0W=_6CG4KtnbUiRT_hvMzfo-5gV7i=-jUT@mail.gmail.com>
	<ij1g43$r0t$1@dough.gmane.org>
Message-ID: <AANLkTi=0vOzustY=R8k+EBfv0w3v_OmhnPLX1ci8ca4r@mail.gmail.com>

On Thu, Feb 10, 2011 at 10:08 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> Am 10.02.2011 19:27, schrieb Brett Cannon:
>> On Wed, Feb 9, 2011 at 23:10, Georg Brandl <g.brandl at gmx.net> wrote:
>>> Am 09.02.2011 23:58, schrieb brett.cannon:
>>>> brett.cannon pushed 7101df1bd817 to devguide:
>>>>
>>>> http://hg.python.org/devguide/rev/7101df1bd817
>>>> changeset: ? 291:7101df1bd817
>>>> branch: ? ? ?hg_transition
>>>> tag: ? ? ? ? tip
>>>> user: ? ? ? ?Brett Cannon <brett at python.org>
>>>> date: ? ? ? ?Wed Feb 09 14:58:17 2011 -0800
>>>> summary:
>>>> ? Fix a silly statement.
>>>>
>>>> files:
>>>> ? setup.rst
>>>>
>>>> diff --git a/setup.rst b/setup.rst
>>>> --- a/setup.rst
>>>> +++ b/setup.rst
>>>> @@ -34,8 +34,7 @@
>>>> ?:abbr:`VCS`. It also means you will have better tool
>>>> ?support through the VCS as it will provide a diff tool, etc.
>>>>
>>>> -To get a read-only checkout of CPython's source, you need a working copy the
>>>> -source code. To get a read-only checkout of
>>>> +To get a read-only checkout of
>>>> ?the :ref:`in-development <indevbranch>` branch of Python, run::
>>>>
>>>> ? ? ?hg clone http://hg.python.org/cpython
>>>
>>> This statement is still somewhat silly, as a) you get a clone, not a checkout
>>> and b) it is not read only in any way: you can commit just fine. ?The only
>>> difference will be the entry in .hg/hgrc pointing the default repo to something
>>> you can't push to.
>>>
>>> Skimming through, the whole section "Checking out the code" is still way too
>>> SVN-point of viewy (e.g. you always get all branches anyway).
>>
>> I'll take another pass, but do realize this needs to be something that
>> can easily be understood by someone who has never used hg before, so I
>> can't get too technically accurate while ignoring a possible base
>> ignorance of hg and DVCSs as a whole.
>
> Well, it's no good to keep using CVCS terms and mislead users. ?That the
> "checkout" is not a checkout but a full repository is about the most important
> fact about a hg (or any DVCS) clone.

+1
--
anatoly t.

From merwok at netwok.org  Wed Feb 16 12:05:11 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 16 Feb 2011 12:05:11 +0100
Subject: [Python-Dev] devguide: Fix a silly statement.
In-Reply-To: <AANLkTi=0vOzustY=R8k+EBfv0w3v_OmhnPLX1ci8ca4r@mail.gmail.com>
References: <E1PnIzO-0007bi-1c@dinsdale.python.org>	<ij02gf$v9v$1@dough.gmane.org>	<AANLkTikNHJ0W=_6CG4KtnbUiRT_hvMzfo-5gV7i=-jUT@mail.gmail.com>	<ij1g43$r0t$1@dough.gmane.org>
	<AANLkTi=0vOzustY=R8k+EBfv0w3v_OmhnPLX1ci8ca4r@mail.gmail.com>
Message-ID: <4D5BAF67.4000406@netwok.org>

> Well, it's no good to keep using CVCS terms and mislead users.  That the
> "checkout" is not a checkout but a full repository is about the most important
> fact about a hg (or any DVCS) clone.

Well, to really use the Mercurial terms, what you have when you get
stuff from a remote server to your disk is a clone, which contains a
full repository and may contain a working copy (also called checkout).

IOW, ?check out? is used with Mercurial, as a synonym for ?update?, an
operation from the (local) repo to the working directory; the
CVCS-inspired mistake is to use that to refer to an operation from a
remote server to the local disk (?clone?, ?pull?).  HTH

Regards

From merwok at netwok.org  Wed Feb 16 12:01:21 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 16 Feb 2011 12:01:21 +0100
Subject: [Python-Dev] python 3.2 (fwd)
In-Reply-To: <AANLkTineTUsXhdNX6ABMYpx7vTqzx-6e4=k5XnSzktzn@mail.gmail.com>
References: <19794.53174.766166.195523@montanaro.dyndns.org>	<4D52E93F.3020108@udel.edu>
	<AANLkTineTUsXhdNX6ABMYpx7vTqzx-6e4=k5XnSzktzn@mail.gmail.com>
Message-ID: <4D5BAE81.5050709@netwok.org>

>>>>> import sqlite3
>>>>> sqlite3.version
>> '2.6.0'
>>>>> sqlite3.sqlite_version
>> '3.7.4'
> 
> That's not intuitive. It is better to point sqlite3.version to the
> actual version of sqlite3 used.

We can?t break compatibility for such a small thing.  However, it should
be documented in
http://docs.python.org/dev/library/sqlite3#module-functions-and-constants
Could you report the bug?  Thanks in advance.

Regards

From tjreedy at udel.edu  Wed Feb 16 18:34:00 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 16 Feb 2011 12:34:00 -0500
Subject: [Python-Dev] 3.2.0
Message-ID: <ijh1q9$hkj$1@dough.gmane.org>

I would like the next release called 3.2.0 rather than just 3.2.

'x.y' is known to be ambiguous and confusing.

In most actual usages, I believe, it refers to the latest x.y.z release. 
On the site, the 'x.y' docs are almost always the latest version of the 
docs (actually x.y.z+additional fixes). In discussions on python-list, 
for instance, advice to use 'x.y' means to download and use the latest 
x.y.z release, not the initial x.y(.0) release. Similarly on the 
tracker, 'what happens with x.y' means the same.

So the alternate use of 'x.y' to mean x.y(.0) is both confusing and 
correctable, at least for the future.

-- 
Terry Jan Reedy


From brett at python.org  Wed Feb 16 19:52:16 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 16 Feb 2011 10:52:16 -0800
Subject: [Python-Dev] 3.2.0
In-Reply-To: <ijh1q9$hkj$1@dough.gmane.org>
References: <ijh1q9$hkj$1@dough.gmane.org>
Message-ID: <AANLkTina35VO8dm2fv1Kcg6xDKCg+0hAN97oUnG=_=ub@mail.gmail.com>

On Wed, Feb 16, 2011 at 09:34, Terry Reedy <tjreedy at udel.edu> wrote:
> I would like the next release called 3.2.0 rather than just 3.2.
>
> 'x.y' is known to be ambiguous and confusing.
>
> In most actual usages, I believe, it refers to the latest x.y.z release. On
> the site, the 'x.y' docs are almost always the latest version of the docs
> (actually x.y.z+additional fixes). In discussions on python-list, for
> instance, advice to use 'x.y' means to download and use the latest x.y.z
> release, not the initial x.y(.0) release. Similarly on the tracker, 'what
> happens with x.y' means the same.
>
> So the alternate use of 'x.y' to mean x.y(.0) is both confusing and
> correctable, at least for the future.

With all of the writing I have been doing recently, I agree that
disambiguating 3.2.0 from 3.2 is a good thing.

From barry at python.org  Wed Feb 16 20:05:52 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 16 Feb 2011 14:05:52 -0500
Subject: [Python-Dev] 3.2.0
In-Reply-To: <ijh1q9$hkj$1@dough.gmane.org>
References: <ijh1q9$hkj$1@dough.gmane.org>
Message-ID: <20110216140552.3eb0ddda@python.org>

On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote:

>I would like the next release called 3.2.0 rather than just 3.2.

+1

(I'd have said +0 for the humor of 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/20110216/6a181a99/attachment.pgp>

From ncoghlan at gmail.com  Wed Feb 16 23:39:55 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 17 Feb 2011 08:39:55 +1000
Subject: [Python-Dev] 3.2.0
In-Reply-To: <20110216140552.3eb0ddda@python.org>
References: <ijh1q9$hkj$1@dough.gmane.org> <20110216140552.3eb0ddda@python.org>
Message-ID: <AANLkTik=TdV3fE-Gn01rmOONUsGqw_P-4gndDZPFWwcz@mail.gmail.com>

On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsaw <barry at python.org> wrote:
> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote:
>
>>I would like the next release called 3.2.0 rather than just 3.2.
>
> +1
>
> (I'd have said +0 for the humor of it :).

+0

I actually *am* only +0, since I like the idea in principle, but it is
Georg, Ronald and Martin that would need to do the work, and I'm not
sure it's a great idea to be messing with it a couple of days out from
the release. So it may be better to do this for 3.3.0, rather than
3.2.0.

Cheers,
Nick.

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

From victor.stinner at haypocalc.com  Wed Feb 16 23:43:04 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Wed, 16 Feb 2011 23:43:04 +0100
Subject: [Python-Dev] 3.2.0
In-Reply-To: <20110216140552.3eb0ddda@python.org>
References: <ijh1q9$hkj$1@dough.gmane.org> <20110216140552.3eb0ddda@python.org>
Message-ID: <1297896184.5710.7.camel@marge>

Le mercredi 16 f?vrier 2011 ? 14:05 -0500, Barry Warsaw a ?crit :
> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote:
> 
> >I would like the next release called 3.2.0 rather than just 3.2.
> 
> +1
> 
> (I'd have said +0 for the humor of it :).

Should we write +1.0, +1.000000003 or just +1? Mark can maybe help us on
this question.

Victor


From anikom15 at gmail.com  Thu Feb 17 00:33:58 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Wed, 16 Feb 2011 15:33:58 -0800
Subject: [Python-Dev] 3.2.0
In-Reply-To: <ijh1q9$hkj$1@dough.gmane.org>
References: <ijh1q9$hkj$1@dough.gmane.org>
Message-ID: <1297899238.5832.2.camel@localhost.localdomain>

On Wed, 2011-02-16 at 12:34 -0500, Terry Reedy wrote:
> I would like the next release called 3.2.0 rather than just 3.2.
- -1


From raymond.hettinger at gmail.com  Thu Feb 17 03:08:17 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 16 Feb 2011 18:08:17 -0800
Subject: [Python-Dev] 3.2.0
In-Reply-To: <AANLkTik=TdV3fE-Gn01rmOONUsGqw_P-4gndDZPFWwcz@mail.gmail.com>
References: <ijh1q9$hkj$1@dough.gmane.org> <20110216140552.3eb0ddda@python.org>
	<AANLkTik=TdV3fE-Gn01rmOONUsGqw_P-4gndDZPFWwcz@mail.gmail.com>
Message-ID: <C5259322-C39C-4E35-8EDA-BDDC925846EF@gmail.com>


On Feb 16, 2011, at 2:39 PM, Nick Coghlan wrote:

> On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsaw <barry at python.org> wrote:
>> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote:
>> 
>>> I would like the next release called 3.2.0 rather than just 3.2.
>> 
>> +1
>> 
>> (I'd have said +0 for the humor of it :).
> 
> +0
> 
> I actually *am* only +0, since I like the idea in principle, but it is
> Georg, Ronald and Martin that would need to do the work, and I'm not
> sure it's a great idea to be messing with it a couple of days out from
> the release. So it may be better to do this for 3.3.0, rather than
> 3.2.0.

The basic idea is reasonable, but it's a little late in the game to make 
any changes.  This is ready to ship and we're doing our best
to make no changes at all to RC3.

The web page and announcement can say 3.2.0 but I'm opposed to
changing anything in the release at this point.  We have some 
real bugfixes that we're delaying until 3.2.1, so why would we
make an exception for a non-essential changes such as this.


Raymond


From tjreedy at udel.edu  Thu Feb 17 04:45:03 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 16 Feb 2011 22:45:03 -0500
Subject: [Python-Dev] 3.2.0
In-Reply-To: <AANLkTik=TdV3fE-Gn01rmOONUsGqw_P-4gndDZPFWwcz@mail.gmail.com>
References: <ijh1q9$hkj$1@dough.gmane.org> <20110216140552.3eb0ddda@python.org>
	<AANLkTik=TdV3fE-Gn01rmOONUsGqw_P-4gndDZPFWwcz@mail.gmail.com>
Message-ID: <iji5k0$70m$1@dough.gmane.org>

On 2/16/2011 5:39 PM, Nick Coghlan wrote:
> On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsaw<barry at python.org>  wrote:
>> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote:
>>
>>> I would like the next release called 3.2.0 rather than just 3.2.
>>
>> +1
>>
>> (I'd have said +0 for the humor of it :).
>
> +0
>
> I actually *am* only +0, since I like the idea in principle, but it is
> Georg, Ronald and Martin that would need to do the work, and I'm not
> sure it's a great idea to be messing with it a couple of days out from
> the release. So it may be better to do this for 3.3.0, rather than
> 3.2.0.

My immediate suggestion is predicated on the assumption that it would be 
easy and safe to change '3.2rc2' in the various places it appears to 
'3.2.0' instead of '3.2'. If that is not true, then my suggestion is 
that after 3.2 is released, that trunk be regarded as 3.3.0a0 rather 
than 3.3a0 as soon as it make any difference anywhere.

-- 
Terry Jan Reedy


From g.brandl at gmx.net  Thu Feb 17 07:07:52 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 17 Feb 2011 07:07:52 +0100
Subject: [Python-Dev] 3.2.0
In-Reply-To: <C5259322-C39C-4E35-8EDA-BDDC925846EF@gmail.com>
References: <ijh1q9$hkj$1@dough.gmane.org>
	<20110216140552.3eb0ddda@python.org>	<AANLkTik=TdV3fE-Gn01rmOONUsGqw_P-4gndDZPFWwcz@mail.gmail.com>
	<C5259322-C39C-4E35-8EDA-BDDC925846EF@gmail.com>
Message-ID: <ijidvv$54v$1@dough.gmane.org>

Am 17.02.2011 03:08, schrieb Raymond Hettinger:
> 
> On Feb 16, 2011, at 2:39 PM, Nick Coghlan wrote:
> 
>> On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsaw <barry at python.org> wrote:
>>> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote:
>>> 
>>>> I would like the next release called 3.2.0 rather than just 3.2.
>>> 
>>> +1
>>> 
>>> (I'd have said +0 for the humor of it :).
>> 
>> +0
>> 
>> I actually *am* only +0, since I like the idea in principle, but it is
>> Georg, Ronald and Martin that would need to do the work, and I'm not
>> sure it's a great idea to be messing with it a couple of days out from
>> the release. So it may be better to do this for 3.3.0, rather than
>> 3.2.0.
> 
> The basic idea is reasonable, but it's a little late in the game to make 
> any changes.  This is ready to ship and we're doing our best
> to make no changes at all to RC3.
> 
> The web page and announcement can say 3.2.0 but I'm opposed to
> changing anything in the release at this point.  We have some 
> real bugfixes that we're delaying until 3.2.1, so why would we
> make an exception for a non-essential changes such as this.

Quite right.  I will see where I can put "3.2.0" on the website, but I
will not fiddle with the release tools (much of this is automated) at
this stage in the process.

Georg


From orsenthil at gmail.com  Thu Feb 17 07:36:11 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Thu, 17 Feb 2011 14:36:11 +0800
Subject: [Python-Dev] 3.2.0
In-Reply-To: <ijh1q9$hkj$1@dough.gmane.org>
References: <ijh1q9$hkj$1@dough.gmane.org>
Message-ID: <AANLkTinYNPLQQ_mAKyigeuRzp=seNrtkp-HDZfNtEijs@mail.gmail.com>

On Thu, Feb 17, 2011 at 1:34 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> 'x.y' is known to be ambiguous and confusing.

Not really.

x.y seems to be saying it is a milestone (major release) and we all
have got used to that convention.

> In most actual usages, I believe, it refers to the latest x.y.z release. On

While I agree with all these points, I feel calling the release itself
as x.y.0 may be distracting the convention which is being followed so
far.
So, it is -1 from me.

In the mailing list we can say that use the 'latest' of python 2.x
version or 'latest' of python 3.x version and on the web-pages,
pointers can be properly set to the correct version.

-- 
Senthil

From solipsis at pitrou.net  Thu Feb 17 12:20:58 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 17 Feb 2011 12:20:58 +0100
Subject: [Python-Dev] 3.2.0
References: <ijh1q9$hkj$1@dough.gmane.org>
	<AANLkTina35VO8dm2fv1Kcg6xDKCg+0hAN97oUnG=_=ub@mail.gmail.com>
Message-ID: <20110217122058.4b83530c@pitrou.net>

On Wed, 16 Feb 2011 10:52:16 -0800
Brett Cannon <brett at python.org> wrote:

> On Wed, Feb 16, 2011 at 09:34, Terry Reedy <tjreedy at udel.edu> wrote:
> > I would like the next release called 3.2.0 rather than just 3.2.
> >
> > 'x.y' is known to be ambiguous and confusing.
> >
> > In most actual usages, I believe, it refers to the latest x.y.z release. On
> > the site, the 'x.y' docs are almost always the latest version of the docs
> > (actually x.y.z+additional fixes). In discussions on python-list, for
> > instance, advice to use 'x.y' means to download and use the latest x.y.z
> > release, not the initial x.y(.0) release. Similarly on the tracker, 'what
> > happens with x.y' means the same.
> >
> > So the alternate use of 'x.y' to mean x.y(.0) is both confusing and
> > correctable, at least for the future.
> 
> With all of the writing I have been doing recently, I agree that
> disambiguating 3.2.0 from 3.2 is a good thing.

Agreed. Although better to defer it to 3.3.0 at this point.

Regards

Antoine.



From regebro at gmail.com  Thu Feb 17 14:14:41 2011
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 17 Feb 2011 14:14:41 +0100
Subject: [Python-Dev] 3.2.0
In-Reply-To: <20110217122058.4b83530c@pitrou.net>
References: <ijh1q9$hkj$1@dough.gmane.org>
	<AANLkTina35VO8dm2fv1Kcg6xDKCg+0hAN97oUnG=_=ub@mail.gmail.com>
	<20110217122058.4b83530c@pitrou.net>
Message-ID: <AANLkTinnHNcVGCY_M8jJj9bDv9NHSDp3cMT9q6HJSAzV@mail.gmail.com>

On Thu, Feb 17, 2011 at 12:20, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Agreed. Although better to defer it to 3.3.0 at this point.

+1.0.0 for that.

Yes, it's confusing, but it's going to be even more confusing if it's
called 3.2 sometimes and 3.2.0 sometimes.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python3porting.com/
+33 661 58 14 64

From tjreedy at udel.edu  Thu Feb 17 18:19:58 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 Feb 2011 12:19:58 -0500
Subject: [Python-Dev] 3.2.0
In-Reply-To: <AANLkTinYNPLQQ_mAKyigeuRzp=seNrtkp-HDZfNtEijs@mail.gmail.com>
References: <ijh1q9$hkj$1@dough.gmane.org>
	<AANLkTinYNPLQQ_mAKyigeuRzp=seNrtkp-HDZfNtEijs@mail.gmail.com>
Message-ID: <ijjlbv$q0t$1@dough.gmane.org>

On 2/17/2011 1:36 AM, Senthil Kumaran wrote:
> On Thu, Feb 17, 2011 at 1:34 AM, Terry Reedy<tjreedy at udel.edu>  wrote:
>
>> 'x.y' is known to be ambiguous and confusing.
>
> Not really.

Actually, to me, the confusion is slightly worse, and the reason to 
change slightly stronger, than I initially explained. Python x.y is a 
version of the *language*. CPython x.y.z is an occasional marked release 
of an *implementation*.

For instance, Python 3.2 is a version of the language and stdlib. It has 
been pretty well defined since new features were prohibited.

The 3.2 docs are the specification of Python 3.2 (with a few 
CPython-specific notes). The 3.2 docs will be continuously upgraded as 
deficiencies are noted and fixed. As I understand it, all patches are 
expected to leave the docs in an improved and buildable state, so that 
updates can be built and uploaded to the site frequently (daily?).

CPython 3.2.0 will be the first 'production' release of the CPython 
implementation of Python 3.2. It will be one in a series of 
approximation of an ideal bug-free 'CPython 3.2'. Some have already been 
released, more will come. Like the docs, the concrete CPython 3.2 
codebase will also be continuously upgraded. For various reasons, it 
will probably not always be buildable on all platforms and not always be 
production ready. For practical reasons, marked releases will be spaced 
some months apart.

So, for me, Python 3.2 is a now theoritically fixed version of the 
language. The Python 3.2 docs document that version, but will be 
upgraded as mistaked, ambiguities, and omissions are found. The CPython 
3.2 codebase is an evolving approximation of an ideal bug-free CPython 
3.2 (that will never be reached). And CPython 3.2.0 is an early snapshot 
release of that evolving codebase.

-- 
Terry Jan Reedy


From ncoghlan at gmail.com  Thu Feb 17 22:56:00 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 18 Feb 2011 07:56:00 +1000
Subject: [Python-Dev] 3.2.0
In-Reply-To: <ijjlbv$q0t$1@dough.gmane.org>
References: <ijh1q9$hkj$1@dough.gmane.org>
	<AANLkTinYNPLQQ_mAKyigeuRzp=seNrtkp-HDZfNtEijs@mail.gmail.com>
	<ijjlbv$q0t$1@dough.gmane.org>
Message-ID: <AANLkTikzk7NunFQ817FvmLcw+2kj=oo9Y2eWvR9LuTnA@mail.gmail.com>

On Fri, Feb 18, 2011 at 3:19 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> Actually, to me, the confusion is slightly worse, and the reason to change
> slightly stronger, than I initially explained. Python x.y is a version of
> the *language*. CPython x.y.z is an occasional marked release of an
> *implementation*.
>
> For instance, Python 3.2 is a version of the language and stdlib. It has
> been pretty well defined since new features were prohibited.
>
> The 3.2 docs are the specification of Python 3.2 (with a few
> CPython-specific notes). The 3.2 docs will be continuously upgraded as
> deficiencies are noted and fixed. As I understand it, all patches are
> expected to leave the docs in an improved and buildable state, so that
> updates can be built and uploaded to the site frequently (daily?).
>
> CPython 3.2.0 will be the first 'production' release of the CPython
> implementation of Python 3.2. It will be one in a series of approximation of
> an ideal bug-free 'CPython 3.2'. Some have already been released, more will
> come. Like the docs, the concrete CPython 3.2 codebase will also be
> continuously upgraded. For various reasons, it will probably not always be
> buildable on all platforms and not always be production ready. For practical
> reasons, marked releases will be spaced some months apart.
>
> So, for me, Python 3.2 is a now theoritically fixed version of the language.
> The Python 3.2 docs document that version, but will be upgraded as mistaked,
> ambiguities, and omissions are found. The CPython 3.2 codebase is an
> evolving approximation of an ideal bug-free CPython 3.2 (that will never be
> reached). And CPython 3.2.0 is an early snapshot release of that evolving
> codebase.

I actually agree with this viewpoint, and think it would definitely be
a good way to go for 3.3.0.

For the 3.2 series, I think living with the ambiguity for another 6
months or so (however long it is until 3.2.1 is released) is the
better choice. There are enough parts of the release process that
involve the version number that we *really* shouldn't be messing with
it during the RC phase.

Cheers,
Nick.

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

From ncoghlan at gmail.com  Thu Feb 17 23:01:55 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 18 Feb 2011 08:01:55 +1000
Subject: [Python-Dev] 3.2.0
In-Reply-To: <AANLkTikzk7NunFQ817FvmLcw+2kj=oo9Y2eWvR9LuTnA@mail.gmail.com>
References: <ijh1q9$hkj$1@dough.gmane.org>
	<AANLkTinYNPLQQ_mAKyigeuRzp=seNrtkp-HDZfNtEijs@mail.gmail.com>
	<ijjlbv$q0t$1@dough.gmane.org>
	<AANLkTikzk7NunFQ817FvmLcw+2kj=oo9Y2eWvR9LuTnA@mail.gmail.com>
Message-ID: <AANLkTikXej8sx0bTZaXtUOc3b=uRk8B6igrqLypzr4Dk@mail.gmail.com>

On Fri, Feb 18, 2011 at 7:56 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> For the 3.2 series, I think living with the ambiguity for another 6
> months or so (however long it is until 3.2.1 is released) is the
> better choice. There are enough parts of the release process that
> involve the version number that we *really* shouldn't be messing with
> it during the RC phase.

And the number 1 reason I consider messing with the numbering to be a bad idea:

>>> "3.2" >= "3.2.0"
False
>>> (3, 2) >= (3, 2, 0)
False

If we miss anything, it could easily lead to errors like the two
above. I'll grant that it *shouldn't* be any different to what happens
when the release version gets bumped to 3.2.1 in the first maintenance
release, but I really don't trust "should" all that much in a release
management context :)

Cheers,
Nick.

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

From santoso.wijaya at gmail.com  Thu Feb 17 23:19:13 2011
From: santoso.wijaya at gmail.com (Santoso Wijaya)
Date: Thu, 17 Feb 2011 14:19:13 -0800
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <1297761906.31674.0.camel@marge>
References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge>
Message-ID: <AANLkTinjrwj8BM_NjYH+AxXktDH==LQywOBJ5dL64RzY@mail.gmail.com>

Speaking of, what is the current status and timeline on the move to
Mercurial?

~/santa


On Tue, Feb 15, 2011 at 1:25 AM, Victor Stinner <
victor.stinner at haypocalc.com> wrote:

> Le mardi 15 f?vrier 2011 ? 09:30 +0100, "Martin v. L?wis" a ?crit :
> > I'm going to perform a Debian upgrade of svn.python.org on Friday,
> > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
> > that time. The outage shouldn't be longer than an hour.
>
> It's time to move 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/santoso.wijaya%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110217/d7ed0e6a/attachment.html>

From fuzzyman at voidspace.org.uk  Thu Feb 17 23:35:30 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 17 Feb 2011 22:35:30 +0000
Subject: [Python-Dev] 3.2.0
In-Reply-To: <AANLkTikXej8sx0bTZaXtUOc3b=uRk8B6igrqLypzr4Dk@mail.gmail.com>
References: <ijh1q9$hkj$1@dough.gmane.org>	<AANLkTinYNPLQQ_mAKyigeuRzp=seNrtkp-HDZfNtEijs@mail.gmail.com>	<ijjlbv$q0t$1@dough.gmane.org>	<AANLkTikzk7NunFQ817FvmLcw+2kj=oo9Y2eWvR9LuTnA@mail.gmail.com>
	<AANLkTikXej8sx0bTZaXtUOc3b=uRk8B6igrqLypzr4Dk@mail.gmail.com>
Message-ID: <4D5DA2B2.2030900@voidspace.org.uk>

On 17/02/2011 22:01, Nick Coghlan wrote:
> On Fri, Feb 18, 2011 at 7:56 AM, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>> For the 3.2 series, I think living with the ambiguity for another 6
>> months or so (however long it is until 3.2.1 is released) is the
>> better choice. There are enough parts of the release process that
>> involve the version number that we *really* shouldn't be messing with
>> it during the RC phase.
> And the number 1 reason I consider messing with the numbering to be a bad idea:
>
>>>> "3.2">= "3.2.0"
> False
>>>> (3, 2)>= (3, 2, 0)
> False
>
> If we miss anything, it could easily lead to errors like the two
> above.

How are those errors?  Surely what matters is that the following *is* True:

 >>> (3, 2, 0) >= (3, 2)
True
 >>> "3.2.0" >= "3.2"
True

I'm +1 for the change, but happy for it to happen for 3.3.0 given how 
close we are to 3.2 release.

Michael Foord



> I'll grant that it *shouldn't* be any different to what happens
> when the release version gets bumped to 3.2.1 in the first maintenance
> release, but I really don't trust "should" all that much in a release
> management context :)
>
> 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 martin at v.loewis.de  Fri Feb 18 00:17:32 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 18 Feb 2011 00:17:32 +0100
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <AANLkTinjrwj8BM_NjYH+AxXktDH==LQywOBJ5dL64RzY@mail.gmail.com>
References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge>
	<AANLkTinjrwj8BM_NjYH+AxXktDH==LQywOBJ5dL64RzY@mail.gmail.com>
Message-ID: <4D5DAC8C.3030304@v.loewis.de>

Am 17.02.2011 23:19, schrieb Santoso Wijaya:
> Speaking of, what is the current status and timeline on the move to
> Mercurial?

I think it's fair to say that the project currently rests, lacking
a project lead. The most recent timeline is that conversion should
be completed by PyCon, and, failing that, should start at PyCon.

Regards,
Martin

From dirkjan at ochtman.nl  Fri Feb 18 08:09:12 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Fri, 18 Feb 2011 08:09:12 +0100
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <4D5DAC8C.3030304@v.loewis.de>
References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge>
	<AANLkTinjrwj8BM_NjYH+AxXktDH==LQywOBJ5dL64RzY@mail.gmail.com>
	<4D5DAC8C.3030304@v.loewis.de>
Message-ID: <AANLkTimQVLfYBuCHZGrTcXyZbxXVb7yV+S9cz9Wgtqsn@mail.gmail.com>

On Fri, Feb 18, 2011 at 00:17, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I think it's fair to say that the project currently rests, lacking
> a project lead. The most recent timeline is that conversion should
> be completed by PyCon, and, failing that, should start at PyCon.

It's not exactly resting; I've been pushing around the
cvs2svn-converted tags to get them to behave sensibly, and I've been
having good discussions with Antoine and Georg about several things we
need to hash out in IRC. Sorry I haven't been doing more progress
reports here.

But yes, it would be nice if we could actually switch by PyCon, but at
the very least there should be a fresh test repo and consensus on most
of the workflow issues by PyCon (for those interested who live in
Europe, I'm going to be at a hg sprint in Karlsruhe during the PyCon
weekend).

Cheers,

Dirkjan

From dirkjan at ochtman.nl  Fri Feb 18 14:41:00 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Fri, 18 Feb 2011 14:41:00 +0100
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <4D5A3990.4040902@v.loewis.de>
References: <4D5A3990.4040902@v.loewis.de>
Message-ID: <AANLkTi=hVdRQbnzJOUjnkSsw4ZKTVfDJcwpOR5D3g6Wy@mail.gmail.com>

On Tue, Feb 15, 2011 at 09:30, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I'm going to perform a Debian upgrade of svn.python.org on Friday,
> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
> that time. The outage shouldn't be longer than an hour.

It seems hg is no longer installed on dinsdale, does that have
anything to do with this?

Cheers,

Dirkjan

From techtonik at gmail.com  Fri Feb 18 14:41:33 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 18 Feb 2011 15:41:33 +0200
Subject: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn outage
 on Friday)
Message-ID: <AANLkTimA45PxAtz1KvA_JWvHnUX=9hBPSqPPBOGHkdtr@mail.gmail.com>

On Fri, Feb 18, 2011 at 9:09 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> On Fri, Feb 18, 2011 at 00:17, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I think it's fair to say that the project currently rests, lacking
>> a project lead. The most recent timeline is that conversion should
>> be completed by PyCon, and, failing that, should start at PyCon.
>
> It's not exactly resting; I've been pushing around the
> cvs2svn-converted tags to get them to behave sensibly, and I've been
> having good discussions with Antoine and Georg about several things we
> need to hash out in IRC. Sorry I haven't been doing more progress
> reports here.

Do you have a public list of stuff to be done (i.e. Roadmap)?
BTW, what is the size of Mercurial clone for Python repository?
--
anatoly t.

From techtonik at gmail.com  Fri Feb 18 14:44:41 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 18 Feb 2011 15:44:41 +0200
Subject: [Python-Dev] devguide: Fix a silly statement.
In-Reply-To: <4D5BAF67.4000406@netwok.org>
References: <E1PnIzO-0007bi-1c@dinsdale.python.org>
	<ij02gf$v9v$1@dough.gmane.org>
	<AANLkTikNHJ0W=_6CG4KtnbUiRT_hvMzfo-5gV7i=-jUT@mail.gmail.com>
	<ij1g43$r0t$1@dough.gmane.org>
	<AANLkTi=0vOzustY=R8k+EBfv0w3v_OmhnPLX1ci8ca4r@mail.gmail.com>
	<4D5BAF67.4000406@netwok.org>
Message-ID: <AANLkTim8=F1xXWTw8BMLBfjjscO9R6NbanDdKcR9fTYF@mail.gmail.com>

On Wed, Feb 16, 2011 at 1:05 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> Well, it's no good to keep using CVCS terms and mislead users. ?That the
>> "checkout" is not a checkout but a full repository is about the most important
>> fact about a hg (or any DVCS) clone.
>
> Well, to really use the Mercurial terms, what you have when you get
> stuff from a remote server to your disk is a clone, which contains a
> full repository and may contain a working copy (also called checkout).

And that's the proper way to describe this.

> IOW, ?check out? is used with Mercurial, as a synonym for ?update?, an
> operation from the (local) repo to the working directory; the
> CVCS-inspired mistake is to use that to refer to an operation from a
> remote server to the local disk (?clone?, ?pull?). ?HTH

Exactly.
--
anatoly t.

From dirkjan at ochtman.nl  Fri Feb 18 15:00:06 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Fri, 18 Feb 2011 15:00:06 +0100
Subject: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn
 outage on Friday)
In-Reply-To: <AANLkTimA45PxAtz1KvA_JWvHnUX=9hBPSqPPBOGHkdtr@mail.gmail.com>
References: <AANLkTimA45PxAtz1KvA_JWvHnUX=9hBPSqPPBOGHkdtr@mail.gmail.com>
Message-ID: <AANLkTimaKn2pE3+tAQXiU7_Zd64RHZNG7i_u0VoHFsuw@mail.gmail.com>

On Fri, Feb 18, 2011 at 14:41, anatoly techtonik <techtonik at gmail.com> wrote:
> Do you have a public list of stuff to be done (i.e. Roadmap)?
> BTW, what is the size of Mercurial clone for Python repository?

There is a TODO file in the pymigr repo (though I think that is
currently inaccessible).

I don't have a recent optimized clone to check the size of, yet.

Cheers,

Dirkjan

From ncoghlan at gmail.com  Fri Feb 18 15:47:42 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Feb 2011 00:47:42 +1000
Subject: [Python-Dev] 3.2.0
In-Reply-To: <4D5DA2B2.2030900@voidspace.org.uk>
References: <ijh1q9$hkj$1@dough.gmane.org>
	<AANLkTinYNPLQQ_mAKyigeuRzp=seNrtkp-HDZfNtEijs@mail.gmail.com>
	<ijjlbv$q0t$1@dough.gmane.org>
	<AANLkTikzk7NunFQ817FvmLcw+2kj=oo9Y2eWvR9LuTnA@mail.gmail.com>
	<AANLkTikXej8sx0bTZaXtUOc3b=uRk8B6igrqLypzr4Dk@mail.gmail.com>
	<4D5DA2B2.2030900@voidspace.org.uk>
Message-ID: <AANLkTi=+O3zzemNOZ2+nDry=SG8rn4uSNXrv+JWi5LTB@mail.gmail.com>

On Fri, Feb 18, 2011 at 8:35 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
>> And the number 1 reason I consider messing with the numbering to be a bad
>> idea:
>>
>>>>> "3.2">= "3.2.0"
>>
>> False
>>>>>
>>>>> (3, 2)>= (3, 2, 0)
>>
>> False
>>
>> If we miss anything, it could easily lead to errors like the two
>> above.
>
> How are those errors? ?Surely what matters is that the following *is* True:
>
>>>> (3, 2, 0) >= (3, 2)
> True
>>>> "3.2.0" >= "3.2"
> True

They aren't errors per se, but they're different from the answer you
get with a "3.2" or "(3, 2)" on both sides of the equation (as
behavioural changes go, such a change is probably a good thing, since
it makes naive version checks less likely to break when 3.2.1 hits,
but it's a concrete behavioural change in the release that isn't
really an option until we start working on 3.3).

Cheers,
Nick.

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

From status at bugs.python.org  Fri Feb 18 18:06:52 2011
From: status at bugs.python.org (Python tracker)
Date: Fri, 18 Feb 2011 18:06:52 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20110218170652.8D9D41D9FD@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2011-02-11 - 2011-02-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    2655 (+28)
  closed 20370 (+22)
  total  23025 (+50)

Open issues with patches: 1130 


Issues opened (41)
==================

#7284: optparse - display version in usage by default
http://bugs.python.org/issue7284  reopened by techtonik

#11195: next fixer fooled by trailing cheracters
http://bugs.python.org/issue11195  opened by piro

#11197: information leakage with SimpleHTTPServer
http://bugs.python.org/issue11197  opened by brett.cannon

#11199: urllib hangs when closing connection
http://bugs.python.org/issue11199  opened by rg3

#11200: Addition of abiflags breaks distutils
http://bugs.python.org/issue11200  opened by a.badger

#11201: Python installation error 2203
http://bugs.python.org/issue11201  opened by corenova

#11203: gzip doc is behind
http://bugs.python.org/issue11203  opened by teamnoir

#11204: re module: strange behaviour of space inside {m, n}
http://bugs.python.org/issue11204  opened by sjmachin

#11205: Evaluation order of dictionary display is different from refer
http://bugs.python.org/issue11205  opened by takayuki

#11206: test_readline unconditionally calls clear_history()
http://bugs.python.org/issue11206  opened by georg.brandl

#11207: Pythong seg fault with PIL/numpy
http://bugs.python.org/issue11207  opened by David.Knapp

#11210: PyErr_SetFromWindowsErrWithFilenameObject() doesn't exist: rem
http://bugs.python.org/issue11210  opened by haypo

#11212: Python memory limit on AIX
http://bugs.python.org/issue11212  opened by sable

#11214: test_asyncore fails on AIX
http://bugs.python.org/issue11214  opened by sable

#11215: test_fileio error on AIX
http://bugs.python.org/issue11215  opened by sable

#11216: email.message.Message set_charset does not encode properly?
http://bugs.python.org/issue11216  opened by Shay.Rojansky

#11217: python-32 not linked in /usr/local/bin in framework builds
http://bugs.python.org/issue11217  opened by tloredo

#11218: pattern=None when following documentation for load_tests and u
http://bugs.python.org/issue11218  opened by gagern

#11219: Produce a warning when the license is specified in both the Li
http://bugs.python.org/issue11219  opened by kelseyhightower

#11222: Python3.2rc3 fails to build on Mac OS X with a non-framework b
http://bugs.python.org/issue11222  opened by jszakmeister

#11223: interruption of locks by signals not guaranteed when the semap
http://bugs.python.org/issue11223  opened by sable

#11224: 3.2: tarfile.getmembers causes 100% cpu usage on Windows
http://bugs.python.org/issue11224  opened by srid

#11225: getcwd fix for NetBSD to handle ERANGE errno
http://bugs.python.org/issue11225  opened by njoly

#11226: subprocesses experience mysterious delay in receiving stdin EO
http://bugs.python.org/issue11226  opened by yaaang

#11227: [DOC] asyncore - use 'Host' header in HTTP example
http://bugs.python.org/issue11227  opened by sandro.tosi

#11229: Make the Mac installer more like the Windows installer
http://bugs.python.org/issue11229  opened by rhettinger

#11230: "Full unicode import system" not in 3.2
http://bugs.python.org/issue11230  opened by jh45

#11231: bytes() constructor is not correctly documented
http://bugs.python.org/issue11231  opened by haypo

#11232: asyncore - don't throw a traceback when a client disconnects i
http://bugs.python.org/issue11232  opened by sandro.tosi

#11233: clarifying Availability: Unix
http://bugs.python.org/issue11233  opened by sandro.tosi

#11234: Possible error in What's new Python3.2(rc3) documentation (sys
http://bugs.python.org/issue11234  opened by chaica_

#11235: Source files with date modifed in 2106 cause OverflowError
http://bugs.python.org/issue11235  opened by Guy.Kisel

#11236: getpass.getpass does not respond to ctrl-c or ctrl-z
http://bugs.python.org/issue11236  opened by valhallasw

#11238: sets - refer to sets/frozenset in stdtypes
http://bugs.python.org/issue11238  opened by sandro.tosi

#11239: regexp-howto - add missing } to metachars
http://bugs.python.org/issue11239  opened by sandro.tosi

#11240: Running unit tests in a command line tool leads to infinite lo
http://bugs.python.org/issue11240  opened by mattchaput

#11241: ctypes: subclassing an already subclassed ArrayType generates 
http://bugs.python.org/issue11241  opened by Steve.Thompson

#11242: urllib.request.url_open() doesn't support SSLContext
http://bugs.python.org/issue11242  opened by haypo

#11243: email/message.py str conversion
http://bugs.python.org/issue11243  opened by sdaoden

#941346: AIX shared library fix
http://bugs.python.org/issue941346  reopened by georg.brandl

#1704474: optparse tests fail under Jython
http://bugs.python.org/issue1704474  reopened by r.david.murray



Most recent 15 issues with no replies (15)
==========================================

#11242: urllib.request.url_open() doesn't support SSLContext
http://bugs.python.org/issue11242

#11241: ctypes: subclassing an already subclassed ArrayType generates 
http://bugs.python.org/issue11241

#11239: regexp-howto - add missing } to metachars
http://bugs.python.org/issue11239

#11238: sets - refer to sets/frozenset in stdtypes
http://bugs.python.org/issue11238

#11229: Make the Mac installer more like the Windows installer
http://bugs.python.org/issue11229

#11226: subprocesses experience mysterious delay in receiving stdin EO
http://bugs.python.org/issue11226

#11225: getcwd fix for NetBSD to handle ERANGE errno
http://bugs.python.org/issue11225

#11224: 3.2: tarfile.getmembers causes 100% cpu usage on Windows
http://bugs.python.org/issue11224

#11218: pattern=None when following documentation for load_tests and u
http://bugs.python.org/issue11218

#11210: PyErr_SetFromWindowsErrWithFilenameObject() doesn't exist: rem
http://bugs.python.org/issue11210

#11206: test_readline unconditionally calls clear_history()
http://bugs.python.org/issue11206

#11204: re module: strange behaviour of space inside {m, n}
http://bugs.python.org/issue11204

#11203: gzip doc is behind
http://bugs.python.org/issue11203

#11199: urllib hangs when closing connection
http://bugs.python.org/issue11199

#11195: next fixer fooled by trailing cheracters
http://bugs.python.org/issue11195



Most recent 15 issues waiting for review (15)
=============================================

#11243: email/message.py str conversion
http://bugs.python.org/issue11243

#11239: regexp-howto - add missing } to metachars
http://bugs.python.org/issue11239

#11238: sets - refer to sets/frozenset in stdtypes
http://bugs.python.org/issue11238

#11232: asyncore - don't throw a traceback when a client disconnects i
http://bugs.python.org/issue11232

#11227: [DOC] asyncore - use 'Host' header in HTTP example
http://bugs.python.org/issue11227

#11225: getcwd fix for NetBSD to handle ERANGE errno
http://bugs.python.org/issue11225

#11223: interruption of locks by signals not guaranteed when the semap
http://bugs.python.org/issue11223

#11222: Python3.2rc3 fails to build on Mac OS X with a non-framework b
http://bugs.python.org/issue11222

#11212: Python memory limit on AIX
http://bugs.python.org/issue11212

#11210: PyErr_SetFromWindowsErrWithFilenameObject() doesn't exist: rem
http://bugs.python.org/issue11210

#11205: Evaluation order of dictionary display is different from refer
http://bugs.python.org/issue11205

#11188: test_time error on AIX
http://bugs.python.org/issue11188

#11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede
http://bugs.python.org/issue11187

#11184: Broken large file support on AIX
http://bugs.python.org/issue11184

#11177: Set asyncore create_socket default argument
http://bugs.python.org/issue11177



Top 10 most discussed issues (10)
=================================

#10181: Problems with Py_buffer management in memoryobject.c (and else
http://bugs.python.org/issue10181  25 msgs

#11222: Python3.2rc3 fails to build on Mac OS X with a non-framework b
http://bugs.python.org/issue11222  20 msgs

#11223: interruption of locks by signals not guaranteed when the semap
http://bugs.python.org/issue11223  16 msgs

#11205: Evaluation order of dictionary display is different from refer
http://bugs.python.org/issue11205  14 msgs

#11212: Python memory limit on AIX
http://bugs.python.org/issue11212  14 msgs

#941346: AIX shared library fix
http://bugs.python.org/issue941346  13 msgs

#11188: test_time error on AIX
http://bugs.python.org/issue11188  12 msgs

#11219: Produce a warning when the license is specified in both the Li
http://bugs.python.org/issue11219   9 msgs

#3244: multipart/form-data encoding
http://bugs.python.org/issue3244   7 msgs

#5537: LWPCookieJar cannot handle cookies with expirations of 2038 or
http://bugs.python.org/issue5537   7 msgs



Issues closed (24)
==================

#4379: Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing
http://bugs.python.org/issue4379  closed by haypo

#5736: Add the iterator protocol to dbm modules
http://bugs.python.org/issue5736  closed by eric.araujo

#7305: urllib2.urlopen() segfault using SSL on Solaris
http://bugs.python.org/issue7305  closed by orsenthil

#10720: test_threadsignals hang on FreeBSD 6.4
http://bugs.python.org/issue10720  closed by pitrou

#11116: mailbox and email errors
http://bugs.python.org/issue11116  closed by r.david.murray

#11134: Add missing type slots
http://bugs.python.org/issue11134  closed by loewis

#11135: Redundant doc field in TypeSpec
http://bugs.python.org/issue11135  closed by loewis

#11171: Python 2.7.1 does not start when "./configure" is used with  "
http://bugs.python.org/issue11171  closed by barry

#11181: TLS end connection not detected properly in retrbinary
http://bugs.python.org/issue11181  closed by adiroiban

#11194: "lock.__exit__ == lock.release" should be False
http://bugs.python.org/issue11194  closed by r.david.murray

#11196: add possibility for returning value the way Matlab does it
http://bugs.python.org/issue11196  closed by brian.curtin

#11198: re sub subn backreferrence too few replacements
http://bugs.python.org/issue11198  closed by r.david.murray

#11202: Win32: shutil.move does not inherit permissions
http://bugs.python.org/issue11202  closed by brian.curtin

#11208: example misprint in documentation whatsnew/3.2
http://bugs.python.org/issue11208  closed by rhettinger

#11209: Example for itertools.count is misleading
http://bugs.python.org/issue11209  closed by rhettinger

#11211: gzip.open() fails for gzipped file
http://bugs.python.org/issue11211  closed by haypo

#11213: distutils2 test issue
http://bugs.python.org/issue11213  closed by pitrou

#11220: https sslv3 error 14077417: illegal parameter
http://bugs.python.org/issue11220  closed by pitrou

#11221: all() returns wrong result when the parameters are non-encapsu
http://bugs.python.org/issue11221  closed by georg.brandl

#11237: odbc module crashes Python interpretter
http://bugs.python.org/issue11237  closed by brett.cannon

#1726687: Bug found in datetime for Epoch time = -1
http://bugs.python.org/issue1726687  closed by belopolsky

#1649329: Extract file-finding and language-handling code from gettext.f
http://bugs.python.org/issue1649329  closed by eric.araujo

#11228: raw unicode strings interpret \u and \U (but not \n, \xHH, ...
http://bugs.python.org/issue11228  closed by haypo

#730467: Not detecting AIX_GENUINE_CPLUSPLUS
http://bugs.python.org/issue730467  closed by georg.brandl

From martin at v.loewis.de  Sat Feb 19 00:02:55 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 19 Feb 2011 00:02:55 +0100
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <AANLkTi=hVdRQbnzJOUjnkSsw4ZKTVfDJcwpOR5D3g6Wy@mail.gmail.com>
References: <4D5A3990.4040902@v.loewis.de>
	<AANLkTi=hVdRQbnzJOUjnkSsw4ZKTVfDJcwpOR5D3g6Wy@mail.gmail.com>
Message-ID: <4D5EFA9F.5030900@v.loewis.de>

Am 18.02.2011 14:41, schrieb Dirkjan Ochtman:
> On Tue, Feb 15, 2011 at 09:30, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I'm going to perform a Debian upgrade of svn.python.org on Friday,
>> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
>> that time. The outage shouldn't be longer than an hour.
> 
> It seems hg is no longer installed on dinsdale, does that have
> anything to do with this?

Yes, it must have gotten uninstalled during the upgrade. I have now
reinstalled it. Please let me know if there is anything else missing.

Regards,
Martin

From stefan_ml at behnel.de  Sat Feb 19 13:37:26 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 19 Feb 2011 13:37:26 +0100
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during
	installation
Message-ID: <ijodi6$h4c$1@dough.gmane.org>

Hi,

sorry for asking here instead of filing a bug, but given that 3.2 final is 
pretty close, I wanted to make sure this gets considered.

A Cython user noticed that the installation (setup.py install or bdist) 
puts several .pyc files into the installed source directory, instead of 
moving them into __pycache__. The latter is still used, and most of the 
.pyc files end up there, but not all of them. Some even end up in both 
directories, once with a ".cpython-32.pyc" suffix in __pycache__ and simply 
as ".pyc" next to the sources.

A specialty of the Cython installation is that a tiny part of Cython gets 
imported at the beginning, then setup() is called. Next, 2to3 is run over 
the sources, and during the extension building phase, the initially 
imported part is removed from sys.modules and Cython is imported completely 
from the converted sources and runs to compile parts of itself. Finally, 
the installation continues and copies/byte-compiles the 2to3 converted .py 
files.

What I think is happening here, is that the normal import mechanism byte 
compiles the 2to3 converted sources into the __pycache__ directory (when 
invoked at extension building time), but then distutils' byte compilation 
seems to decide that it's better to keep the .pyc files where the sources 
are. And thus a mix of both ends up in the installation.

Wouldn't it be better to let distutils *always* byte-compile the .py files 
into the appropriate __pycache__ directory, just like the import mechanism 
does? Or is there something else broken here?

Stefan



From martin at v.loewis.de  Sat Feb 19 13:55:56 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Feb 2011 13:55:56 +0100
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__
 during installation
In-Reply-To: <ijodi6$h4c$1@dough.gmane.org>
References: <ijodi6$h4c$1@dough.gmane.org>
Message-ID: <4D5FBDDC.1080607@v.loewis.de>

> sorry for asking here instead of filing a bug, but given that 3.2 final
> is pretty close, I wanted to make sure this gets considered.

If you want it decided before the 3.2 release, it must be a
release-critical bug report in the tracker. Posting it here does not
make sure
it gets considered.

Regards,
Martin

From ncoghlan at gmail.com  Sat Feb 19 14:07:17 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Feb 2011 23:07:17 +1000
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__
 during installation
In-Reply-To: <ijodi6$h4c$1@dough.gmane.org>
References: <ijodi6$h4c$1@dough.gmane.org>
Message-ID: <AANLkTi=t3yEdbe1mo6rN+p3G0CbhmhCYWUpNG3NH8Mx2@mail.gmail.com>

On Sat, Feb 19, 2011 at 10:37 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> What I think is happening here, is that the normal import mechanism byte
> compiles the 2to3 converted sources into the __pycache__ directory (when
> invoked at extension building time), but then distutils' byte compilation
> seems to decide that it's better to keep the .pyc files where the sources
> are. And thus a mix of both ends up in the installation.
>
> Wouldn't it be better to let distutils *always* byte-compile the .py files
> into the appropriate __pycache__ directory, just like the import mechanism
> does? Or is there something else broken here?

A quick look [1] suggests that distutils.util.bytes_compile is indeed
second-guessing py_compile.compile and forcing use of the legacy .pyc
location rather than accepting the default location. (Why? I have no
idea, it's distutils...)

While this is definitely untidy, it doesn't strike me as a release
blocker. More of a "fix it in 3.2.1", since the status quo will
*work*, it just means the precompiled file will be ignored on first
execution with newer Python versions.

Cheers,
Nick.

[1] http://svn.python.org/view/python/branches/py3k/Lib/distutils/util.py?view=markup


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

From solipsis at pitrou.net  Sat Feb 19 14:14:19 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 19 Feb 2011 14:14:19 +0100
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__
 during installation
References: <ijodi6$h4c$1@dough.gmane.org>
	<AANLkTi=t3yEdbe1mo6rN+p3G0CbhmhCYWUpNG3NH8Mx2@mail.gmail.com>
Message-ID: <20110219141419.246af6aa@pitrou.net>

On Sat, 19 Feb 2011 23:07:17 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> While this is definitely untidy, it doesn't strike me as a release
> blocker. More of a "fix it in 3.2.1", since the status quo will
> *work*, it just means the precompiled file will be ignored on first
> execution with newer Python versions.

Are you sure? If the package gets installed in a root-writable-only
directory, later execution cannot create the right pyc files.

This certainly looks like a critical issue (hopefully not release
blocker).



From solipsis at pitrou.net  Sat Feb 19 14:23:52 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 19 Feb 2011 14:23:52 +0100
Subject: [Python-Dev] svn outage on Friday
References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge>
	<AANLkTinjrwj8BM_NjYH+AxXktDH==LQywOBJ5dL64RzY@mail.gmail.com>
	<4D5DAC8C.3030304@v.loewis.de>
	<AANLkTimQVLfYBuCHZGrTcXyZbxXVb7yV+S9cz9Wgtqsn@mail.gmail.com>
Message-ID: <20110219142352.76388f2b@pitrou.net>

On Fri, 18 Feb 2011 08:09:12 +0100
Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> On Fri, Feb 18, 2011 at 00:17, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > I think it's fair to say that the project currently rests, lacking
> > a project lead. The most recent timeline is that conversion should
> > be completed by PyCon, and, failing that, should start at PyCon.
> 
> It's not exactly resting; I've been pushing around the
> cvs2svn-converted tags to get them to behave sensibly, and I've been
> having good discussions with Antoine and Georg about several things we
> need to hash out in IRC. Sorry I haven't been doing more progress
> reports here.
> 
> But yes, it would be nice if we could actually switch by PyCon, but at
> the very least there should be a fresh test repo and consensus on most
> of the workflow issues by PyCon (for those interested who live in
> Europe, I'm going to be at a hg sprint in Karlsruhe during the PyCon
> weekend).

Would be nice if at least a simple repo (e.g. peps) got fully migrated
as soon as possible. 

Thanks

Antoine.



From martin at v.loewis.de  Sat Feb 19 14:27:56 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Feb 2011 14:27:56 +0100
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__
 during installation
In-Reply-To: <20110219141419.246af6aa@pitrou.net>
References: <ijodi6$h4c$1@dough.gmane.org>	<AANLkTi=t3yEdbe1mo6rN+p3G0CbhmhCYWUpNG3NH8Mx2@mail.gmail.com>
	<20110219141419.246af6aa@pitrou.net>
Message-ID: <4D5FC55C.9060100@v.loewis.de>

Am 19.02.2011 14:14, schrieb Antoine Pitrou:
> On Sat, 19 Feb 2011 23:07:17 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> While this is definitely untidy, it doesn't strike me as a release
>> blocker. More of a "fix it in 3.2.1", since the status quo will
>> *work*, it just means the precompiled file will be ignored on first
>> execution with newer Python versions.
> 
> Are you sure? If the package gets installed in a root-writable-only
> directory, later execution cannot create the right pyc files.

It will certainly work. It won't create pyc files, but it will still
work - right?

Regards,
Martin

From ncoghlan at gmail.com  Sat Feb 19 14:29:36 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Feb 2011 23:29:36 +1000
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__
 during installation
In-Reply-To: <20110219141419.246af6aa@pitrou.net>
References: <ijodi6$h4c$1@dough.gmane.org>
	<AANLkTi=t3yEdbe1mo6rN+p3G0CbhmhCYWUpNG3NH8Mx2@mail.gmail.com>
	<20110219141419.246af6aa@pitrou.net>
Message-ID: <AANLkTi=7qL82rKR_c1W24Vip7RuXD95vnYb0H482SOPz@mail.gmail.com>

On Sat, Feb 19, 2011 at 11:14 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 19 Feb 2011 23:07:17 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> While this is definitely untidy, it doesn't strike me as a release
>> blocker. More of a "fix it in 3.2.1", since the status quo will
>> *work*, it just means the precompiled file will be ignored on first
>> execution with newer Python versions.
>
> Are you sure? If the package gets installed in a root-writable-only
> directory, later execution cannot create the right pyc files.

Worst case, it will run from the source file. It may even use the
legacy .pyc file in the case where it can't write to __pycache__ (I
don't remember how that particular subtlety of PEP 3147 played out).
Certainly not ideal from a performance point of view, but also not
difficult to workaround once discovered.

> This certainly looks like a critical issue (hopefully not release
> blocker).

As a performance problem that only arises in some situations when
using distutils to do bulk compilation, and with running "compileall"
as root available as a relatively straightforward workaround, I
personally think it can wait until 3.2.1.

So I'd agree with the critical-but-not-a-release-blocker assessment,
but it's ultimately Georg's call.

Cheers,
Nick.

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

From solipsis at pitrou.net  Sat Feb 19 14:29:42 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 19 Feb 2011 14:29:42 +0100
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__
 during installation
In-Reply-To: <4D5FC55C.9060100@v.loewis.de>
References: <ijodi6$h4c$1@dough.gmane.org>
	<AANLkTi=t3yEdbe1mo6rN+p3G0CbhmhCYWUpNG3NH8Mx2@mail.gmail.com>
	<20110219141419.246af6aa@pitrou.net>  <4D5FC55C.9060100@v.loewis.de>
Message-ID: <1298122182.3793.1.camel@localhost.localdomain>

Le samedi 19 f?vrier 2011 ? 14:27 +0100, "Martin v. L?wis" a ?crit :
> Am 19.02.2011 14:14, schrieb Antoine Pitrou:
> > On Sat, 19 Feb 2011 23:07:17 +1000
> > Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>
> >> While this is definitely untidy, it doesn't strike me as a release
> >> blocker. More of a "fix it in 3.2.1", since the status quo will
> >> *work*, it just means the precompiled file will be ignored on first
> >> execution with newer Python versions.
> > 
> > Are you sure? If the package gets installed in a root-writable-only
> > directory, later execution cannot create the right pyc files.
> 
> It will certainly work. It won't create pyc files, but it will still
> work - right?

Right, but that's a big performance regression if it doesn't use cached
bytecode file.

Regards

Antoine.



From songofacandy at gmail.com  Sat Feb 19 17:19:51 2011
From: songofacandy at gmail.com (INADA Naoki)
Date: Sun, 20 Feb 2011 01:19:51 +0900
Subject: [Python-Dev] What's L2R status?
Message-ID: <AANLkTim-kciMhTypjG-anjuUW68=O2Vh7cjWE9gQ=94u@mail.gmail.com>

Ref: http://bugs.python.org/issue448679

Has this bug fixed already?
This bug seems not be fixed for Python 2.6 and Python 3.2rc3.

Python 3.2rc3 (r32rc3:88413, Feb 15 2011, 18:31:14)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> C=0
>>> def x():
...     global C
...     C += 1
...     return C
...
>>> {x(): x(), x(): x()}
{2: 1, 4: 3}


-- 
INADA Naoki? <songofacandy at gmail.com>

From songofacandy at gmail.com  Sat Feb 19 17:35:53 2011
From: songofacandy at gmail.com (INADA Naoki)
Date: Sun, 20 Feb 2011 01:35:53 +0900
Subject: [Python-Dev] What's L2R status?
In-Reply-To: <AANLkTim-kciMhTypjG-anjuUW68=O2Vh7cjWE9gQ=94u@mail.gmail.com>
References: <AANLkTim-kciMhTypjG-anjuUW68=O2Vh7cjWE9gQ=94u@mail.gmail.com>
Message-ID: <AANLkTin_RVQUTdEn9BVt5f8F3P7CYuQCK94w2ebioX-V@mail.gmail.com>

Sorry. There is a issue already.
http://bugs.python.org/issue11205

On Sun, Feb 20, 2011 at 1:19 AM, INADA Naoki <songofacandy at gmail.com> wrote:
> Ref: http://bugs.python.org/issue448679
>
> Has this bug fixed already?
> This bug seems not be fixed for Python 2.6 and Python 3.2rc3.
>
> Python 3.2rc3 (r32rc3:88413, Feb 15 2011, 18:31:14)
> [GCC 4.4.5] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> C=0
>>>> def x():
> ... ? ? global C
> ... ? ? C += 1
> ... ? ? return C
> ...
>>>> {x(): x(), x(): x()}
> {2: 1, 4: 3}
>
>
> --
> INADA Naoki? <songofacandy at gmail.com>
>



-- 
INADA Naoki? <songofacandy at gmail.com>

From skip at pobox.com  Sat Feb 19 19:08:38 2011
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 19 Feb 2011 12:08:38 -0600
Subject: [Python-Dev] What's L2R status?
In-Reply-To: <AANLkTin_RVQUTdEn9BVt5f8F3P7CYuQCK94w2ebioX-V@mail.gmail.com>
References: <AANLkTim-kciMhTypjG-anjuUW68=O2Vh7cjWE9gQ=94u@mail.gmail.com>
	<AANLkTin_RVQUTdEn9BVt5f8F3P7CYuQCK94w2ebioX-V@mail.gmail.com>
Message-ID: <19808.1830.651449.644661@montanaro.dyndns.org>


    INADA> Sorry. There is a issue already.
    INADA> http://bugs.python.org/issue11205

>From Raymond's last comment on the above ticket:

> How much to change and how far to backport may make for a good python-dev
> discussion.

I think the simple patch I posted for 2.7 is probably all that should be
done for the 2.x series.  Briefly, change the visit order to evaluate the
key before the value, then use ROT_TWO to reorder the top of the stack for
STORE_MAP.

> I don't have any feelings about it one way or the other, but it would
> great to see Py3.2.1 get fixed properly.

I don't know if bumping the bytecode version is okay after 3.2 is released,
or if that's something which could only happen with 3.3.  Whatever is deemed
proper by the release managers, the better change would be to bump the
version number, remove the ROT_TWO from my basic patch and change the order
of arguments expected by STORE_MAP.

Skip

From g.brandl at gmx.net  Sat Feb 19 21:53:31 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 19 Feb 2011 21:53:31 +0100
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__
	during installation
In-Reply-To: <AANLkTi=7qL82rKR_c1W24Vip7RuXD95vnYb0H482SOPz@mail.gmail.com>
References: <ijodi6$h4c$1@dough.gmane.org>	<AANLkTi=t3yEdbe1mo6rN+p3G0CbhmhCYWUpNG3NH8Mx2@mail.gmail.com>	<20110219141419.246af6aa@pitrou.net>
	<AANLkTi=7qL82rKR_c1W24Vip7RuXD95vnYb0H482SOPz@mail.gmail.com>
Message-ID: <ijpam7$ubh$1@dough.gmane.org>

Am 19.02.2011 14:29, schrieb Nick Coghlan:
> On Sat, Feb 19, 2011 at 11:14 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Sat, 19 Feb 2011 23:07:17 +1000
>> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>
>>> While this is definitely untidy, it doesn't strike me as a release
>>> blocker. More of a "fix it in 3.2.1", since the status quo will
>>> *work*, it just means the precompiled file will be ignored on first
>>> execution with newer Python versions.
>>
>> Are you sure? If the package gets installed in a root-writable-only
>> directory, later execution cannot create the right pyc files.
> 
> Worst case, it will run from the source file. It may even use the
> legacy .pyc file in the case where it can't write to __pycache__ (I
> don't remember how that particular subtlety of PEP 3147 played out).
> Certainly not ideal from a performance point of view, but also not
> difficult to workaround once discovered.
> 
>> This certainly looks like a critical issue (hopefully not release
>> blocker).
> 
> As a performance problem that only arises in some situations when
> using distutils to do bulk compilation, and with running "compileall"
> as root available as a relatively straightforward workaround, I
> personally think it can wait until 3.2.1.
> 
> So I'd agree with the critical-but-not-a-release-blocker assessment,
> but it's ultimately Georg's call.

Given that we are only hours from the final, I'm quite unwilling to
call this a blocker, seeing that running from the .py file works well
(and I'm not really of Antoine's opinion that that is such a big
performance hit).

BTW, I haven't seen an issue yet.

Georg


From ncoghlan at gmail.com  Sun Feb 20 01:41:56 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Feb 2011 10:41:56 +1000
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__
 during installation
In-Reply-To: <ijpam7$ubh$1@dough.gmane.org>
References: <ijodi6$h4c$1@dough.gmane.org>
	<AANLkTi=t3yEdbe1mo6rN+p3G0CbhmhCYWUpNG3NH8Mx2@mail.gmail.com>
	<20110219141419.246af6aa@pitrou.net>
	<AANLkTi=7qL82rKR_c1W24Vip7RuXD95vnYb0H482SOPz@mail.gmail.com>
	<ijpam7$ubh$1@dough.gmane.org>
Message-ID: <AANLkTi=anDPuNsoDCnLeTCURKKv4H1TTRXBnufp4ANWz@mail.gmail.com>

On Sun, Feb 20, 2011 at 6:53 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> Given that we are only hours from the final, I'm quite unwilling to
> call this a blocker, seeing that running from the .py file works well
> (and I'm not really of Antoine's opinion that that is such a big
> performance hit).

How significant the performance hit is depends on at least a few
different factors:

1. How many files are affected
2. How many files are implicitly imported when the application starts
3. How big/complicated those files
4. How long the actual "do work" part of the application takes

I expect something like "hg diff" on a small working copy would be
severely impacted if the application files for hg itself weren't
cached properly.

Cheers,
Nick.

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

From hoytak at stat.washington.edu  Sun Feb 20 06:43:14 2011
From: hoytak at stat.washington.edu (Hoyt Koepke)
Date: Sat, 19 Feb 2011 21:43:14 -0800
Subject: [Python-Dev] Bug in linking to gomp with python;
	causes crash in matplotlib.
Message-ID: <AANLkTinw-3RKaoHt4tRoueXkmf5oeXx1whUdHHo-XCmy@mail.gmail.com>

Hello,

I've encountered a strange bug that appears to be either in gcc's gomp
implementation or in how python loads extension modules linked against
gomp.  Here's the error:

Using gcc (multiple versions) on linux, I compile an empty c extension
module and pass -lgomp as a linker arg.  If I import it, running a
simple script in matplotlib causes a segfault.  Not passing -lgomp or
not loading the empty module makes the code works fine.  More
specifically, if I compile:

#include "Python.h"
static struct PyMethodDef methods[] = {
  {0, 0, 0, 0}
};
PyMODINIT_FUNC initempty(void) {
  Py_InitModule4("empty", methods, 0, 0, PYTHON_API_VERSION);
}

using ``ext_modules = [Extension("empty", ["empty.c"], extra_link_args
= ["-lgomp"])]``, then


import empty
import matplotlib.pylab as plt

plt.figure()
plt.plot([0,1], [0,1], '-b')
plt.show()


causes the program to segfault (removing ``import empty`` makes it
fine).  Looking at a traceback:

#0  0x00f78bc7 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
#1  0x008f51f2 in py_to_agg_transformation_matrix (obj=0x8223f58,
errors=false) at src/agg_py_transforms.cpp:20
#2  0x008fdd73 in _path_module::update_path_extents (this=0x8e45f90,
args=...) at src/path.cpp:378
#3  0x009048bd in
Py::ExtensionModule<_path_module>::invoke_method_varargs (this=<value
optimized out>, method_def=0x8e9ae30, args=...) at
./CXX/Python2/ExtensionModule.hxx:184
#4  0x008f0d96 in method_varargs_call_handler
(_self_and_name_tuple=0x8e6eeac, _args=0x94e683c) at
CXX/Python2/cxx_extensions.cxx:1714
#5  0x080dc0d0 in PyEval_EvalFrameEx ()
#6  0x080dddf2 in PyEval_EvalCodeEx ()

While occurring in some of matplotlib's extension code (and I haven't
found another library that crashes it), the fact that the deciding
factor is whether I link against gomp indicates the it's probably
upstream somewhere.

I encountered this error a year ago and asked about it on the
matplotlib mailing list, but found a quick workaround then, and with
deadline pressure I forgot about it.  However, it's come up again, and
then I was asked to bump it to python-dev, which is why I'm posting it
here.

I can reproduce it on the following systems.  In all cases, matplotlib
is compiled from source on the development branch (r8969) and uses
QT4Agg as the backend, as is numpy, scipy, etc.  If needed, I can
track down more versions.

gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.4, 64bit, Python 2.6.6, ubuntu 10.10
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64bit, Python 2.6.5, ubuntu 10.04
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1, 32bit, Python 2.6.4, ubuntu 9.10

gcc 4.5.2 (source build), Python 2.6.5, ubuntu 10.04.  On this build,
the given source example does not produce the result, and I haven't
been able to tweak it so it does.  However, linking to a much larger
extension library that uses many different parts of openmp causes
exactly the same crash.  If I recompile that library without openmp
support, then everything works fine; with openmp support it corrupts
something and matplotlib crashes in exactly the same way.

gcc 4.3.2, Python 2.6.2, ubuntu 9.04 (I don't have access to this
system any more, since it got upgraded, but it had the same problem a
year ago).

I'd be happy to provide any more information if needed.  I attached
example code that reproduces it.  Let me know if I should file a bug
report (and where to file it -- which is why I haven't yet).

Thanks,

--Hoyt

++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ hoytak at gmail.com
++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-gomp-bug.tar.gz
Type: application/x-gzip
Size: 672 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110219/7a276300/attachment.bin>

From ncoghlan at gmail.com  Sun Feb 20 07:28:03 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Feb 2011 16:28:03 +1000
Subject: [Python-Dev] Bug in linking to gomp with python;
	causes crash in matplotlib.
In-Reply-To: <AANLkTinw-3RKaoHt4tRoueXkmf5oeXx1whUdHHo-XCmy@mail.gmail.com>
References: <AANLkTinw-3RKaoHt4tRoueXkmf5oeXx1whUdHHo-XCmy@mail.gmail.com>
Message-ID: <AANLkTi=JpZRXz__41d1GPyg5sDdc7nZarU=1aJOvbPWF@mail.gmail.com>

On Sun, Feb 20, 2011 at 3:43 PM, Hoyt Koepke <hoytak at stat.washington.edu> wrote:
> I'd be happy to provide any more information if needed. ?I attached
> example code that reproduces it. ?Let me know if I should file a bug
> report (and where to file it -- which is why I haven't yet).

An associated bug report would be appreciated (mailing list
discussions are useful for raising awareness, but are more likely to
be forgotten over time than bug reports): http://bugs.python.org

Cheers,
Nick.

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

From techtonik at gmail.com  Sun Feb 20 07:39:12 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 20 Feb 2011 08:39:12 +0200
Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on
	Windows
In-Reply-To: <4D505323.5020909@stoneleaf.us>
References: <AANLkTikifW_+tVYPVX49EAGHgT+tPwPEKzjY0_5h6gTx@mail.gmail.com>
	<AANLkTik35dsnN_uE-3GhKz9_P8ouQ3eqD9rv1A11hStO@mail.gmail.com>
	<4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk>
	<AANLkTi=LbpUEYSmedeSEQvfn_W0FbKnXkoQN=c325FS+@mail.gmail.com>
	<AANLkTikWxpOTvRBKS=LRm9b0rLdsp-E6wD-z9h=i+=2r@mail.gmail.com>
	<4D4EBCC4.1090003@simplistix.co.uk>
	<AANLkTinhzYMo7PJJv8ZwPtc_BDbMELvKgKdPy6QSNm8d@mail.gmail.com>
	<4D4EBDC7.9000301@simplistix.co.uk> <4D505323.5020909@stoneleaf.us>
Message-ID: <AANLkTinh2Y2TpUHCpjpHd1cJcOzGYf0uwJzrM=Gsrd5P@mail.gmail.com>

I've got a feeling that policy is evil and can not be applied cleanly
when change falls out of scope of Python core .c sources and .py files
from standard library.

Right now the proposal is to add Python to %PATH% to make Python more
user friendly for newbies. I can't see what can become worse than it
is now. People are discussing advanced scenarios with multiple Python
installations, but I propose first to make Python a normal command
line user-friendly system application for Windows, and then discuss
more advanced usage scenarios to make it developer-friendly in
subsequent versions. Time is passing by and nothing happens.

-- 
anatoly t.

From techtonik at gmail.com  Sun Feb 20 07:43:06 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 20 Feb 2011 08:43:06 +0200
Subject: [Python-Dev] w9xpopen.exe is still in 3.2
Message-ID: <AANLkTimjihGtQ2xF8poaWWWnhA_QxxNJL41cTE8COMz6@mail.gmail.com>

Python definitely needs a development Roadmap to avoid things like
w9xpopen.exe slipping off radar from release to release. We don't
support Windows 9x since Python 2.6. What this file does in 3.x
distributions?

http://bugs.python.org/issue2405
-- 
anatoly t.

From martin at v.loewis.de  Sun Feb 20 10:10:08 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 20 Feb 2011 10:10:08 +0100
Subject: [Python-Dev] w9xpopen.exe is still in 3.2
In-Reply-To: <AANLkTimjihGtQ2xF8poaWWWnhA_QxxNJL41cTE8COMz6@mail.gmail.com>
References: <AANLkTimjihGtQ2xF8poaWWWnhA_QxxNJL41cTE8COMz6@mail.gmail.com>
Message-ID: <4D60DA70.1010509@v.loewis.de>

Am 20.02.2011 07:43, schrieb anatoly techtonik:
> Python definitely needs a development Roadmap to avoid things like
> w9xpopen.exe slipping off radar from release to release. We don't
> support Windows 9x since Python 2.6. What this file does in 3.x
> distributions?
> 
> http://bugs.python.org/issue2405

Read the report carefully. It can't be removed to support installations
that have changed COMSPEC.

Regards,
Martin

From stefan_ml at behnel.de  Sun Feb 20 10:55:42 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Feb 2011 10:55:42 +0100
Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__
	during installation
In-Reply-To: <ijpam7$ubh$1@dough.gmane.org>
References: <ijodi6$h4c$1@dough.gmane.org>	<AANLkTi=t3yEdbe1mo6rN+p3G0CbhmhCYWUpNG3NH8Mx2@mail.gmail.com>	<20110219141419.246af6aa@pitrou.net>	<AANLkTi=7qL82rKR_c1W24Vip7RuXD95vnYb0H482SOPz@mail.gmail.com>
	<ijpam7$ubh$1@dough.gmane.org>
Message-ID: <ijqoeu$g73$1@dough.gmane.org>

Georg Brandl, 19.02.2011 21:53:
> BTW, I haven't seen an issue yet.

http://bugs.python.org/issue11254

Stefan


From techtonik at gmail.com  Sun Feb 20 22:22:55 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 20 Feb 2011 23:22:55 +0200
Subject: [Python-Dev] w9xpopen.exe is still in 3.2
In-Reply-To: <4D60DA70.1010509@v.loewis.de>
References: <AANLkTimjihGtQ2xF8poaWWWnhA_QxxNJL41cTE8COMz6@mail.gmail.com>
	<4D60DA70.1010509@v.loewis.de>
Message-ID: <AANLkTi=cxcatMB4A_KYUzq2CTjsNpr37p00pf77kfJye@mail.gmail.com>

On Sun, Feb 20, 2011 at 11:10 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 20.02.2011 07:43, schrieb anatoly techtonik:
>> Python definitely needs a development Roadmap to avoid things like
>> w9xpopen.exe slipping off radar from release to release. We don't
>> support Windows 9x since Python 2.6. What this file does in 3.x
>> distributions?
>>
>> http://bugs.python.org/issue2405
>
> Read the report carefully. It can't be removed to support installations
> that have changed COMSPEC.

What is the percentage of these installations?
Is it possible to support them using by 3rd-party package/distribution?
--
anatoly t.

From georg at python.org  Sun Feb 20 23:22:47 2011
From: georg at python.org (Georg Brandl)
Date: Sun, 20 Feb 2011 23:22:47 +0100
Subject: [Python-Dev] [RELEASED] Python 3.2
Message-ID: <4D619437.7050507@python.org>

On behalf of the Python development team, I'm delighted to announce
Python 3.2 final release.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
  hostname matching
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
  for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations

For a more extensive list of changes in 3.2, see

    http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

    http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

    http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)

From techtonik at gmail.com  Sun Feb 20 23:24:41 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 21 Feb 2011 00:24:41 +0200
Subject: [Python-Dev] Gsoc 2011 ideas
In-Reply-To: <AANLkTikp9C4LN4u4vuwmw3wMs5_Zz+d_PcxMtuEKLpWh@mail.gmail.com>
References: <AANLkTikp9C4LN4u4vuwmw3wMs5_Zz+d_PcxMtuEKLpWh@mail.gmail.com>
Message-ID: <AANLkTikfFOy0q5g=rf=SSBtZ7v8c4yq6_aSTmAOj5xFb@mail.gmail.com>

I've compiled a list of issues with python.org services that are not
strictly related to core development, but still may be beneficial for
Python community as a GSoC project at
http://code.google.com/p/pydotorg/issues/list Feel free to add your
own proposals/ideas.
-- 
anatoly t.



On Sat, Feb 12, 2011 at 2:44 PM, yeswanth swami <swamiyeswanth at gmail.com> wrote:
> Hi everyone,
> I am planning to apply for Gsoc 2011 for the PSF . I would like to know if
> any of you have any ideas which can be implemented this summer. I guess the
> gsoc 2011 ideas page has not been put up as yet. So I thought maybe any of
> you can suggest some ideas .
> Thanks
> Yeswanth
> _______________________________________________
> 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 brian.curtin at gmail.com  Mon Feb 21 00:11:54 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Sun, 20 Feb 2011 17:11:54 -0600
Subject: [Python-Dev] w9xpopen.exe is still in 3.2
In-Reply-To: <AANLkTi=cxcatMB4A_KYUzq2CTjsNpr37p00pf77kfJye@mail.gmail.com>
References: <AANLkTimjihGtQ2xF8poaWWWnhA_QxxNJL41cTE8COMz6@mail.gmail.com>
	<4D60DA70.1010509@v.loewis.de>
	<AANLkTi=cxcatMB4A_KYUzq2CTjsNpr37p00pf77kfJye@mail.gmail.com>
Message-ID: <AANLkTimwVoZi8OJYUQAcYppt6iEMeo+PEM0zwFfoAQj7@mail.gmail.com>

On Sun, Feb 20, 2011 at 15:22, anatoly techtonik <techtonik at gmail.com>wrote:

> On Sun, Feb 20, 2011 at 11:10 AM, "Martin v. L?wis" <martin at v.loewis.de>
> wrote:
> > Am 20.02.2011 07:43, schrieb anatoly techtonik:
> >> Python definitely needs a development Roadmap to avoid things like
> >> w9xpopen.exe slipping off radar from release to release. We don't
> >> support Windows 9x since Python 2.6. What this file does in 3.x
> >> distributions?
> >>
> >> http://bugs.python.org/issue2405
> >
> > Read the report carefully. It can't be removed to support installations
> > that have changed COMSPEC.
>
> What is the percentage of these installations?
> Is it possible to support them using by 3rd-party package/distribution?


I'm not sure the percentage matters. Someone somewhere may need it now or in
the future, and keeping it requires zero effort.

Removing it and creating an external distribution requires extra work from
someone on python-dev and also on the user's part, which is a losing
situation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110220/c7269901/attachment.html>

From victor.stinner at haypocalc.com  Mon Feb 21 00:39:12 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Mon, 21 Feb 2011 00:39:12 +0100
Subject: [Python-Dev] [RELEASED] Python 3.2
In-Reply-To: <4D619437.7050507@python.org>
References: <4D619437.7050507@python.org>
Message-ID: <1298245152.5269.24.camel@marge>

Le dimanche 20 f?vrier 2011 ? 23:22 +0100, Georg Brandl a ?crit :
> On behalf of the Python development team, I'm delighted to announce
> Python 3.2 final release.
> 
> Python 3.2 is a continuation of the efforts to improve and stabilize the
> Python 3.x line.

Congratulation to all Python developers for this wonderful release! And
a special kudo to our release manager, Georg.

I hope that Python 3 is now stable enough to support migration of major
projects like Django, Twisted or Zope. Other important projets like
Distribute, Jinja2, PyQt, PyGObject, pygame, NumPy+SciPy and Sphinx are
already compatible with Python 3.

Victor


From foom at fuhm.net  Mon Feb 21 02:42:07 2011
From: foom at fuhm.net (James Y Knight)
Date: Sun, 20 Feb 2011 20:42:07 -0500
Subject: [Python-Dev] w9xpopen.exe is still in 3.2
In-Reply-To: <4D60DA70.1010509@v.loewis.de>
References: <AANLkTimjihGtQ2xF8poaWWWnhA_QxxNJL41cTE8COMz6@mail.gmail.com>
	<4D60DA70.1010509@v.loewis.de>
Message-ID: <24DB6936-C0FB-40B9-B9D1-373B0E4C853F@fuhm.net>


On Feb 20, 2011, at 4:10 AM, Martin v. L?wis wrote:

> Am 20.02.2011 07:43, schrieb anatoly techtonik:
>> Python definitely needs a development Roadmap to avoid things like
>> w9xpopen.exe slipping off radar from release to release. We don't
>> support Windows 9x since Python 2.6. What this file does in 3.x
>> distributions?
>> 
>> http://bugs.python.org/issue2405
> 
> Read the report carefully. It can't be removed to support installations
> that have changed COMSPEC.

Does a modern windows installation actually even *work* if you change COMSPEC to command.com instead of cmd.exe? And why would anyone ever do that? Hey, I have a good idea: python can just ignore COMSPEC and always run cmd.exe. Then you can delete w9xpopen, hooray.

James

From martin at v.loewis.de  Mon Feb 21 07:35:28 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 21 Feb 2011 07:35:28 +0100
Subject: [Python-Dev] w9xpopen.exe is still in 3.2
In-Reply-To: <24DB6936-C0FB-40B9-B9D1-373B0E4C853F@fuhm.net>
References: <AANLkTimjihGtQ2xF8poaWWWnhA_QxxNJL41cTE8COMz6@mail.gmail.com>
	<4D60DA70.1010509@v.loewis.de>
	<24DB6936-C0FB-40B9-B9D1-373B0E4C853F@fuhm.net>
Message-ID: <4D6207B0.3060804@v.loewis.de>

> Does a modern windows installation actually even *work* if you change
> COMSPEC to command.com instead of cmd.exe? And why would anyone ever
> do that? Hey, I have a good idea: python can just ignore COMSPEC and
> always run cmd.exe. Then you can delete w9xpopen, hooray.

We have a process for that: in version 3.x, we deprecate the feature,
and in version 3.x+1, we drop support for it. Since deprecation missed
Python 3.2, we can only deprecate in 3.3, and drop in 3.4.

As for "always run cmd.exe": we can't, as it's not us who runs
cmd.exe, but the CRT (in the popen library function).

Regards,
Martin

From ziade.tarek at gmail.com  Mon Feb 21 08:41:51 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 21 Feb 2011 08:41:51 +0100
Subject: [Python-Dev] Distutils2 next steps
Message-ID: <AANLkTi=z_032c9EJq3Xz6grwot6Nub8PqHHh7Dr09ObY@mail.gmail.com>

Hello

Now that Python 3.2 is out, I am planning to do the following with Distutils2:

1 - release a new alpha before Pycon for community feedback
2 - add distutils2 back in the trunk, along with the changes in
pkgutil and sysconfig
3 - continue the ongoing work in Distutils2 to prepare the first
Python 3.3 release

If you want me to give more details here on what is going to be done
precisely in the various stdlib parts, let me know.

I plan to do 2. as a sprint task, and will be looking for help from
other core devs, for reviews, advices etc. So if anyone is interested
and present at Pycon, please add your name at
http://us.pycon.org/2011/sprints/projects under the "Disttuils2"
project.

Thanks !

Cheers
Tarek
-- 
Tarek Ziad? | http://ziade.org

From g.brandl at gmx.net  Mon Feb 21 08:48:54 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 21 Feb 2011 08:48:54 +0100
Subject: [Python-Dev] Distutils2 next steps
In-Reply-To: <AANLkTi=z_032c9EJq3Xz6grwot6Nub8PqHHh7Dr09ObY@mail.gmail.com>
References: <AANLkTi=z_032c9EJq3Xz6grwot6Nub8PqHHh7Dr09ObY@mail.gmail.com>
Message-ID: <ijt5et$qtf$1@dough.gmane.org>

On 21.02.2011 08:41, Tarek Ziad? wrote:
> Hello
> 
> Now that Python 3.2 is out, I am planning to do the following with Distutils2:
> 
> 1 - release a new alpha before Pycon for community feedback
> 2 - add distutils2 back in the trunk, along with the changes in
> pkgutil and sysconfig
> 3 - continue the ongoing work in Distutils2 to prepare the first
> Python 3.3 release
> 
> If you want me to give more details here on what is going to be done
> precisely in the various stdlib parts, let me know.

I think I'm also speaking for the prospective release manager of 3.3
by saying yes, please, details would be nice, but not necessarily
*right* now. :)

Georg



From ziade.tarek at gmail.com  Mon Feb 21 09:02:51 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 21 Feb 2011 09:02:51 +0100
Subject: [Python-Dev] Distutils2 next steps
In-Reply-To: <ijt5et$qtf$1@dough.gmane.org>
References: <AANLkTi=z_032c9EJq3Xz6grwot6Nub8PqHHh7Dr09ObY@mail.gmail.com>
	<ijt5et$qtf$1@dough.gmane.org>
Message-ID: <AANLkTim_LJ=MejY29ew_G1wRxu1psyWf415uTpp15mTn@mail.gmail.com>

On Mon, Feb 21, 2011 at 8:48 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> On 21.02.2011 08:41, Tarek Ziad? wrote:
>> Hello
>>
>> Now that Python 3.2 is out, I am planning to do the following with Distutils2:
>>
>> 1 - release a new alpha before Pycon for community feedback
>> 2 - add distutils2 back in the trunk, along with the changes in
>> pkgutil and sysconfig
>> 3 - continue the ongoing work in Distutils2 to prepare the first
>> Python 3.3 release
>>
>> If you want me to give more details here on what is going to be done
>> precisely in the various stdlib parts, let me know.
>
> I think I'm also speaking for the prospective release manager of 3.3
> by saying yes, please, details would be nice, but not necessarily
> *right* now. :)

It's easy enough to give right now:

- pkgutil will gain all the API that are implementing PEP 376 -- a py2
version of this module that has them can be seen at
http://hg.python.org/distutils2/file/tip/distutils2/_backport/pkgutil.py
 for the moment

- sysconfig will need to have two things:

  - create via the Makefile a "_sysconfig" module, so the API stop to
read data dynamically in pyconfig.h and Makefile at runtime
  - [to be validated-discussed] an easier way to configure the
installation paths. the current plan is to use a sysconfig.cfg file
that may be changed. This file will be global to Python, but also
possibly local to a user or a project --
http://hg.python.org/distutils2/file/tip/distutils2/_backport/sysconfig.cfg

- distutils2 will be converted to Py3 using 2to3, then included in
Lib/ -- the code base is ready for this, besides a few spots.

- distutils2 will continue to be released as a standalone project from
2.4 to 3.2. Probably by using 3to2, but I have not tried the tool yet.


Cheers
Tarek

>
> 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/ziade.tarek%40gmail.com
>



-- 
Tarek Ziad? | http://ziade.org

From ncoghlan at gmail.com  Mon Feb 21 13:52:19 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 Feb 2011 22:52:19 +1000
Subject: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135
Message-ID: <AANLkTimCF_p3F7QnG-_zaeSj9Uc_J05wu86kLBcLP=6k@mail.gmail.com>

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
 SA  391  Dictionary-Based Configuration For Logging              Sajip
 SA 3108  Standard Library Reorganization                         Cannon
 SA 3121  Extension Module Initialization and Finalization        von L?wis
 SA 3135  New Super
Spealman, Delaney, Ryan

(I deliberately left 3118 off the list, since there are some
discrepancies between the PEP and the implementation that need to be
clarified for 3.3 and the 3 distutils related PEPs won't be done until
Tarek merges distutils2 back into the main line of development)

It would be good to clear the decks before new PEPs start to be
accepted for inclusion in 3.3.

Cheers,
Nick.

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

From guido at python.org  Mon Feb 21 18:20:48 2011
From: guido at python.org (Guido van Rossum)
Date: Mon, 21 Feb 2011 09:20:48 -0800
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: <AANLkTikekEcFJu2q0VzAmfYDQoNNTnWaAM7EwZEyuOGm@mail.gmail.com>

On Mon, Feb 21, 2011 at 4:52 AM, 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
> ?SA ?391 ?Dictionary-Based Configuration For Logging ? ? ? ? ? ? ?Sajip
> ?SA 3108 ?Standard Library Reorganization ? ? ? ? ? ? ? ? ? ? ? ? Cannon
> ?SA 3121 ?Extension Module Initialization and Finalization ? ? ? ?von L?wis
> ?SA 3135 ?New Super
> Spealman, Delaney, Ryan

Somebody (not me, not necessarily the same person for each PEP) needs
to check each of these PEPs for how well they match the implemented
reality and report back here. (Unless you already did this and are
basically giving them a certificate of correctness with your post?)

> (I deliberately left 3118 off the list, since there are some
> discrepancies between the PEP and the implementation that need to be
> clarified for 3.3 and the 3 distutils related PEPs won't be done until
> Tarek merges distutils2 back into the main line of development)
>
> It would be good to clear the decks before new PEPs start to be
> accepted for inclusion in 3.3.

Why?

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

From hoytak at stat.washington.edu  Mon Feb 21 18:55:46 2011
From: hoytak at stat.washington.edu (Hoyt Koepke)
Date: Mon, 21 Feb 2011 09:55:46 -0800
Subject: [Python-Dev] Bug in linking to gomp with python;
	causes crash in matplotlib.
In-Reply-To: <AANLkTi=JpZRXz__41d1GPyg5sDdc7nZarU=1aJOvbPWF@mail.gmail.com>
References: <AANLkTinw-3RKaoHt4tRoueXkmf5oeXx1whUdHHo-XCmy@mail.gmail.com>
	<AANLkTi=JpZRXz__41d1GPyg5sDdc7nZarU=1aJOvbPWF@mail.gmail.com>
Message-ID: <AANLkTimsaMXpw_y9TGs5TYPs0K8PJwjBFjrwt1C-RWKG@mail.gmail.com>

> An associated bug report would be appreciated (mailing list
> discussions are useful for raising awareness, but are more likely to
> be forgotten over time than bug reports): http://bugs.python.org

Just did that; thanks!

-- Hoyt

++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ hoytak at gmail.com
++++++++++++++++++++++++++++++++++++++++++

From brett at python.org  Mon Feb 21 19:22:39 2011
From: brett at python.org (Brett Cannon)
Date: Mon, 21 Feb 2011 10:22:39 -0800
Subject: [Python-Dev] Distutils2 next steps
In-Reply-To: <AANLkTim_LJ=MejY29ew_G1wRxu1psyWf415uTpp15mTn@mail.gmail.com>
References: <AANLkTi=z_032c9EJq3Xz6grwot6Nub8PqHHh7Dr09ObY@mail.gmail.com>
	<ijt5et$qtf$1@dough.gmane.org>
	<AANLkTim_LJ=MejY29ew_G1wRxu1psyWf415uTpp15mTn@mail.gmail.com>
Message-ID: <AANLkTinAcF1Dv1GxHzp4B9hEUUjxF31q2EybX7N9h9_G@mail.gmail.com>

On Mon, Feb 21, 2011 at 00:02, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Mon, Feb 21, 2011 at 8:48 AM, Georg Brandl <g.brandl at gmx.net> wrote:
>> On 21.02.2011 08:41, Tarek Ziad? wrote:
>>> Hello
>>>
>>> Now that Python 3.2 is out, I am planning to do the following with Distutils2:
>>>
>>> 1 - release a new alpha before Pycon for community feedback
>>> 2 - add distutils2 back in the trunk, along with the changes in
>>> pkgutil and sysconfig
>>> 3 - continue the ongoing work in Distutils2 to prepare the first
>>> Python 3.3 release
>>>
>>> If you want me to give more details here on what is going to be done
>>> precisely in the various stdlib parts, let me know.
>>
>> I think I'm also speaking for the prospective release manager of 3.3
>> by saying yes, please, details would be nice, but not necessarily
>> *right* now. :)
>
> It's easy enough to give right now:
>
> - pkgutil will gain all the API that are implementing PEP 376 -- a py2
> version of this module that has them can be seen at
> http://hg.python.org/distutils2/file/tip/distutils2/_backport/pkgutil.py
> ?for the moment
>
> - sysconfig will need to have two things:
>
> ?- create via the Makefile a "_sysconfig" module, so the API stop to
> read data dynamically in pyconfig.h and Makefile at runtime
> ?- [to be validated-discussed] an easier way to configure the
> installation paths. the current plan is to use a sysconfig.cfg file
> that may be changed. This file will be global to Python, but also
> possibly local to a user or a project --
> http://hg.python.org/distutils2/file/tip/distutils2/_backport/sysconfig.cfg
>
> - distutils2 will be converted to Py3 using 2to3, then included in
> Lib/ -- the code base is ready for this, besides a few spots.
>
> - distutils2 will continue to be released as a standalone project from
> 2.4 to 3.2. Probably by using 3to2, but I have not tried the tool yet.

So does this mean that primary development will move to py3k and then
you will simply push changes downstream to the distutils2 project for
separate releases? Or are you going to go the reverse route?

-Brett

>
>
> Cheers
> Tarek
>
>>
>> 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/ziade.tarek%40gmail.com
>>
>
>
>
> --
> Tarek Ziad? | http://ziade.org
> _______________________________________________
> 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
>

From brett at python.org  Mon Feb 21 19:25:58 2011
From: brett at python.org (Brett Cannon)
Date: Mon, 21 Feb 2011 10:25:58 -0800
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: <AANLkTin3UNvCLsr+P_oE1HFAxVo66-uEA5noHxoRbdLu@mail.gmail.com>

On Mon, Feb 21, 2011 at 04:52, 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
> ?SA ?391 ?Dictionary-Based Configuration For Logging ? ? ? ? ? ? ?Sajip
> ?SA 3108 ?Standard Library Reorganization ? ? ? ? ? ? ? ? ? ? ? ? Cannon

PEP 3108 (http://bugs.python.org/issue2775) will be considered done
once cProfile and profile are merged.

-Brett


> ?SA 3121 ?Extension Module Initialization and Finalization ? ? ? ?von L?wis
> ?SA 3135 ?New Super
> Spealman, Delaney, Ryan
>
> (I deliberately left 3118 off the list, since there are some
> discrepancies between the PEP and the implementation that need to be
> clarified for 3.3 and the 3 distutils related PEPs won't be done until
> Tarek merges distutils2 back into the main line of development)
>
> It would be good to clear the decks before new PEPs start to be
> accepted for inclusion in 3.3.
>
> 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/brett%40python.org
>

From ziade.tarek at gmail.com  Mon Feb 21 19:30:46 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 21 Feb 2011 19:30:46 +0100
Subject: [Python-Dev] Distutils2 next steps
In-Reply-To: <AANLkTinAcF1Dv1GxHzp4B9hEUUjxF31q2EybX7N9h9_G@mail.gmail.com>
References: <AANLkTi=z_032c9EJq3Xz6grwot6Nub8PqHHh7Dr09ObY@mail.gmail.com>
	<ijt5et$qtf$1@dough.gmane.org>
	<AANLkTim_LJ=MejY29ew_G1wRxu1psyWf415uTpp15mTn@mail.gmail.com>
	<AANLkTinAcF1Dv1GxHzp4B9hEUUjxF31q2EybX7N9h9_G@mail.gmail.com>
Message-ID: <AANLkTim8tBx9qMQmR6Z9MnaYsBSfBkPT81J4VpLK+RoD@mail.gmail.com>

On Mon, Feb 21, 2011 at 7:22 PM, Brett Cannon <brett at python.org> wrote:
...
>> - distutils2 will continue to be released as a standalone project from
>> 2.4 to 3.2. Probably by using 3to2, but I have not tried the tool yet.
>
> So does this mean that primary development will move to py3k and then
> you will simply push changes downstream to the distutils2 project for
> separate releases? Or are you going to go the reverse route?

I will backport from py3k to the standalone version, yes.

I think it will be better because the changes will be exposed to more
people in the Python trunk, and maybe get more feedback before pushing
downstream

Cheers
Tarek

>
> -Brett
>
>>
>>
>> Cheers
>> Tarek
>>
>>>
>>> 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/ziade.tarek%40gmail.com
>>>
>>
>>
>>
>> --
>> Tarek Ziad? | http://ziade.org
>> _______________________________________________
>> 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
>>
>



-- 
Tarek Ziad? | http://ziade.org

From ncoghlan at gmail.com  Mon Feb 21 23:01:28 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Feb 2011 08:01:28 +1000
Subject: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135
In-Reply-To: <AANLkTikekEcFJu2q0VzAmfYDQoNNTnWaAM7EwZEyuOGm@mail.gmail.com>
References: <AANLkTimCF_p3F7QnG-_zaeSj9Uc_J05wu86kLBcLP=6k@mail.gmail.com>
	<AANLkTikekEcFJu2q0VzAmfYDQoNNTnWaAM7EwZEyuOGm@mail.gmail.com>
Message-ID: <AANLkTimsORSZUoBwxzupdqFfaUqYEsoH=bpGa6r3mFkV@mail.gmail.com>

On Tue, Feb 22, 2011 at 3:20 AM, Guido van Rossum <guido at python.org> wrote:
> On Mon, Feb 21, 2011 at 4:52 AM, 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
>> ?SA ?391 ?Dictionary-Based Configuration For Logging ? ? ? ? ? ? ?Sajip
>> ?SA 3108 ?Standard Library Reorganization ? ? ? ? ? ? ? ? ? ? ? ? Cannon
>> ?SA 3121 ?Extension Module Initialization and Finalization ? ? ? ?von L?wis
>> ?SA 3135 ?New Super
>> Spealman, Delaney, Ryan
>
> Somebody (not me, not necessarily the same person for each PEP) needs
> to check each of these PEPs for how well they match the implemented
> reality and report back here. (Unless you already did this and are
> basically giving them a certificate of correctness with your post?)

I did have a look and those listed are the ones that seemed to be
finished. Before moving them to Final, I figured I would ask for
additional opinions in case I had missed something and they still had
some elements that needed to be implemented for 3.3.

As it turns out, I had missed the incomplete profile/cProfile merge
for PEP 3108.

>> It would be good to clear the decks before new PEPs start to be
>> accepted for inclusion in 3.3.
>
> Why?

It's mainly just a continuation of the PEP 0 cleanup I started a while
back, trying to make it clearer which major items are still on the
to-do list for 3.3 and which were completed for 3.2.

I have an associated PEP 1 update I'd like to propose as well (giving
the API/metadata standardisation PEPs a dedicated "Consensus" state to
better separate them from Accepted language and standard library
feature PEPs), but I need to actually write it first.

Cheers,
Nick.

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

From daave at daave.com  Tue Feb 22 00:34:45 2011
From: daave at daave.com (David Claridge)
Date: Tue, 22 Feb 2011 10:34:45 +1100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
Message-ID: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>

Hi,

I was wondering if there is some reason why C API functions like
PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments
rather than const char*s? If there is some reason these methods will
modify their string arguments, it would be nice if it was documented,
because at the moment it's unclear whether it is safe to cast a string
literal to char* in these cases. For instance it seems reasonable that
I should be able to call PySys_GetObject("path") without having to
deal with a 'deprecated conversion from string constant to ?char*?'
error.

Thanks,

--
David Claridge
http://daave.com

[1] http://docs.python.org/c-api/object.html
[2] http://docs.python.org/c-api/sys.html

From victor.stinner at haypocalc.com  Tue Feb 22 01:02:58 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Tue, 22 Feb 2011 01:02:58 +0100
Subject: [Python-Dev] [Python-checkins] r88484 - in
 python/branches/py3k:	Lib/test/subprocessdata/fd_status.py
 Lib/test/test_subprocess.py Misc/NEWS
In-Reply-To: <20110221215548.98F23EE98F@mail.python.org>
References: <20110221215548.98F23EE98F@mail.python.org>
Message-ID: <4D62FD32.6040009@haypocalc.com>

Le 21/02/2011 22:55, antoine.pitrou a ?crit :
> Author: antoine.pitrou
> Date: Mon Feb 21 22:55:48 2011
> New Revision: 88484
>
> Log:
> Issue #10826: Prevent sporadic failure in test_subprocess on Solaris due
> to open door files.
>    
>   if __name__ == "__main__":
> -    print(','.join(str(fd) for fd in range(0, _MAXFD) if isopen(fd)))
> +    fds = []
> +    for fd in range(0, _MAXFD):
> +        try:
> +            st = os.fstat(fd)
> +        except OSError as e:
> +            if e.errno == errno.EBADF:
> +                continue
> +            raise
> +        # Ignore Solaris door files
> +        if st.st_mode&  0xF000 != 0xd000:
> +            fds.append(fd)
>    

Are 0xF000 and 0xD000 constants specific to Solaris? If yes, you may 
only skip these files on Solaris, not on other OSes.

Victor

From wst at pancaprima.com  Tue Feb 22 02:29:51 2011
From: wst at pancaprima.com (wst at pancaprima.com)
Date: Tue, 22 Feb 2011 08:29:51 +0700
Subject: [Python-Dev] Mail System Error - Returned Mail
Message-ID: <MAIL9ueBp7rZeBYCOPl00003b55@mail.pancaprima.com>

The original message was received at Tue, 22 Feb 2011 08:29:51 +0700
from pancaprima.com [196.86.11.104]

----- The following addresses had permanent fatal errors -----
<python-dev at python.org>




From wenheping at gmail.com  Tue Feb 22 04:02:34 2011
From: wenheping at gmail.com (wen heping)
Date: Tue, 22 Feb 2011 11:02:34 +0800
Subject: [Python-Dev] Is Demo directory removed from python3.2 ?
Message-ID: <AANLkTi=RzSHEz2UBUqCPj92TYi7R2cpxwED_78iLQaba@mail.gmail.com>

Hi,

   I found 2 changes in python-3.2 compared to previous python version:
   i) Demo directory removed
   ii) lib/libpython3.2.so.1  changed to lib/libpython3.2mu.so.1

   Would someone tell me why ?

   Thanks at advance.

wen

From brian.curtin at gmail.com  Tue Feb 22 04:34:58 2011
From: brian.curtin at gmail.com (Brian Curtin)
Date: Mon, 21 Feb 2011 21:34:58 -0600
Subject: [Python-Dev] Is Demo directory removed from python3.2 ?
In-Reply-To: <AANLkTi=RzSHEz2UBUqCPj92TYi7R2cpxwED_78iLQaba@mail.gmail.com>
References: <AANLkTi=RzSHEz2UBUqCPj92TYi7R2cpxwED_78iLQaba@mail.gmail.com>
Message-ID: <AANLkTikkrwnvYChjw=Oj11LmcLWrnrKx=xo5fJyEraGu@mail.gmail.com>

On Mon, Feb 21, 2011 at 21:02, wen heping <wenheping at gmail.com> wrote:

> Hi,
>
>   I found 2 changes in python-3.2 compared to previous python version:
>   i) Demo directory removed


>From the "What's new in 3.2" document: The unmaintained Demo directory has
been removed. Some demos were integrated into the documentation, some were
moved to the Tools/demo directory, and others were removed altogether.

See http://bugs.python.org/issue7962
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110221/eeb2396a/attachment-0001.html>

From jackdied at gmail.com  Tue Feb 22 04:40:19 2011
From: jackdied at gmail.com (Jack Diederich)
Date: Mon, 21 Feb 2011 22:40:19 -0500
Subject: [Python-Dev] Is Demo directory removed from python3.2 ?
In-Reply-To: <AANLkTi=RzSHEz2UBUqCPj92TYi7R2cpxwED_78iLQaba@mail.gmail.com>
References: <AANLkTi=RzSHEz2UBUqCPj92TYi7R2cpxwED_78iLQaba@mail.gmail.com>
Message-ID: <AANLkTinSx6CUVZR6d5RMudRwxmajnD=WTOsLnJR4QcZS@mail.gmail.com>

On Mon, Feb 21, 2011 at 10:02 PM, wen heping <wenheping at gmail.com> wrote:
> Hi,
>
> ? I found 2 changes in python-3.2 compared to previous python version:
> ? i) Demo directory removed
> ? ii) lib/libpython3.2.so.1 ?changed to lib/libpython3.2mu.so.1
>
> ? Would someone tell me why ?

The demo directory was largely out of date (some of it by a decade).
Most of what was in it plain didn't work or was an outdated example of
how you should do things.  The good stuff was moved into the
documentation or the standard library.

-Jack

From ncoghlan at gmail.com  Tue Feb 22 06:06:07 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Feb 2011 15:06:07 +1000
Subject: [Python-Dev] Is Demo directory removed from python3.2 ?
In-Reply-To: <AANLkTi=RzSHEz2UBUqCPj92TYi7R2cpxwED_78iLQaba@mail.gmail.com>
References: <AANLkTi=RzSHEz2UBUqCPj92TYi7R2cpxwED_78iLQaba@mail.gmail.com>
Message-ID: <AANLkTik-gmwt9PGoAH+PrqnLd_nXhhfFHWYFkHjdc8vn@mail.gmail.com>

On Tue, Feb 22, 2011 at 1:02 PM, wen heping <wenheping at gmail.com> wrote:
> Hi,
>
> ? I found 2 changes in python-3.2 compared to previous python version:
> ? i) Demo directory removed
> ? ii) lib/libpython3.2.so.1 ?changed to lib/libpython3.2mu.so.1

Others have answered your first question, but the latter is part of PEP 3149:
http://docs.python.org/py3k/whatsnew/3.2.html#pep-3149-abi-version-tagged-so-files

In addition to allowing multiple builds of extension modules to exist
in parallel, PEP 3149 allows multiple builds of Python itself (with
different build options) to coexist.

Cheers,
Nick.

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

From jcea at jcea.es  Tue Feb 22 13:14:18 2011
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 22 Feb 2011 13:14:18 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
Message-ID: <4D63A89A.20609@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have 10MB pickled structure generated in Python 2.7. I only use basic
types (no clases) like sets, dictionaries, lists, strings, etc.

The pickle stores a lot of strings. Some of them should be "bytes",
while other should be "unicode". My idea is to import ALL the strings as
bytes in Python 3.2 and navigate the data structure to convert the
appropiate values to unicode, in a one-time operation (I version the
structure, so I can know if this conversion is already done, simply
storing a new version value).

But I get this error:

"""
Python 3.2 (r32:88445, Feb 21 2011, 13:34:07)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f=open("file.pickle", mode="rb").read()
>>> len(f)
9847316
>>> b=pickle.loads(f,encoding="latin1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: operation forbidden on released memoryview object
"""

I use the encoding "latin1" for transparent byte/unicode conversion (do
not touch the values!).

This seems to be a bug in Python 3.2. Any suggestion?.

PS: The bytestream is protocol 2.

PPS: If there is consensus that this is a real bug, I would create an
issue in the tracker and try to get a minimal testcase.

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

iQCVAwUBTWOomplgi5GaxT1NAQLTYAP/U+eqhQ5nIJyBAqSgYwPmkH4DOlMj4JnH
Jgt6okvOV0hRIXlZ7kbWI2l9OuQyUM4gAeTNDSjFaKs9Hswy26Ro6xhtjidivXDS
TKw6ocRx92/eHvgsOdEZjrE0D8l0dOqodZddbXELp2DjpYs9aozzAsjTHqNZDE1L
fujeTOhtUKw=
=/bcO
-----END PGP SIGNATURE-----

From fuzzyman at voidspace.org.uk  Tue Feb 22 13:20:57 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 22 Feb 2011 12:20:57 +0000
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D63A89A.20609@jcea.es>
References: <4D63A89A.20609@jcea.es>
Message-ID: <4D63AA29.9020004@voidspace.org.uk>

On 22/02/2011 12:14, Jesus Cea wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have 10MB pickled structure generated in Python 2.7. I only use basic
> types (no clases) like sets, dictionaries, lists, strings, etc.
>
> The pickle stores a lot of strings. Some of them should be "bytes",
> while other should be "unicode". My idea is to import ALL the strings as
> bytes in Python 3.2 and navigate the data structure to convert the
> appropiate values to unicode, in a one-time operation (I version the
> structure, so I can know if this conversion is already done, simply
> storing a new version value).
>
> But I get this error:
>
> """
> Python 3.2 (r32:88445, Feb 21 2011, 13:34:07)
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> f=open("file.pickle", mode="rb").read()
>>>> len(f)
> 9847316
>>>> b=pickle.loads(f,encoding="latin1")
> Traceback (most recent call last):
>    File "<stdin>", line 1, in<module>
> ValueError: operation forbidden on released memoryview object
> """
>

That seems like an odd error, but the decision was made that Python 2 
byte-strings would be unpickled on Python 3 as Unicode strings.

See the discussion here:

     http://bugs.python.org/issue6784

This is basically because many people "do the wrong thing" and use 
Python 2 byte strings for restoring text. What it means though is that 
people who "do the right thing" and store binary data in Python 2 byte 
strings can't use Python 2 pickles from Python 3. It also means that 
only ascii data can be unpickled.

A custom pickler / unpickler is suggested as the solution in this issue.

All the best,

Michael Foord

> I use the encoding "latin1" for transparent byte/unicode conversion (do
> not touch the values!).
>
> This seems to be a bug in Python 3.2. Any suggestion?.
>
> PS: The bytestream is protocol 2.
>
> PPS: If there is consensus that this is a real bug, I would create an
> issue in the tracker and try to get a minimal testcase.
>
> - -- 
> 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/
>
> iQCVAwUBTWOomplgi5GaxT1NAQLTYAP/U+eqhQ5nIJyBAqSgYwPmkH4DOlMj4JnH
> Jgt6okvOV0hRIXlZ7kbWI2l9OuQyUM4gAeTNDSjFaKs9Hswy26Ro6xhtjidivXDS
> TKw6ocRx92/eHvgsOdEZjrE0D8l0dOqodZddbXELp2DjpYs9aozzAsjTHqNZDE1L
> fujeTOhtUKw=
> =/bcO
> -----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 solipsis at pitrou.net  Tue Feb 22 13:25:01 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 22 Feb 2011 13:25:01 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
References: <4D63A89A.20609@jcea.es>
Message-ID: <20110222132501.64a8b1e0@pitrou.net>

On Tue, 22 Feb 2011 13:14:18 +0100
Jesus Cea <jcea at jcea.es> wrote:
> 
> This seems to be a bug in Python 3.2. Any suggestion?.

Report an issue and investigate :)

Antoine.



From jcea at jcea.es  Tue Feb 22 14:35:19 2011
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 22 Feb 2011 14:35:19 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D63AA29.9020004@voidspace.org.uk>
References: <4D63A89A.20609@jcea.es> <4D63AA29.9020004@voidspace.org.uk>
Message-ID: <4D63BB97.8050608@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/02/11 13:20, Michael Foord wrote:
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in<module>
>> ValueError: operation forbidden on released memoryview object
> 
> That seems like an odd error, but the decision was made that Python 2
> byte-strings would be unpickled on Python 3 as Unicode strings.

This problem seems NOT related to unicode. In fact, when saying
'encoding="latin1"', my "binary" strings should be converted to unicode
without any kind of issue (my plan was, then, to scan the datastructure
and convert them to native bytes).

The fact is that I get a strange error: "ValueError: operation forbidden
on released memoryview object". Seems like a bug to me. Google shows no
hits. I want to discard any obvious overlooked point.

PS: Just checked... Python 3.1.3 imports the pickle just fine. So busy
migrating my projects to 3.2 (it was my compromise two years ago :), I
don't have time to debug this :).

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

iQCVAwUBTWO7l5lgi5GaxT1NAQJVLQP/fZMxsybbHfkbwDEJ/DVaBSj8VZ2dkO38
oXsH9ojspbxRTv9BCNakKt8SyDMtzJIB6kaZ10qScxftDAGs22xlkpOJyGxBYgNZ
Ut5U425YuUTCyFQyYfREWNs2AqUQOWymnXgIlThDS93n1Y+W2S1ovcT9WJaHyebe
ZVDabLUZYlw=
=IBN8
-----END PGP SIGNATURE-----

From eliben at gmail.com  Tue Feb 22 15:32:45 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 22 Feb 2011 16:32:45 +0200
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D63BB97.8050608@jcea.es>
References: <4D63A89A.20609@jcea.es> <4D63AA29.9020004@voidspace.org.uk>
	<4D63BB97.8050608@jcea.es>
Message-ID: <AANLkTinFQ_jtt8Y0jrxF_bqohFRvWz1Ofvin+x3m-Bz5@mail.gmail.com>

> PS: Just checked... Python 3.1.3 imports the pickle just fine. So busy
> migrating my projects to 3.2 (it was my compromise two years ago :), I
> don't have time to debug this :).
>

I hope you do have a time to open an issue, though :-)
Eli

From jcea at jcea.es  Tue Feb 22 16:10:07 2011
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 22 Feb 2011 16:10:07 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTinFQ_jtt8Y0jrxF_bqohFRvWz1Ofvin+x3m-Bz5@mail.gmail.com>
References: <4D63A89A.20609@jcea.es>
	<4D63AA29.9020004@voidspace.org.uk>	<4D63BB97.8050608@jcea.es>
	<AANLkTinFQ_jtt8Y0jrxF_bqohFRvWz1Ofvin+x3m-Bz5@mail.gmail.com>
Message-ID: <4D63D1CF.7000902@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/02/11 15:32, Eli Bendersky wrote:
>> PS: Just checked... Python 3.1.3 imports the pickle just fine. So busy
>> migrating my projects to 3.2 (it was my compromise two years ago :), I
>> don't have time to debug this :).
>>
> 
> I hope you do have a time to open an issue, though :-)
> Eli

Bugs bug me a lot :). I spend a couple of hours trying to reduce my
pickle to something I could post (the original pickle has tons of
propietary information):

http://bugs.python.org/issue11286

I got a reproductible pickle testcase in only 41 bytes.

Seems to be a SERIOUS regression in 3.2.

I can't progress further. Pickle internals are out of my expertise.

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

iQCVAwUBTWPRz5lgi5GaxT1NAQKwdgQAjV5zKB3LhuVMU+JDbPeZjo/oFu1Yz++Z
1xFPuXTtaeMGMYuQH16j5rghqp90Q4u0M/VGaXI99uxcyTR9fpGGVEBE2L0qnVTg
1sbRyCaaVrPDVju3tTonw5QEe7eXnsec9INuK7KCIXUqEZK7klbqoWFFflU5g/Ui
hcxe8Zt6lQE=
=nWu0
-----END PGP SIGNATURE-----

From techtonik at gmail.com  Tue Feb 22 16:41:47 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 22 Feb 2011 17:41:47 +0200
Subject: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn
 outage on Friday)
In-Reply-To: <AANLkTimaKn2pE3+tAQXiU7_Zd64RHZNG7i_u0VoHFsuw@mail.gmail.com>
References: <AANLkTimA45PxAtz1KvA_JWvHnUX=9hBPSqPPBOGHkdtr@mail.gmail.com>
	<AANLkTimaKn2pE3+tAQXiU7_Zd64RHZNG7i_u0VoHFsuw@mail.gmail.com>
Message-ID: <AANLkTi=mwJbSd9QW5UXqGTPg5mPSphAOhzh4+ke3__n7@mail.gmail.com>

On Fri, Feb 18, 2011 at 4:00 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> On Fri, Feb 18, 2011 at 14:41, anatoly techtonik <techtonik at gmail.com> wrote:
>> Do you have a public list of stuff to be done (i.e. Roadmap)?
>> BTW, what is the size of Mercurial clone for Python repository?
>
> There is a TODO file in the pymigr repo (though I think that is
> currently inaccessible).

Can you provide a link? I don't know where to search. Should we open a
src.python.org domain?

> I don't have a recent optimized clone to check the size of, yet.

What is the size of non-optimized clone then? I know that a clone of
such relatively small project as MoinMoin is about 250Mb. ISTM that
Python repository may take more than 1GB, and that's not acceptable
IMHO. BTW, what do you mean by optimization - I hope not stripping the
history?

[1] http://moinmo.in/MoinMoin2.0/InfrastructurePlans
--
anatoly t.

From john at arbash-meinel.com  Tue Feb 22 17:56:10 2011
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Tue, 22 Feb 2011 10:56:10 -0600
Subject: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn
 outage on Friday)
In-Reply-To: <AANLkTi=mwJbSd9QW5UXqGTPg5mPSphAOhzh4+ke3__n7@mail.gmail.com>
References: <AANLkTimA45PxAtz1KvA_JWvHnUX=9hBPSqPPBOGHkdtr@mail.gmail.com>	<AANLkTimaKn2pE3+tAQXiU7_Zd64RHZNG7i_u0VoHFsuw@mail.gmail.com>
	<AANLkTi=mwJbSd9QW5UXqGTPg5mPSphAOhzh4+ke3__n7@mail.gmail.com>
Message-ID: <4D63EAAA.8010106@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/22/2011 9:41 AM, anatoly techtonik wrote:
> On Fri, Feb 18, 2011 at 4:00 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>> On Fri, Feb 18, 2011 at 14:41, anatoly techtonik <techtonik at gmail.com> wrote:
>>> Do you have a public list of stuff to be done (i.e. Roadmap)?
>>> BTW, what is the size of Mercurial clone for Python repository?
>>
>> There is a TODO file in the pymigr repo (though I think that is
>> currently inaccessible).
> 
> Can you provide a link? I don't know where to search. Should we open a
> src.python.org domain?
> 
>> I don't have a recent optimized clone to check the size of, yet.
> 
> What is the size of non-optimized clone then? I know that a clone of
> such relatively small project as MoinMoin is about 250Mb. ISTM that
> Python repository may take more than 1GB, and that's not acceptable
> IMHO. BTW, what do you mean by optimization - I hope not stripping the
> history?

Mercurial repositories are sensitive to the order that data is inserted
into them. So re-ordering the topological insert can dramatically
improve compression.

The quick overview is that in a given file's history, each diff is
computed to the previous text in that file. So if you have a history like:

 foo
  | \
 foo baz
 bar foo
  | /
  baz
  foo
  bar

This can be stored as either:

 foo

 +bar

 -bar

 +baz
 +bar

This matters more if you have a long divergent history for a while:

 A
 |\
 B C
 | |
 D E
 | |
 F G
 : :
 X Y
 |/
 Z


In this case, you could end up with contents that look like:

 A +B +D +F +X -BDFX+C +E +G +Y +ABDFXZ

Or you could have the history 'interleaved':

 A +B -B+C -C+BD -BD+CE -BDF+CEG -...

There are tools that take a history file, and rewrite it to be more
compact. I don't know much more than that myself. But especially with
something like an svn conversion which probably works on each revision
at a time, where people are committing to different branches
concurrently, I would imagine the conversion could easily end up in the
pessimistic case.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1j6qoACgkQJdeBCYSNAAPzPgCdEOJsHf4Xf4lZH+jHX42FQb8J
sQoAn3JuCmDcsyv0JZpXtbVJoGewA+7t
=M8DI
-----END PGP SIGNATURE-----

From ethan at stoneleaf.us  Tue Feb 22 19:43:28 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 22 Feb 2011 10:43:28 -0800
Subject: [Python-Dev] %-formatting depracation
Message-ID: <4D6403D0.4030107@stoneleaf.us>

Greetings!

According to these release notes in Python 3.0, %-formatting will be 
going away.

http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting


However, I was unable to find any further evidence of actual deprecation 
in 3.1 or 3.2...  does anybody know the status of this?

~Ethan~

From brett at python.org  Tue Feb 22 19:55:26 2011
From: brett at python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 10:55:26 -0800
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
Message-ID: <AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>

On Mon, Feb 21, 2011 at 15:34, David Claridge <daave at daave.com> wrote:

> Hi,
>
> I was wondering if there is some reason why C API functions like
> PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments
> rather than const char*s? If there is some reason these methods will
> modify their string arguments, it would be nice if it was documented,
> because at the moment it's unclear whether it is safe to cast a string
> literal to char* in these cases. For instance it seems reasonable that
> I should be able to call PySys_GetObject("path") without having to
> deal with a 'deprecated conversion from string constant to ?char*?'
> error.
>

Probably because (a) the person who first wrote them used char* instead of
const char*, and (b) it gives us API flexibility by not promising to not
alter the char array at some point in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110222/5e621d48/attachment.html>

From brett at python.org  Tue Feb 22 19:51:57 2011
From: brett at python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 10:51:57 -0800
Subject: [Python-Dev] %-formatting depracation
In-Reply-To: <4D6403D0.4030107@stoneleaf.us>
References: <4D6403D0.4030107@stoneleaf.us>
Message-ID: <AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>

On Tue, Feb 22, 2011 at 10:43, Ethan Furman <ethan at stoneleaf.us> wrote:

> Greetings!
>
> According to these release notes in Python 3.0, %-formatting will be going
> away.
>
>
> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting
>
>
> However, I was unable to find any further evidence of actual deprecation in
> 3.1 or 3.2...  does anybody know the status of this?
>

There isn't one. =)

The very long term view is for %-formatting to go away, but that's as far as
the thinking has gone. There are currently no plans to introduce any
deprecation warning, and I highly doubt we will even remove the feature in
Python 3, giving you probably at least another decade of use at our current
major version release schedule. =)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110222/3d28c58c/attachment-0001.html>

From guido at python.org  Tue Feb 22 20:06:41 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Feb 2011 11:06:41 -0800
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
Message-ID: <AANLkTi=kjzhevGmstfpedu_At4ikE06HME6XYNXhg8wb@mail.gmail.com>

On Tue, Feb 22, 2011 at 10:55 AM, Brett Cannon <brett at python.org> wrote:
>
>
> On Mon, Feb 21, 2011 at 15:34, David Claridge <daave at daave.com> wrote:
>>
>> Hi,
>>
>> I was wondering if there is some reason why C API functions like
>> PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments
>> rather than const char*s? If there is some reason these methods will
>> modify their string arguments, it would be nice if it was documented,
>> because at the moment it's unclear whether it is safe to cast a string
>> literal to char* in these cases. For instance it seems reasonable that
>> I should be able to call PySys_GetObject("path") without having to
>> deal with a 'deprecated conversion from string constant to ?char*?'
>> error.
>
> Probably because (a) the person who first wrote them used char* instead of
> const char*, and (b) it gives us API flexibility by not promising to not
> alter the char array at some point in the future.

I'm sorry, but (b) does not make sense. These APIs typically get
passed string literals and modifying the argument would be a bad idea.

FWIW, in Python 3.2, PySys_GetObject() is actually using const char *.
I don't see a problem with changing PyObject_CallMethod() and its
variations as well.

Though I do not get that warning -- which compiler and version issues
it? Is it a C or a C++ compiler? (If it is a C++ compiler I'm tempted
to reject the complaint -- CPython is not written in C++ even though
at various points we try to keep the headers usable with C++ as well
as with C.)

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

From eric at trueblade.com  Tue Feb 22 20:04:46 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 22 Feb 2011 14:04:46 -0500
Subject: [Python-Dev] %-formatting depracation
In-Reply-To: <4D6403D0.4030107@stoneleaf.us>
References: <4D6403D0.4030107@stoneleaf.us>
Message-ID: <4D6408CE.5050406@trueblade.com>

On 02/22/2011 01:43 PM, Ethan Furman wrote:
> Greetings!
>
> According to these release notes in Python 3.0, %-formatting will be
> going away.
>
> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting
>
>
>
> However, I was unable to find any further evidence of actual deprecation
> in 3.1 or 3.2... does anybody know the status of this?

The last thread on this I have a reference to was in September 2009. I 
think was basically the outcome: 
http://mail.python.org/pipermail/python-dev/2009-September/092399.html

So there will be no deprecation, just a gradual shift to PEP 3101 
formatting.

Eric.

From eric at trueblade.com  Tue Feb 22 20:09:56 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 22 Feb 2011 14:09:56 -0500
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
Message-ID: <4D640A04.7080209@trueblade.com>

On 02/22/2011 01:55 PM, Brett Cannon wrote:
>
>
> On Mon, Feb 21, 2011 at 15:34, David Claridge <daave at daave.com
> <mailto:daave at daave.com>> wrote:
>
>     Hi,
>
>     I was wondering if there is some reason why C API functions like
>     PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments
>     rather than const char*s? If there is some reason these methods will
>     modify their string arguments, it would be nice if it was documented,
>     because at the moment it's unclear whether it is safe to cast a string
>     literal to char* in these cases. For instance it seems reasonable that
>     I should be able to call PySys_GetObject("path") without having to
>     deal with a 'deprecated conversion from string constant to ?char*?'
>     error.
>
>
> Probably because (a) the person who first wrote them used char* instead
> of const char*, and (b) it gives us API flexibility by not promising to
> not alter the char array at some point in the future.

Also changing it now would be a giant hassle, leading to so-called 
"const poisoning" where many, many APIs need to be changed before 
everything would again work.

From solipsis at pitrou.net  Tue Feb 22 20:25:44 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 22 Feb 2011 20:25:44 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
	<AANLkTi=kjzhevGmstfpedu_At4ikE06HME6XYNXhg8wb@mail.gmail.com>
Message-ID: <20110222202544.4009b85e@pitrou.net>

On Tue, 22 Feb 2011 11:06:41 -0800
Guido van Rossum <guido at python.org> wrote:
> >
> > Probably because (a) the person who first wrote them used char* instead of
> > const char*, and (b) it gives us API flexibility by not promising to not
> > alter the char array at some point in the future.
> 
> I'm sorry, but (b) does not make sense. These APIs typically get
> passed string literals and modifying the argument would be a bad idea.

+1. If we started mutating strings passed to such APIs, it would
certainly break a lot of third-party code.

> FWIW, in Python 3.2, PySys_GetObject() is actually using const char *.
> I don't see a problem with changing PyObject_CallMethod() and its
> variations as well.
> 
> Though I do not get that warning -- which compiler and version issues
> it? Is it a C or a C++ compiler?

Well, which warning are you talking about?

I don't think changing a "char *" to a "const char *" specification
would be harmful, since it makes the API more tolerant: with the
latter, you can pass it both const and non-const strings.

Regards

Antoine.



From reid.kleckner at gmail.com  Tue Feb 22 21:21:35 2011
From: reid.kleckner at gmail.com (Reid Kleckner)
Date: Tue, 22 Feb 2011 15:21:35 -0500
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <4D640A04.7080209@trueblade.com>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
	<4D640A04.7080209@trueblade.com>
Message-ID: <AANLkTin=994Fbno-Sra5A0Uzyiyo_1Guw9EDhS-VV_LW@mail.gmail.com>

On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith <eric at trueblade.com> wrote:
> Also changing it now would be a giant hassle, leading to so-called "const
> poisoning" where many, many APIs need to be changed before everything would
> again work.

The poisoning will not break any users of the API, though, since they
can pass const and non-const pointers.  Internally Python would have
to go through and add const keywords as appropriate when passing
strings around.  IMO it's worth it to not cause this warning for
users.

Reid

From stefan_ml at behnel.de  Tue Feb 22 21:48:51 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 22 Feb 2011 21:48:51 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <AANLkTin=994Fbno-Sra5A0Uzyiyo_1Guw9EDhS-VV_LW@mail.gmail.com>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>	<4D640A04.7080209@trueblade.com>
	<AANLkTin=994Fbno-Sra5A0Uzyiyo_1Guw9EDhS-VV_LW@mail.gmail.com>
Message-ID: <ik17fj$cnh$1@dough.gmane.org>

Reid Kleckner, 22.02.2011 21:21:
> On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote:
>> Also changing it now would be a giant hassle, leading to so-called "const
>> poisoning" where many, many APIs need to be changed before everything would
>> again work.
>
> The poisoning will not break any users of the API, though, since they
> can pass const and non-const pointers.  Internally Python would have
> to go through and add const keywords as appropriate when passing
> strings around.  IMO it's worth it to not cause this warning for
> users.

The problem is that Python's C-API functions are used both internally and 
externally, so changes like this can easily impact other public API 
functions because the function being changed uses them. I think that's what 
"const poisoning" refers to here.

Stefan


From solipsis at pitrou.net  Tue Feb 22 21:55:46 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 22 Feb 2011 21:55:46 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
	<4D640A04.7080209@trueblade.com>
	<AANLkTin=994Fbno-Sra5A0Uzyiyo_1Guw9EDhS-VV_LW@mail.gmail.com>
	<ik17fj$cnh$1@dough.gmane.org>
Message-ID: <20110222215546.21bfdad1@pitrou.net>

On Tue, 22 Feb 2011 21:48:51 +0100
Stefan Behnel <stefan_ml at behnel.de> wrote:
> Reid Kleckner, 22.02.2011 21:21:
> > On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote:
> >> Also changing it now would be a giant hassle, leading to so-called "const
> >> poisoning" where many, many APIs need to be changed before everything would
> >> again work.
> >
> > The poisoning will not break any users of the API, though, since they
> > can pass const and non-const pointers.  Internally Python would have
> > to go through and add const keywords as appropriate when passing
> > strings around.  IMO it's worth it to not cause this warning for
> > users.
> 
> The problem is that Python's C-API functions are used both internally and 
> externally, so changes like this can easily impact other public API 
> functions because the function being changed uses them.

How so?




From python-dev at masklinn.net  Tue Feb 22 22:17:43 2011
From: python-dev at masklinn.net (Xavier Morel)
Date: Tue, 22 Feb 2011 22:17:43 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <20110222215546.21bfdad1@pitrou.net>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
	<4D640A04.7080209@trueblade.com>
	<AANLkTin=994Fbno-Sra5A0Uzyiyo_1Guw9EDhS-VV_LW@mail.gmail.com>
	<ik17fj$cnh$1@dough.gmane.org> <20110222215546.21bfdad1@pitrou.net>
Message-ID: <CC79B6D8-4E2B-4919-8982-C961CFCE1EFD@masklinn.net>

On 2011-02-22, at 21:55 , Antoine Pitrou wrote:
> On Tue, 22 Feb 2011 21:48:51 +0100
> Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Reid Kleckner, 22.02.2011 21:21:
>>> On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote:
>>>> Also changing it now would be a giant hassle, leading to so-called "const
>>>> poisoning" where many, many APIs need to be changed before everything would
>>>> again work.
>>> 
>>> The poisoning will not break any users of the API, though, since they
>>> can pass const and non-const pointers.  Internally Python would have
>>> to go through and add const keywords as appropriate when passing
>>> strings around.  IMO it's worth it to not cause this warning for
>>> users.
>> The problem is that Python's C-API functions are used both internally and 
>> externally, so changes like this can easily impact other public API 
>> functions because the function being changed uses them.
> How so?

If the parameters are passed from the newly const'ed function to an
other public-API function, that one will have to be const'ed as well
(or the const will have to be cast away which generally isn't
considered good style and may lead to UBs), which may cascade into yet
an other public-API function, the end result being that numerous
functions would have to be const'ed:

> Adding const qualification may propagate through a program; as you
> add const qualifiers, still more become necessary. This phenomenon is
> sometimes called "const-poisoning." Const-poisoning can frequently
> lead to violations of recommendation EXP05-C. Do not cast away a const
> qualification. While const qualification is a good idea, the costs may
> outweigh the value in the remediation of existing code.

https://www.securecoding.cert.org/confluence/display/seccode/STR05-C.+Use+pointers+to+const+when+referring+to+string+literals

From guido at python.org  Tue Feb 22 22:22:51 2011
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Feb 2011 13:22:51 -0800
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <CC79B6D8-4E2B-4919-8982-C961CFCE1EFD@masklinn.net>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
	<4D640A04.7080209@trueblade.com>
	<AANLkTin=994Fbno-Sra5A0Uzyiyo_1Guw9EDhS-VV_LW@mail.gmail.com>
	<ik17fj$cnh$1@dough.gmane.org> <20110222215546.21bfdad1@pitrou.net>
	<CC79B6D8-4E2B-4919-8982-C961CFCE1EFD@masklinn.net>
Message-ID: <AANLkTinsn=hdVbHt7T2AKk=9FS25rQWhJtYtQBOGeDu_@mail.gmail.com>

On Tue, Feb 22, 2011 at 1:17 PM, Xavier Morel <python-dev at masklinn.net> wrote:
> On 2011-02-22, at 21:55 , Antoine Pitrou wrote:
>> On Tue, 22 Feb 2011 21:48:51 +0100
>> Stefan Behnel <stefan_ml at behnel.de> wrote:
>>> Reid Kleckner, 22.02.2011 21:21:
>>>> On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote:
>>>>> Also changing it now would be a giant hassle, leading to so-called "const
>>>>> poisoning" where many, many APIs need to be changed before everything would
>>>>> again work.
>>>>
>>>> The poisoning will not break any users of the API, though, since they
>>>> can pass const and non-const pointers. ?Internally Python would have
>>>> to go through and add const keywords as appropriate when passing
>>>> strings around. ?IMO it's worth it to not cause this warning for
>>>> users.
>>> The problem is that Python's C-API functions are used both internally and
>>> externally, so changes like this can easily impact other public API
>>> functions because the function being changed uses them.
>> How so?
>
> If the parameters are passed from the newly const'ed function to an
> other public-API function, that one will have to be const'ed as well
> (or the const will have to be cast away which generally isn't
> considered good style and may lead to UBs), which may cascade into yet
> an other public-API function, the end result being that numerous
> functions would have to be const'ed:

I tried this in my codebase. I found no need for further const
propagation in this particular case.

>> Adding const qualification may propagate through a program; as you
>> add const qualifiers, still more become necessary. This phenomenon is
>> sometimes called "const-poisoning." Const-poisoning can frequently
>> lead to violations of recommendation EXP05-C. Do not cast away a const
>> qualification. While const qualification is a good idea, the costs may
>> outweigh the value in the remediation of existing code.
>
> https://www.securecoding.cert.org/confluence/display/seccode/STR05-C.+Use+pointers+to+const+when+referring+to+string+literals
> _______________________________________________
> 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 ncoghlan at gmail.com  Tue Feb 22 22:52:23 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Feb 2011 07:52:23 +1000
Subject: [Python-Dev] %-formatting depracation
In-Reply-To: <AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>
References: <4D6403D0.4030107@stoneleaf.us>
	<AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>
Message-ID: <AANLkTimvEJkNbdPx6MYk9mUQUJhzV4uya1HYL3BALTjh@mail.gmail.com>

On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon <brett at python.org> wrote:
> The very long term view is for %-formatting to go away, but that's as far as
> the thinking has gone. There are currently no plans to introduce any
> deprecation warning, and I highly doubt we will even remove the feature in
> Python 3, giving you probably at least another decade of use at our current
> major version release schedule. =)

This. Without a systematic way to detect and convert %-style to
{}-style formatting, enforcing the switch in the 3.x series just isn't
practical. Heck, we still haven't figured out how to convert a lot of
higher level APIs to the new scheme in a backwards compatible way
(that's why modules like logging still default to %-style, with
{}-style only available via options and wrapper objects).

Cheers,
Nick.

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

From martin at v.loewis.de  Tue Feb 22 22:57:16 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 22 Feb 2011 22:57:16 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <4D640A04.7080209@trueblade.com>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
	<4D640A04.7080209@trueblade.com>
Message-ID: <4D64313C.1020309@v.loewis.de>

> Also changing it now would be a giant hassle, leading to so-called
> "const poisoning" where many, many APIs need to be changed before
> everything would again work.

We have been adding const to many places over the years. I think the
specific case was just missed (i.e. nobody cared about adding const
there).

Regards,
Martin

From solipsis at pitrou.net  Tue Feb 22 23:03:00 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 22 Feb 2011 23:03:00 +0100
Subject: [Python-Dev] %-formatting depracation
References: <4D6403D0.4030107@stoneleaf.us>
	<AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>
	<AANLkTimvEJkNbdPx6MYk9mUQUJhzV4uya1HYL3BALTjh@mail.gmail.com>
Message-ID: <20110222230300.46e426f2@pitrou.net>

On Wed, 23 Feb 2011 07:52:23 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon <brett at python.org> wrote:
> > The very long term view is for %-formatting to go away, but that's as far as
> > the thinking has gone. There are currently no plans to introduce any
> > deprecation warning, and I highly doubt we will even remove the feature in
> > Python 3, giving you probably at least another decade of use at our current
> > major version release schedule. =)
> 
> This. Without a systematic way to detect and convert %-style to
> {}-style formatting, enforcing the switch in the 3.x series just isn't
> practical. Heck, we still haven't figured out how to convert a lot of
> higher level APIs to the new scheme in a backwards compatible way
> (that's why modules like logging still default to %-style, with
> {}-style only available via options and wrapper objects).

I think there are many people still finding %-style more practical for
simple uses, so this might be a case of "practicality beats purity"
over "there should be one obvious way to do it".

Regards

Antoine.



From martin at v.loewis.de  Tue Feb 22 23:06:36 2011
From: martin at v.loewis.de (=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 22 Feb 2011 23:06:36 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <20110222202544.4009b85e@pitrou.net>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>	<AANLkTi=kjzhevGmstfpedu_At4ikE06HME6XYNXhg8wb@mail.gmail.com>
	<20110222202544.4009b85e@pitrou.net>
Message-ID: <4D64336C.5080206@v.loewis.de>

>> Though I do not get that warning -- which compiler and version issues
>> it? Is it a C or a C++ compiler?
> 
> Well, which warning are you talking about?

I think Guido assumed that the OP was getting actual complaints from
some actual compiler - else he wouldn't have asked the question.
However, he didn't actually say he got compile issues.

If you compile

#include <Python.h>

int main()
{
    const char* s = "stdin";
    PyObject_CallMethod(0, s, s);
}

with a g++, you get

a.cc: In function ?int main()?:
a.cc:6: error: invalid conversion from ?const char*? to ?char*?
a.cc:6: error:   initializing argument 2 of ?PyObject*
PyObject_CallMethod(PyObject*, char*, char*, ...)?
a.cc:6: error: invalid conversion from ?const char*? to ?char*?
a.cc:6: error:   initializing argument 3 of ?PyObject*
PyObject_CallMethod(PyObject*, char*, char*, ...)?

If you compile

#include <Python.h>

int main()
{
    PyObject_CallMethod(0, "stdin", "stdin");
}

you get

a.cc: In function ?int main()?:
a.cc:5: warning: deprecated conversion from string constant to ?char*?
a.cc:5: warning: deprecated conversion from string constant to ?char*?

Since most people likely use string literals, and since g++ only started
warning about the deprecated conversion only recently, most people
probably haven't run into the issue.

Regards,
Martin

From martin at v.loewis.de  Tue Feb 22 23:11:09 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 22 Feb 2011 23:11:09 +0100
Subject: [Python-Dev] %-formatting depracation
In-Reply-To: <AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>
References: <4D6403D0.4030107@stoneleaf.us>
	<AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>
Message-ID: <4D64347D.6070501@v.loewis.de>

> The very long term view is for %-formatting to go away

Add to that that this view isn't universally shared among contributors.
Many of us would rather see % formatting stay indefinitely. I regularly
use it for new code.

Regards,
Martin

From ncoghlan at gmail.com  Tue Feb 22 23:13:44 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Feb 2011 08:13:44 +1000
Subject: [Python-Dev] %-formatting depracation
In-Reply-To: <20110222230300.46e426f2@pitrou.net>
References: <4D6403D0.4030107@stoneleaf.us>
	<AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>
	<AANLkTimvEJkNbdPx6MYk9mUQUJhzV4uya1HYL3BALTjh@mail.gmail.com>
	<20110222230300.46e426f2@pitrou.net>
Message-ID: <AANLkTi=_ro2unTXC0a9crhmif0PVKSy_fTTjZ+Dc+usg@mail.gmail.com>

On Wed, Feb 23, 2011 at 8:03 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> I think there are many people still finding %-style more practical for
> simple uses,

A lot of the sting went out of that objection when field autonumbering
was added to new-style formatting ("'%s' % (obj,)" vs
"'{}'.format(obj)" as the minimal case that correctly handles tuples).
The addition of format_map() reduces it even further.

> so this might be a case of "practicality beats purity"
> over "there should be one obvious way to do it".

I agree with that part though, just for historical reasons rather than
seeing much in the way in the way of inherent advantages with %-style
formatting.

Cheers,
Nick.

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

From steve at holdenweb.com  Wed Feb 23 00:01:06 2011
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 22 Feb 2011 15:01:06 -0800
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>
Message-ID: <B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>

One of the students on an introductory Python 3 class asks a very good question about string formatting. This could be because the course materials are misleading, so I would like to understand. It would appear from tests that "{0[X]}".format(...) first tries to convert the string "X" to in integer. If it succeeds then __getitem__() is called with the integer as an argument, otherwise it is called with the string itself as an argument. Is this correct?

The documentation at http://docs.python.org/library/string.html#formatspec is silent on whether strings were ever intended to be used as subscripts. Does this seem sensible? Was it considered during design? Should I alter the materials so that only integer subscripts are used?

regards
 Steve


Begin forwarded message:

> From: kirby urner <kirby.urner at gmail.com>
> Date: February 22, 2011 2:31:08 PM PST
> To: Steve Holden <steve at holdenweb.com>
> Subject: deep question re dict as formatting input
> 
>>>> d
> {'Steve': 'Holden', 'Tim': 'Peters', 'Guido': 'van Rossum', '1':
> 'string', 1: 'integer'}
>>>> "{0[Guido]} is cool".format(d)
> 'van Rossum is cool'
>>>> "{0[1]} is cool".format(d)
> 'integer is cool'
>>>> "{0['1']} is cool".format(d)
> Traceback (most recent call last):
>  File "<pyshell#19>", line 1, in <module>
>    "{0['1']} is cool".format(d)
> KeyError: "'1'"
> 
> 
> Student question:
> 
> Good morning!
> 
> Question on .format(), interactive session follows:
> 
> --> d = {"Steve": "Holden",
> ...      "Guido": "van Rossum",
> ...      "Tim": "Peters",
> ...      "1": "string",
> ...      1: "integer"}
> 
> --> d
> {'Steve': 'Holden', 'Tim': 'Peters', '1': 'string', 1: 'integer',
> 'Guido': 'van Rossum'}
> 
> --> d[1]
> 'integer'
> 
> --> d['1']
> 'string'
> 
> --> "{dct[1]}".format(dct=d)
> 'integer'
> 
> --> "{dct[Guido]}".format(dct=d)
> 'van Rossum'
> 
> --> "{dct['1']}".format(dct=d)
> Traceback (most recent call last):
>  File "<console>", line 1, in <module>
> KeyError: "'1'"
> 
> Question:  If {dct[Guido]} treats Guido as str, why doesn't {dct[1]}
> treate 1 as str?  Feels like an automatic conversion from str to int.
> Furthermore, how does one access the key '1' in a format statement?
> 
> ~Ethan~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110222/7a53741f/attachment.html>

From alexander.belopolsky at gmail.com  Wed Feb 23 00:08:01 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Feb 2011 18:08:01 -0500
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
Message-ID: <AANLkTikGnpnoYJMY_97DbcAtLAoei8x_gXthbF1MnD6H@mail.gmail.com>

On Mon, Feb 21, 2011 at 6:34 PM, David Claridge <daave at daave.com> wrote:
..
> I was wondering if there is some reason why C API functions like
> PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments
> rather than const char*s?

The later is addressed by issue 1699259
<http://bugs.python.org/issue1699259>.  It looks like const was added
in 3.2, but deemed not important enough to backport to 2.7.  The issue
is still open, so interested parties can argue for backport there.

The former (PyObject_CallMethod) is similarly subject of an open issue
in a commit review stage: <http://bugs.python.org/issue9369>.

From daave at daave.com  Wed Feb 23 00:14:10 2011
From: daave at daave.com (David Claridge)
Date: Wed, 23 Feb 2011 10:14:10 +1100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <4D64336C.5080206@v.loewis.de>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>
	<AANLkTi=kjzhevGmstfpedu_At4ikE06HME6XYNXhg8wb@mail.gmail.com>
	<20110222202544.4009b85e@pitrou.net> <4D64336C.5080206@v.loewis.de>
Message-ID: <AANLkTi=-0zt0a2WG1T8X8S6nFG_4_oB4H48brssUwADd@mail.gmail.com>

> If you compile
>
> #include <Python.h>
>
> int main()
> {
> ? ?PyObject_CallMethod(0, "stdin", "stdin");
> }
>
> you get
>
> a.cc: In function ?int main()?:
> a.cc:5: warning: deprecated conversion from string constant to ?char*?
> a.cc:5: warning: deprecated conversion from string constant to ?char*?
>
> Since most people likely use string literals, and since g++ only started
> warning about the deprecated conversion only recently, most people
> probably haven't run into the issue.
>
> Regards,
> Martin

This is precisely the warning I've been getting, I've been embedding
Python 2.6 in an application built using g++ 4.4.

> The later is addressed by issue 1699259
> <http://bugs.python.org/issue1699259>. ?It looks like const was added
> in 3.2, but deemed not important enough to backport to 2.7. ?The issue
> is still open, so interested parties can argue for backport there.
>
> The former (PyObject_CallMethod) is similarly subject of an open issue
> in a commit review stage: <http://bugs.python.org/issue9369>.

Thanks, I'll add my 2c worth on those issues.

Even if it is eventually decided not to backport those patches to 2.7,
it would be nice if the documentation could be updated to indicate
that strings passed to those functions won't be modified, so that API
users like myself can feel a little safer when passing literals in,
without having to trawl through the interpreter source to see if the
arguments are modified.

Thanks,

--
David Claridge
http://daave.com

From alexander.belopolsky at gmail.com  Wed Feb 23 00:15:08 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Feb 2011 18:15:08 -0500
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>
	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
Message-ID: <AANLkTinN0z80Y245A6AwMBJCCxLqqztJiUajeKQS2Y5b@mail.gmail.com>

On Tue, Feb 22, 2011 at 6:01 PM, Steve Holden <steve at holdenweb.com> wrote:
> ... It would appear from tests
> that "{0[X]}".format(...) first tries to convert the string "X" to in
> integer. If it succeeds then __getitem__() is called with the integer as an
> argument, otherwise it is called with the string itself as an argument. Is
> this correct?

This is addressed in the PEP 3101:
"""
    The rules for parsing an item key are very simple.
    If it starts with a digit, then it is treated as a number, otherwise
    it is used as a string.
""" http://www.python.org/dev/peps/pep-3101/

If current implementation does something more involved, I would say it is a bug.

From solipsis at pitrou.net  Wed Feb 23 00:18:59 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Feb 2011 00:18:59 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTikGnpnoYJMY_97DbcAtLAoei8x_gXthbF1MnD6H@mail.gmail.com>
Message-ID: <20110223001859.5113aad5@pitrou.net>

On Tue, 22 Feb 2011 18:08:01 -0500
Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> On Mon, Feb 21, 2011 at 6:34 PM, David Claridge <daave at daave.com> wrote:
> ..
> > I was wondering if there is some reason why C API functions like
> > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments
> > rather than const char*s?
> 
> The later is addressed by issue 1699259
> <http://bugs.python.org/issue1699259>.  It looks like const was added
> in 3.2, but deemed not important enough to backport to 2.7.  The issue
> is still open, so interested parties can argue for backport there.

I don't think it's a good idea to backport visible API changes.
(someone successfully compiling on 2.7.N could then have users
complaining that compilation fails on 2.7.N-1).
Moreover, it doesn't really fix a bug.

Regards

Antoine.



From eric at trueblade.com  Wed Feb 23 00:08:50 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 22 Feb 2011 18:08:50 -0500
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>
	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
Message-ID: <4D644202.7010505@trueblade.com>

Quoting PEP 3101:

An example of the 'getitem' syntax:

         "My name is {0[name]}".format(dict(name='Fred'))

It should be noted that the use of 'getitem' within a format string
is much more limited than its conventional usage.  In the above example,
the string 'name' really is the literal string 'name', not a variable
named 'name'.  The rules for parsing an item key are very simple.
If it starts with a digit, then it is treated as a number, otherwise
it is used as a string.


On 2/22/2011 6:01 PM, Steve Holden wrote:
> One of the students on an introductory Python 3 class asks a very good
> question about string formatting. This could be because the course
> materials are misleading, so I would like to understand. It would appear
> from tests that "{0[X]}".format(...) first tries to convert the string
> "X" to in integer. If it succeeds then __getitem__() is called with the
> integer as an argument, otherwise it is called with the string itself as
> an argument. Is this correct?
>
> The documentation at
> http://docs.python.org/library/string.html#formatspec is silent on
> whether strings were ever intended to be used as subscripts. Does this
> seem sensible? Was it considered during design? Should I alter the
> materials so that only integer subscripts are used?
>
> regards
> Steve
>
>
> Begin forwarded message:
>
>> *From: *kirby urner <kirby.urner at gmail.com <mailto:kirby.urner at gmail.com>>
>> *Date: *February 22, 2011 2:31:08 PM PST
>> *To: *Steve Holden <steve at holdenweb.com <mailto:steve at holdenweb.com>>
>> *Subject: **deep question re dict as formatting input*
>>
>>>>> d
>> {'Steve': 'Holden', 'Tim': 'Peters', 'Guido': 'van Rossum', '1':
>> 'string', 1: 'integer'}
>>>>> "{0[Guido]} is cool".format(d)
>> 'van Rossum is cool'
>>>>> "{0[1]} is cool".format(d)
>> 'integer is cool'
>>>>> "{0['1']} is cool".format(d)
>> Traceback (most recent call last):
>> File "<pyshell#19>", line 1, in <module>
>> "{0['1']} is cool".format(d)
>> KeyError: "'1'"
>>
>>
>> Student question:
>>
>> Good morning!
>>
>> Question on .format(), interactive session follows:
>>
>> --> d = {"Steve": "Holden",
>> ... "Guido": "van Rossum",
>> ... "Tim": "Peters",
>> ... "1": "string",
>> ... 1: "integer"}
>>
>> --> d
>> {'Steve': 'Holden', 'Tim': 'Peters', '1': 'string', 1: 'integer',
>> 'Guido': 'van Rossum'}
>>
>> --> d[1]
>> 'integer'
>>
>> --> d['1']
>> 'string'
>>
>> --> "{dct[1]}".format(dct=d)
>> 'integer'
>>
>> --> "{dct[Guido]}".format(dct=d)
>> 'van Rossum'
>>
>> --> "{dct['1']}".format(dct=d)
>> Traceback (most recent call last):
>> File "<console>", line 1, in <module>
>> KeyError: "'1'"
>>
>> Question: If {dct[Guido]} treats Guido as str, why doesn't {dct[1]}
>> treate 1 as str? Feels like an automatic conversion from str to int.
>> Furthermore, how does one access the key '1' in a format statement?
>>
>> ~Ethan~
>
>
>
> _______________________________________________
> 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/eric%2Ba-python-dev%40trueblade.com


From steve at holdenweb.com  Wed Feb 23 00:28:10 2011
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 22 Feb 2011 15:28:10 -0800
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <4D644202.7010505@trueblade.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>
	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
	<4D644202.7010505@trueblade.com>
Message-ID: <C12A521E-D2D5-4E51-AF10-EFE235180C6D@holdenweb.com>


On Feb 22, 2011, at 3:08 PM, Eric Smith wrote:

> Quoting PEP 3101:
> 
> An example of the 'getitem' syntax:
> 
>        "My name is {0[name]}".format(dict(name='Fred'))
> 
> It should be noted that the use of 'getitem' within a format string
> is much more limited than its conventional usage.  In the above example,
> the string 'name' really is the literal string 'name', not a variable
> named 'name'.  The rules for parsing an item key are very simple.
> If it starts with a digit, then it is treated as a number, otherwise
> it is used as a string.
> 
That's not strictly true:

>>> d = {"Steve":"Holden", "Guido":"van Rossum", 21.2:"float"}
>>> d[21.1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 21.1
>>> d[21.2]
'float'
>>> "{0[21.2]}".format(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: '21.2'
>>> 

But I take your point, and should have thought to read the PEP. Thanks!

Kirby: Please apologize to Ethan. I can't remember being aware of the PEP 3101 specification quoted by Eric above. We will probably need to modify the course materials to take this wrinkle into account (at least by demonstrating that we are aware of it).

regards
 Steve

> 
> On 2/22/2011 6:01 PM, Steve Holden wrote:
>> One of the students on an introductory Python 3 class asks a very good
>> question about string formatting. This could be because the course
>> materials are misleading, so I would like to understand. It would appear
>> from tests that "{0[X]}".format(...) first tries to convert the string
>> "X" to in integer. If it succeeds then __getitem__() is called with the
>> integer as an argument, otherwise it is called with the string itself as
>> an argument. Is this correct?
>> 
>> The documentation at
>> http://docs.python.org/library/string.html#formatspec is silent on
>> whether strings were ever intended to be used as subscripts. Does this
>> seem sensible? Was it considered during design? Should I alter the
>> materials so that only integer subscripts are used?
>> 
>> regards
>> Steve
>> 
>> 
>> Begin forwarded message:
>> 
>>> *From: *kirby urner <kirby.urner at gmail.com <mailto:kirby.urner at gmail.com>>
>>> *Date: *February 22, 2011 2:31:08 PM PST
>>> *To: *Steve Holden <steve at holdenweb.com <mailto:steve at holdenweb.com>>
>>> *Subject: **deep question re dict as formatting input*
>>> 
>>>>>> d
>>> {'Steve': 'Holden', 'Tim': 'Peters', 'Guido': 'van Rossum', '1':
>>> 'string', 1: 'integer'}
>>>>>> "{0[Guido]} is cool".format(d)
>>> 'van Rossum is cool'
>>>>>> "{0[1]} is cool".format(d)
>>> 'integer is cool'
>>>>>> "{0['1']} is cool".format(d)
>>> Traceback (most recent call last):
>>> File "<pyshell#19>", line 1, in <module>
>>> "{0['1']} is cool".format(d)
>>> KeyError: "'1'"
>>> 
>>> 
>>> Student question:
>>> 
>>> Good morning!
>>> 
>>> Question on .format(), interactive session follows:
>>> 
>>> --> d = {"Steve": "Holden",
>>> ... "Guido": "van Rossum",
>>> ... "Tim": "Peters",
>>> ... "1": "string",
>>> ... 1: "integer"}
>>> 
>>> --> d
>>> {'Steve': 'Holden', 'Tim': 'Peters', '1': 'string', 1: 'integer',
>>> 'Guido': 'van Rossum'}
>>> 
>>> --> d[1]
>>> 'integer'
>>> 
>>> --> d['1']
>>> 'string'
>>> 
>>> --> "{dct[1]}".format(dct=d)
>>> 'integer'
>>> 
>>> --> "{dct[Guido]}".format(dct=d)
>>> 'van Rossum'
>>> 
>>> --> "{dct['1']}".format(dct=d)
>>> Traceback (most recent call last):
>>> File "<console>", line 1, in <module>
>>> KeyError: "'1'"
>>> 
>>> Question: If {dct[Guido]} treats Guido as str, why doesn't {dct[1]}
>>> treate 1 as str? Feels like an automatic conversion from str to int.
>>> Furthermore, how does one access the key '1' in a format statement?
>>> 
>>> ~Ethan~
>> 
>> 
>> 
>> _______________________________________________
>> 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/eric%2Ba-python-dev%40trueblade.com
> 


From alexander.belopolsky at gmail.com  Wed Feb 23 00:30:01 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Feb 2011 18:30:01 -0500
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <20110223001859.5113aad5@pitrou.net>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTikGnpnoYJMY_97DbcAtLAoei8x_gXthbF1MnD6H@mail.gmail.com>
	<20110223001859.5113aad5@pitrou.net>
Message-ID: <AANLkTi=g3w-TD071Exq5M_ZjiRxwe2Pr7QGw8yfs9VTv@mail.gmail.com>

On Tue, Feb 22, 2011 at 6:18 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
..
> I don't think it's a good idea to backport visible API changes.
> (someone successfully compiling on 2.7.N could then have users
> complaining that compilation fails on 2.7.N-1).
> Moreover, it doesn't really fix a bug.

That was the argument that I voiced
http://bugs.python.org/issue1699259#msg119032, but I cannot really
think of the code that would be broken by changing the type of an API
function *argument* from char * to const char *.  Given that 2.7 is an
odd-ball with extended maintenance period, I am not sure "it doesn't
really fix a bug" argument is dispositive.   I am still -0 on
backport, however.

From orsenthil at gmail.com  Wed Feb 23 00:32:45 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 23 Feb 2011 07:32:45 +0800
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <AANLkTinN0z80Y245A6AwMBJCCxLqqztJiUajeKQS2Y5b@mail.gmail.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>
	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
	<AANLkTinN0z80Y245A6AwMBJCCxLqqztJiUajeKQS2Y5b@mail.gmail.com>
Message-ID: <AANLkTikNwqsroCkhenp-RWEbk=B4Bqeef+4=VBKhG_u+@mail.gmail.com>

> On Tue, Feb 22, 2011 at 6:01 PM, Steve Holden <steve at holdenweb.com> wrote:
>> ... It would appear from tests
>> that "{0[X]}".format(...) first tries to convert the string "X" to in
>> integer. If it succeeds then __getitem__() is called with the integer as an
>> argument, otherwise it is called with the string itself as an argument. Is
>> this correct?
>
> This is addressed in the PEP 3101:
> """
> ? ?The rules for parsing an item key are very simple.
> ? ?If it starts with a digit, then it is treated as a number, otherwise
> ? ?it is used as a string.
> """ http://www.python.org/dev/peps/pep-3101/

To the other question :

> Furthermore, how does one access the key '1' in a format statement?
> ~Ethan~

I think, parsing rule already helps to understand the problem with the
key like '1'.
The PEP also explicitly states that:

"""
Because keys are not quote-delimited, it is not possible to
    specify arbitrary dictionary keys (e.g., the strings "10" or
    ":-]") from within a format string.
"""
-- 
Senthil

From anikom15 at gmail.com  Wed Feb 23 00:36:00 2011
From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Tue, 22 Feb 2011 15:36:00 -0800
Subject: [Python-Dev] %-formatting depracation
In-Reply-To: <20110222230300.46e426f2@pitrou.net>
References: <4D6403D0.4030107@stoneleaf.us>
	<AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>
	<AANLkTimvEJkNbdPx6MYk9mUQUJhzV4uya1HYL3BALTjh@mail.gmail.com>
	<20110222230300.46e426f2@pitrou.net>
Message-ID: <1298417760.12731.1.camel@localhost.localdomain>

On Tue, 2011-02-22 at 23:03 +0100, Antoine Pitrou wrote:
> On Wed, 23 Feb 2011 07:52:23 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> > On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon <brett at python.org> wrote:
> > > The very long term view is for %-formatting to go away, but that's as far as
> > > the thinking has gone. There are currently no plans to introduce any
> > > deprecation warning, and I highly doubt we will even remove the feature in
> > > Python 3, giving you probably at least another decade of use at our current
> > > major version release schedule. =)
> > 
> > This. Without a systematic way to detect and convert %-style to
> > {}-style formatting, enforcing the switch in the 3.x series just isn't
> > practical. Heck, we still haven't figured out how to convert a lot of
> > higher level APIs to the new scheme in a backwards compatible way
> > (that's why modules like logging still default to %-style, with
> > {}-style only available via options and wrapper objects).
> 
> I think there are many people still finding %-style more practical for
> simple uses, so this might be a case of "practicality beats purity"
> over "there should be one obvious way to do it".
> 
> 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

I tried to use the format method, but I found the syntax was getting on
my nerves and have since gone back to %-formatting. So I don't think
it's going away anytime soon.


From solipsis at pitrou.net  Wed Feb 23 00:36:33 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Feb 2011 00:36:33 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <AANLkTi=g3w-TD071Exq5M_ZjiRxwe2Pr7QGw8yfs9VTv@mail.gmail.com>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTikGnpnoYJMY_97DbcAtLAoei8x_gXthbF1MnD6H@mail.gmail.com>
	<20110223001859.5113aad5@pitrou.net>
	<AANLkTi=g3w-TD071Exq5M_ZjiRxwe2Pr7QGw8yfs9VTv@mail.gmail.com>
Message-ID: <1298417793.3757.40.camel@localhost.localdomain>

Le mardi 22 f?vrier 2011 ? 18:30 -0500, Alexander Belopolsky a ?crit :
> On Tue, Feb 22, 2011 at 6:18 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> ..
> > I don't think it's a good idea to backport visible API changes.
> > (someone successfully compiling on 2.7.N could then have users
> > complaining that compilation fails on 2.7.N-1).
> > Moreover, it doesn't really fix a bug.
> 
> That was the argument that I voiced
> http://bugs.python.org/issue1699259#msg119032, but I cannot really
> think of the code that would be broken by changing the type of an API
> function *argument* from char * to const char *.

To quote the message above: someone successfully compiling on 2.7.N
could then have users complaining that compilation fails on 2.7.N-1.
(note: *N-1*)



From martin at v.loewis.de  Wed Feb 23 00:43:29 2011
From: martin at v.loewis.de (=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 23 Feb 2011 00:43:29 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <AANLkTi=-0zt0a2WG1T8X8S6nFG_4_oB4H48brssUwADd@mail.gmail.com>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>	<AANLkTinGCNKcJ-OoBPTk8+sbS54qhTfr1VkZOwYXjFk7@mail.gmail.com>	<AANLkTi=kjzhevGmstfpedu_At4ikE06HME6XYNXhg8wb@mail.gmail.com>	<20110222202544.4009b85e@pitrou.net>	<4D64336C.5080206@v.loewis.de>
	<AANLkTi=-0zt0a2WG1T8X8S6nFG_4_oB4H48brssUwADd@mail.gmail.com>
Message-ID: <4D644A21.3020105@v.loewis.de>

> Even if it is eventually decided not to backport those patches to 2.7,
> it would be nice if the documentation could be updated to indicate
> that strings passed to those functions won't be modified, so that API
> users like myself can feel a little safer when passing literals in,
> without having to trawl through the interpreter source to see if the
> arguments are modified.

Can you provide the proper patches?

In writing them, you can assume that Python never modifies parameters,
except when it is already documented that it does.

Regards,
Martin

From alexander.belopolsky at gmail.com  Wed Feb 23 00:49:55 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Feb 2011 18:49:55 -0500
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <1298417793.3757.40.camel@localhost.localdomain>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>
	<AANLkTikGnpnoYJMY_97DbcAtLAoei8x_gXthbF1MnD6H@mail.gmail.com>
	<20110223001859.5113aad5@pitrou.net>
	<AANLkTi=g3w-TD071Exq5M_ZjiRxwe2Pr7QGw8yfs9VTv@mail.gmail.com>
	<1298417793.3757.40.camel@localhost.localdomain>
Message-ID: <AANLkTi=psz3g2ZW-9V6zaCLgvJLD7_-tEXcBkFer9OGQ@mail.gmail.com>

On Tue, Feb 22, 2011 at 6:36 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
..
> To quote the message above: someone successfully compiling on 2.7.N
> could then have users complaining that compilation fails on 2.7.N-1.
> (note: *N-1*)

I missed that.  Yes, this is a valid concern.  I change my vote from
-0 to -1. :-)

From martin at v.loewis.de  Wed Feb 23 00:50:41 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 23 Feb 2011 00:50:41 +0100
Subject: [Python-Dev] Const-correctness in C-API Object Protocol
In-Reply-To: <20110223001859.5113aad5@pitrou.net>
References: <AANLkTin9q7DFME6k+gHRhTSzhJ5qzku1R4tRfs-rzZ6A@mail.gmail.com>	<AANLkTikGnpnoYJMY_97DbcAtLAoei8x_gXthbF1MnD6H@mail.gmail.com>
	<20110223001859.5113aad5@pitrou.net>
Message-ID: <4D644BD1.1020806@v.loewis.de>

> I don't think it's a good idea to backport visible API changes.
> (someone successfully compiling on 2.7.N could then have users
> complaining that compilation fails on 2.7.N-1).

+1. If it was a bug fix (which it isn't), having this kind of breakage
would be fine, of course (i.e. code relying on the bug fix will
reasonably break when used with buggy versions).

Regards,
Martin

From tjreedy at udel.edu  Wed Feb 23 01:55:18 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 22 Feb 2011 19:55:18 -0500
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <AANLkTikNwqsroCkhenp-RWEbk=B4Bqeef+4=VBKhG_u+@mail.gmail.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>	<AANLkTinN0z80Y245A6AwMBJCCxLqqztJiUajeKQS2Y5b@mail.gmail.com>
	<AANLkTikNwqsroCkhenp-RWEbk=B4Bqeef+4=VBKhG_u+@mail.gmail.com>
Message-ID: <ik1ltm$on7$1@dough.gmane.org>

On 2/22/2011 6:32 PM, Senthil Kumaran wrote:
>> On Tue, Feb 22, 2011 at 6:01 PM, Steve Holden<steve at holdenweb.com>  wrote:
>>> ... It would appear from tests
>>> that "{0[X]}".format(...) first tries to convert the string "X" to in
>>> integer. If it succeeds then __getitem__() is called with the integer as an
>>> argument, otherwise it is called with the string itself as an argument. Is
>>> this correct?
>>
>> This is addressed in the PEP 3101:
>> """
>>     The rules for parsing an item key are very simple.
>>     If it starts with a digit, then it is treated as a number, otherwise
>>     it is used as a string.
>> """ http://www.python.org/dev/peps/pep-3101/
>
> To the other question :
>
>> Furthermore, how does one access the key '1' in a format statement?
>> ~Ethan~
>
> I think, parsing rule already helps to understand the problem with the
> key like '1'.
> The PEP also explicitly states that:
>
> """
> Because keys are not quote-delimited, it is not possible to
>      specify arbitrary dictionary keys (e.g., the strings "10" or
>      ":-]") from within a format string.
> """

Is this all specific in the lib docs? If not, it should be.


-- 
Terry Jan Reedy


From eric at trueblade.com  Wed Feb 23 01:32:56 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 22 Feb 2011 19:32:56 -0500
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <C12A521E-D2D5-4E51-AF10-EFE235180C6D@holdenweb.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>	<4D644202.7010505@trueblade.com>
	<C12A521E-D2D5-4E51-AF10-EFE235180C6D@holdenweb.com>
Message-ID: <4D6455B8.309@trueblade.com>

On 2/22/2011 6:28 PM, Steve Holden wrote:
>
> On Feb 22, 2011, at 3:08 PM, Eric Smith wrote:
>
>> Quoting PEP 3101:
>>
>> An example of the 'getitem' syntax:
>>
>>         "My name is {0[name]}".format(dict(name='Fred'))
>>
>> It should be noted that the use of 'getitem' within a format string
>> is much more limited than its conventional usage.  In the above example,
>> the string 'name' really is the literal string 'name', not a variable
>> named 'name'.  The rules for parsing an item key are very simple.
>> If it starts with a digit, then it is treated as a number, otherwise
>> it is used as a string.
>>
> That's not strictly true:
>
>>>> d = {"Steve":"Holden", "Guido":"van Rossum", 21.2:"float"}
>>>> d[21.1]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in<module>
> KeyError: 21.1
>>>> d[21.2]
> 'float'
>>>> "{0[21.2]}".format(d)
> Traceback (most recent call last):
>    File "<stdin>", line 1, in<module>
> KeyError: '21.2'
>>>>

You are correct, I didn't exactly implement the PEP on this point, 
probably as a shortcut. I think there's an issue somewhere that 
discusses this, but I can't find it. The CPython implementation is 
really using "If every character is a digit, then it is treated as an 
integer, otherwise it is used as a string".

See find_name_split in Objects/stringlib/string_format.h, in particular 
the call to get_integer() and the interpretation of the result.

Eric.

From victor.stinner at haypocalc.com  Wed Feb 23 02:25:34 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Wed, 23 Feb 2011 02:25:34 +0100
Subject: [Python-Dev] [Python-checkins] r88505 -
	python/branches/py3k/Lib/ftplib.py
In-Reply-To: <20110222192433.60A86EEA06@mail.python.org>
References: <20110222192433.60A86EEA06@mail.python.org>
Message-ID: <1298424334.4903.5.camel@marge>

You should maybe backport this fix to Python 3.2.

Le mardi 22 f?vrier 2011 ? 20:24 +0100, giampaolo.rodola a ?crit :
> Author: giampaolo.rodola
> Date: Tue Feb 22 20:24:33 2011
> New Revision: 88505
> 
> Log:
> In FTP.close() method, make sure to also close the socket object, not only the file.
> 
> Modified:
>    python/branches/py3k/Lib/ftplib.py
> 
> Modified: python/branches/py3k/Lib/ftplib.py
> ==============================================================================
> --- python/branches/py3k/Lib/ftplib.py	(original)
> +++ python/branches/py3k/Lib/ftplib.py	Tue Feb 22 20:24:33 2011
> @@ -589,11 +589,11 @@
>  
>      def close(self):
>          '''Close the connection without assuming anything about it.'''
> -        if self.file:
> +        if self.file is not None:
>              self.file.close()
> +        if self.sock is not None:
>              self.sock.close()
> -            self.file = self.sock = None
> -
> +        self.file = self.sock = None
>  


From ncoghlan at gmail.com  Wed Feb 23 02:43:54 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Feb 2011 11:43:54 +1000
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <4D5A3990.4040902@v.loewis.de>
References: <4D5A3990.4040902@v.loewis.de>
Message-ID: <AANLkTi=aCs3RGuVOhDqknGeqO5jp06OfG2djKyem1qRq@mail.gmail.com>

On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I'm going to perform a Debian upgrade of svn.python.org on Friday,
> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
> that time. The outage shouldn't be longer than an hour.

This may have caused some issues with the SVN viewer - I'm currently
getting "code" with no syntax highlighting and all leading whitespace
stripped when attempting to look at file contents.

Cheers,
Nick.

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

From raymond.hettinger at gmail.com  Wed Feb 23 02:51:56 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Tue, 22 Feb 2011 17:51:56 -0800
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <AANLkTi=aCs3RGuVOhDqknGeqO5jp06OfG2djKyem1qRq@mail.gmail.com>
References: <4D5A3990.4040902@v.loewis.de>
	<AANLkTi=aCs3RGuVOhDqknGeqO5jp06OfG2djKyem1qRq@mail.gmail.com>
Message-ID: <EC91E8F3-83FF-47A9-81F9-9D3E57EC3C3E@gmail.com>


On Feb 22, 2011, at 5:43 PM, Nick Coghlan wrote:

> On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I'm going to perform a Debian upgrade of svn.python.org on Friday,
>> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
>> that time. The outage shouldn't be longer than an hour.
> 
> This may have caused some issues with the SVN viewer - I'm currently
> getting "code" with no syntax highlighting and all leading whitespace
> stripped when attempting to look at file contents.

I saw the same thing yesterday when viewing with the Chrome browser
but it looked fine on Firefox.  Later, after restarting the browsers the
problem disappeared.  I wonder if there was some sort of caching issue.


Raymond

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

From benjamin at python.org  Wed Feb 23 03:23:54 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 22 Feb 2011 20:23:54 -0600
Subject: [Python-Dev] [Python-checkins] r88503 - in
 python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3
In-Reply-To: <20110222191243.810C3F634@mail.python.org>
References: <20110222191243.810C3F634@mail.python.org>
Message-ID: <AANLkTimmsW-_G-sRoon1BrG_rs_5DtVBtAH8DaDOJ_V2@mail.gmail.com>

2011/2/22 brett.cannon <python-checkins at python.org>:
> Author: brett.cannon
> Date: Tue Feb 22 20:12:43 2011
> New Revision: 88503
>
> Log:
> Add lib2to3.__main__ to make it easier for debugging purposes to run 2to3.

Please revert this and do it in the sandbox.

>
> Added:
> ? python/branches/py3k/Lib/lib2to3/__main__.py
> Modified:
> ? python/branches/py3k/Tools/scripts/2to3
>
> Added: python/branches/py3k/Lib/lib2to3/__main__.py
> ==============================================================================
> --- (empty file)
> +++ python/branches/py3k/Lib/lib2to3/__main__.py ? ? ? ?Tue Feb 22 20:12:43 2011
> @@ -0,0 +1,4 @@
> +import sys
> +from .main import main
> +
> +sys.exit(main("lib2to3.fixes"))
>
> Modified: python/branches/py3k/Tools/scripts/2to3
> ==============================================================================
> --- python/branches/py3k/Tools/scripts/2to3 ? ? (original)
> +++ python/branches/py3k/Tools/scripts/2to3 ? ? Tue Feb 22 20:12:43 2011
> @@ -1,5 +1,4 @@
> ?#!/usr/bin/env python
> -import sys
> -from lib2to3.main import main
> +import runpy
>
> -sys.exit(main("lib2to3.fixes"))
> +runpy.run_module('lib2to3', run_name='__main__', alter_sys=True)
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>



-- 
Regards,
Benjamin

From stephen at xemacs.org  Wed Feb 23 03:31:39 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 23 Feb 2011 11:31:39 +0900
Subject: [Python-Dev]  Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D63A89A.20609@jcea.es>
References: <4D63A89A.20609@jcea.es>
Message-ID: <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>

Jesus Cea writes:

 > PPS: If there is consensus that this is a real bug, I would create an
 > issue in the tracker and try to get a minimal testcase.

All bugs are issues, but not all issues are bugs.

Please don't wait for consensus or even a second opinion to file the
issue.

It's reasonable for a new Python user to ask whether something is a
bug or not, but if somebody with your experience and contribution
level to Python doesn't understand something, at the very least we
have to suspect a doc bug.  So please file the issue to ensure that
something will be done to address the issue, and even if it turns out
to be some misunderstanding that only you are ever likely to
make<wink>, at least the issue will remain as documentation if
somebody else has the same misunderstanding.

OTOH, the testcase might require a lot of effort on your part.  Of
course it's reasonable for you to check whether it's a simple
misunderstanding before exerting that effort.

From alexander.belopolsky at gmail.com  Wed Feb 23 04:06:51 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 22 Feb 2011 22:06:51 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTimDuvh9n1c1HLJdYJ4nK3WmfHzVZ4dejWqxjMp3@mail.gmail.com>

On Tue, Feb 22, 2011 at 9:31 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Jesus Cea writes:
>
> ?> PPS: If there is consensus that this is a real bug, I would create an
> ?> issue in the tracker and try to get a minimal testcase.
>
> All bugs are issues, but not all issues are bugs.
>
> Please don't wait for consensus or even a second opinion to file the
> issue.
>

AFAICT, it was not mentioned in this thread, but the issue has been
created on the tracker:

http://bugs.python.org/issue11286

From jcea at jcea.es  Wed Feb 23 05:34:43 2011
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 23 Feb 2011 05:34:43 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4D648E63.2050106@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/02/11 03:31, Stephen J. Turnbull wrote:
> Please don't wait for consensus or even a second opinion to file the
> issue.
> 
> It's reasonable for a new Python user to ask whether something is a
> bug or not, but if somebody with your experience and contribution
> level to Python doesn't understand something, at the very least we
> have to suspect a doc bug.

Every time I read a message from Antoine Pitrou, Brett Cannon, Nick
Coghlan, Martin L?wis, Eric Smith, Steve Holden, Benjamin Peterson,
Victor Stinner, Greog Brandl, Raymond Hettinger, Guido and so many
others python-devs (not an exhaustive list, if you are not there, you
probably should, sorry :), I feel I am faking my knowledge of Python
:-). I am a pretender :).

BTW, this project is my first real python 3 code (I promised to myself
to move after 3.2 release, a year ago), for a real/big project, and I
was thinking that maybe I was overlooking something obvious for any
seasoned "real" python programmer.

I overcame my fear of being seen as a fool last millenia, so I am not
afraid of asking. Sometimes I even ask too much.

> OTOH, the testcase might require a lot of effort on your part.  Of
> course it's reasonable for you to check whether it's a simple
> misunderstanding before exerting that effort.

In fact, I invested *hours* trying to reduce my multimegabyte
problematic pickle to 41 bytes, but at this time I was already convinced
that I had hit an ugly and serious bug.

Issue filed. It already has a patch. That was fast!. Now I can sit back
waiting for 3.2.1 before touching my project again :). Mixed feelings
about the waiting. I hope it is short.

Life sucks sometimes :). Thanks $DEITY there are quite a few better
python-devs than me :).

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

iQCVAwUBTWSOY5lgi5GaxT1NAQIqQAP/Wf/e2iN3FRb7istoGCpqCgjDv7UyCOWF
RzOYMJWh0xhNL5ydZZ2YwtcQNEWrQS538zrr8piOqvV3ielOBCgSWArqChWaQTHU
ZC3gdaw8N5VMr0AXGBMXwcflkLaQ7BrBtiQBizFL9KLYGDI9JG8+O1YjpjamUeQv
iXEyGdqWUp4=
=XwYt
-----END PGP SIGNATURE-----

From g.rodola at gmail.com  Wed Feb 23 05:41:40 2011
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Wed, 23 Feb 2011 05:41:40 +0100
Subject: [Python-Dev] [Python-checkins] r88505 -
	python/branches/py3k/Lib/ftplib.py
In-Reply-To: <1298424334.4903.5.camel@marge>
References: <20110222192433.60A86EEA06@mail.python.org>
	<1298424334.4903.5.camel@marge>
Message-ID: <AANLkTins9i+OiQGeFfBRUGNnONfKryS4982+q5QiUB8M@mail.gmail.com>

I'll do.

2011/2/23 Victor Stinner <victor.stinner at haypocalc.com>:
> You should maybe backport this fix to Python 3.2.
>
> Le mardi 22 f?vrier 2011 ? 20:24 +0100, giampaolo.rodola a ?crit :
>> Author: giampaolo.rodola
>> Date: Tue Feb 22 20:24:33 2011
>> New Revision: 88505
>>
>> Log:
>> In FTP.close() method, make sure to also close the socket object, not only the file.
>>
>> Modified:
>> ? ?python/branches/py3k/Lib/ftplib.py
>>
>> Modified: python/branches/py3k/Lib/ftplib.py
>> ==============================================================================
>> --- python/branches/py3k/Lib/ftplib.py ? ? ? ?(original)
>> +++ python/branches/py3k/Lib/ftplib.py ? ? ? ?Tue Feb 22 20:24:33 2011
>> @@ -589,11 +589,11 @@
>>
>> ? ? ?def close(self):
>> ? ? ? ? ?'''Close the connection without assuming anything about it.'''
>> - ? ? ? ?if self.file:
>> + ? ? ? ?if self.file is not None:
>> ? ? ? ? ? ? ?self.file.close()
>> + ? ? ? ?if self.sock is not None:
>> ? ? ? ? ? ? ?self.sock.close()
>> - ? ? ? ? ? ?self.file = self.sock = None
>> -
>> + ? ? ? ?self.file = self.sock = None
>>
>
> _______________________________________________
> 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 stephen at xemacs.org  Wed Feb 23 06:51:48 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 23 Feb 2011 14:51:48 +0900
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D648E63.2050106@jcea.es>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
Message-ID: <87bp23nvrf.fsf@uwakimon.sk.tsukuba.ac.jp>

Jesus Cea writes:

 > Every time I read a message from [long, incomplete<wink> list] and
 > so many others python-devs (not an exhaustive list, if you are not
 > there, you probably should, sorry :), I feel I am faking my
 > knowledge of Python :-). I am a pretender :).

Sure.  I suspect even some of those *on* the list feel that way
sometimes.  That's what's so great about the list, the people who
contribute!


From martin at v.loewis.de  Wed Feb 23 07:22:19 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 23 Feb 2011 07:22:19 +0100
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <AANLkTi=aCs3RGuVOhDqknGeqO5jp06OfG2djKyem1qRq@mail.gmail.com>
References: <4D5A3990.4040902@v.loewis.de>
	<AANLkTi=aCs3RGuVOhDqknGeqO5jp06OfG2djKyem1qRq@mail.gmail.com>
Message-ID: <4D64A79B.8040607@v.loewis.de>

Am 23.02.2011 02:43, schrieb Nick Coghlan:
> On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I'm going to perform a Debian upgrade of svn.python.org on Friday,
>> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during
>> that time. The outage shouldn't be longer than an hour.
> 
> This may have caused some issues with the SVN viewer - I'm currently
> getting "code" with no syntax highlighting and all leading whitespace
> stripped when attempting to look at file contents.

The ViewVC configuration has significantly changed, so I originally
tried to adjust the old configuration. I went now the other path of
configuring starting with the new configuration template. I may have
broken things in the process; if so, please let me know. Post the
specific URL that gives troubles.

Regards,
Martin

From g.brandl at gmx.net  Wed Feb 23 08:32:02 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 23 Feb 2011 08:32:02 +0100
Subject: [Python-Dev] r88501 - python/branches/py3k/Lib/smtplib.py
In-Reply-To: <20110222155620.B82D2EE9B5@mail.python.org>
References: <20110222155620.B82D2EE9B5@mail.python.org>
Message-ID: <ik2d74$lpn$1@dough.gmane.org>

You're sure this will not cause tedious conflicts with backports?

Georg

On 22.02.2011 16:56, giampaolo.rodola wrote:
> Author: giampaolo.rodola
> Date: Tue Feb 22 16:56:20 2011
> New Revision: 88501
> 
> Log:
> smtlib.py PEP8 normalization via pep8.py script.
> 
> Modified:
>    python/branches/py3k/Lib/smtplib.py
> 
> Modified: python/branches/py3k/Lib/smtplib.py
> ==============================================================================
> --- python/branches/py3k/Lib/smtplib.py	(original)
> +++ python/branches/py3k/Lib/smtplib.py	Tue Feb 22 16:56:20 2011
> @@ -52,15 +52,15 @@




From g.brandl at gmx.net  Wed Feb 23 08:35:04 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 23 Feb 2011 08:35:04 +0100
Subject: [Python-Dev] r88516 - in python/branches/py3k/Python:
 dynload_aix.c dynload_dl.c dynload_hpux.c dynload_next.c dynload_os2.c
 dynload_shlib.c dynload_win.c importdl.c
In-Reply-To: <20110222231620.1668BEE9A5@mail.python.org>
References: <20110222231620.1668BEE9A5@mail.python.org>
Message-ID: <ik2dcq$lpn$2@dough.gmane.org>

This commit introduced tabs, at least in dynload_dl.c.

Georg

On 23.02.2011 00:16, victor.stinner wrote:
> Author: victor.stinner
> Date: Wed Feb 23 00:16:19 2011
> New Revision: 88516
> 
> Log:
> Issue #3080: Remove unused argument of _PyImport_GetDynLoadFunc()
> 
> The first argument, fqname, was not used.
> 
> Modified:
>    python/branches/py3k/Python/dynload_aix.c
>    python/branches/py3k/Python/dynload_dl.c
>    python/branches/py3k/Python/dynload_hpux.c
>    python/branches/py3k/Python/dynload_next.c
>    python/branches/py3k/Python/dynload_os2.c
>    python/branches/py3k/Python/dynload_shlib.c
>    python/branches/py3k/Python/dynload_win.c
>    python/branches/py3k/Python/importdl.c
> 
> Modified: python/branches/py3k/Python/dynload_aix.c
> ==============================================================================
> --- python/branches/py3k/Python/dynload_aix.c	(original)
> +++ python/branches/py3k/Python/dynload_aix.c	Wed Feb 23 00:16:19 2011
> @@ -154,7 +154,7 @@
>  }
>  
>  
> -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname,
> +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname,
>                                      const char *pathname, FILE *fp)
>  {
>      dl_funcptr p;
> 
> Modified: python/branches/py3k/Python/dynload_dl.c
> ==============================================================================
> --- python/branches/py3k/Python/dynload_dl.c	(original)
> +++ python/branches/py3k/Python/dynload_dl.c	Wed Feb 23 00:16:19 2011
> @@ -16,7 +16,7 @@
>  };
>  
>  
> -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname,
> +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname,
>  				    const char *pathname, FILE *fp)
>  {
>  	char funcname[258];
> 
> Modified: python/branches/py3k/Python/dynload_hpux.c
> ==============================================================================
> --- python/branches/py3k/Python/dynload_hpux.c	(original)
> +++ python/branches/py3k/Python/dynload_hpux.c	Wed Feb 23 00:16:19 2011
> @@ -19,7 +19,7 @@
>      {0, 0}
>  };
>  
> -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname,
> +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname,
>                                      const char *pathname, FILE *fp)
>  {
>      dl_funcptr p;
> 
> Modified: python/branches/py3k/Python/dynload_next.c
> ==============================================================================
> --- python/branches/py3k/Python/dynload_next.c	(original)
> +++ python/branches/py3k/Python/dynload_next.c	Wed Feb 23 00:16:19 2011
> @@ -31,8 +31,8 @@
>  #define LINKOPTIONS NSLINKMODULE_OPTION_BINDNOW| \
>      NSLINKMODULE_OPTION_RETURN_ON_ERROR|NSLINKMODULE_OPTION_PRIVATE
>  #endif
> -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname,
> -                                        const char *pathname, FILE *fp)
> +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname,
> +                                    const char *pathname, FILE *fp)
>  {
>      dl_funcptr p = NULL;
>      char funcname[258];
> 
> Modified: python/branches/py3k/Python/dynload_os2.c
> ==============================================================================
> --- python/branches/py3k/Python/dynload_os2.c	(original)
> +++ python/branches/py3k/Python/dynload_os2.c	Wed Feb 23 00:16:19 2011
> @@ -15,7 +15,7 @@
>      {0, 0}
>  };
>  
> -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname,
> +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname,
>                                      const char *pathname, FILE *fp)
>  {
>      dl_funcptr p;
> 
> Modified: python/branches/py3k/Python/dynload_shlib.c
> ==============================================================================
> --- python/branches/py3k/Python/dynload_shlib.c	(original)
> +++ python/branches/py3k/Python/dynload_shlib.c	Wed Feb 23 00:16:19 2011
> @@ -75,7 +75,7 @@
>  static int nhandles = 0;
>  
>  
> -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname,
> +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname,
>                                      const char *pathname, FILE *fp)
>  {
>      dl_funcptr p;
> 
> Modified: python/branches/py3k/Python/dynload_win.c
> ==============================================================================
> --- python/branches/py3k/Python/dynload_win.c	(original)
> +++ python/branches/py3k/Python/dynload_win.c	Wed Feb 23 00:16:19 2011
> @@ -171,7 +171,7 @@
>      return NULL;
>  }
>  
> -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname,
> +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname,
>                                      const char *pathname, FILE *fp)
>  {
>      dl_funcptr p;
> 
> Modified: python/branches/py3k/Python/importdl.c
> ==============================================================================
> --- python/branches/py3k/Python/importdl.c	(original)
> +++ python/branches/py3k/Python/importdl.c	Wed Feb 23 00:16:19 2011
> @@ -12,8 +12,7 @@
>  
>  #include "importdl.h"
>  
> -extern dl_funcptr _PyImport_GetDynLoadFunc(const char *name,
> -                                           const char *shortname,
> +extern dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname,
>                                             const char *pathname, FILE *fp);
>  
>  
> @@ -48,7 +47,7 @@
>          shortname = lastdot+1;
>      }
>  
> -    p0 = _PyImport_GetDynLoadFunc(name, shortname, pathname, fp);
> +    p0 = _PyImport_GetDynLoadFunc(shortname, pathname, fp);
>      p = (PyObject*(*)(void))p0;
>      if (PyErr_Occurred())
>          goto error;



From victor.stinner at haypocalc.com  Wed Feb 23 12:31:14 2011
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Wed, 23 Feb 2011 12:31:14 +0100
Subject: [Python-Dev] r88516 - in python/branches/py3k/Python:
 dynload_aix.c dynload_dl.c dynload_hpux.c dynload_next.c dynload_os2.c
 dynload_shlib.c dynload_win.c importdl.c
In-Reply-To: <ik2dcq$lpn$2@dough.gmane.org>
References: <20110222231620.1668BEE9A5@mail.python.org>
	<ik2dcq$lpn$2@dough.gmane.org>
Message-ID: <1298460674.30842.0.camel@marge>

Le mercredi 23 f?vrier 2011 ? 08:35 +0100, Georg Brandl a ?crit :
> This commit introduced tabs, at least in dynload_dl.c.

WHAT? No, I didn't introduced new tabs: dynload_dl.c always used tabs.

Anyway, I converted tabs to spaces in r88527.

Victor


From hrvoje.niksic at avl.com  Wed Feb 23 12:30:57 2011
From: hrvoje.niksic at avl.com (Hrvoje Niksic)
Date: Wed, 23 Feb 2011 12:30:57 +0100
Subject: [Python-Dev] %-formatting depracation
In-Reply-To: <20110222230300.46e426f2@pitrou.net>
References: <4D6403D0.4030107@stoneleaf.us>	<AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>	<AANLkTimvEJkNbdPx6MYk9mUQUJhzV4uya1HYL3BALTjh@mail.gmail.com>
	<20110222230300.46e426f2@pitrou.net>
Message-ID: <4D64EFF1.6000009@avl.com>

On 02/22/2011 11:03 PM, Antoine Pitrou wrote:
> I think there are many people still finding %-style more practical for
> simple uses,

It's also a clash of cultures. People coming from a C/Unix background 
typically find %-style format obvious and self-explanatory, while people 
coming from Java/DotNET background feel the same way about {}-style formats.

From eric at trueblade.com  Wed Feb 23 13:10:04 2011
From: eric at trueblade.com (Eric Smith)
Date: Wed, 23 Feb 2011 07:10:04 -0500
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <4D6455B8.309@trueblade.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>	<4D644202.7010505@trueblade.com>	<C12A521E-D2D5-4E51-AF10-EFE235180C6D@holdenweb.com>
	<4D6455B8.309@trueblade.com>
Message-ID: <4D64F91C.8080902@trueblade.com>

On 02/22/2011 07:32 PM, Eric Smith wrote:
> On 2/22/2011 6:28 PM, Steve Holden wrote:
>>
>> On Feb 22, 2011, at 3:08 PM, Eric Smith wrote:
>>
>>> Quoting PEP 3101:
>>>
>>> An example of the 'getitem' syntax:
>>>
>>> "My name is {0[name]}".format(dict(name='Fred'))
>>>
>>> It should be noted that the use of 'getitem' within a format string
>>> is much more limited than its conventional usage. In the above example,
>>> the string 'name' really is the literal string 'name', not a variable
>>> named 'name'. The rules for parsing an item key are very simple.
>>> If it starts with a digit, then it is treated as a number, otherwise
>>> it is used as a string.
>>>
>> That's not strictly true:
>>
>>>>> d = {"Steve":"Holden", "Guido":"van Rossum", 21.2:"float"}
>>>>> d[21.1]
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in<module>
>> KeyError: 21.1
>>>>> d[21.2]
>> 'float'
>>>>> "{0[21.2]}".format(d)
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in<module>
>> KeyError: '21.2'
>>>>>
>
> You are correct, I didn't exactly implement the PEP on this point,
> probably as a shortcut. I think there's an issue somewhere that
> discusses this, but I can't find it. The CPython implementation is
> really using "If every character is a digit, then it is treated as an
> integer, otherwise it is used as a string".
>
> See find_name_split in Objects/stringlib/string_format.h, in particular
> the call to get_integer() and the interpretation of the result.

Just for the archives, I'll mention why it works this way. It's trying 
to support indexing by integers, as well as dictionary access using 
arbitrary keys. Both of course use the same syntax.

In this case it must convert the index values into ints:
 >>> a = ['usr', 'var']
 >>> '{0[0]} {0[1]}'.format(a)
'usr var'

And in this case it doesn't:
 >>> a = {'one':'usr', 'two':'var'}
 >>> '{0[one]} {0[two]}'.format(a)
'usr var'

Eric.

From python-dev at masklinn.net  Wed Feb 23 14:03:08 2011
From: python-dev at masklinn.net (Xavier Morel)
Date: Wed, 23 Feb 2011 14:03:08 +0100
Subject: [Python-Dev] %-formatting depracation
In-Reply-To: <4D64EFF1.6000009@avl.com>
References: <4D6403D0.4030107@stoneleaf.us>	<AANLkTi=0m5fKnex7b+h=LtEqRcV+BsuRVTNitCbkXJ5Z@mail.gmail.com>	<AANLkTimvEJkNbdPx6MYk9mUQUJhzV4uya1HYL3BALTjh@mail.gmail.com>
	<20110222230300.46e426f2@pitrou.net> <4D64EFF1.6000009@avl.com>
Message-ID: <F0C220F2-D937-4DF6-8161-2A7EB9E6EAF8@masklinn.net>

On 2011-02-23, at 12:30 , Hrvoje Niksic wrote:
> On 02/22/2011 11:03 PM, Antoine Pitrou wrote:
>> I think there are many people still finding %-style more practical for
>> simple uses,
> 
> It's also a clash of cultures. People coming from a C/Unix background typically find %-style format obvious and self-explanatory, while people coming from Java/DotNET background feel the same way about {}-style formats.
For Java it's debatable: the Java 5 string formatting APIs are all printf-style (java.io.PrintStream#printf[0], String#format[1], java.util.Formatter[2]).

The older java.text.MessageFormat[3] (still used a lot for property lists as it's built for localization among other things) does use {}-style, though one quite different than Python's.

[0] http://download.oracle.com/javase/1.5.0/docs/api/java/io/PrintStream.html#printf(java.lang.String,%20java.lang.Object...)
[1] http://download.oracle.com/javase/1.5.0/docs/api/java/lang/String.html#format(java.lang.String,%20java.lang.Object?)
[2] http://download.oracle.com/javase/1.5.0/docs/api/java/util/Formatter.html
[3] http://download.oracle.com/javase/1.5.0/docs/api/java/text/MessageFormat.html

From ncoghlan at gmail.com  Wed Feb 23 14:21:02 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Feb 2011 23:21:02 +1000
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <87bp23nvrf.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<87bp23nvrf.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTi=q_e=VY0GmghuK-QGedvL=xnc=rMe1KyZwtdf9@mail.gmail.com>

On Wed, Feb 23, 2011 at 3:51 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Jesus Cea writes:
>
> ?> Every time I read a message from [long, incomplete<wink> list] and
> ?> so many others python-devs (not an exhaustive list, if you are not
> ?> there, you probably should, sorry :), I feel I am faking my
> ?> knowledge of Python :-). I am a pretender :).
>
> Sure. ?I suspect even some of those *on* the list feel that way
> sometimes. ?That's what's so great about the list, the people who
> contribute!

I personally feel that way every time I realise just how much of the
standard library I have never even seriously looked at (let alone
used) and how much more there is to the Python ecosystem than just
CPython (subscribing to Planet Python and the python tag on Stack
Overflow has been truly eye opening in that regard).

Heck, some day I may even get around to learning how to build a proper
Python package ;)

Cheers,
Nick.

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

From ncoghlan at gmail.com  Wed Feb 23 14:26:13 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Feb 2011 23:26:13 +1000
Subject: [Python-Dev] svn outage on Friday
In-Reply-To: <4D64A79B.8040607@v.loewis.de>
References: <4D5A3990.4040902@v.loewis.de>
	<AANLkTi=aCs3RGuVOhDqknGeqO5jp06OfG2djKyem1qRq@mail.gmail.com>
	<4D64A79B.8040607@v.loewis.de>
Message-ID: <AANLkTi=PSiXZbc-7-gymneSO0zns977+HybDEdpkJvh-@mail.gmail.com>

On Wed, Feb 23, 2011 at 4:22 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> The ViewVC configuration has significantly changed, so I originally
> tried to adjust the old configuration. I went now the other path of
> configuring starting with the new configuration template. I may have
> broken things in the process; if so, please let me know. Post the
> specific URL that gives troubles.

Seems to be OK now when checking from my home machine - I'll check the
misbehaving box again tomorrow.

Cheers,
Nick.

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

From ncoghlan at gmail.com  Wed Feb 23 14:42:21 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 23 Feb 2011 23:42:21 +1000
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <AANLkTikNwqsroCkhenp-RWEbk=B4Bqeef+4=VBKhG_u+@mail.gmail.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>
	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
	<AANLkTinN0z80Y245A6AwMBJCCxLqqztJiUajeKQS2Y5b@mail.gmail.com>
	<AANLkTikNwqsroCkhenp-RWEbk=B4Bqeef+4=VBKhG_u+@mail.gmail.com>
Message-ID: <AANLkTimPxkyX3NGzfKNef2DgD_exfu8CgX+6nwXiPt_=@mail.gmail.com>

On Wed, Feb 23, 2011 at 9:32 AM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> """
> Because keys are not quote-delimited, it is not possible to
> ? ?specify arbitrary dictionary keys (e.g., the strings "10" or
> ? ?":-]") from within a format string.
> """

I was curious as to whether or not nested substitution could be used
to avoid that limitation, but it would seem not:

>>> "{0[{1}]}".format(d, 21.2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: '{1}'

Turns out that was also a deliberate design choice:

"""
These 'internal' replacement fields can only occur in the format
specifier part of the replacement field.  Internal replacement fields
cannot themselves have format specifiers.  This implies also that
replacement fields cannot be nested to arbitrary levels.
"""

Ah, how (much more) confused would we be if we didn't have the PEPs
and mailing list archives to remind ourselves of what we were thinking
years ago...

Cheers,
Nick.

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

From rdmurray at bitdance.com  Wed Feb 23 15:42:45 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 23 Feb 2011 09:42:45 -0500
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <4D6455B8.309@trueblade.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>
	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
	<4D644202.7010505@trueblade.com>
	<C12A521E-D2D5-4E51-AF10-EFE235180C6D@holdenweb.com>
	<4D6455B8.309@trueblade.com>
Message-ID: <20110223144245.108E82371B2@kimball.webabinitio.net>

On Tue, 22 Feb 2011 19:32:56 -0500, Eric Smith <eric at trueblade.com> wrote:
> You are correct, I didn't exactly implement the PEP on this point, 
> probably as a shortcut. I think there's an issue somewhere that 
> discusses this, but I can't find it. The CPython implementation is 
> really using "If every character is a digit, then it is treated as an 
> integer, otherwise it is used as a string".

Perhaps you are thinking of http://bugs.python.org/issue7951.  Not
directly on point, but related.

--
R. David Murray                                      www.bitdance.com

From solipsis at pitrou.net  Wed Feb 23 16:58:55 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Feb 2011 16:58:55 +0100
Subject: [Python-Dev] Link to issue tracker
Message-ID: <20110223165855.10d63be9@pitrou.net>


Hello,

I think it was a slight mistake to remove the link to the issue tracker
from the sidebar in the "core development" section. Dave Beazley just
complained about it
(http://twitter.com/dabeaz/status/40397577916661760) and I think it
will probably confuse other people too. Could we add it back ?

cheers

Antoine.



From eric at trueblade.com  Wed Feb 23 17:01:38 2011
From: eric at trueblade.com (Eric Smith)
Date: Wed, 23 Feb 2011 11:01:38 -0500
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <20110223144245.108E82371B2@kimball.webabinitio.net>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>	<4D644202.7010505@trueblade.com>	<C12A521E-D2D5-4E51-AF10-EFE235180C6D@holdenweb.com>	<4D6455B8.309@trueblade.com>
	<20110223144245.108E82371B2@kimball.webabinitio.net>
Message-ID: <4D652F62.5000708@trueblade.com>

On 02/23/2011 09:42 AM, R. David Murray wrote:
> On Tue, 22 Feb 2011 19:32:56 -0500, Eric Smith<eric at trueblade.com>  wrote:
>> You are correct, I didn't exactly implement the PEP on this point,
>> probably as a shortcut. I think there's an issue somewhere that
>> discusses this, but I can't find it. The CPython implementation is
>> really using "If every character is a digit, then it is treated as an
>> integer, otherwise it is used as a string".
>
> Perhaps you are thinking of http://bugs.python.org/issue7951.  Not
> directly on point, but related.

Yes, that's the one I was thinking of. Thanks, David.

I'm not sure I agree with all of the points raised there, but it does 
some additional background on the issue.

From g.rodola at gmail.com  Wed Feb 23 18:18:05 2011
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Wed, 23 Feb 2011 18:18:05 +0100
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <20110223165855.10d63be9@pitrou.net>
References: <20110223165855.10d63be9@pitrou.net>
Message-ID: <AANLkTimdwcxC-yikOzXST3z5TiE0mLAV24tATUKwaWHZ@mail.gmail.com>

+1, I often use that link as well.

2011/2/23 Antoine Pitrou <solipsis at pitrou.net>:
>
> Hello,
>
> I think it was a slight mistake to remove the link to the issue tracker
> from the sidebar in the "core development" section. Dave Beazley just
> complained about it
> (http://twitter.com/dabeaz/status/40397577916661760) and I think it
> will probably confuse other people too. Could we add it back ?
>
> 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/g.rodola%40gmail.com
>

From steve at holdenweb.com  Wed Feb 23 19:02:47 2011
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 23 Feb 2011 10:02:47 -0800
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <AANLkTimPxkyX3NGzfKNef2DgD_exfu8CgX+6nwXiPt_=@mail.gmail.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>
	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
	<AANLkTinN0z80Y245A6AwMBJCCxLqqztJiUajeKQS2Y5b@mail.gmail.com>
	<AANLkTikNwqsroCkhenp-RWEbk=B4Bqeef+4=VBKhG_u+@mail.gmail.com>
	<AANLkTimPxkyX3NGzfKNef2DgD_exfu8CgX+6nwXiPt_=@mail.gmail.com>
Message-ID: <4B891A59-7AB5-4867-AFE9-3EA356A3CE7D@holdenweb.com>

On Feb 23, 2011, at 5:42 AM, Nick Coghlan wrote:

> Ah, how (much more) confused would we be if we didn't have the PEPs
> and mailing list archives to remind ourselves of what we were thinking
> years ago...
> 
True. And how much more useful it would be if it were incorporated into the documentation after implementation. Too much of the format() stuff is demonstrated rather than explained.

regards
 Steve


From ethan at stoneleaf.us  Wed Feb 23 19:18:58 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 23 Feb 2011 10:18:58 -0800
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <4D6455B8.309@trueblade.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>	<4D644202.7010505@trueblade.com>	<C12A521E-D2D5-4E51-AF10-EFE235180C6D@holdenweb.com>
	<4D6455B8.309@trueblade.com>
Message-ID: <4D654F92.90006@stoneleaf.us>

Eric Smith wrote:
> On 2/22/2011 6:28 PM, Steve Holden wrote:
>> On Feb 22, 2011, at 3:08 PM, Eric Smith wrote:
>>> Quoting PEP 3101:
>>>
>>> An example of the 'getitem' syntax:
>>>
>>>         "My name is {0[name]}".format(dict(name='Fred'))
>>>
>>> It should be noted that the use of 'getitem' within a format string
>>> is much more limited than its conventional usage.  In the above example,
>>> the string 'name' really is the literal string 'name', not a variable
>>> named 'name'.  The rules for parsing an item key are very simple.
>>> If it starts with a digit, then it is treated as a number, otherwise
>>> it is used as a string.
>>>
>> That's not strictly true:
>>
>>--> d = {"Steve":"Holden", "Guido":"van Rossum", 21.2:"float"}
>>--> d[21.1]
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in<module>
>> KeyError: 21.1
>>--> d[21.2]
>> 'float'
>>--> "{0[21.2]}".format(d)
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in<module>
>> KeyError: '21.2'
>>
> 
> You are correct, I didn't exactly implement the PEP on this point, 
> probably as a shortcut. I think there's an issue somewhere that 
> discusses this, but I can't find it. The CPython implementation is 
> really using "If every character is a digit, then it is treated as an 
> integer, otherwise it is used as a string".

Given the representation issues with floating point, I think the current 
behavior is desirable.  Also, leaving digits with periods as strings 
would, I think, be more useful (Dewey Decimal, anyone?).

~Ethan~

From eric at trueblade.com  Wed Feb 23 19:18:40 2011
From: eric at trueblade.com (Eric Smith)
Date: Wed, 23 Feb 2011 13:18:40 -0500 (EST)
Subject: [Python-Dev] Fwd: deep question re dict as formatting input
In-Reply-To: <4B891A59-7AB5-4867-AFE9-3EA356A3CE7D@holdenweb.com>
References: <AANLkTikU0xw3KiYonuGsj+yPKDpZLx5EvnGFgUOtajRt@mail.gmail.com>
	<B149E56E-5FF8-48CD-914E-7A7CD7E7092A@holdenweb.com>
	<AANLkTinN0z80Y245A6AwMBJCCxLqqztJiUajeKQS2Y5b@mail.gmail.com>
	<AANLkTikNwqsroCkhenp-RWEbk=B4Bqeef+4=VBKhG_u+@mail.gmail.com>
	<AANLkTimPxkyX3NGzfKNef2DgD_exfu8CgX+6nwXiPt_=@mail.gmail.com>
	<4B891A59-7AB5-4867-AFE9-3EA356A3CE7D@holdenweb.com>
Message-ID: <974ee64aafc02e1dff6a4949c4734af4.squirrel@mail.trueblade.com>

> On Feb 23, 2011, at 5:42 AM, Nick Coghlan wrote:
>
>> Ah, how (much more) confused would we be if we didn't have the PEPs
>> and mailing list archives to remind ourselves of what we were thinking
>> years ago...
>>
> True. And how much more useful it would be if it were incorporated into
> the documentation after implementation. Too much of the format() stuff is
> demonstrated rather than explained.

I think the documentation team has been pretty good about responding to
format() issues that have been brought up in the bug tracker.

Eric.



From tjreedy at udel.edu  Wed Feb 23 19:42:22 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 23 Feb 2011 13:42:22 -0500
Subject: [Python-Dev] 3.2.0 == 20th anniversary release
Message-ID: <ik3kee$kvf$1@dough.gmane.org>

As pointed out by Ramiro Morales on the Python-Argentina list
(quoting Guido's blog post
http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html
)
Python 0.9.0 was released on 20 Feb 1991

Python 3.2.0 was released on 20 Feb 2011

Python's come a long way.
I look forward to the next 20.

-- 
Terry Jan Reedy


From brett at python.org  Wed Feb 23 19:30:54 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 10:30:54 -0800
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <20110223165855.10d63be9@pitrou.net>
References: <20110223165855.10d63be9@pitrou.net>
Message-ID: <AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>

I won't add the link back, but I will try to change the global link on the
website to point to the devguide. python.org/dev/ at this point exists
purely to not break pre-existing links.

On Wed, Feb 23, 2011 at 07:58, Antoine Pitrou <solipsis at pitrou.net> wrote:

>
> Hello,
>
> I think it was a slight mistake to remove the link to the issue tracker
> from the sidebar in the "core development" section. Dave Beazley just
> complained about it
> (http://twitter.com/dabeaz/status/40397577916661760) and I think it
> will probably confuse other people too. Could we add it back ?
>
> 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/20110223/b386e7a7/attachment.html>

From guido at python.org  Wed Feb 23 19:51:21 2011
From: guido at python.org (Guido van Rossum)
Date: Wed, 23 Feb 2011 10:51:21 -0800
Subject: [Python-Dev] 3.2.0 == 20th anniversary release
In-Reply-To: <ik3kee$kvf$1@dough.gmane.org>
References: <ik3kee$kvf$1@dough.gmane.org>
Message-ID: <AANLkTi=6DmdJcKP7hF=ek_eV66ZAESVuB8YZDfWRFsb7@mail.gmail.com>

On Wed, Feb 23, 2011 at 10:42 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> As pointed out by Ramiro Morales on the Python-Argentina list
> (quoting Guido's blog post
> http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html
> )
> Python 0.9.0 was released on 20 Feb 1991
>
> Python 3.2.0 was released on 20 Feb 2011
>
> Python's come a long way.
> I look forward to the next 20.

Me too!

BTW very nice of Georg to time it this way.

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

From solipsis at pitrou.net  Wed Feb 23 19:52:05 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Feb 2011 19:52:05 +0100
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
Message-ID: <20110223195205.5bb428e8@pitrou.net>

On Wed, 23 Feb 2011 10:30:54 -0800
Brett Cannon <brett at python.org> wrote:
> I won't add the link back, but I will try to change the global link on the
> website to point to the devguide. python.org/dev/ at this point exists
> purely to not break pre-existing links.

There are items there that are out of scope for the dev guide
(e.g. "Python.org Maintenance and Administration").
Also, I do believe that being able to report a bug immediately is very
important. Reporting a bug doesn't mean you want to contribute code; it
just means you've found an issue and would like the community to know
(and possibly fix it).

Regards

Antoine.

From brett at python.org  Wed Feb 23 19:52:04 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 10:52:04 -0800
Subject: [Python-Dev] [Python-checkins] r88503 - in
 python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3
In-Reply-To: <AANLkTimmsW-_G-sRoon1BrG_rs_5DtVBtAH8DaDOJ_V2@mail.gmail.com>
References: <20110222191243.810C3F634@mail.python.org>
	<AANLkTimmsW-_G-sRoon1BrG_rs_5DtVBtAH8DaDOJ_V2@mail.gmail.com>
Message-ID: <AANLkTikV5UjyKn8sEyxJQExDNYj0Neq5h1Qc+L0DHSF9@mail.gmail.com>

I assume you are having me do this because you still plan to cut separate
releases. Is there a minimum Python version that needs to be supported?

On Tue, Feb 22, 2011 at 18:23, Benjamin Peterson <benjamin at python.org>wrote:

> 2011/2/22 brett.cannon <python-checkins at python.org>:
> > Author: brett.cannon
> > Date: Tue Feb 22 20:12:43 2011
> > New Revision: 88503
> >
> > Log:
> > Add lib2to3.__main__ to make it easier for debugging purposes to run
> 2to3.
>
> Please revert this and do it in the sandbox.
>
> >
> > Added:
> >   python/branches/py3k/Lib/lib2to3/__main__.py
> > Modified:
> >   python/branches/py3k/Tools/scripts/2to3
> >
> > Added: python/branches/py3k/Lib/lib2to3/__main__.py
> >
> ==============================================================================
> > --- (empty file)
> > +++ python/branches/py3k/Lib/lib2to3/__main__.py        Tue Feb 22
> 20:12:43 2011
> > @@ -0,0 +1,4 @@
> > +import sys
> > +from .main import main
> > +
> > +sys.exit(main("lib2to3.fixes"))
> >
> > Modified: python/branches/py3k/Tools/scripts/2to3
> >
> ==============================================================================
> > --- python/branches/py3k/Tools/scripts/2to3     (original)
> > +++ python/branches/py3k/Tools/scripts/2to3     Tue Feb 22 20:12:43 2011
> > @@ -1,5 +1,4 @@
> >  #!/usr/bin/env python
> > -import sys
> > -from lib2to3.main import main
> > +import runpy
> >
> > -sys.exit(main("lib2to3.fixes"))
> > +runpy.run_module('lib2to3', run_name='__main__', alter_sys=True)
> > _______________________________________________
> > Python-checkins mailing list
> > Python-checkins at python.org
> > http://mail.python.org/mailman/listinfo/python-checkins
> >
>
>
>
> --
> Regards,
> Benjamin
> _______________________________________________
> 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/20110223/512b9e39/attachment.html>

From g.brandl at gmx.net  Wed Feb 23 20:11:46 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 23 Feb 2011 20:11:46 +0100
Subject: [Python-Dev] 3.2.0 == 20th anniversary release
In-Reply-To: <AANLkTi=6DmdJcKP7hF=ek_eV66ZAESVuB8YZDfWRFsb7@mail.gmail.com>
References: <ik3kee$kvf$1@dough.gmane.org>
	<AANLkTi=6DmdJcKP7hF=ek_eV66ZAESVuB8YZDfWRFsb7@mail.gmail.com>
Message-ID: <ik3m72$uk6$1@dough.gmane.org>

On 23.02.2011 19:51, Guido van Rossum wrote:
> On Wed, Feb 23, 2011 at 10:42 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>> As pointed out by Ramiro Morales on the Python-Argentina list
>> (quoting Guido's blog post
>> http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html
>> )
>> Python 0.9.0 was released on 20 Feb 1991
>>
>> Python 3.2.0 was released on 20 Feb 2011
>>
>> Python's come a long way.
>> I look forward to the next 20.
> 
> Me too!
> 
> BTW very nice of Georg to time it this way.

As much as I'd like to claim it, it's pure coincidence where my
planning is concerned.  I knew that Python 0.9 was in 1991, so I
knew about 20 years, but not about the exact date.  Very nice!

Maybe it was a subconscious thing :)

cheers,
Georg



From alexander.belopolsky at gmail.com  Wed Feb 23 20:16:24 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 14:16:24 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D648E63.2050106@jcea.es>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
Message-ID: <AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>

On Tue, Feb 22, 2011 at 11:34 PM, Jesus Cea <jcea at jcea.es> wrote:
..
> Issue filed. It already has a patch. That was fast!. Now I can sit back
> waiting for 3.2.1 before touching my project again :). Mixed feelings
> about the waiting. I hope it is short.

It looks like you don't need delay your project: if you spell encoding
as "latin-1", your pickle loads just fine:


>>> with open("z.pickle", mode="rb") as f: pickle.load(f, encoding="latin-1")
...
{'ya_volcados': {'comment': ''}}


With encoding="latin1", it does fail:

>>> with open("z.pickle", mode="rb") as f: pickle.load(f, encoding="latin1")
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: operation forbidden on released memoryview object

(For those not following the tracker issue, the z.pickle file was
posted at <http://bugs.python.org/file20839/z.pickle>.)

There is still a bug, which is best demonstrated by

>>> pickle.loads(b'\x80\x02U\x00.', encoding='latin1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: operation forbidden on released memoryview object

The fact that the above works with encoding='latin-1',

>>> pickle.loads(b'\x80\x02U\x00.', encoding='latin-1')
''

shows that there is probably more than one bug.

From brett at python.org  Wed Feb 23 20:21:58 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 11:21:58 -0800
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <20110223195205.5bb428e8@pitrou.net>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<20110223195205.5bb428e8@pitrou.net>
Message-ID: <AANLkTinkoPtxJi9gfeKNLfzQtTrN4QdaPD8YvmR=r7fU@mail.gmail.com>

On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Wed, 23 Feb 2011 10:30:54 -0800
> Brett Cannon <brett at python.org> wrote:
> > I won't add the link back, but I will try to change the global link on
> the
> > website to point to the devguide. python.org/dev/ at this point exists
> > purely to not break pre-existing links.
>
> There are items there that are out of scope for the dev guide
> (e.g. "Python.org Maintenance and Administration").
> Also, I do believe that being able to report a bug immediately is very
> important. Reporting a bug doesn't mean you want to contribute code; it
> just means you've found an issue and would like the community to know
> (and possibly fix it).
>

Those are all linked from the devguide in the Resources section. IOW that
sidebar is in the index doc already.


>
> 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/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110223/bf1b20dd/attachment.html>

From benjamin at python.org  Wed Feb 23 20:36:51 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 23 Feb 2011 13:36:51 -0600
Subject: [Python-Dev] 3.2.0 == 20th anniversary release
In-Reply-To: <ik3m72$uk6$1@dough.gmane.org>
References: <ik3kee$kvf$1@dough.gmane.org>
	<AANLkTi=6DmdJcKP7hF=ek_eV66ZAESVuB8YZDfWRFsb7@mail.gmail.com>
	<ik3m72$uk6$1@dough.gmane.org>
Message-ID: <AANLkTi=OLJ+rHoE9mKhVGgK4xjFhj5CCFgrVeBSwbPUV@mail.gmail.com>

2011/2/23 Georg Brandl <g.brandl at gmx.net>:
> On 23.02.2011 19:51, Guido van Rossum wrote:
>> On Wed, Feb 23, 2011 at 10:42 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>>> As pointed out by Ramiro Morales on the Python-Argentina list
>>> (quoting Guido's blog post
>>> http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html
>>> )
>>> Python 0.9.0 was released on 20 Feb 1991
>>>
>>> Python 3.2.0 was released on 20 Feb 2011
>>>
>>> Python's come a long way.
>>> I look forward to the next 20.
>>
>> Me too!
>>
>> BTW very nice of Georg to time it this way.
>
> As much as I'd like to claim it, it's pure coincidence where my
> planning is concerned. ?I knew that Python 0.9 was in 1991, so I
> knew about 20 years, but not about the exact date. ?Very nice!
>
> Maybe it was a subconscious thing :)

Or you realized later how nice it would be, grabbed the time machine,
and fixed 10 release blockers on the 19th. :)


-- 
Regards,
Benjamin

From benjamin at python.org  Wed Feb 23 20:38:05 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 23 Feb 2011 13:38:05 -0600
Subject: [Python-Dev] [Python-checkins] r88503 - in
 python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3
In-Reply-To: <AANLkTikV5UjyKn8sEyxJQExDNYj0Neq5h1Qc+L0DHSF9@mail.gmail.com>
References: <20110222191243.810C3F634@mail.python.org>
	<AANLkTimmsW-_G-sRoon1BrG_rs_5DtVBtAH8DaDOJ_V2@mail.gmail.com>
	<AANLkTikV5UjyKn8sEyxJQExDNYj0Neq5h1Qc+L0DHSF9@mail.gmail.com>
Message-ID: <AANLkTim1CH7Y3MJZj5JWQzntG-FOXi90wMPJrJmgZe3B@mail.gmail.com>

2011/2/23 Brett Cannon <brett at python.org>:
> I assume you are having me do this because you still plan to cut separate
> releases. Is there a minimum Python version that needs to be supported?

2.5 but that's only for benchmarking purposes IIRC.



-- 
Regards,
Benjamin

From brett at python.org  Wed Feb 23 20:41:20 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 11:41:20 -0800
Subject: [Python-Dev] [Python-checkins] r88503 - in
 python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3
In-Reply-To: <AANLkTim1CH7Y3MJZj5JWQzntG-FOXi90wMPJrJmgZe3B@mail.gmail.com>
References: <20110222191243.810C3F634@mail.python.org>
	<AANLkTimmsW-_G-sRoon1BrG_rs_5DtVBtAH8DaDOJ_V2@mail.gmail.com>
	<AANLkTikV5UjyKn8sEyxJQExDNYj0Neq5h1Qc+L0DHSF9@mail.gmail.com>
	<AANLkTim1CH7Y3MJZj5JWQzntG-FOXi90wMPJrJmgZe3B@mail.gmail.com>
Message-ID: <AANLkTikdzKUubAvfv7i9ZEhgWT5KGJHGjg-QwagoSb+i@mail.gmail.com>

Does the benchmarking use the 2to3 script? I'm asking because package
execution is not supported that far back.

On Wed, Feb 23, 2011 at 11:38, Benjamin Peterson <benjamin at python.org>wrote:

> 2011/2/23 Brett Cannon <brett at python.org>:
> > I assume you are having me do this because you still plan to cut separate
> > releases. Is there a minimum Python version that needs to be supported?
>
> 2.5 but that's only for benchmarking purposes IIRC.
>
>
>
> --
> Regards,
> Benjamin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110223/19a8fcd2/attachment-0001.html>

From benjamin at python.org  Wed Feb 23 20:42:58 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 23 Feb 2011 13:42:58 -0600
Subject: [Python-Dev] [Python-checkins] r88503 - in
 python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3
In-Reply-To: <AANLkTikdzKUubAvfv7i9ZEhgWT5KGJHGjg-QwagoSb+i@mail.gmail.com>
References: <20110222191243.810C3F634@mail.python.org>
	<AANLkTimmsW-_G-sRoon1BrG_rs_5DtVBtAH8DaDOJ_V2@mail.gmail.com>
	<AANLkTikV5UjyKn8sEyxJQExDNYj0Neq5h1Qc+L0DHSF9@mail.gmail.com>
	<AANLkTim1CH7Y3MJZj5JWQzntG-FOXi90wMPJrJmgZe3B@mail.gmail.com>
	<AANLkTikdzKUubAvfv7i9ZEhgWT5KGJHGjg-QwagoSb+i@mail.gmail.com>
Message-ID: <AANLkTi=JgMkkmbAYphRRFfQwXdMWGb13k5ojz84kMiT7@mail.gmail.com>

2011/2/23 Brett Cannon <brett at python.org>:
> Does the benchmarking use the 2to3 script? I'm asking because package
> execution is not supported that far back.

Correct. But I suppose, it wouldn't really be harmful to add __main__.
Just a no-op.



-- 
Regards,
Benjamin

From martin at v.loewis.de  Wed Feb 23 20:43:02 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 23 Feb 2011 20:43:02 +0100
Subject: [Python-Dev] 3.2.0 == 20th anniversary release
In-Reply-To: <AANLkTi=OLJ+rHoE9mKhVGgK4xjFhj5CCFgrVeBSwbPUV@mail.gmail.com>
References: <ik3kee$kvf$1@dough.gmane.org>	<AANLkTi=6DmdJcKP7hF=ek_eV66ZAESVuB8YZDfWRFsb7@mail.gmail.com>	<ik3m72$uk6$1@dough.gmane.org>
	<AANLkTi=OLJ+rHoE9mKhVGgK4xjFhj5CCFgrVeBSwbPUV@mail.gmail.com>
Message-ID: <4D656346.901@v.loewis.de>

> Or you realized later how nice it would be, grabbed the time machine,
> and fixed 10 release blockers on the 19th. :)

No no no. He actually grabbed the time machine, drove 20 years back,
and gave it to Guido so he could release Python 0.9 in time. Guido
then kept the machine ever since.

Regards,
Martin

From martin at v.loewis.de  Wed Feb 23 20:52:16 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 23 Feb 2011 20:52:16 +0100
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
Message-ID: <4D656570.1010002@v.loewis.de>

Am 23.02.2011 19:30, schrieb Brett Cannon:
> I won't add the link back

Why not? It's a useful link apparently. The "Developer's Guide"
link does not hint that it will be the only way to find the
bug tracker.

It's like adding the download page at the end of the tutorial -
"you can get Python only if you read through this".

Regards,
Martin

From solipsis at pitrou.net  Wed Feb 23 20:53:40 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Feb 2011 20:53:40 +0100
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <AANLkTinkoPtxJi9gfeKNLfzQtTrN4QdaPD8YvmR=r7fU@mail.gmail.com>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<20110223195205.5bb428e8@pitrou.net>
	<AANLkTinkoPtxJi9gfeKNLfzQtTrN4QdaPD8YvmR=r7fU@mail.gmail.com>
Message-ID: <20110223205340.0b7276ce@pitrou.net>

On Wed, 23 Feb 2011 11:21:58 -0800
Brett Cannon <brett at python.org> wrote:
> On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 
> > On Wed, 23 Feb 2011 10:30:54 -0800
> > Brett Cannon <brett at python.org> wrote:
> > > I won't add the link back, but I will try to change the global link on
> > the
> > > website to point to the devguide. python.org/dev/ at this point exists
> > > purely to not break pre-existing links.
> >
> > There are items there that are out of scope for the dev guide
> > (e.g. "Python.org Maintenance and Administration").
> > Also, I do believe that being able to report a bug immediately is very
> > important. Reporting a bug doesn't mean you want to contribute code; it
> > just means you've found an issue and would like the community to know
> > (and possibly fix it).
> >
> 
> Those are all linked from the devguide in the Resources section. IOW that
> sidebar is in the index doc already.

Yes, but I think it would be better if that link was more proeminent,
either on python.org, or in the devguide. Currently it has become much
less visible (you have to scroll down a page or two and hunt it in that
section named "resources", assuming you know it is there at all).

Of course, the Web site in general is not that good at presenting
useful information first ;)

Regards

Antoine.

From barry at python.org  Wed Feb 23 20:54:40 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Feb 2011 14:54:40 -0500
Subject: [Python-Dev] 3.2.0 == 20th anniversary release
In-Reply-To: <4D656346.901@v.loewis.de>
References: <ik3kee$kvf$1@dough.gmane.org>
	<AANLkTi=6DmdJcKP7hF=ek_eV66ZAESVuB8YZDfWRFsb7@mail.gmail.com>
	<ik3m72$uk6$1@dough.gmane.org>
	<AANLkTi=OLJ+rHoE9mKhVGgK4xjFhj5CCFgrVeBSwbPUV@mail.gmail.com>
	<4D656346.901@v.loewis.de>
Message-ID: <20110223145440.54515df7@python.org>

On Feb 23, 2011, at 08:43 PM, Martin v. L?wis wrote:

>> Or you realized later how nice it would be, grabbed the time machine,
>> and fixed 10 release blockers on the 19th. :)
>
>No no no. He actually grabbed the time machine, drove 20 years back,
>and gave it to Guido so he could release Python 0.9 in time. Guido
>then kept the machine ever since.

Keanu Reeves should definitely play Guido.  I guess that means Alex Winter
gets to play Georg.

-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/20110223/4503730f/attachment.pgp>

From g.brandl at gmx.net  Wed Feb 23 20:55:11 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 23 Feb 2011 20:55:11 +0100
Subject: [Python-Dev] r88516 - in python/branches/py3k/Python:
 dynload_aix.c dynload_dl.c dynload_hpux.c dynload_next.c dynload_os2.c
 dynload_shlib.c dynload_win.c importdl.c
In-Reply-To: <1298460674.30842.0.camel@marge>
References: <20110222231620.1668BEE9A5@mail.python.org>
	<ik2dcq$lpn$2@dough.gmane.org> <1298460674.30842.0.camel@marge>
Message-ID: <ik3oof$hed$1@dough.gmane.org>

On 23.02.2011 12:31, Victor Stinner wrote:
> Le mercredi 23 f?vrier 2011 ? 08:35 +0100, Georg Brandl a ?crit :
>> This commit introduced tabs, at least in dynload_dl.c.
> 
> WHAT? No, I didn't introduced new tabs: dynload_dl.c always used tabs.

Oh, sorry then: I thought the whole codebase had been converted.  But
apparently, some Gaulish villages resisted :)

Georg


From brett at python.org  Wed Feb 23 21:06:43 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 12:06:43 -0800
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <20110223205340.0b7276ce@pitrou.net>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<20110223195205.5bb428e8@pitrou.net>
	<AANLkTinkoPtxJi9gfeKNLfzQtTrN4QdaPD8YvmR=r7fU@mail.gmail.com>
	<20110223205340.0b7276ce@pitrou.net>
Message-ID: <AANLkTi=PngGjRMEg7jRR19jzGzdseAxJBbi2SkAYQmCq@mail.gmail.com>

On Wed, Feb 23, 2011 at 11:53, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Wed, 23 Feb 2011 11:21:58 -0800
> Brett Cannon <brett at python.org> wrote:
> > On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> >
> > > On Wed, 23 Feb 2011 10:30:54 -0800
> > > Brett Cannon <brett at python.org> wrote:
> > > > I won't add the link back, but I will try to change the global link
> on
> > > the
> > > > website to point to the devguide. python.org/dev/ at this point
> exists
> > > > purely to not break pre-existing links.
> > >
> > > There are items there that are out of scope for the dev guide
> > > (e.g. "Python.org Maintenance and Administration").
> > > Also, I do believe that being able to report a bug immediately is very
> > > important. Reporting a bug doesn't mean you want to contribute code; it
> > > just means you've found an issue and would like the community to know
> > > (and possibly fix it).
> > >
> >
> > Those are all linked from the devguide in the Resources section. IOW that
> > sidebar is in the index doc already.
>
> Yes, but I think it would be better if that link was more proeminent,
> either on python.org, or in the devguide. Currently it has become much
> less visible (you have to scroll down a page or two and hunt it in that
> section named "resources", assuming you know it is there at all).
>

The Resources section can move up the page, or at least the issue tracker
link. We are not talking about a page that is hard to edit (unlike
python.org).

-Brett


>
> Of course, the Web site in general is not that good at presenting
> useful information first ;)
>
> 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/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110223/8237f813/attachment.html>

From brett at python.org  Wed Feb 23 21:05:49 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 12:05:49 -0800
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <4D656570.1010002@v.loewis.de>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<4D656570.1010002@v.loewis.de>
Message-ID: <AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>

On Wed, Feb 23, 2011 at 11:52, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> Am 23.02.2011 19:30, schrieb Brett Cannon:
> > I won't add the link back
>
> Why not? It's a useful link apparently. The "Developer's Guide"
> link does not hint that it will be the only way to find the
> bug tracker.
>

But python.org/dev/ is a dead page. I was trying to avoid adding a redirect
for python.org/dev/ as I was afraid that it would lead to the website doing
something silly like redirecting everything below that URL, but obviously
this can continue since people seem to think that python.org/dev/ has
anything useful on it (which it does not).

-Brett


>
> It's like adding the download page at the end of the tutorial -
> "you can get Python only if you read through this".
>
> Regards,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110223/b316700a/attachment.html>

From brett at python.org  Wed Feb 23 21:18:41 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 12:18:41 -0800
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <AANLkTi=PngGjRMEg7jRR19jzGzdseAxJBbi2SkAYQmCq@mail.gmail.com>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<20110223195205.5bb428e8@pitrou.net>
	<AANLkTinkoPtxJi9gfeKNLfzQtTrN4QdaPD8YvmR=r7fU@mail.gmail.com>
	<20110223205340.0b7276ce@pitrou.net>
	<AANLkTi=PngGjRMEg7jRR19jzGzdseAxJBbi2SkAYQmCq@mail.gmail.com>
Message-ID: <AANLkTimE+4-x3-HxPjRf+dhUASpDdey+aqxRowD-awPu@mail.gmail.com>

I just added a Quick Links section to the devguide at the very top which is
short and to the point. I also committed to pydotorg for python.org/dev/ to
redirect to docs.python.org/devguide/, so this whole discussion is dealt
with IMO.

On Wed, Feb 23, 2011 at 12:06, Brett Cannon <brett at python.org> wrote:

>
>
> On Wed, Feb 23, 2011 at 11:53, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
>> On Wed, 23 Feb 2011 11:21:58 -0800
>> Brett Cannon <brett at python.org> wrote:
>> > On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou <solipsis at pitrou.net>
>> wrote:
>> >
>> > > On Wed, 23 Feb 2011 10:30:54 -0800
>> > > Brett Cannon <brett at python.org> wrote:
>> > > > I won't add the link back, but I will try to change the global link
>> on
>> > > the
>> > > > website to point to the devguide. python.org/dev/ at this point
>> exists
>> > > > purely to not break pre-existing links.
>> > >
>> > > There are items there that are out of scope for the dev guide
>> > > (e.g. "Python.org Maintenance and Administration").
>> > > Also, I do believe that being able to report a bug immediately is very
>> > > important. Reporting a bug doesn't mean you want to contribute code;
>> it
>> > > just means you've found an issue and would like the community to know
>> > > (and possibly fix it).
>> > >
>> >
>> > Those are all linked from the devguide in the Resources section. IOW
>> that
>> > sidebar is in the index doc already.
>>
>> Yes, but I think it would be better if that link was more proeminent,
>> either on python.org, or in the devguide. Currently it has become much
>> less visible (you have to scroll down a page or two and hunt it in that
>> section named "resources", assuming you know it is there at all).
>>
>
> The Resources section can move up the page, or at least the issue tracker
> link. We are not talking about a page that is hard to edit (unlike
> python.org).
>
> -Brett
>
>
>>
>> Of course, the Web site in general is not that good at presenting
>> useful information first ;)
>>
>> 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/brett%40python.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110223/b6dbda7e/attachment.html>

From g.brandl at gmx.net  Wed Feb 23 21:30:20 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 23 Feb 2011 21:30:20 +0100
Subject: [Python-Dev] 3.2.0 == 20th anniversary release
In-Reply-To: <4D656346.901@v.loewis.de>
References: <ik3kee$kvf$1@dough.gmane.org>	<AANLkTi=6DmdJcKP7hF=ek_eV66ZAESVuB8YZDfWRFsb7@mail.gmail.com>	<ik3m72$uk6$1@dough.gmane.org>
	<AANLkTi=OLJ+rHoE9mKhVGgK4xjFhj5CCFgrVeBSwbPUV@mail.gmail.com>
	<4D656346.901@v.loewis.de>
Message-ID: <ik3qqb$vo5$1@dough.gmane.org>

On 23.02.2011 20:43, "Martin v. L?wis" wrote:
>> Or you realized later how nice it would be, grabbed the time machine,
>> and fixed 10 release blockers on the 19th. :)
> 
> No no no. He actually grabbed the time machine, drove 20 years back,
> and gave it to Guido so he could release Python 0.9 in time. Guido
> then kept the machine ever since.

Uh oh. Temporal mechanics gives me headaches.

Georg


From foom at fuhm.net  Wed Feb 23 21:38:50 2011
From: foom at fuhm.net (James Y Knight)
Date: Wed, 23 Feb 2011 15:38:50 -0500
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<4D656570.1010002@v.loewis.de>
	<AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
Message-ID: <74192470-92DE-4FDD-84FE-4D3ADAF316D8@fuhm.net>


On Feb 23, 2011, at 3:05 PM, Brett Cannon wrote:

> 
> 
> On Wed, Feb 23, 2011 at 11:52, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 23.02.2011 19:30, schrieb Brett Cannon:
> > I won't add the link back
> 
> Why not? It's a useful link apparently. The "Developer's Guide"
> link does not hint that it will be the only way to find the
> bug tracker.
> 
> But python.org/dev/ is a dead page. I was trying to avoid adding a redirect for python.org/dev/ as I was afraid that it would lead to the website doing something silly like redirecting everything below that URL, but obviously this can continue since people seem to think that python.org/dev/ has anything useful on it (which it does not).

It seems unfortunate that the "Core Development" link now points directly to the devguide, since it unexpectedly breaks the navigation UI. It seemed rather more useful and consistent to have "Core Development" show the page with quick links.

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

From martin at v.loewis.de  Wed Feb 23 21:51:36 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 23 Feb 2011 21:51:36 +0100
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<4D656570.1010002@v.loewis.de>
	<AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
Message-ID: <4D657358.1070602@v.loewis.de>

> But python.org/dev/ <http://python.org/dev/> is a dead page. I was
> trying to avoid adding a redirect for python.org/dev/
> <http://python.org/dev/> as I was afraid that it would lead to the
> website doing something silly like redirecting everything below that
> URL, but obviously this can continue since people seem to think that
> python.org/dev/ <http://python.org/dev/> has anything useful on it
> (which it does not).

Well, *I* ran into the problem because I hadn't reloaded the main page,
and "Core Development" would still point to /dev.

Now that I see that "Core Development" points to /devguide,
I change my request to "please add the tracker link to the side menu
of /devguide" (preferably along with a source repository link,
and a linked title "More" going to #resources).

As for redirects: it's certainly possible to redirect ^/dev$ to
/devguide, leaving /dev..* alone. I can set this up if you want me to.

Regards,
Martin

From brett at python.org  Wed Feb 23 22:00:40 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 13:00:40 -0800
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <74192470-92DE-4FDD-84FE-4D3ADAF316D8@fuhm.net>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<4D656570.1010002@v.loewis.de>
	<AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
	<74192470-92DE-4FDD-84FE-4D3ADAF316D8@fuhm.net>
Message-ID: <AANLkTikr-cmtRoEufj4PA05QF-NigzaZr3CphmSVAzuR@mail.gmail.com>

On Wed, Feb 23, 2011 at 12:38, James Y Knight <foom at fuhm.net> wrote:

>
> On Feb 23, 2011, at 3:05 PM, Brett Cannon wrote:
>
>
>
> On Wed, Feb 23, 2011 at 11:52, "Martin v. L?wis" <martin at v.loewis.de>wrote:
>
>> Am 23.02.2011 19:30, schrieb Brett Cannon:
>> > I won't add the link back
>>
>> Why not? It's a useful link apparently. The "Developer's Guide"
>> link does not hint that it will be the only way to find the
>> bug tracker.
>>
>
> But python.org/dev/ is a dead page. I was trying to avoid adding a
> redirect for python.org/dev/ as I was afraid that it would lead to the
> website doing something silly like redirecting everything below that URL,
> but obviously this can continue since people seem to think that
> python.org/dev/ has anything useful on it (which it does not).
>
>
> It seems unfortunate that the "Core Development" link now points directly
> to the devguide, since it unexpectedly breaks the navigation UI. It seemed
> rather more useful and consistent to have "Core Development" show the page
> with quick links.
>

Honestly, working on pydotorg is too bloody painful to even conceive of
doing this purely to keep a single link on www.python.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110223/0e4046a0/attachment.html>

From guido at python.org  Wed Feb 23 22:07:11 2011
From: guido at python.org (Guido van Rossum)
Date: Wed, 23 Feb 2011 13:07:11 -0800
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
Message-ID: <AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>

I'm guessing that one of these encoding names is recognized by the C
code while the other one takes the slow path via the aliasing code.

On Wed, Feb 23, 2011 at 11:16 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Tue, Feb 22, 2011 at 11:34 PM, Jesus Cea <jcea at jcea.es> wrote:
> ..
>> Issue filed. It already has a patch. That was fast!. Now I can sit back
>> waiting for 3.2.1 before touching my project again :). Mixed feelings
>> about the waiting. I hope it is short.
>
> It looks like you don't need delay your project: if you spell encoding
> as "latin-1", your pickle loads just fine:
>
>
>>>> with open("z.pickle", mode="rb") as f: pickle.load(f, encoding="latin-1")
> ...
> {'ya_volcados': {'comment': ''}}
>
>
> With encoding="latin1", it does fail:
>
>>>> with open("z.pickle", mode="rb") as f: pickle.load(f, encoding="latin1")
> ...
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> ValueError: operation forbidden on released memoryview object
>
> (For those not following the tracker issue, the z.pickle file was
> posted at <http://bugs.python.org/file20839/z.pickle>.)
>
> There is still a bug, which is best demonstrated by
>
>>>> pickle.loads(b'\x80\x02U\x00.', encoding='latin1')
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> ValueError: operation forbidden on released memoryview object
>
> The fact that the above works with encoding='latin-1',
>
>>>> pickle.loads(b'\x80\x02U\x00.', encoding='latin-1')
> ''
>
> shows that there is probably more than one bug.
> _______________________________________________
> 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  Wed Feb 23 22:13:14 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 16:13:14 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
Message-ID: <AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>

On Wed, Feb 23, 2011 at 4:07 PM, Guido van Rossum <guido at python.org> wrote:
> I'm guessing that one of these encoding names is recognized by the C
> code while the other one takes the slow path via the aliasing code.

This is absolutely right.  In fact I am going to propose adding
strcmp(lower, "latin1") to the following test in
PyUnicode_AsEncodedString():


	else if ((strcmp(lower, "latin-1") == 0) ||
                 (strcmp(lower, "iso-8859-1") == 0))
            return PyUnicode_EncodeLatin1(...

I'll open a separate issue for that.  In Python's own stdlib and tests
"latin1" is a more common spelling than "latin-1", so it makes sense
to optimize it.

From brett at python.org  Wed Feb 23 21:58:50 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 12:58:50 -0800
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <4D657358.1070602@v.loewis.de>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<4D656570.1010002@v.loewis.de>
	<AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
	<4D657358.1070602@v.loewis.de>
Message-ID: <AANLkTim3davr4F3zyWGOMy1q55p0oRZ30oV_KjxMN9W_@mail.gmail.com>

On Wed, Feb 23, 2011 at 12:51, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> > But python.org/dev/ <http://python.org/dev/> is a dead page. I was
> > trying to avoid adding a redirect for python.org/dev/
> > <http://python.org/dev/> as I was afraid that it would lead to the
> > website doing something silly like redirecting everything below that
> > URL, but obviously this can continue since people seem to think that
> > python.org/dev/ <http://python.org/dev/> has anything useful on it
> > (which it does not).
>
> Well, *I* ran into the problem because I hadn't reloaded the main page,
> and "Core Development" would still point to /dev.
>
> Now that I see that "Core Development" points to /devguide,
> I change my request to "please add the tracker link to the side menu
> of /devguide" (preferably along with a source repository link,
> and a linked title "More" going to #resources).
>

I'll see what I can do. I added a Quick Links section at the very top of the
main page so that can at least hold you over.


>
> As for redirects: it's certainly possible to redirect ^/dev$ to
> /devguide, leaving /dev..* alone. I can set this up if you want me to.
>

Please. Or double-check what I put into pydotorg's redirect.txt will work
properly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110223/928dce10/attachment.html>

From mal at egenix.com  Wed Feb 23 22:23:29 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 23 Feb 2011 22:23:29 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
References: <4D63A89A.20609@jcea.es>
	<87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D648E63.2050106@jcea.es>	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
Message-ID: <4D657AD1.7000408@egenix.com>

Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 4:07 PM, Guido van Rossum <guido at python.org> wrote:
>> I'm guessing that one of these encoding names is recognized by the C
>> code while the other one takes the slow path via the aliasing code.
> 
> This is absolutely right.  In fact I am going to propose adding
> strcmp(lower, "latin1") to the following test in
> PyUnicode_AsEncodedString():
> 
> 
> 	else if ((strcmp(lower, "latin-1") == 0) ||
>                  (strcmp(lower, "iso-8859-1") == 0))
>             return PyUnicode_EncodeLatin1(...
> 
> I'll open a separate issue for that.  In Python's own stdlib and tests
> "latin1" is a more common spelling than "latin-1", so it makes sense
> to optimize it.

"Latin-1" is the official name and the one used internally by Python,
so it would be good to have the test suite and Python code in general
to use that variant of the name (just as "utf-8" is preferred over
"utf8").

Instead of adding more aliases to the C code, please change the
encoding names in the stdlib and test suite.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 23 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 alexander.belopolsky at gmail.com  Wed Feb 23 22:34:01 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 16:34:01 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D657AD1.7000408@egenix.com>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
	<4D657AD1.7000408@egenix.com>
Message-ID: <AANLkTikhLNW=EoVznV4BT+YgtQ2Dn6pW8wp5Zg49QZbu@mail.gmail.com>

On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg <mal at egenix.com> wrote:
..
> "Latin-1" is the official name and the one used internally by Python,
> so it would be good to have the test suite and Python code in general
> to use that variant of the name (just as "utf-8" is preferred over
> "utf8").
>
> Instead of adding more aliases to the C code, please change the
> encoding names in the stdlib and test suite.

I cannot agree with you on this one.  Official or not, "latin-1" is
much less commonly used than "latin1".   Currently decode("latin1") is
10x slower than  decode("latin-1") on short strings.  We already have
a check for "iso-8859-1" alias in PyUnicode_AsEncodedString().  Adding
"latin1" (and possibly "utf8" as well) is likely to speed up many
applications at minimal cost.

From foom at fuhm.net  Wed Feb 23 22:45:04 2011
From: foom at fuhm.net (James Y Knight)
Date: Wed, 23 Feb 2011 16:45:04 -0500
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <AANLkTikr-cmtRoEufj4PA05QF-NigzaZr3CphmSVAzuR@mail.gmail.com>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<4D656570.1010002@v.loewis.de>
	<AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
	<74192470-92DE-4FDD-84FE-4D3ADAF316D8@fuhm.net>
	<AANLkTikr-cmtRoEufj4PA05QF-NigzaZr3CphmSVAzuR@mail.gmail.com>
Message-ID: <F1C9ED07-7FBC-4DD5-98D4-E895B321E719@fuhm.net>

On Feb 23, 2011, at 4:00 PM, Brett Cannon wrote:
> On Wed, Feb 23, 2011 at 12:38, James Y Knight <foom at fuhm.net> wrote:
> 
> On Feb 23, 2011, at 3:05 PM, Brett Cannon wrote:
> 
>> 
>> 
>> On Wed, Feb 23, 2011 at 11:52, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Am 23.02.2011 19:30, schrieb Brett Cannon:
>> > I won't add the link back
>> 
>> Why not? It's a useful link apparently. The "Developer's Guide"
>> link does not hint that it will be the only way to find the
>> bug tracker.
>> 
>> But python.org/dev/ is a dead page. I was trying to avoid adding a redirect for python.org/dev/ as I was afraid that it would lead to the website doing something silly like redirecting everything below that URL, but obviously this can continue since people seem to think that python.org/dev/ has anything useful on it (which it does not).
> 
> It seems unfortunate that the "Core Development" link now points directly to the devguide, since it unexpectedly breaks the navigation UI. It seemed rather more useful and consistent to have "Core Development" show the page with quick links.
> 
> Honestly, working on pydotorg is too bloody painful to even conceive of doing this purely to keep a single link onwww.python.org.

Well, presumably at least 5 links: Devguide, PEP index, buildbot, issue tracker, link to source code browser. But sure, I'm just a user, I have no idea how hard it is to edit a page on pydotorg (and no, I don't really want to know). But I seriously cannot imagine it's so hard that you can't leave a page with a few links there, that had already been written!

Note how clicking everything else in the left navbar makes useful links appear below the item, and the rest of the page keep the same theme/general layout. "Core Development" is now the unexpected exception to that UI consistency, and is less useful because of it.

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

From mal at egenix.com  Wed Feb 23 22:54:34 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 23 Feb 2011 22:54:34 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTikhLNW=EoVznV4BT+YgtQ2Dn6pW8wp5Zg49QZbu@mail.gmail.com>
References: <4D63A89A.20609@jcea.es>
	<87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D648E63.2050106@jcea.es>	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>	<4D657AD1.7000408@egenix.com>
	<AANLkTikhLNW=EoVznV4BT+YgtQ2Dn6pW8wp5Zg49QZbu@mail.gmail.com>
Message-ID: <4D65821A.30905@egenix.com>

Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> ..
>> "Latin-1" is the official name and the one used internally by Python,
>> so it would be good to have the test suite and Python code in general
>> to use that variant of the name (just as "utf-8" is preferred over
>> "utf8").
>>
>> Instead of adding more aliases to the C code, please change the
>> encoding names in the stdlib and test suite.
> 
> I cannot agree with you on this one.  Official or not, "latin-1" is
> much less commonly used than "latin1".   Currently decode("latin1") is
> 10x slower than  decode("latin-1") on short strings.  We already have
> a check for "iso-8859-1" alias in PyUnicode_AsEncodedString().  Adding
> "latin1" (and possibly "utf8" as well) is likely to speed up many
> applications at minimal cost.

Fair enough, then add "latin1" and "utf8" to both PyUnicode_Decode()
and PyUnicode_AsEncodedString().

Still, the stdlib and test suite should be examples of using the
correct names.

I only found these few cases where the wrong Latin-1 name is used
in the stdlib:

./distutils/command/bdist_wininst.py:
--             # convert back to bytes. "latin1" simply avoids any possible
--                 encoding="latin1") as script:
--                 script_data = script.read().encode("latin1")
./urllib/request.py:
--             data = base64.decodebytes(data.encode('ascii')).decode('latin1')
./asynchat.py:
--     encoding                = 'latin1'
./ftplib.py:
--     encoding = "latin1"
./sre_parse.py:
--         encode = lambda x: x.encode('latin1')

I get 12 hits for the test suite.

Yet 108 for the correct name, so I can't follow your statement
that the wrong variant is used more often.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 23 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 alexander.belopolsky at gmail.com  Wed Feb 23 23:09:36 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 17:09:36 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D65821A.30905@egenix.com>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
	<4D657AD1.7000408@egenix.com>
	<AANLkTikhLNW=EoVznV4BT+YgtQ2Dn6pW8wp5Zg49QZbu@mail.gmail.com>
	<4D65821A.30905@egenix.com>
Message-ID: <AANLkTikRO4BojafFZNAe5_futqccbuJRLufyRAh7O3CG@mail.gmail.com>

On Wed, Feb 23, 2011 at 4:54 PM, M.-A. Lemburg <mal at egenix.com> wrote:
..
> Yet 108 for the correct name, so I can't follow your statement
> that the wrong variant is used more often.

Hmm, your grepping skills are probably better than mine. I get


$ grep -iw latin-1 Lib/*.py | wc -l
      24

and

$ grep -iw latin1 Lib/test/*.py | wc -l
      25

(I did get spurious hits with naive "grep latin1", so I retract my
"more often" claim and just say that both spellings are equally
common.)

From alexander.belopolsky at gmail.com  Wed Feb 23 23:21:54 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 17:21:54 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D657AD1.7000408@egenix.com>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
	<4D657AD1.7000408@egenix.com>
Message-ID: <AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>

On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg <mal at egenix.com> wrote:
..
> "Latin-1" is the official name and the one used internally by Python,

In what sense is "Latin-1" the official name?  The IANA charset
registry has the following listing


Name: ISO_8859-1:1987                                    [RFC1345,KXS2]
MIBenum: 4
Source: ECMA registry
Alias: iso-ir-100
Alias: ISO_8859-1
Alias: ISO-8859-1 (preferred MIME name)
Alias: latin1
Alias: l1
Alias: IBM819
Alias: CP819
Alias: csISOLatin1

(See http://www.iana.org/assignments/character-sets)

"Latin-1" spelling does appear in various unicode.org documents, but
not in machine readable files as far as I can tell.

From mal at egenix.com  Wed Feb 23 23:21:56 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 23 Feb 2011 23:21:56 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTikRO4BojafFZNAe5_futqccbuJRLufyRAh7O3CG@mail.gmail.com>
References: <4D63A89A.20609@jcea.es>
	<87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D648E63.2050106@jcea.es>	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>	<4D657AD1.7000408@egenix.com>	<AANLkTikhLNW=EoVznV4BT+YgtQ2Dn6pW8wp5Zg49QZbu@mail.gmail.com>	<4D65821A.30905@egenix.com>
	<AANLkTikRO4BojafFZNAe5_futqccbuJRLufyRAh7O3CG@mail.gmail.com>
Message-ID: <4D658884.4060606@egenix.com>

Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 4:54 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> ..
>> Yet 108 for the correct name, so I can't follow your statement
>> that the wrong variant is used more often.
> 
> Hmm, your grepping skills are probably better than mine. I get
> 
> 
> $ grep -iw latin-1 Lib/*.py | wc -l
>       24
> 
> and
> 
> $ grep -iw latin1 Lib/test/*.py | wc -l
>       25
> 
> (I did get spurious hits with naive "grep latin1", so I retract my
> "more often" claim and just say that both spellings are equally
> common.)

I used a Python script based on re, perhaps that's why :-)

grep only counts lines, not multiple instances on a single line
and looking through the hits I found, there are a few false
positives such as 'latin-10' or 'iso-latin-1'. Without those,
I get 83 hits.

If you open a ticket for this, I'll add the list of hits to
that ticket.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 23 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 alexander.belopolsky at gmail.com  Wed Feb 23 23:36:18 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 17:36:18 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D658884.4060606@egenix.com>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
	<4D657AD1.7000408@egenix.com>
	<AANLkTikhLNW=EoVznV4BT+YgtQ2Dn6pW8wp5Zg49QZbu@mail.gmail.com>
	<4D65821A.30905@egenix.com>
	<AANLkTikRO4BojafFZNAe5_futqccbuJRLufyRAh7O3CG@mail.gmail.com>
	<4D658884.4060606@egenix.com>
Message-ID: <AANLkTim2V4XiWcDBKBt=ELvWqZmnNafTNf9hvqroFX4m@mail.gmail.com>

On Wed, Feb 23, 2011 at 5:21 PM, M.-A. Lemburg <mal at egenix.com> wrote:
..
> If you open a ticket for this, I'll add the list of hits to
> that ticket.
>

http://bugs.python.org/issue11303

From ethan at stoneleaf.us  Wed Feb 23 23:46:06 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 23 Feb 2011 14:46:06 -0800
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D65821A.30905@egenix.com>
References: <4D63A89A.20609@jcea.es>	<87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D648E63.2050106@jcea.es>	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>	<4D657AD1.7000408@egenix.com>	<AANLkTikhLNW=EoVznV4BT+YgtQ2Dn6pW8wp5Zg49QZbu@mail.gmail.com>
	<4D65821A.30905@egenix.com>
Message-ID: <4D658E2E.3000907@stoneleaf.us>

M.-A. Lemburg wrote:
> Still, the stdlib and test suite should be examples of using the
> correct names.

I won't argue with the stdlib portion of your argument, but I would 
think that the best example of test code would be a complete and 
thorough check of all options.

~Ethan~

From barry at python.org  Wed Feb 23 23:45:30 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Feb 2011 17:45:30 -0500
Subject: [Python-Dev] [RELEASED] Python 3.2
In-Reply-To: <1298245152.5269.24.camel@marge>
References: <4D619437.7050507@python.org>
	<1298245152.5269.24.camel@marge>
Message-ID: <20110223174530.2c3a6ae6@python.org>

On Feb 21, 2011, at 12:39 AM, Victor Stinner wrote:

>Le dimanche 20 f?vrier 2011 ? 23:22 +0100, Georg Brandl a ?crit :
>> On behalf of the Python development team, I'm delighted to announce
>> Python 3.2 final release.
>> 
>> Python 3.2 is a continuation of the efforts to improve and stabilize the
>> Python 3.x line.
>
>Congratulation to all Python developers for this wonderful release! And
>a special kudo to our release manager, Georg.

Indeed, great job Georg.  I hereby nominate you for Python 3.3 RM.  No good
deed goes unpunished. :)

>I hope that Python 3 is now stable enough to support migration of major
>projects like Django, Twisted or Zope. Other important projets like
>Distribute, Jinja2, PyQt, PyGObject, pygame, NumPy+SciPy and Sphinx are
>already compatible with Python 3.

Agreed!  I hope porting to Python 3 can be a major theme for Pycon this year.

-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/20110223/966dc049/attachment.pgp>

From mal at egenix.com  Thu Feb 24 00:32:56 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 24 Feb 2011 00:32:56 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>
References: <4D63A89A.20609@jcea.es>
	<87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D648E63.2050106@jcea.es>	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>	<4D657AD1.7000408@egenix.com>
	<AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>
Message-ID: <4D659928.7090404@egenix.com>

Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> ..
>> "Latin-1" is the official name and the one used internally by Python,
> 
> In what sense is "Latin-1" the official name?  The IANA charset
> registry has the following listing
> 
> 
> Name: ISO_8859-1:1987                                    [RFC1345,KXS2]
> MIBenum: 4
> Source: ECMA registry
> Alias: iso-ir-100
> Alias: ISO_8859-1
> Alias: ISO-8859-1 (preferred MIME name)
> Alias: latin1
> Alias: l1
> Alias: IBM819
> Alias: CP819
> Alias: csISOLatin1
> 
> (See http://www.iana.org/assignments/character-sets)

Those are registered character set names, not necessarily
standard names. Anyone can apply for new aliases to get
added to that list.

> "Latin-1" spelling does appear in various unicode.org documents, but
> not in machine readable files as far as I can tell.

"Latin-1" is short for "Latin Alphabet No. 1" and
started out as ECMA-94 in 1985 and 1986:

http://www.ecma-international.org/publications/standards/Ecma-094.htm

ISO then applied their numbering scheme for the character set
standard ISO-8859 in 1987 where "Latin-1" became "ISO-8859-1".
Note that this was before the Internet took off.

I assume that since the HTML standard used the more popular
name "Latin-1" for its definition of the default character set
and also made use of the term throughout the spec, it
became the de-facto standard name for that character set
at the time. I only learned about the term "ISO-8859-1"
when starting to dive into the Unicode world late in the
1990s.

"Latin-1" is also sometimes written as "ISO Latin-1", e.g.
http://msdn.microsoft.com/en-us/library/ms537495(v=vs.85).aspx

For much the same reasons, "ISO-10646" never really became
popular, but "Unicode" eventually did.

"ECMA-262" or "ISO/IEC 16262" just doesn't sound as good as
"JavaScript" either :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 23 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 martin at v.loewis.de  Thu Feb 24 00:40:25 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 24 Feb 2011 00:40:25 +0100
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <AANLkTim3davr4F3zyWGOMy1q55p0oRZ30oV_KjxMN9W_@mail.gmail.com>
References: <20110223165855.10d63be9@pitrou.net>	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>	<4D656570.1010002@v.loewis.de>	<AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>	<4D657358.1070602@v.loewis.de>
	<AANLkTim3davr4F3zyWGOMy1q55p0oRZ30oV_KjxMN9W_@mail.gmail.com>
Message-ID: <4D659AE9.1050408@v.loewis.de>

>     As for redirects: it's certainly possible to redirect ^/dev$ to
>     /devguide, leaving /dev..* alone. I can set this up if you want me to.
> 
> 
> Please. Or double-check what I put into pydotorg's redirect.txt will
> work properly. 

What redirect.txt did you edit specifically?

I have now changed redirects.conf, and it seems to work fine. Please
let me know if there are any problems.

Regards,
Martin

From brett at python.org  Thu Feb 24 00:42:52 2011
From: brett at python.org (Brett Cannon)
Date: Wed, 23 Feb 2011 15:42:52 -0800
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <4D659AE9.1050408@v.loewis.de>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<4D656570.1010002@v.loewis.de>
	<AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
	<4D657358.1070602@v.loewis.de>
	<AANLkTim3davr4F3zyWGOMy1q55p0oRZ30oV_KjxMN9W_@mail.gmail.com>
	<4D659AE9.1050408@v.loewis.de>
Message-ID: <AANLkTiki1XfpsMh58kwg9v1-L2HpbGot_cDLSKeAv9FW@mail.gmail.com>

On Wed, Feb 23, 2011 at 15:40, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> >     As for redirects: it's certainly possible to redirect ^/dev$ to
> >     /devguide, leaving /dev..* alone. I can set this up if you want me
> to.
> >
> >
> > Please. Or double-check what I put into pydotorg's redirect.txt will
> > work properly.
>
> What redirect.txt did you edit specifically?
>

It was beta.python.org/build/redirects.txt, but I went ahead and reverted
the change since your solution works.


>
> I have now changed redirects.conf, and it seems to work fine. Please
> let me know if there are any problems.
>

Works for me. Thanks, Martin!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110223/581f2a54/attachment.html>

From alexander.belopolsky at gmail.com  Thu Feb 24 00:56:14 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 18:56:14 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D659928.7090404@egenix.com>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
	<4D657AD1.7000408@egenix.com>
	<AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>
	<4D659928.7090404@egenix.com>
Message-ID: <AANLkTimnNa9x7QV7EdTe5dqB7QgYemWG5JxXr_H1gG5f@mail.gmail.com>

On Wed, Feb 23, 2011 at 6:32 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> Alexander Belopolsky wrote:
..
>> In what sense is "Latin-1" the official name? ?The IANA charset
>> registry has the following listing
>>
>>
>> Name: ISO_8859-1:1987 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[RFC1345,KXS2]
>> MIBenum: 4
>> Source: ECMA registry
>> Alias: iso-ir-100
>> Alias: ISO_8859-1
>> Alias: ISO-8859-1 (preferred MIME name)
>> Alias: latin1
..
> "Latin-1" is short for "Latin Alphabet No. 1" and
> started out as ECMA-94 in 1985 and 1986:

This does not explain your preference of "Latin-1" over "Latin1".
Both are perfectly valid abbreviations for "Latin Alphabet No. 1".
The spelling without "-" has the advantage of being a valid Python
identifier and a module name.  The IANA registration for "latin1" and
lack of that for "latin-1" most likely indicates that the former is
more commonly found in machine readable metadata.

From stephen at xemacs.org  Thu Feb 24 02:14:59 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 24 Feb 2011 10:14:59 +0900
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D659928.7090404@egenix.com>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
	<4D657AD1.7000408@egenix.com>
	<AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>
	<4D659928.7090404@egenix.com>
Message-ID: <878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp>

M.-A. Lemburg writes:

 > "Latin-1" is short for "Latin Alphabet No. 1" [...].

 > I assume that since the HTML standard used the more popular
 > name "Latin-1" for its definition of the default character set
 > and also made use of the term throughout the spec, it
 > became the de-facto standard name for that character set
 > at the time.

As usual with de facto standards, it got "embraced and extended".
I've seen people seriously contend that Windows-1252 is an
"implementation" or (conformant) extension of "Latin-1", and that the
EURO SIGN is now a member of "Latin-1".  It's just too ambiguous for
my taste; I avoid it in discussions of character sets, preferring to
be thought idiosyncratic and pedantic.

As for the spelling, I think "Latin-1" is slightly more readable than
"Latin1", but the latter is in the same degree more typable.<wink>

 > For much the same reasons, "ISO-10646" never really became
 > popular, but "Unicode" eventually did.

No, there are much more important reasons why "Unicode" became
popular.  IMHO, as an encoding standard ISO-10646 had a slight edge
over Unicode in the early 1990s, before the two were unified as coded
character sets.  However, as a text processing system there simply was
no comparison.  Unicode provided a large number of standard
facilities, and was clearly set to add to those, that were way outside
of the scope of ISO 10646.  Claiming Unicode conformance was a much
bigger deal than ISO 10646 (not to mention having the "advantage" that
you could *optionally* save Intel shorts to disk without swabbing them
first).


From digitalxero at gmail.com  Thu Feb 24 02:48:04 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Wed, 23 Feb 2011 20:48:04 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
	<4D657AD1.7000408@egenix.com>
	<AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>
	<4D659928.7090404@egenix.com>
	<878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTi=PnfPuMjVPjhUvZ5afnYoM9jJcLjkHomCP7_ii@mail.gmail.com>

Google Code search limited to python

latin1:?3,489 http://www.google.com/codesearch?hl=en&lr=&q=latin1+lang%3Apython&sbtn=Search
latin-1: 5,604 http://www.google.com/codesearch?hl=en&lr=&q=latin-1+lang%3Apython&sbtn=Search

utf8: 25,341 http://www.google.com/codesearch?hl=en&lr=&q=utf8+lang%3Apython&sbtn=Search
utf-8: 179,806 http://www.google.com/codesearch?hl=en&lr=&q=utf-8+lang%3Apython&sbtn=Search


Interesting that for Latin-1 the split of "wrong"/"right" is 40/60 and
the split for utf8 is 15/85

From alexander.belopolsky at gmail.com  Thu Feb 24 03:19:06 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 21:19:06 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTi=PnfPuMjVPjhUvZ5afnYoM9jJcLjkHomCP7_ii@mail.gmail.com>
References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4D648E63.2050106@jcea.es>
	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>
	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>
	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>
	<4D657AD1.7000408@egenix.com>
	<AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>
	<4D659928.7090404@egenix.com>
	<878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTi=PnfPuMjVPjhUvZ5afnYoM9jJcLjkHomCP7_ii@mail.gmail.com>
Message-ID: <AANLkTimOskQzgoS67Xwut_p=rJvbOHSbz4=+HJHTeH+u@mail.gmail.com>

On Wed, Feb 23, 2011 at 8:48 PM, Dj Gilcrease <digitalxero at gmail.com> wrote:
> Google Code search limited to python
>
> latin1:?3,489 http://www.google.com/codesearch?hl=en&lr=&q=latin1+lang%3Apython&sbtn=Search
> latin-1: 5,604 http://www.google.com/codesearch?hl=en&lr=&q=latin-1+lang%3Apython&sbtn=Search
>
> utf8: 25,341 http://www.google.com/codesearch?hl=en&lr=&q=utf8+lang%3Apython&sbtn=Search
> utf-8: 179,806 http://www.google.com/codesearch?hl=en&lr=&q=utf-8+lang%3Apython&sbtn=Search
>
>
> Interesting that for Latin-1 the split of "wrong"/"right" is 40/60 and
> the split for utf8 is 15/85

Your search is invalid.  You hit things such as Latin1ClassModel which
have no relevance to the issue at hand.

From jnoller at gmail.com  Thu Feb 24 04:05:50 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 23 Feb 2011 22:05:50 -0500
Subject: [Python-Dev] [RELEASED] Python 3.2
In-Reply-To: <20110223174530.2c3a6ae6@python.org>
References: <4D619437.7050507@python.org> <1298245152.5269.24.camel@marge>
	<20110223174530.2c3a6ae6@python.org>
Message-ID: <AANLkTikpVTN3rNYS92R7K59LBFOME4aBY8YwyQq3xLG-@mail.gmail.com>

On Wed, Feb 23, 2011 at 5:45 PM, Barry Warsaw <barry at python.org> wrote:
> On Feb 21, 2011, at 12:39 AM, Victor Stinner wrote:
>
>>Le dimanche 20 f?vrier 2011 ? 23:22 +0100, Georg Brandl a ?crit :
>>> On behalf of the Python development team, I'm delighted to announce
>>> Python 3.2 final release.
>>>
>>> Python 3.2 is a continuation of the efforts to improve and stabilize the
>>> Python 3.x line.
>>
>>Congratulation to all Python developers for this wonderful release! And
>>a special kudo to our release manager, Georg.
>
> Indeed, great job Georg. ?I hereby nominate you for Python 3.3 RM. ?No good
> deed goes unpunished. :)
>
>>I hope that Python 3 is now stable enough to support migration of major
>>projects like Django, Twisted or Zope. Other important projets like
>>Distribute, Jinja2, PyQt, PyGObject, pygame, NumPy+SciPy and Sphinx are
>>already compatible with Python 3.
>
> Agreed! ?I hope porting to Python 3 can be a major theme for Pycon this year.
>
> -Barry

It is. Trust me.

From scott+python-dev at scottdial.com  Thu Feb 24 04:22:05 2011
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Wed, 23 Feb 2011 22:22:05 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTimOskQzgoS67Xwut_p=rJvbOHSbz4=+HJHTeH+u@mail.gmail.com>
References: <4D63A89A.20609@jcea.es>
	<87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D648E63.2050106@jcea.es>	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>	<4D657AD1.7000408@egenix.com>	<AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>	<4D659928.7090404@egenix.com>	<878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp>	<AANLkTi=PnfPuMjVPjhUvZ5afnYoM9jJcLjkHomCP7_ii@mail.gmail.com>
	<AANLkTimOskQzgoS67Xwut_p=rJvbOHSbz4=+HJHTeH+u@mail.gmail.com>
Message-ID: <4D65CEDD.5000404@scottdial.com>

On 2/23/2011 9:19 PM, Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 8:48 PM, Dj Gilcrease <digitalxero at gmail.com> wrote:
>> Google Code search limited to python
>>
>> latin1: 3,489 http://www.google.com/codesearch?hl=en&lr=&q=latin1+lang%3Apython&sbtn=Search
>> latin-1: 5,604 http://www.google.com/codesearch?hl=en&lr=&q=latin-1+lang%3Apython&sbtn=Search

latin1: 1,618
http://www.google.com/codesearch?hl=en&lr=&q=%28\%22latin1\%22|\%27latin1\%27%29+lang%3Apython&sbtn=Search
latin-1: 2,241
http://www.google.com/codesearch?hl=en&lr=&q=%28\%22latin-1\%22|\%27latin-1\%27%29+lang%3Apython&sbtn=Search

>> utf8: 25,341 http://www.google.com/codesearch?hl=en&lr=&q=utf8+lang%3Apython&sbtn=Search
>> utf-8: 179,806 http://www.google.com/codesearch?hl=en&lr=&q=utf-8+lang%3Apython&sbtn=Search

utf8 9,676
http://www.google.com/codesearch?hl=en&lr=&q=%28\%22utf8\%22|\%27utf8\%27%29+lang%3Apython&sbtn=Search
utf-8 44,795
http://www.google.com/codesearch?hl=en&lr=&q=%28\%22utf-8\%22|\%27utf-8\%27%29+lang%3Apython&sbtn=Search

> Your search is invalid.  You hit things such as Latin1ClassModel which
> have no relevance to the issue at hand.

You get about the same ratio if you filter out only the quoted strings.

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

From martin at v.loewis.de  Thu Feb 24 07:43:50 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 24 Feb 2011 07:43:50 +0100
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <AANLkTiki1XfpsMh58kwg9v1-L2HpbGot_cDLSKeAv9FW@mail.gmail.com>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<4D656570.1010002@v.loewis.de>
	<AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
	<4D657358.1070602@v.loewis.de>
	<AANLkTim3davr4F3zyWGOMy1q55p0oRZ30oV_KjxMN9W_@mail.gmail.com>
	<4D659AE9.1050408@v.loewis.de>
	<AANLkTiki1XfpsMh58kwg9v1-L2HpbGot_cDLSKeAv9FW@mail.gmail.com>
Message-ID: <4D65FE26.4060800@v.loewis.de>

>     What redirect.txt did you edit specifically?
> 
> 
> It was beta.python.org/build/redirects.txt
> <http://beta.python.org/build/redirects.txt>, but I went ahead and
> reverted the change since your solution works.

Ah. That file isn't used, AFAICT, so I now deleted it. If there
are any other redirects that you want to see active, please
let me know.

Regards,
Martin

From mal at egenix.com  Thu Feb 24 10:02:10 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 24 Feb 2011 10:02:10 +0100
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <AANLkTimnNa9x7QV7EdTe5dqB7QgYemWG5JxXr_H1gG5f@mail.gmail.com>
References: <4D63A89A.20609@jcea.es>
	<87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D648E63.2050106@jcea.es>	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>	<4D657AD1.7000408@egenix.com>	<AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>	<4D659928.7090404@egenix.com>
	<AANLkTimnNa9x7QV7EdTe5dqB7QgYemWG5JxXr_H1gG5f@mail.gmail.com>
Message-ID: <4D661E92.1080909@egenix.com>

Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 6:32 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Alexander Belopolsky wrote:
> ..
>>> In what sense is "Latin-1" the official name?  The IANA charset
>>> registry has the following listing
>>>
>>>
>>> Name: ISO_8859-1:1987                                    [RFC1345,KXS2]
>>> MIBenum: 4
>>> Source: ECMA registry
>>> Alias: iso-ir-100
>>> Alias: ISO_8859-1
>>> Alias: ISO-8859-1 (preferred MIME name)
>>> Alias: latin1
> ..
>> "Latin-1" is short for "Latin Alphabet No. 1" and
>> started out as ECMA-94 in 1985 and 1986:
> 
> This does not explain your preference of "Latin-1" over "Latin1".

This is not my preference. See e.g. Wikipedia
http://en.wikipedia.org/wiki/ISO/IEC_8859-1

It is common practice to replace spaces in descriptive names with
a hyphen to come up with an identifier string (even Google
does or undoes this when searching the net).

Replacing spaces with an empty string is also an option, but
doesn't read as well.

> Both are perfectly valid abbreviations for "Latin Alphabet No. 1".
> The spelling without "-" has the advantage of being a valid Python
> identifier and a module name.

The hyphens are converted to underscores by the lookup function
in the encodings package. That turns the name into a valid
Python module name.

>  The IANA registration for "latin1" and
> lack of that for "latin-1" most likely indicates that the former is
> more commonly found in machine readable metadata.

I don't know why you emphasize so much on machine readable metadata.
Python source code is machine readable, the Internet is machine
readable, all documents found there are machine readable.

As I said earlier on: the IANA registry is just that - a registry
of names with the purpose of avoiding name clashes in the resp.
name space. As such, it is not a standard, but merely a tool
to map various aliases to a canoncial name.

The fact that an alias is registered doesn't allow any
implication on whether it's in wide-spread use or not, e.g.
"csISOLatin1" gives me 6810 hits on Google.

I get 788,000 hits for 'latin1 -"latin-1"' on Google,
'latin-1' gives 2,600,000 hits. Looks like it's still
the preferred way to write that encoding name.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 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 scott+python-dev at scottdial.com  Thu Feb 24 17:59:57 2011
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Thu, 24 Feb 2011 11:59:57 -0500
Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2
In-Reply-To: <4D661E92.1080909@egenix.com>
References: <4D63A89A.20609@jcea.es>	<87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp>	<4D648E63.2050106@jcea.es>	<AANLkTikGVqSEWviYuqfAC1EZjWmSmFMx8aEmpJ2YkJej@mail.gmail.com>	<AANLkTikRitTFBvmHc8p03Uk98ExSR3zPSVYEvYGmu4zS@mail.gmail.com>	<AANLkTimie2=idMUMAhAUh+JMbAPcRto2iKYFv8y59Sf4@mail.gmail.com>	<4D657AD1.7000408@egenix.com>	<AANLkTi=tBvtQ8kPVdPpMXOS4ZJRPdivn2Moosw8HqzW-@mail.gmail.com>	<4D659928.7090404@egenix.com>	<AANLkTimnNa9x7QV7EdTe5dqB7QgYemWG5JxXr_H1gG5f@mail.gmail.com>
	<4D661E92.1080909@egenix.com>
Message-ID: <4D668E8D.1020305@scottdial.com>

On 2/24/2011 4:02 AM, M.-A. Lemburg wrote:
> I get 788,000 hits for 'latin1 -"latin-1"' on Google,
> 'latin-1' gives 2,600,000 hits. Looks like it's still
> the preferred way to write that encoding name.

That's bogus. You can't search for "latin-1" on Google, it isn't strict
enough. The third hit is a url containing "latin1" and a title of "Latin
1". And it picks up things like "Latin 1: The Easy Way", which is a book
on Latin.

However, you *can* search much more strictly on Google Code Search,
which gives 4,014 ("latin-1") to 13,597 ("latin1").

http://www.google.com/codesearch?hl=en&lr=&q=%28\%22latin1\%22|\%27latin1\%27%29&sbtn=Search
http://www.google.com/codesearch?hl=en&lr=&q=%28\%22latin-1\%22|\%27latin-1\%27%29&sbtn=Search

So, no, I don't think the development world aligns with your pedantry.
That's not to say this is a popularity contest, but then let's not cite
google hit counts as proof.

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

From brett at python.org  Thu Feb 24 19:42:27 2011
From: brett at python.org (Brett Cannon)
Date: Thu, 24 Feb 2011 10:42:27 -0800
Subject: [Python-Dev] Link to issue tracker
In-Reply-To: <4D65FE26.4060800@v.loewis.de>
References: <20110223165855.10d63be9@pitrou.net>
	<AANLkTimZGfSdBFhNXe+hQMgsGtBs1uM+kAGKEpfv3P=D@mail.gmail.com>
	<4D656570.1010002@v.loewis.de>
	<AANLkTike+7Ga7fb5eih8L4Re4t0P8Y3DSrby3hY8s1kf@mail.gmail.com>
	<4D657358.1070602@v.loewis.de>
	<AANLkTim3davr4F3zyWGOMy1q55p0oRZ30oV_KjxMN9W_@mail.gmail.com>
	<4D659AE9.1050408@v.loewis.de>
	<AANLkTiki1XfpsMh58kwg9v1-L2HpbGot_cDLSKeAv9FW@mail.gmail.com>
	<4D65FE26.4060800@v.loewis.de>
Message-ID: <AANLkTinpXghEdJbWNqc5EzZ5yBfDfEjzq3t-VzT+Pmqo@mail.gmail.com>

On Wed, Feb 23, 2011 at 22:43, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> >     What redirect.txt did you edit specifically?
> >
> >
> > It was beta.python.org/build/redirects.txt
> > <http://beta.python.org/build/redirects.txt>, but I went ahead and
> > reverted the change since your solution works.
>
> Ah. That file isn't used, AFAICT, so I now deleted it.


Are you sure? I added entries last week to that file and they worked when
the website updated.


> If there
> are any other redirects that you want to see active, please
> let me know.
>

Personally I cared about all of the redirects that were in that file
pertaining to /dev.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110224/bf9555dd/attachment.html>

From g.rodola at gmail.com  Thu Feb 24 20:51:20 2011
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Thu, 24 Feb 2011 20:51:20 +0100
Subject: [Python-Dev] r88501 - python/branches/py3k/Lib/smtplib.py
In-Reply-To: <ik2d74$lpn$1@dough.gmane.org>
References: <20110222155620.B82D2EE9B5@mail.python.org>
	<ik2d74$lpn$1@dough.gmane.org>
Message-ID: <AANLkTinqv+Vyp-PyMq3frRU0vhKiqhF3yGfw50eryS=v@mail.gmail.com>

Mmmm probably. smtplib patches aren't too big/many though.
Should I revert the change?


2011/2/23 Georg Brandl <g.brandl at gmx.net>:
> You're sure this will not cause tedious conflicts with backports?
>
> Georg
>
> On 22.02.2011 16:56, giampaolo.rodola wrote:
>> Author: giampaolo.rodola
>> Date: Tue Feb 22 16:56:20 2011
>> New Revision: 88501
>>
>> Log:
>> smtlib.py PEP8 normalization via pep8.py script.
>>
>> Modified:
>> ? ?python/branches/py3k/Lib/smtplib.py
>>
>> Modified: python/branches/py3k/Lib/smtplib.py
>> ==============================================================================
>> --- python/branches/py3k/Lib/smtplib.py ? ? ? (original)
>> +++ python/branches/py3k/Lib/smtplib.py ? ? ? Tue Feb 22 16:56:20 2011
>> @@ -52,15 +52,15 @@
>
>
>
> _______________________________________________
> 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 g.brandl at gmx.net  Thu Feb 24 20:53:10 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 24 Feb 2011 20:53:10 +0100
Subject: [Python-Dev] r88501 - python/branches/py3k/Lib/smtplib.py
In-Reply-To: <AANLkTinqv+Vyp-PyMq3frRU0vhKiqhF3yGfw50eryS=v@mail.gmail.com>
References: <20110222155620.B82D2EE9B5@mail.python.org>
	<ik2d74$lpn$1@dough.gmane.org>
	<AANLkTinqv+Vyp-PyMq3frRU0vhKiqhF3yGfw50eryS=v@mail.gmail.com>
Message-ID: <ik6d0h$5hk$1@dough.gmane.org>

On 24.02.2011 20:51, Giampaolo Rodol? wrote:
> Mmmm probably. smtplib patches aren't too big/many though.
> Should I revert the change?

It's probably fine if you do the same change to the maintenance
branches as well.

Georg



From g.rodola at gmail.com  Thu Feb 24 21:43:49 2011
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Thu, 24 Feb 2011 21:43:49 +0100
Subject: [Python-Dev] r88501 - python/branches/py3k/Lib/smtplib.py
In-Reply-To: <ik6d0h$5hk$1@dough.gmane.org>
References: <20110222155620.B82D2EE9B5@mail.python.org>
	<ik2d74$lpn$1@dough.gmane.org>
	<AANLkTinqv+Vyp-PyMq3frRU0vhKiqhF3yGfw50eryS=v@mail.gmail.com>
	<ik6d0h$5hk$1@dough.gmane.org>
Message-ID: <AANLkTimGZ0EL6tmdz89wE1o35MB1i43k2BsuB0ALJvb9@mail.gmail.com>

Done for Python 3.1 and 2.7.

2011/2/24 Georg Brandl <g.brandl at gmx.net>:
> On 24.02.2011 20:51, Giampaolo Rodol? wrote:
>> Mmmm probably. smtplib patches aren't too big/many though.
>> Should I revert the change?
>
> It's probably fine if you do the same change to the maintenance
> branches as well.
>
> 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/g.rodola%40gmail.com
>

From g.brandl at gmx.net  Thu Feb 24 22:10:00 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 24 Feb 2011 22:10:00 +0100
Subject: [Python-Dev] [RELEASED] Python 3.2
In-Reply-To: <20110223174530.2c3a6ae6@python.org>
References: <4D619437.7050507@python.org> <1298245152.5269.24.camel@marge>
	<20110223174530.2c3a6ae6@python.org>
Message-ID: <ik6hgj$vos$1@dough.gmane.org>

On 23.02.2011 23:45, Barry Warsaw wrote:
> On Feb 21, 2011, at 12:39 AM, Victor Stinner wrote:
> 
>>Le dimanche 20 f?vrier 2011 ? 23:22 +0100, Georg Brandl a ?crit :
>>> On behalf of the Python development team, I'm delighted to announce
>>> Python 3.2 final release.
>>> 
>>> Python 3.2 is a continuation of the efforts to improve and stabilize the
>>> Python 3.x line.
>>
>>Congratulation to all Python developers for this wonderful release! And
>>a special kudo to our release manager, Georg.
> 
> Indeed, great job Georg.  I hereby nominate you for Python 3.3 RM.  No good
> deed goes unpunished. :)

Well, I guess that makes sense.  In a twisted way :)

Georg


From belopolsky at users.sourceforge.net  Thu Feb 24 22:18:20 2011
From: belopolsky at users.sourceforge.net (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 16:18:20 -0500
Subject: [Python-Dev] [issue11286] Some "trivial" python 2.x pickles
 fails to load in Python 3.2
In-Reply-To: <1298581635.3722.2.camel@localhost.localdomain>
References: <AANLkTi=9Aqr07Ez0133qbr+Wjbv6HTbo2XoR19g1w+Pz@mail.gmail.com>
	<1298581635.3722.2.camel@localhost.localdomain>
Message-ID: <AANLkTi=7zVzeZaHkUMRQnaQKgNhMV=FFGygBw7X+n1Yr@mail.gmail.com>

It seems appropriate to consult python-dev on this.  I thought
ValueError was for values that are valid Python objects but out of
acceptable range of the function.  Errors that can only be triggered
in C code normally handled with either assert() or raise SystemError.
I think you are splitting hairs too thin by distinguishing between
stdlib and 3rd party extensions.

On Thu, Feb 24, 2011 at 4:07 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> > I've committed the part of the patch which disallows a NULL data pointer
>> > with PyMemoryView_FromBuffer in r88550 and r88551.
>>
>> Is it possible to create such buffer in Python (other than by
>> exploiting a bug or writing a rogue extension module)? ?If not, this
>> should be a SystemError or even just an assert() rather than
>> ValueError.
>
> I'm against asserts for such use, since they get disabled in non-debug
> mode (which is the mode 99.99% of users run in).
>
> As for SystemError, it means "Internal error in the Python interpreter",
> which isn't the case here (most likely it's an error in an extension
> module instead, possibly a third-party one).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11286>
> _______________________________________
>

From solipsis at pitrou.net  Fri Feb 25 01:19:04 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 01:19:04 +0100
Subject: [Python-Dev] Mercurial conversion repositories
Message-ID: <20110225011904.3ed09de7@pitrou.net>


Hello,

Georg and I have been working on converting the SVN repository to
Mercurial. We can now present you a test repository (actually, two).


CPython repository: http://hg.python.org/cpython/
------------------

This is the main conversion repository. It contains all history of
trunk and py3k (since 1990!) up to now, including all maintenance
branches starting from 2.0 up to 3.2.

If you are a core developer, get your local clone of the repository
using:

    $ hg clone ssh://hg at hg.python.org/cpython

(this uses the same SSH key as your Subversion access; for more
information about Mercurial and SSH keys, see the converted development
FAQ: http://potrou.net/hgdevguide/faq.html#faq )

If you are not a core developer:

    $ hg clone http://hg.python.org/cpython

Your clone will contain the following branches:

    $ hg branches
    default                    68026:f12ef116dd10
    3.2                        68025:cef92ee1a323
    2.7                        68010:8174d00d0797
    3.1                        67955:5be8b695ea86
    2.6                        67287:5e26a860eded
    2.5                        65464:e4ecac76e499
    trunk                      62750:800f6c92c3ed
    3.0                        60075:1d05144224fe
    2.4                        58552:df72cac1899e
    2.3                        45731:a3d9a9730743
    2.2                        40444:d55ddc8c8501
    2.1                        30171:06fcccf6eca8
    2.0                        18214:dc0dfc9565cd

The branch "default" is the current py3k branch from SVN. The branch
"trunk" represents SVN trunk history until 2.7 was branched for
maintenance.

The full list of tags is too long to print here, but you can get it
using:

    $ hg tags

The size of the repository on-disk is (depending on your filesystem):

    $ du -hs .hg
    176M    .hg

(the size of the network transfer is estimated to be around 80MB)

You can commit and even push to this repository (the latter if you are a
core developer).  Since this is a test repository, whatever you push
will be discarded when we do the final conversion.


CPython with extra history: http://hg.python.org/cpythonextrahist/
--------------------------

This repository is bigger, and has a much more complicated topology. It
is a superset of the other repository, and contains the totality of the
branches from the SVN repository (it has more than 450 repository
heads, of which 87 non-closed). It also weighs quite a bit more:

    $ du -hs .hg
    248M    .hg

This repository is unnecessary for development work, since even for
history-digging purposes the normal repository has the necessary
information. This repository is only to preserve historical record of
some of the non-trunk development work from the SVN repository (such
as orphaned/deleted feature branches).


Development guide: http://potrou.net/hgdevguide/
-----------------

This is the development guide adapted for Mercurial.  You can get its
sources from the branch "hg_transition" in
http://hg.python.org/devguide/.


Regards

Antoine.



From raymond.hettinger at gmail.com  Fri Feb 25 01:46:57 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Thu, 24 Feb 2011 16:46:57 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225011904.3ed09de7@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
Message-ID: <773AD9BF-95AF-4A58-80BF-7C2468C5F678@gmail.com>


On Feb 24, 2011, at 4:19 PM, Antoine Pitrou wrote:

> Georg and I have been working on converting the SVN repository to
> Mercurial. We can now present you a test repository (actually, two).
> 
> 
> CPython repository: http://hg.python.org/cpython/

Thank you both for all the effort you put in.
I'll do some tests today.


Raymond

From brett at python.org  Fri Feb 25 02:39:40 2011
From: brett at python.org (Brett Cannon)
Date: Thu, 24 Feb 2011 17:39:40 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225011904.3ed09de7@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
Message-ID: <AANLkTi=7RzfF0Vqr3x_xPqGoLQjkzFCagp=kHDQnTuYA@mail.gmail.com>

On Thu, Feb 24, 2011 at 16:19, Antoine Pitrou <solipsis at pitrou.net> wrote:

>
> Hello,
>
> Georg and I have been working on converting the SVN repository to
> Mercurial. We can now present you a test repository (actually, two).
>

Thanks to the both of you for moving this forward!


>
>
> CPython repository: http://hg.python.org/cpython/
> ------------------
>
> This is the main conversion repository. It contains all history of
> trunk and py3k (since 1990!) up to now, including all maintenance
> branches starting from 2.0 up to 3.2.
>
> If you are a core developer, get your local clone of the repository
> using:
>
>    $ hg clone ssh://hg at hg.python.org/cpython
>
> (this uses the same SSH key as your Subversion access; for more
> information about Mercurial and SSH keys, see the converted development
> FAQ: http://potrou.net/hgdevguide/faq.html#faq )
>
> If you are not a core developer:
>
>    $ hg clone http://hg.python.org/cpython
>
> Your clone will contain the following branches:
>
>    $ hg branches
>    default                    68026:f12ef116dd10
>    3.2                        68025:cef92ee1a323
>    2.7                        68010:8174d00d0797
>    3.1                        67955:5be8b695ea86
>    2.6                        67287:5e26a860eded
>    2.5                        65464:e4ecac76e499
>    trunk                      62750:800f6c92c3ed
>    3.0                        60075:1d05144224fe
>    2.4                        58552:df72cac1899e
>    2.3                        45731:a3d9a9730743
>    2.2                        40444:d55ddc8c8501
>    2.1                        30171:06fcccf6eca8
>    2.0                        18214:dc0dfc9565cd
>
> The branch "default" is the current py3k branch from SVN. The branch
> "trunk" represents SVN trunk history until 2.7 was branched for
> maintenance.
>

Just to help justify it in my head, the trunk branch exists for the history
and nothing more, right? I mean we are not even accepting commits on it
after we branched so I assume there is no real new history there compared to
2.7. Could we actually close the branch so it isn't even visible by default
to prevent confusing people?

-Brett


>
> The full list of tags is too long to print here, but you can get it
> using:
>
>    $ hg tags
>
> The size of the repository on-disk is (depending on your filesystem):
>
>    $ du -hs .hg
>    176M    .hg
>
> (the size of the network transfer is estimated to be around 80MB)
>
> You can commit and even push to this repository (the latter if you are a
> core developer).  Since this is a test repository, whatever you push
> will be discarded when we do the final conversion.
>
>
> CPython with extra history: http://hg.python.org/cpythonextrahist/
> --------------------------
>
> This repository is bigger, and has a much more complicated topology. It
> is a superset of the other repository, and contains the totality of the
> branches from the SVN repository (it has more than 450 repository
> heads, of which 87 non-closed). It also weighs quite a bit more:
>
>    $ du -hs .hg
>    248M    .hg
>
> This repository is unnecessary for development work, since even for
> history-digging purposes the normal repository has the necessary
> information. This repository is only to preserve historical record of
> some of the non-trunk development work from the SVN repository (such
> as orphaned/deleted feature branches).
>

Just to give a comparison to svn, release-27maint is 243M and py3k is 231M
(and that is with `make distclean` run). IOW the complete history of all
branches of Python is just 5M bigger than just a checkout of 2.7.

-Brett


>
>
> Development guide: http://potrou.net/hgdevguide/
> -----------------
>
> This is the development guide adapted for Mercurial.  You can get its
> sources from the branch "hg_transition" in
> http://hg.python.org/devguide/.
>
>
> 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/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110224/5b91ace8/attachment-0001.html>

From eliben at gmail.com  Fri Feb 25 06:38:32 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Fri, 25 Feb 2011 07:38:32 +0200
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225011904.3ed09de7@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
Message-ID: <AANLkTi=g_ZBMjEr_1w6HRKprsDg3W0M9v8ZR6XYhDyc9@mail.gmail.com>

On Fri, Feb 25, 2011 at 02:19, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hello,
>
> Georg and I have been working on converting the SVN repository to
> Mercurial. We can now present you a test repository (actually, two).
>
>
> CPython repository: http://hg.python.org/cpython/
> ------------------
>
> This is the main conversion repository. It contains all history of
> trunk and py3k (since 1990!) up to now, including all maintenance
> branches starting from 2.0 up to 3.2.
>
> If you are a core developer, get your local clone of the repository
> using:
>
> ? ?$ hg clone ssh://hg at hg.python.org/cpython
>
> (this uses the same SSH key as your Subversion access; for more
> information about Mercurial and SSH keys, see the converted development
> FAQ: http://potrou.net/hgdevguide/faq.html#faq )
>

Yay - Mercurial at last! Thanks for pushing this forward. I'll do some
tests with the new repo later today.
Eli

From g.brandl at gmx.net  Fri Feb 25 07:46:04 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 25 Feb 2011 07:46:04 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225011904.3ed09de7@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
Message-ID: <ik7j8s$kis$1@dough.gmane.org>

On 25.02.2011 01:19, Antoine Pitrou wrote:
> 
> Hello,
> 
> Georg and I have been working on converting the SVN repository to
> Mercurial. We can now present you a test repository (actually, two).

The implied agenda is that we would be *very* happy if we could do the
final conversion during PyCon (we both won't be attending, so we have
plenty of time ;)  -- so that the sprints can already benefit from the
agility provided by hg.

That's a timescale of around two weeks, which should be plenty for
testing.

> CPython repository: http://hg.python.org/cpython/
> ------------------
> 
> This is the main conversion repository. It contains all history of
> trunk and py3k (since 1990!) up to now, including all maintenance
> branches starting from 2.0 up to 3.2.
> 
> If you are a core developer, get your local clone of the repository
> using:
> 
>     $ hg clone ssh://hg at hg.python.org/cpython
> 
> (this uses the same SSH key as your Subversion access; for more
> information about Mercurial and SSH keys, see the converted development
> FAQ: http://potrou.net/hgdevguide/faq.html#faq )

[...]

> You can commit and even push to this repository (the latter if you are a
> core developer).  Since this is a test repository, whatever you push
> will be discarded when we do the final conversion.

So, to stress this point:  Please *do* experiment, commit and push stuff
to this repository, especially if you've not worked with hg before.  You
can break nothing (or if you do, it's not your fault :)

Georg


From eliben at gmail.com  Fri Feb 25 08:29:16 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Fri, 25 Feb 2011 09:29:16 +0200
Subject: [Python-Dev] strange buildbot fail
Message-ID: <AANLkTi=j1ntM869qbFkRXsbqVO2-CRv_XbgQZL9uye4C@mail.gmail.com>

Hi,
Earlier today I've committed revision 88554, and a bit later a
buildbot failure message was received:
Builder AMD64 Windows Server 2008 hg-3.x build #47 failed with failed
test_import, blamelist having my name because I made the last commit
(apparently).

Two other buildbots succeeded building and testing after my commit, as
did my local tests. Some examination of the failed test shows no
apparent connection to my commit.

What can be done in cases like this? How to investigate further?
Thanks in advance,
Eli

From dirkjan at ochtman.nl  Fri Feb 25 08:50:16 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Fri, 25 Feb 2011 08:50:16 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225011904.3ed09de7@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
Message-ID: <AANLkTina1qLUE0dnp_zvZtuwBT6qQhBm_MTAZvwO7ia9@mail.gmail.com>

On Fri, Feb 25, 2011 at 01:19, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Georg and I have been working on converting the SVN repository to
> Mercurial. We can now present you a test repository (actually, two).

Sorry everyone for taking so long on the conversion. Looks like
Antoine and Georg have more time and energy to spend on this than I
do, so I will let them pick up my slack.

Cheers,

Dirkjan

From martin at v.loewis.de  Fri Feb 25 09:09:36 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 25 Feb 2011 09:09:36 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225011904.3ed09de7@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
Message-ID: <4D6763C0.3030904@v.loewis.de>

> Georg and I have been working on converting the SVN repository to
> Mercurial. We can now present you a test repository (actually, two).

Thanks for working on this!

How do you want bugs reported?

Can you please update the PEP? I see at least the following deviations:
- the extrahist repository is not mentioned
- the branchmap is (apparently?) not evaluated; in particular,
  it's not clear whether the keep-clone branches went.
- it's not clear what your view on the subversion repository
  is - do you keep the notion of discarded branches (i.e. branches
  that can only be discovered from looking at a copy of the subversion
  repository), or do you mean to convert everything?

As for the cpythonextrahist repository: why are the heads all unnamed?
How are you supposed to find anything in it?

I think I would have liked the strategy of the PEP better (i.e.
create clones for feature branches, rather than putting all
in a single repository).

Regards,
Martin

From nyamatongwe at gmail.com  Fri Feb 25 09:13:49 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Fri, 25 Feb 2011 19:13:49 +1100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225011904.3ed09de7@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
Message-ID: <AANLkTik3nDpUHaiR2X8txV=AaxX0asr6uHWBLmvNnGCE@mail.gmail.com>

   With hg 1.7.5 on Windows 7 I performed a non-core checkout:

hg clone http://hg.python.org/cpython

   The eol extension is enabled in global settings. I looked at things
a bit, opening some files and using the Tortoise Hg Repository
Explorer. But made no actual changes. Running hg diff produces a large
amount of output with almost all the *.decTest and most of the Windows
build files (*.mk, *.sln, *.vcproj, *.bat) showing as changed but with
identical text.

   I've had problems like this with Hg before
(http://mercurial.selenic.com/bts/issue2287). The situation can be
fixed by hg update to another version and then back to default.

   Neil

From dirkjan at ochtman.nl  Fri Feb 25 09:17:28 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Fri, 25 Feb 2011 09:17:28 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D6763C0.3030904@v.loewis.de>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
Message-ID: <AANLkTimeBMZYFoz5q-umwCawPcVwNAPtWX4J9R=nGSHr@mail.gmail.com>

On Fri, Feb 25, 2011 at 09:09, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I think I would have liked the strategy of the PEP better (i.e.
> create clones for feature branches, rather than putting all
> in a single repository).

Unnamed heads are trivial to convert to clones.

Cheers,

Dirkjan

From martin at v.loewis.de  Fri Feb 25 09:21:00 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 25 Feb 2011 09:21:00 +0100
Subject: [Python-Dev] strange buildbot fail
In-Reply-To: <AANLkTi=j1ntM869qbFkRXsbqVO2-CRv_XbgQZL9uye4C@mail.gmail.com>
References: <AANLkTi=j1ntM869qbFkRXsbqVO2-CRv_XbgQZL9uye4C@mail.gmail.com>
Message-ID: <4D67666C.4080707@v.loewis.de>

Am 25.02.2011 08:29, schrieb Eli Bendersky:
> Hi,
> Earlier today I've committed revision 88554, and a bit later a
> buildbot failure message was received:
> Builder AMD64 Windows Server 2008 hg-3.x build #47 failed with failed
> test_import, blamelist having my name because I made the last commit
> (apparently).
> 
> Two other buildbots succeeded building and testing after my commit, as
> did my local tests. Some examination of the failed test shows no
> apparent connection to my commit.
> 

You find the builder here:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%20hg-3.x

The specific build you can find here

http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%20hg-3.x/builds/47

The failing build step is here

http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%20hg-3.x/builds/47/steps/test/logs/stdio

The failure message is this:

test test_import failed -- Traceback (most recent call last):
  File
"c:\buildslave-py3k\hg-3.x.curtin-win2008-amd64\build\lib\test\test_import.py",
line 182, in test_failing_import_sticks
    self.assertRaises(ZeroDivisionError, __import__, TESTFN)
AssertionError: ZeroDivisionError not raised by __import__

In re-running the test, the test succeeded:

test_failing_import_sticks (test.test_import.ImportTests) ... ok

So apparently, this test case has a transient failure. It's not
obvious (to me) why there might be a transient failure in this
test case.

> What can be done in cases like this? How to investigate further?

One way of dealing with it is to ignore it. If you do want to
investigate further, try to reproduce the failure. It may be
that the specific sequence in which the tests are executed
can cause the failure. Or it's specific to the Windows installation,
and some interaction with the virus scanner, in which case you
should ask Brian for remote-desktop access to the build slave
in order to reproduce it.

HTH,
Martin

From martin at v.loewis.de  Fri Feb 25 09:25:31 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 25 Feb 2011 09:25:31 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTimeBMZYFoz5q-umwCawPcVwNAPtWX4J9R=nGSHr@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<AANLkTimeBMZYFoz5q-umwCawPcVwNAPtWX4J9R=nGSHr@mail.gmail.com>
Message-ID: <4D67677B.6060706@v.loewis.de>

Am 25.02.2011 09:17, schrieb Dirkjan Ochtman:
> On Fri, Feb 25, 2011 at 09:09, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I think I would have liked the strategy of the PEP better (i.e.
>> create clones for feature branches, rather than putting all
>> in a single repository).
> 
> Unnamed heads are trivial to convert to clones.

If there are hundreds of them, it's far from trivial. I don't even know
how to find out which one to convert.

Regards,
Martin

From dirkjan at ochtman.nl  Fri Feb 25 09:29:05 2011
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Fri, 25 Feb 2011 09:29:05 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D67677B.6060706@v.loewis.de>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<AANLkTimeBMZYFoz5q-umwCawPcVwNAPtWX4J9R=nGSHr@mail.gmail.com>
	<4D67677B.6060706@v.loewis.de>
Message-ID: <AANLkTinurQZA_j0K09SUAATE9Nr6f4OFaM-sAstFepR2@mail.gmail.com>

On Fri, Feb 25, 2011 at 09:25, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> If there are hundreds of them, it's far from trivial. I don't even know
> how to find out which one to convert.

Right, I mostly mean it's trivial for Antoine or Georg to extract into
a clone (at least that's how I was planning to do it, not sure what
their idea is).

Cheers,

Dirkjan

From martin at v.loewis.de  Fri Feb 25 09:36:32 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 25 Feb 2011 09:36:32 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTinurQZA_j0K09SUAATE9Nr6f4OFaM-sAstFepR2@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<AANLkTimeBMZYFoz5q-umwCawPcVwNAPtWX4J9R=nGSHr@mail.gmail.com>
	<4D67677B.6060706@v.loewis.de>
	<AANLkTinurQZA_j0K09SUAATE9Nr6f4OFaM-sAstFepR2@mail.gmail.com>
Message-ID: <4D676A10.6090901@v.loewis.de>

Am 25.02.2011 09:29, schrieb Dirkjan Ochtman:
> On Fri, Feb 25, 2011 at 09:25, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> If there are hundreds of them, it's far from trivial. I don't even know
>> how to find out which one to convert.
> 
> Right, I mostly mean it's trivial for Antoine or Georg to extract into
> a clone (at least that's how I was planning to do it, not sure what
> their idea is).

Ah ok. So I guess that goes back to my original request - that the PEP
be updated.

Regards,
Martin

From juraj.ivancic at gmail.com  Fri Feb 25 09:48:54 2011
From: juraj.ivancic at gmail.com (=?ISO-8859-2?Q?Juraj_Ivan=E8i=E6?=)
Date: Fri, 25 Feb 2011 09:48:54 +0100
Subject: [Python-Dev] PyEval_InitThreads() no longer safe before
	Py_Initialize() in 3.2
Message-ID: <ik7qdr$l8f$1@dough.gmane.org>

It seems that PyEval_InitThreads() can no longer be called before
Py_Initialize(). I get a fatal error in PyThreadState_GET().
This contradicts the documentation

http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads

Minimal repro:

#include "Python.h"
int main()
{
     PyEval_InitThreads();
     return 0;
}


From raymond.hettinger at gmail.com  Fri Feb 25 10:50:13 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Fri, 25 Feb 2011 01:50:13 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D6763C0.3030904@v.loewis.de>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
Message-ID: <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>


On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote:

> I think I would have liked the strategy of the PEP better (i.e.
> create clones for feature branches, rather than putting all
> in a single repository).

In my brief tests, the single repository has been easy to work with.
If they were separate, it would complicate backporting patches
and merges.  So, I'm happy with how George and Benjamin put this together.

Raymond


From solipsis at pitrou.net  Fri Feb 25 13:52:58 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 13:52:58 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTik3nDpUHaiR2X8txV=AaxX0asr6uHWBLmvNnGCE@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTik3nDpUHaiR2X8txV=AaxX0asr6uHWBLmvNnGCE@mail.gmail.com>
Message-ID: <20110225135258.3cae8851@pitrou.net>

On Fri, 25 Feb 2011 19:13:49 +1100
Neil Hodgson <nyamatongwe at gmail.com> wrote:
>    With hg 1.7.5 on Windows 7 I performed a non-core checkout:
> 
> hg clone http://hg.python.org/cpython
> 
>    The eol extension is enabled in global settings.

Yes, please try to disable it. The issue is we have a .hgeol in the
repository right now (it's in the SVN repository too), but it doesn't
match the reality of on-disk files, so when you update, the eol
extension tries to "fix" those files.

Regards

Antoine.

From solipsis at pitrou.net  Fri Feb 25 14:08:51 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 14:08:51 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTi=7RzfF0Vqr3x_xPqGoLQjkzFCagp=kHDQnTuYA@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTi=7RzfF0Vqr3x_xPqGoLQjkzFCagp=kHDQnTuYA@mail.gmail.com>
Message-ID: <20110225140851.5a655cfb@pitrou.net>

On Thu, 24 Feb 2011 17:39:40 -0800
Brett Cannon <brett at python.org> wrote:
> >
> > Your clone will contain the following branches:
> >
> >    $ hg branches
> >    default                    68026:f12ef116dd10
> >    3.2                        68025:cef92ee1a323
> >    2.7                        68010:8174d00d0797
> >    3.1                        67955:5be8b695ea86
> >    2.6                        67287:5e26a860eded
> >    2.5                        65464:e4ecac76e499
> >    trunk                      62750:800f6c92c3ed
> >    3.0                        60075:1d05144224fe
> >    2.4                        58552:df72cac1899e
> >    2.3                        45731:a3d9a9730743
> >    2.2                        40444:d55ddc8c8501
> >    2.1                        30171:06fcccf6eca8
> >    2.0                        18214:dc0dfc9565cd
> >
> > The branch "default" is the current py3k branch from SVN. The branch
> > "trunk" represents SVN trunk history until 2.7 was branched for
> > maintenance.
> >
> 
> Just to help justify it in my head, the trunk branch exists for the history
> and nothing more, right?

True.

> Could we actually close the branch so it isn't even visible by default
> to prevent confusing people?

Yes, we can. This can be done post-conversion, actually. Something like:

$ hg up trunk
$ hg ci --close-branch -m "Close trunk"

Regards

Antoine.

From g.brandl at gmx.net  Fri Feb 25 14:14:17 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 25 Feb 2011 14:14:17 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D67677B.6060706@v.loewis.de>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<AANLkTimeBMZYFoz5q-umwCawPcVwNAPtWX4J9R=nGSHr@mail.gmail.com>
	<4D67677B.6060706@v.loewis.de>
Message-ID: <ik8a0i$a0h$1@dough.gmane.org>

On 25.02.2011 09:25, "Martin v. L?wis" wrote:
> Am 25.02.2011 09:17, schrieb Dirkjan Ochtman:
>> On Fri, Feb 25, 2011 at 09:09, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> I think I would have liked the strategy of the PEP better (i.e.
>>> create clones for feature branches, rather than putting all
>>> in a single repository).
>> 
>> Unnamed heads are trivial to convert to clones.
> 
> If there are hundreds of them, it's far from trivial. I don't even know
> how to find out which one to convert.

The full-history repo has several ways to get at that information, so it's
quite for us to extract feature branches as separate clones.

Since most side-track branches won't actually be needed anymore, we'd like
to reconstruct them on request.  I assume you'd like to have pep-0383?

Georg


From barry at python.org  Fri Feb 25 17:12:53 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 25 Feb 2011 11:12:53 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
Message-ID: <20110225111253.2f34357e@limelight.wooz.org>

On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:

>
>On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote:
>
>> I think I would have liked the strategy of the PEP better (i.e.
>> create clones for feature branches, rather than putting all
>> in a single repository).
>
>In my brief tests, the single repository has been easy to work with.
>If they were separate, it would complicate backporting patches
>and merges.  So, I'm happy with how George and Benjamin put this together.

The way I work with the Subversion branches is to have all the active branches
checked out into separate directories under a common parent, e.g.

~/projects/python/py26
~/projects/python/py27
~/projects/python/trunk
~/projects/python/py31
~/projects/python/py32
~/projects/python/py3k

This makes it very easy to just cd, svn up, make distclean, configure, make to
test things.  How can I do this with the hg clone when all the branches are
in the single repository, but more or less hidden?  After doing the 'hg clone'
operation specified by Antoine, I'm left with a single cpython directory
containing (iiuc) the contents of the 'default' branch.

I'm sure I'm not the only one who works this way with Subversion.  IWBN to
cover this in the devguide (or is it there and I missed it?).

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/20110225/89c3240a/attachment.pgp>

From techtonik at gmail.com  Fri Feb 25 17:13:09 2011
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 25 Feb 2011 18:13:09 +0200
Subject: [Python-Dev] 3.2.0 == 20th anniversary release
In-Reply-To: <ik3qqb$vo5$1@dough.gmane.org>
References: <ik3kee$kvf$1@dough.gmane.org>
	<AANLkTi=6DmdJcKP7hF=ek_eV66ZAESVuB8YZDfWRFsb7@mail.gmail.com>
	<ik3m72$uk6$1@dough.gmane.org>
	<AANLkTi=OLJ+rHoE9mKhVGgK4xjFhj5CCFgrVeBSwbPUV@mail.gmail.com>
	<4D656346.901@v.loewis.de> <ik3qqb$vo5$1@dough.gmane.org>
Message-ID: <AANLkTikjKk9G4DV6xgxXL4yRXHT2pZLzozbi_a4bSTan@mail.gmail.com>

On Wed, Feb 23, 2011 at 10:30 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> On 23.02.2011 20:43, "Martin v. L?wis" wrote:
>>> Or you realized later how nice it would be, grabbed the time machine,
>>> and fixed 10 release blockers on the 19th. :)
>>
>> No no no. He actually grabbed the time machine, drove 20 years back,
>> and gave it to Guido so he could release Python 0.9 in time. Guido
>> then kept the machine ever since.
>
> Uh oh. Temporal mechanics gives me headaches.

While SciPy conference folks are inventing pythonic API for that
stuff, the most we can do now is analyze reasons for missing goals and
aims from this period, and try to neutralize their effect as the
Python grows.
--
anatoly t.

From solipsis at pitrou.net  Fri Feb 25 17:29:01 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 17:29:01 +0100
Subject: [Python-Dev] 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>
Message-ID: <20110225172901.36dffde6@pitrou.net>


Hi Barry,

> The way I work with the Subversion branches is to have all the active branches
> checked out into separate directories under a common parent, e.g.
> 
> ~/projects/python/py26
> ~/projects/python/py27
> ~/projects/python/trunk
> ~/projects/python/py31
> ~/projects/python/py32
> ~/projects/python/py3k
> 
> This makes it very easy to just cd, svn up, make distclean, configure, make to
> test things.  How can I do this with the hg clone when all the branches are
> in the single repository, but more or less hidden?  After doing the 'hg clone'
> operation specified by Antoine, I'm left with a single cpython directory
> containing (iiuc) the contents of the 'default' branch.

Indeed, the default branch is checked out by default. But you can
switch to another branch:

$ hg sum
parent: 68026:f12ef116dd10 tip
 In FTP.close() method, make sure to also close the socket object, not only the file.
branch: default
commit: (clean)
update: (current)

$ hg up 2.7
3310 files updated, 0 files merged, 378 files removed, 0 files unresolved

$ hg sum
parent: 68010:8174d00d0797 
 Merged revisions 88486 via svnmerge from
branch: 2.7
commit: (clean)
update: (current)

("hg sum" is a shorthand for "hg summary")

Furthermore, once you have a local clone, you can clone it further to
get several independent clones, and keep each of them updated on
whatever branch you want. This makes it easy to replicate your workflow
(by having a "master clone" - a mirror if you want - and then child
clones that get updated from the master clone by running "hg pull").

> I'm sure I'm not the only one who works this way with Subversion.  IWBN to
> cover this in the devguide (or is it there and I missed it?).

Use of "hg update" to switch between branches is mentioned in 
http://potrou.net/hgdevguide/setup.html#getting-the-source-code
and also http://potrou.net/hgdevguide/coredev.html#read-write-checkout
and also in
http://potrou.net/hgdevguide/committing.html#porting-within-a-major-version.

But a dedicated FAQ entry could be added.

Regards

Antoine.



From g.brandl at gmx.net  Fri Feb 25 17:31:45 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 25 Feb 2011 17:31:45 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225111253.2f34357e@limelight.wooz.org>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
Message-ID: <ik8lj4$evr$1@dough.gmane.org>

On 25.02.2011 17:12, Barry Warsaw wrote:
> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
> 
>>
>>On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote:
>>
>>> I think I would have liked the strategy of the PEP better (i.e.
>>> create clones for feature branches, rather than putting all
>>> in a single repository).
>>
>>In my brief tests, the single repository has been easy to work with.
>>If they were separate, it would complicate backporting patches
>>and merges.  So, I'm happy with how George and Benjamin put this together.
> 
> The way I work with the Subversion branches is to have all the active branches
> checked out into separate directories under a common parent, e.g.
> 
> ~/projects/python/py26
> ~/projects/python/py27
> ~/projects/python/trunk
> ~/projects/python/py31
> ~/projects/python/py32
> ~/projects/python/py3k
> 
> This makes it very easy to just cd, svn up, make distclean, configure, make to
> test things.  How can I do this with the hg clone when all the branches are
> in the single repository, but more or less hidden?  After doing the 'hg clone'
> operation specified by Antoine, I'm left with a single cpython directory
> containing (iiuc) the contents of the 'default' branch.

Two scenarios are possible:

* You make a clone per branch with the full history, with the current branch
  being different in each of those.  Since "hg update" updates to the head of
  the current branch, this should be easy to do.  When you pull from the single
  repo you will get changes for the other branches as well, but they will not
  bother you.

* You make a clone per branch, containing *only* the respective branch (with
  its ancestors).  This is done by using "URI#branchname" as the source when
  cloning/pulling.

Both should work equally well, with the former giving larger repository sizes,
and the latter taking somewhat longer on the initial clone.

Georg


From g.brandl at gmx.net  Fri Feb 25 17:42:55 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 25 Feb 2011 17:42:55 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <ik8lj4$evr$1@dough.gmane.org>
References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de>
	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
	<ik8lj4$evr$1@dough.gmane.org>
Message-ID: <ik8m7o$imu$1@dough.gmane.org>

On 25.02.2011 17:31, Georg Brandl wrote:
> On 25.02.2011 17:12, Barry Warsaw wrote:
>> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
>> 
>>>
>>>On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote:
>>>
>>>> I think I would have liked the strategy of the PEP better (i.e.
>>>> create clones for feature branches, rather than putting all
>>>> in a single repository).
>>>
>>>In my brief tests, the single repository has been easy to work with.
>>>If they were separate, it would complicate backporting patches
>>>and merges.  So, I'm happy with how George and Benjamin put this together.
>> 
>> The way I work with the Subversion branches is to have all the active branches
>> checked out into separate directories under a common parent, e.g.
>> 
>> ~/projects/python/py26
>> ~/projects/python/py27
>> ~/projects/python/trunk
>> ~/projects/python/py31
>> ~/projects/python/py32
>> ~/projects/python/py3k
>> 
>> This makes it very easy to just cd, svn up, make distclean, configure, make to
>> test things.  How can I do this with the hg clone when all the branches are
>> in the single repository, but more or less hidden?  After doing the 'hg clone'
>> operation specified by Antoine, I'm left with a single cpython directory
>> containing (iiuc) the contents of the 'default' branch.
> 
> Two scenarios are possible:
> 
> * You make a clone per branch with the full history, with the current branch
>   being different in each of those.  Since "hg update" updates to the head of
>   the current branch, this should be easy to do.  When you pull from the single
>   repo you will get changes for the other branches as well, but they will not
>   bother you.
> 
> * You make a clone per branch, containing *only* the respective branch (with
>   its ancestors).  This is done by using "URI#branchname" as the source when
>   cloning/pulling.
> 
> Both should work equally well, with the former giving larger repository sizes,
> and the latter taking somewhat longer on the initial clone.

Ah, and the latter obviously also won't work with the "hg-native" workflow
(merging between the branches using hg merge).

Georg


From status at bugs.python.org  Fri Feb 25 18:07:03 2011
From: status at bugs.python.org (Python tracker)
Date: Fri, 25 Feb 2011 18:07:03 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20110225170703.F22FE1CC70@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2011-02-18 - 2011-02-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    2682 (+27)
  closed 20422 (+52)
  total  23104 (+79)

Open issues with patches: 1137 


Issues opened (56)
==================

#11244: Negative tuple elements produce inefficient code.
http://bugs.python.org/issue11244  opened by jdharper

#11245: Implementation of IMAP IDLE in imaplib?
http://bugs.python.org/issue11245  opened by Shay.Rojansky

#11246: PyUnicode_FromFormat("%V") decodes the byte string from ISO-88
http://bugs.python.org/issue11246  opened by haypo

#11247: Error sending packets to multicast IPV4 address
http://bugs.python.org/issue11247  opened by dmahn

#11250: 2to3 truncates files at formfeed character
http://bugs.python.org/issue11250  opened by cgohlke

#11253: autodocument first appearance of ctypes.wintypes constants
http://bugs.python.org/issue11253  opened by techtonik

#11254: distutils doesn't byte-compile .py files to __pycache__ during
http://bugs.python.org/issue11254  opened by scoder

#11255: 2to3 throws AttributeError during distutils installation with 
http://bugs.python.org/issue11255  opened by scoder

#11256: inspect.getcallargs raises TypeError on valid arguments
http://bugs.python.org/issue11256  opened by durban

#11257: asyncore stores unnecessary object references
http://bugs.python.org/issue11257  opened by mmarkk

#11258: ctypes: Speed up find_library() on Linux by 500%
http://bugs.python.org/issue11258  opened by jonash

#11259: asynchat does not check if terminator is negative integer
http://bugs.python.org/issue11259  opened by mmarkk

#11260: smtpd-as-a-script feature should be documented and should use 
http://bugs.python.org/issue11260  opened by xmorel

#11261: urlopen breaks when data parameter is used.
http://bugs.python.org/issue11261  opened by david193

#11265: asyncore does not check for EAGAIN errno
http://bugs.python.org/issue11265  opened by mmarkk

#11266: asyncore does not handle EINTR in recv, send, connect, accept,
http://bugs.python.org/issue11266  opened by mmarkk

#11267: asyncore does not check for POLLERR and POLLHUP if neither rea
http://bugs.python.org/issue11267  opened by mmarkk

#11270: logging: RotatingFileHandler crash when opening the Logfile in
http://bugs.python.org/issue11270  opened by RockstarVC

#11271: concurrent.futures.ProcessPoolExecutor.map() slower than multi
http://bugs.python.org/issue11271  opened by tbrink

#11273: asyncore creates selec (or poll) on every iteration
http://bugs.python.org/issue11273  opened by mmarkk

#11275: Linking to gcc's gomp causes crash later.
http://bugs.python.org/issue11275  opened by hoytak

#11276: 2to3: imports fixer doesn't update references to modules speci
http://bugs.python.org/issue11276  opened by Arfrever

#11279: test_posix and lack of "id -G" support - less noise required?
http://bugs.python.org/issue11279  opened by illumino

#11281: smtplib: add ability to bind to specific source IP address/por
http://bugs.python.org/issue11281  opened by paulos

#11282: unittest document not keep consist with code
http://bugs.python.org/issue11282  opened by ysj.ray

#11283: incorrect pattern in the re module docs for conditional regex
http://bugs.python.org/issue11283  opened by wesley.chun

#11284: slow close file descriptors in subprocess, popen2, os.pepen*
http://bugs.python.org/issue11284  opened by s7v7nislands

#11287: Add context manager support to dbm modules
http://bugs.python.org/issue11287  opened by ysj.ray

#11289: smtplib context manager
http://bugs.python.org/issue11289  opened by giampaolo.rodola

#11290: ttk.Combobox['values'] String Conversion to Tcl
http://bugs.python.org/issue11290  opened by claytondarwin

#11291: poplib suppresses exception on QUIT
http://bugs.python.org/issue11291  opened by giampaolo.rodola

#11292: Curses - add A_REVERSE to attributes table
http://bugs.python.org/issue11292  opened by sandro.tosi

#11293: Distutils - read the file when using it in long_description
http://bugs.python.org/issue11293  opened by sandro.tosi

#11294: Locale - update & uniform ERA_*_FMT doc
http://bugs.python.org/issue11294  opened by sandro.tosi

#11297: Make ChainMap() public in the collections module.
http://bugs.python.org/issue11297  opened by rhettinger

#11298: unittest discovery needs better explanation
http://bugs.python.org/issue11298  opened by blokeley

#11299: Allow deepcopying and pickling paused generators
http://bugs.python.org/issue11299  opened by cool-RR

#11300: mmap() large file failures on Mac OS X docfix
http://bugs.python.org/issue11300  opened by sdaoden

#11302: Add more tests to test_ast.py
http://bugs.python.org/issue11302  opened by vincele

#11303: b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1
http://bugs.python.org/issue11303  opened by belopolsky

#11305: TextIOWrapper.readline and str.splitlines have different behav
http://bugs.python.org/issue11305  opened by benjamin.peterson

#11306: mailbox should test for errno.EROFS
http://bugs.python.org/issue11306  opened by matt

#11307: re engine exhaustively explores more than necessary
http://bugs.python.org/issue11307  opened by nikomatsakis

#11309: #include <wctype.h> in Objects/unicodetype_db.h and	Objects/un
http://bugs.python.org/issue11309  opened by dilyan.palauzov

#11310: Document byte[s|array]() and byte[s|array](count) in docstring
http://bugs.python.org/issue11310  opened by terry.reedy

#11311: StringIO.readline(0) returns incorrect results
http://bugs.python.org/issue11311  opened by scop

#11312: Confusing sentence in file.readline() doc
http://bugs.python.org/issue11312  opened by scop

#11313: Speed up default encode()/decode()
http://bugs.python.org/issue11313  opened by belopolsky

#11314: Subprocess suffers 40% process creation overhead penalty
http://bugs.python.org/issue11314  opened by Aaron.Sherman

#11315: Cookie.py breaks when passed unicode, fix included
http://bugs.python.org/issue11315  opened by Alexander.Tsepkov

#11316: RFC822 header parsing API inconsistencies between httplib.HTTP
http://bugs.python.org/issue11316  opened by jrjsmrtn

#11318: Python 3.2 FAQ example code typo?
http://bugs.python.org/issue11318  opened by Retro

#11319: Command line option -t (and -tt) does not work for a particula
http://bugs.python.org/issue11319  opened by jerome.radix

#11320: Usage of API method Py_SetPath causes errors in Py_Initialize(
http://bugs.python.org/issue11320  opened by palm.kevin

#11321: 9th import of module _pickle always crashes
http://bugs.python.org/issue11321  opened by palm.kevin

#11322: encoding package's normalize_encoding() function is too slow
http://bugs.python.org/issue11322  opened by lemburg



Most recent 15 issues with no replies (15)
==========================================

#11321: 9th import of module _pickle always crashes
http://bugs.python.org/issue11321

#11320: Usage of API method Py_SetPath causes errors in Py_Initialize(
http://bugs.python.org/issue11320

#11319: Command line option -t (and -tt) does not work for a particula
http://bugs.python.org/issue11319

#11315: Cookie.py breaks when passed unicode, fix included
http://bugs.python.org/issue11315

#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

#11300: mmap() large file failures on Mac OS X docfix
http://bugs.python.org/issue11300

#11294: Locale - update & uniform ERA_*_FMT doc
http://bugs.python.org/issue11294

#11293: Distutils - read the file when using it in long_description
http://bugs.python.org/issue11293

#11292: Curses - add A_REVERSE to attributes table
http://bugs.python.org/issue11292

#11291: poplib suppresses exception on QUIT
http://bugs.python.org/issue11291

#11290: ttk.Combobox['values'] String Conversion to Tcl
http://bugs.python.org/issue11290

#11283: incorrect pattern in the re module docs for conditional regex
http://bugs.python.org/issue11283

#11282: unittest document not keep consist with code
http://bugs.python.org/issue11282

#11279: test_posix and lack of "id -G" support - less noise required?
http://bugs.python.org/issue11279



Most recent 15 issues waiting for review (15)
=============================================

#11315: Cookie.py breaks when passed unicode, fix included
http://bugs.python.org/issue11315

#11313: Speed up default encode()/decode()
http://bugs.python.org/issue11313

#11310: Document byte[s|array]() and byte[s|array](count) in docstring
http://bugs.python.org/issue11310

#11303: b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1
http://bugs.python.org/issue11303

#11302: Add more tests to test_ast.py
http://bugs.python.org/issue11302

#11300: mmap() large file failures on Mac OS X docfix
http://bugs.python.org/issue11300

#11298: unittest discovery needs better explanation
http://bugs.python.org/issue11298

#11297: Make ChainMap() public in the collections module.
http://bugs.python.org/issue11297

#11294: Locale - update & uniform ERA_*_FMT doc
http://bugs.python.org/issue11294

#11293: Distutils - read the file when using it in long_description
http://bugs.python.org/issue11293

#11292: Curses - add A_REVERSE to attributes table
http://bugs.python.org/issue11292

#11291: poplib suppresses exception on QUIT
http://bugs.python.org/issue11291

#11289: smtplib context manager
http://bugs.python.org/issue11289

#11287: Add context manager support to dbm modules
http://bugs.python.org/issue11287

#11284: slow close file descriptors in subprocess, popen2, os.pepen*
http://bugs.python.org/issue11284



Top 10 most discussed issues (10)
=================================

#11303: b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1
http://bugs.python.org/issue11303  40 msgs

#11281: smtplib: add ability to bind to specific source IP address/por
http://bugs.python.org/issue11281  13 msgs

#11244: Negative tuple elements produce inefficient code.
http://bugs.python.org/issue11244  11 msgs

#11260: smtpd-as-a-script feature should be documented and should use 
http://bugs.python.org/issue11260  11 msgs

#11243: email/message.py str conversion
http://bugs.python.org/issue11243  10 msgs

#11199: urllib hangs when closing connection
http://bugs.python.org/issue11199   9 msgs

#10791: Wrapping TextIOWrapper around gzip files
http://bugs.python.org/issue10791   8 msgs

#11298: unittest discovery needs better explanation
http://bugs.python.org/issue11298   8 msgs

#11015: Bring test.support docs up to date
http://bugs.python.org/issue11015   7 msgs

#11071: What's New review comments
http://bugs.python.org/issue11071   7 msgs



Issues closed (47)
==================

#4681: mmap offset should be off_t instead of ssize_t, and size calcu
http://bugs.python.org/issue4681  closed by pitrou

#8914: Run clang's static analyzer
http://bugs.python.org/issue8914  closed by brett.cannon

#10512: regrtest ResourceWarning - unclosed sockets and files
http://bugs.python.org/issue10512  closed by brett.cannon

#10516: Add list.clear() and list.copy()
http://bugs.python.org/issue10516  closed by georg.brandl

#10826: pass_fds sometimes fails
http://bugs.python.org/issue10826  closed by pitrou

#10830: PyUnicode_FromFormatV("%c") doesn't support non-BMP characters
http://bugs.python.org/issue10830  closed by haypo

#10867: mmap.flush() issue msync() even if mapping was created with  p
http://bugs.python.org/issue10867  closed by mmarkk

#10868: ABCMeta.register() should work as a decorator
http://bugs.python.org/issue10868  closed by eric.araujo

#10990: tests mutating sys.gettrace() w/o re-instating previous state
http://bugs.python.org/issue10990  closed by brett.cannon

#10992: tests failing when run under coverage
http://bugs.python.org/issue10992  closed by brett.cannon

#11074: fix tokenize so it can be reloaded
http://bugs.python.org/issue11074  closed by brett.cannon

#11085: expose _abcoll as collections.abc
http://bugs.python.org/issue11085  closed by rhettinger

#11086: add lib2to3/__main__.py
http://bugs.python.org/issue11086  closed by brett.cannon

#11089: ConfigParser 50x slower in 2.7
http://bugs.python.org/issue11089  closed by rhettinger

#11168: UnicodeEncodeError on recusion limit if the script filename is
http://bugs.python.org/issue11168  closed by haypo

#11169: compileall doesn't support PEP 383 (undecodable paths/filename
http://bugs.python.org/issue11169  closed by haypo

#11184: Broken large file support on AIX
http://bugs.python.org/issue11184  closed by georg.brandl

#11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede
http://bugs.python.org/issue11187  closed by haypo

#11222: Python3.2rc3 fails to build on Mac OS X with a non-framework b
http://bugs.python.org/issue11222  closed by ned.deily

#11224: 3.2: tarfile.getmembers causes 100% cpu usage on Windows
http://bugs.python.org/issue11224  closed by lars.gustaebel

#11226: subprocesses experience mysterious delay in receiving stdin EO
http://bugs.python.org/issue11226  closed by yaaang

#11232: asyncore - don't throw a traceback when a client disconnects i
http://bugs.python.org/issue11232  closed by giampaolo.rodola

#11234: Error in What's new 3.2rc3 with sysconfig.get_config_var('SO')
http://bugs.python.org/issue11234  closed by eric.araujo

#11238: sets - refer to sets/frozenset in stdtypes
http://bugs.python.org/issue11238  closed by eric.araujo

#11248: Tails of generator get lost under zip()
http://bugs.python.org/issue11248  closed by ezio.melotti

#11249: Memory mismanagement with Py_tp_doc
http://bugs.python.org/issue11249  closed by georg.brandl

#11251: cmd.Cmd tab completion treats dashes as spaces
http://bugs.python.org/issue11251  closed by Jon.McKenzie

#11252: Handling statement OR assignment continuation '\' on Win32 pla
http://bugs.python.org/issue11252  closed by georg.brandl

#11262: re.sub replaces only first 32 matches with re.U flag
http://bugs.python.org/issue11262  closed by SilentGhost

#11263: Wrong link to source code of ftplib
http://bugs.python.org/issue11263  closed by rhettinger

#11264: Format Specification Mini-Language missing type 'i'?
http://bugs.python.org/issue11264  closed by eric.smith

#11268: 3.2 Mac OS X installer may fail if documentation was previousl
http://bugs.python.org/issue11268  closed by ned.deily

#11269: cgi.FieldStorage forgets to unquote field names when parsing m
http://bugs.python.org/issue11269  closed by r.david.murray

#11272: input() has trailing carriage return on windows
http://bugs.python.org/issue11272  closed by haypo

#11274: asyncore does not support epoll
http://bugs.python.org/issue11274  closed by giampaolo.rodola

#11277: test_zlib crashes under Snow Leopard buildbot
http://bugs.python.org/issue11277  closed by pitrou

#11278: raw_input() and input() not stripping EOL on win32
http://bugs.python.org/issue11278  closed by brian.curtin

#11280: urllib2 http_error_302 calls undefined "getheaders" method
http://bugs.python.org/issue11280  closed by orsenthil

#11285: io.py standart stream setup crash
http://bugs.python.org/issue11285  closed by sdaoden

#11286: Some "trivial" python 2.x pickles fails to load in	Python 3.2
http://bugs.python.org/issue11286  closed by belopolsky

#11288: Python installed from MSI doesn't work
http://bugs.python.org/issue11288  closed by loewis

#11295: On Windows, Python crashes on ANSI / Windows-formatted source 
http://bugs.python.org/issue11295  closed by JonathanHayward

#11296: Possible error in What's new in Python 3.2 : duplication of rs
http://bugs.python.org/issue11296  closed by rhettinger

#11301: cookielib.LWPCookieJar.save() doesn't save cookies
http://bugs.python.org/issue11301  closed by mcencula

#11304: Input/output tutorial - PI is rounded not truncated
http://bugs.python.org/issue11304  closed by rhettinger

#11308: extraneous link getit in the main website sidebar
http://bugs.python.org/issue11308  closed by SilentGhost

#11317: Documentation not updated to show string exceptions have been 
http://bugs.python.org/issue11317  closed by georg.brandl

From solipsis at pitrou.net  Fri Feb 25 18:24:26 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 18:24:26 +0100
Subject: [Python-Dev] Mercurial conversion repositories
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTik3nDpUHaiR2X8txV=AaxX0asr6uHWBLmvNnGCE@mail.gmail.com>
	<20110225135258.3cae8851@pitrou.net>
Message-ID: <20110225182426.5f087bfa@pitrou.net>

On Fri, 25 Feb 2011 13:52:58 +0100
Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Fri, 25 Feb 2011 19:13:49 +1100
> Neil Hodgson <nyamatongwe at gmail.com> wrote:
> >    With hg 1.7.5 on Windows 7 I performed a non-core checkout:
> > 
> > hg clone http://hg.python.org/cpython
> > 
> >    The eol extension is enabled in global settings.
> 
> Yes, please try to disable it. The issue is we have a .hgeol in the
> repository right now (it's in the SVN repository too), but it doesn't
> match the reality of on-disk files, so when you update, the eol
> extension tries to "fix" those files.

It should now be fixed in current SVN, meaning the final conversion
should be perfectly usable with the eol extension enabled.

Do you find other issues under Windows? Have you tried pushing changes?

Regards

Antoine.



From solipsis at pitrou.net  Fri Feb 25 18:32:44 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 18:32:44 +0100
Subject: [Python-Dev] r88580 - in python/branches/py3k:
 Doc/library/os.rst Doc/whatsnew/3.3.rst Lib/test/test_os.py Misc/NEWS
 Modules/posixmodule.c configure.in pyconfig.h.in
References: <20110225143916.BEC74EE9A6@mail.python.org>
Message-ID: <20110225183244.0e321e2e@pitrou.net>

On Fri, 25 Feb 2011 15:39:16 +0100 (CET)
giampaolo.rodola <python-checkins at python.org> wrote:

> +#else
> +    *((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg)
> +            : PyLong_AsLong(arg);
> +#endif

There's something fishy here. Why would you call PyLong_AsLong() if
PyLong_Check() is false?

Regards

Antoine.



From adrian at cadifra.com  Fri Feb 25 18:40:53 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Fri, 25 Feb 2011 18:40:53 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225111253.2f34357e@limelight.wooz.org>
References: <20110225011904.3ed09de7@pitrou.net>
	<4D6763C0.3030904@v.loewis.de>	<8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com>
	<20110225111253.2f34357e@limelight.wooz.org>
Message-ID: <4D67E9A5.5030203@cadifra.com>

On 2011-02-25 17:12, Barry Warsaw wrote:
> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
> 
>>
>> On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote:
>>
>>> I think I would have liked the strategy of the PEP better (i.e.
>>> create clones for feature branches, rather than putting all
>>> in a single repository).
>>
>> In my brief tests, the single repository has been easy to work with.
>> If they were separate, it would complicate backporting patches
>> and merges.  So, I'm happy with how George and Benjamin put this together.
> 
> The way I work with the Subversion branches is to have all the active branches
> checked out into separate directories under a common parent, e.g.
> 
> ~/projects/python/py26
> ~/projects/python/py27
> ~/projects/python/trunk
> ~/projects/python/py31
> ~/projects/python/py32
> ~/projects/python/py3k
> 
> This makes it very easy to just cd, svn up, make distclean, configure, make to
> test things.  How can I do this with the hg clone when all the branches are
> in the single repository, but more or less hidden?  After doing the 'hg clone'
> operation specified by Antoine, I'm left with a single cpython directory
> containing (iiuc) the contents of the 'default' branch.
> 
> I'm sure I'm not the only one who works this way with Subversion.  IWBN to
> cover this in the devguide (or is it there and I missed it?).

I know (almost) nothing about developing Python (this is my first post
to this list after lurking for quite a while now), but as a regular
Mercurial contributor, I think the following could be useful for you:

First, get an initial clone (let's name it 'master') over the wire
using: [1]

  $ hg clone -U ssh://hg at hg.python.org/cpython master

Then create a hardlinked clone [2] for working in each branch,
specifying the branch to check out using option -u:

  $ hg clone master py26 -u 2.6
  updating to branch 2.6
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master py27 -u 2.7
  updating to branch 2.7
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master trunk -u trunk
  updating to branch trunk
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master py31 -u 3.1
  updating to branch 3.1
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master py32 -u 3.2
  updating to branch 3.2
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

This will be fast and save space as these local 'branch clones' will
share diskspace inside .hg/store by using hardlinks, and you need to do
the initial slow clone over the wire only once.

Note that each of these branch clones will initially have your local
master repo as the default path [3,4]. If you'd like to have the default
push/pull path to point to ssh://hg at hg.python.org/cpython instead, you'd
want to edit the [paths] section in the .hg/hgrc file in each of the
branch repos. But of course you can also leave the default paths as they
are and synchronize via the master repo (e.g. pull new changesets into
master first, and then pull into the specific branch repo).

[1] http://selenic.com/repo/hg/help/clone
[2] http://mercurial.selenic.com/wiki/HardlinkedClones
[3] http://www.selenic.com/mercurial/hgrc.5.html#paths
[4] http://selenic.com/repo/hg/help/urls

From vinay_sajip at yahoo.co.uk  Fri Feb 25 19:10:28 2011
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Fri, 25 Feb 2011 18:10:28 +0000 (UTC)
Subject: [Python-Dev] Finding buildbot failures
Message-ID: <loom.20110225T190113-46@post.gmane.org>

What's the easiest way of finding which tests failed on buildbot builds? I mean,
is there anything easier than using the Web interface to browse to failing
builds and then looking at the stdio output in a browser?

Thanks,

Vinay Sajip


From rosslagerwall at gmail.com  Fri Feb 25 19:11:20 2011
From: rosslagerwall at gmail.com (Ross Lagerwall)
Date: Fri, 25 Feb 2011 20:11:20 +0200
Subject: [Python-Dev] r88580 - in python/branches/py3k:
 Doc/library/os.rst Doc/whatsnew/3.3.rst Lib/test/test_os.py Misc/NEWS
 Modules/posixmodule.c configure.in pyconfig.h.in
In-Reply-To: <20110225183244.0e321e2e@pitrou.net>
References: <20110225143916.BEC74EE9A6@mail.python.org>
	<20110225183244.0e321e2e@pitrou.net>
Message-ID: <1298657480.3678.4.camel@hobo>

On Fri, 2011-02-25 at 18:32 +0100, Antoine Pitrou wrote:
> On Fri, 25 Feb 2011 15:39:16 +0100 (CET)
> giampaolo.rodola <python-checkins at python.org> wrote:
> 
> > +#else
> > +    *((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg)
> > +            : PyLong_AsLong(arg);
> > +#endif
> 
> There's something fishy here. Why would you call PyLong_AsLong() if
> PyLong_Check() is false?
> 

I'm not entirely sure how that works (other than it seems to!).
The code came from other places where large file support is, such as in
ftruncate() and lseek() in the posix module.

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/rosslagerwall%40gmail.com



From solipsis at pitrou.net  Fri Feb 25 19:35:10 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 19:35:10 +0100
Subject: [Python-Dev] r88580 - in python/branches/py3k:
 Doc/library/os.rst Doc/whatsnew/3.3.rst Lib/test/test_os.py Misc/NEWS
 Modules/posixmodule.c configure.in pyconfig.h.in
In-Reply-To: <1298657480.3678.4.camel@hobo>
References: <20110225143916.BEC74EE9A6@mail.python.org>
	<20110225183244.0e321e2e@pitrou.net>  <1298657480.3678.4.camel@hobo>
Message-ID: <1298658910.3739.1.camel@localhost.localdomain>

Le vendredi 25 f?vrier 2011 ? 20:11 +0200, Ross Lagerwall a ?crit :
> On Fri, 2011-02-25 at 18:32 +0100, Antoine Pitrou wrote:
> > On Fri, 25 Feb 2011 15:39:16 +0100 (CET)
> > giampaolo.rodola <python-checkins at python.org> wrote:
> > 
> > > +#else
> > > +    *((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg)
> > > +            : PyLong_AsLong(arg);
> > > +#endif
> > 
> > There's something fishy here. Why would you call PyLong_AsLong() if
> > PyLong_Check() is false?
> > 
> 
> I'm not entirely sure how that works (other than it seems to!).
> The code came from other places where large file support is, such as in
> ftruncate() and lseek() in the posix module.

Ok, then I guess that code was ported straightly from 2.x without really
a thought.
Thanks for your contribution, by the way!

Regards

Antoine.



From solipsis at pitrou.net  Fri Feb 25 19:36:07 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 19:36:07 +0100
Subject: [Python-Dev] Finding buildbot failures
References: <loom.20110225T190113-46@post.gmane.org>
Message-ID: <20110225193607.73117b01@pitrou.net>

On Fri, 25 Feb 2011 18:10:28 +0000 (UTC)
Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> What's the easiest way of finding which tests failed on buildbot builds? I mean,
> is there anything easier than using the Web interface to browse to failing
> builds and then looking at the stdio output in a browser?

Not really, but that becomes quite easy once you're used to it.
Good luck :)

Regards

Antoine.



From fuzzyman at voidspace.org.uk  Fri Feb 25 19:47:53 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 25 Feb 2011 18:47:53 +0000
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <loom.20110225T190113-46@post.gmane.org>
References: <loom.20110225T190113-46@post.gmane.org>
Message-ID: <4D67F959.8080701@voidspace.org.uk>

On 25/02/2011 18:10, Vinay Sajip wrote:
> What's the easiest way of finding which tests failed on buildbot builds? I mean,
> is there anything easier than using the Web interface to browse to failing
> builds and then looking at the stdio output in a browser?

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.

Michael

> Thanks,
>
> Vinay Sajip
>
> _______________________________________________
> 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 g.brandl at gmx.net  Fri Feb 25 19:49:48 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 25 Feb 2011 19:49:48 +0100
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <loom.20110225T190113-46@post.gmane.org>
References: <loom.20110225T190113-46@post.gmane.org>
Message-ID: <ik8tlk$ud5$1@dough.gmane.org>

On 25.02.2011 19:10, Vinay Sajip wrote:
> What's the easiest way of finding which tests failed on buildbot builds? I mean,
> is there anything easier than using the Web interface to browse to failing
> builds and then looking at the stdio output in a browser?

Once every failure sent a mail to python-checkins; I had modified the email
reporting to include as much info about the failed test as possible.

However, there were so many of these emails that we discontinued sending them.

Georg



From exarkun at twistedmatrix.com  Fri Feb 25 20:00:14 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Fri, 25 Feb 2011 19:00:14 -0000
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <4D67F959.8080701@voidspace.org.uk>
References: <loom.20110225T190113-46@post.gmane.org>
	<4D67F959.8080701@voidspace.org.uk>
Message-ID: <20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain>

On 06:47 pm, fuzzyman at voidspace.org.uk wrote:
>On 25/02/2011 18:10, Vinay Sajip wrote:
>>What's the easiest way of finding which tests failed on buildbot 
>>builds? I mean,
>>is there anything easier than using the Web interface to browse to 
>>failing
>>builds and then looking at the stdio output in a browser?
>
>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.

Jean-Paul

From benjamin at python.org  Fri Feb 25 20:39:27 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 25 Feb 2011 13:39:27 -0600
Subject: [Python-Dev] [Python-checkins] cpython (2.7): Update copyright
	years.
In-Reply-To: <E1Pt3Rv-0007zY-64@dinsdale.python.org>
References: <E1Pt3Rv-0007zY-64@dinsdale.python.org>
Message-ID: <AANLkTikV+8qeo6NyGmrJHYsXekDQUhvCxSfw3a3d=ioE@mail.gmail.com>

2011/2/25 barry.warsaw <python-checkins at python.org>:
> barry.warsaw pushed 9619d21d8198 to cpython:
>
> http://hg.python.org/cpython/rev/9619d21d8198
> changeset: ? 68030:9619d21d8198
> branch: ? ? ?2.7
> tag: ? ? ? ? tip
> parent: ? ? ?68010:8174d00d0797
> user: ? ? ? ?Barry Warsaw <barry at python.org>
> date: ? ? ? ?Fri Feb 25 14:35:22 2011 -0500
> summary:
> ?Update copyright years.
>
> files:
> ?Python/Python-ast.c
> ?README
>
> 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__ 82160.
> + ? __version__ .

Ah, this reminds me. Figuring out what to do with the AST version
should probably be a hg roadmap topic.



-- 
Regards,
Benjamin

From barry at python.org  Fri Feb 25 20:43:15 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 25 Feb 2011 14:43:15 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D67E9A5.5030203@cadifra.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>
Message-ID: <20110225144315.3eebcafc@limelight.wooz.org>

On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:

>First, get an initial clone (let's name it 'master') over the wire
>using: [1]
>
>  $ hg clone -U ssh://hg at hg.python.org/cpython master
>
>Then create a hardlinked clone [2] for working in each branch,
>specifying the branch to check out using option -u:
>
>  $ hg clone master py26 -u 2.6
>  updating to branch 2.6
>  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved
>
>  $ hg clone master py27 -u 2.7
>  updating to branch 2.7
>  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved
>
>  $ hg clone master trunk -u trunk
>  updating to branch trunk
>  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved
>
>  $ hg clone master py31 -u 3.1
>  updating to branch 3.1
>  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved
>
>  $ hg clone master py32 -u 3.2
>  updating to branch 3.2
>  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved
>
>Note that each of these branch clones will initially have your local
>master repo as the default path [3,4]. If you'd like to have the default
>push/pull path to point to ssh://hg at hg.python.org/cpython instead, you'd
>want to edit the [paths] section in the .hg/hgrc file in each of the
>branch repos.

Thanks very much Adrian, this is exactly what I was looking for.  It maps
almost directly to my current mental model for working on Python in Subversion
(and truth be told, also how I do/did it with Bazaar).

It does leave me with an empty 'master' directory that I basically won't
touch, though I suppose I could hide it in a dot-filename.  And I have to
remember to fiddle with .hg/hgrc when I clone a new branch working directory,
but I guess that's mostly a one-time cost.

I'll have to remember that 'hg pull' does not update the working copy by
default, and eventually I'll figure out the whole merge thing.

One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes
my editor and always shows me a 'diff -u' in the commit message buffer.  This
is incredibly handy because I don't have to remember to do the diff in a
different window, and I always have all the information I want right there to
craft the commit message.  It doesn't look like this is possible with 'hg
commit' though, right?

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/20110225/58ef475c/attachment.pgp>

From barry at python.org  Fri Feb 25 20:45:18 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 25 Feb 2011 14:45:18 -0500
Subject: [Python-Dev] [Python-checkins] cpython (2.7): Update copyright
	years.
In-Reply-To: <AANLkTikV+8qeo6NyGmrJHYsXekDQUhvCxSfw3a3d=ioE@mail.gmail.com>
References: <E1Pt3Rv-0007zY-64@dinsdale.python.org>
	<AANLkTikV+8qeo6NyGmrJHYsXekDQUhvCxSfw3a3d=ioE@mail.gmail.com>
Message-ID: <20110225144518.1ae921c1@limelight.wooz.org>

On Feb 25, 2011, at 01:39 PM, Benjamin Peterson wrote:

>Ah, this reminds me. Figuring out what to do with the AST version
>should probably be a hg roadmap topic.

Is there a bug tracker for the conversion?

-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/20110225/eb295088/attachment.pgp>

From g.brandl at gmx.net  Fri Feb 25 20:53:10 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 25 Feb 2011 20:53:10 +0100
Subject: [Python-Dev] [Python-checkins] cpython (2.7): Update copyright
	years.
In-Reply-To: <20110225144518.1ae921c1@limelight.wooz.org>
References: <E1Pt3Rv-0007zY-64@dinsdale.python.org>
	<AANLkTikV+8qeo6NyGmrJHYsXekDQUhvCxSfw3a3d=ioE@mail.gmail.com>
	<20110225144518.1ae921c1@limelight.wooz.org>
Message-ID: <ik91ce$k8d$1@dough.gmane.org>

On 25.02.2011 20:45, Barry Warsaw wrote:
> On Feb 25, 2011, at 01:39 PM, Benjamin Peterson wrote:
> 
>>Ah, this reminds me. Figuring out what to do with the AST version
>>should probably be a hg roadmap topic.
> 
> Is there a bug tracker for the conversion?

There's todo.txt in the pymigr repo.

Georg


From solipsis at pitrou.net  Fri Feb 25 20:57:53 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 20:57:53 +0100
Subject: [Python-Dev] 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>
Message-ID: <20110225205753.3d011f68@pitrou.net>

On Fri, 25 Feb 2011 14:43:15 -0500
Barry Warsaw <barry at python.org> wrote:
> 
> I'll have to remember that 'hg pull' does not update the working copy by
> default, and eventually I'll figure out the whole merge thing.

You can use "hg pull -u" to update (and "hg pull -uv" if you want to
see the list of updated files).

> One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes
> my editor and always shows me a 'diff -u' in the commit message buffer.  This
> is incredibly handy because I don't have to remember to do the diff in a
> different window, and I always have all the information I want right there to
> craft the commit message.  It doesn't look like this is possible with 'hg
> commit' though, right?

Should be customizable:
http://mercurial.selenic.com/wiki/CommitMessageTemplate
http://mercurial.selenic.com/wiki/DiffsInCommitMessageInVIM
(never tried myself)

Regards

Antoine.



From phil at freehackers.org  Fri Feb 25 21:04:12 2011
From: phil at freehackers.org (Philippe Fremy)
Date: Fri, 25 Feb 2011 21:04:12 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225144315.3eebcafc@limelight.wooz.org>
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>
Message-ID: <4D680B3C.4040209@freehackers.org>

On 25/02/2011 20:43, Barry Warsaw wrote:
>
> One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes
> my editor and always shows me a 'diff -u' in the commit message buffer.  This
> is incredibly handy because I don't have to remember to do the diff in a
> different window, and I always have all the information I want right there to
> craft the commit message.  It doesn't look like this is possible with 'hg
> commit' though, right?

What you are asking for is available in TortoiseHg which absolutely
rocks (if you are not allergic to the idea of a graphical tool).

You can even select indvidually inside a file which lines to commit or
not. A bit risky but very handy when you have a few oneliners to commit
or not to commit.

cheers,

Philippe

From nyamatongwe at gmail.com  Fri Feb 25 22:40:14 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sat, 26 Feb 2011 08:40:14 +1100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225182426.5f087bfa@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTik3nDpUHaiR2X8txV=AaxX0asr6uHWBLmvNnGCE@mail.gmail.com>
	<20110225135258.3cae8851@pitrou.net>
	<20110225182426.5f087bfa@pitrou.net>
Message-ID: <AANLkTin22nLS_rdZepg+zTQ8XaV5JfYe+CJ-7AkQa8za@mail.gmail.com>

Antoine Pitrou:

> It should now be fixed in current SVN, meaning the final conversion
> should be perfectly usable with the eol extension enabled.

   Good.

> Do you find other issues under Windows? Have you tried pushing changes?

   Since I'm not a member of core developers I used a http pull and can't push:

C:\u\cpython>hg push
pushing to http://hg.python.org/cpython
searching for changes
remote: ssl required

   Neil

From solipsis at pitrou.net  Fri Feb 25 22:43:17 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 22:43:17 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTin22nLS_rdZepg+zTQ8XaV5JfYe+CJ-7AkQa8za@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTik3nDpUHaiR2X8txV=AaxX0asr6uHWBLmvNnGCE@mail.gmail.com>
	<20110225135258.3cae8851@pitrou.net>
	<20110225182426.5f087bfa@pitrou.net>
	<AANLkTin22nLS_rdZepg+zTQ8XaV5JfYe+CJ-7AkQa8za@mail.gmail.com>
Message-ID: <1298670197.3739.7.camel@localhost.localdomain>

Le samedi 26 f?vrier 2011 ? 08:40 +1100, Neil Hodgson a ?crit :
> Antoine Pitrou:
> 
> > It should now be fixed in current SVN, meaning the final conversion
> > should be perfectly usable with the eol extension enabled.
> 
>    Good.
> 
> > Do you find other issues under Windows? Have you tried pushing changes?
> 
>    Since I'm not a member of core developers I used a http pull and can't push:

Ok, well that's expected then ;) Sorry for the confusion.

Regards

Antoine.



From barry at python.org  Fri Feb 25 22:46:00 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 25 Feb 2011 16:46:00 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D680B3C.4040209@freehackers.org>
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>
	<4D680B3C.4040209@freehackers.org>
Message-ID: <20110225164600.415f8e04@limelight.wooz.org>

On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote:

>What you are asking for is available in TortoiseHg which absolutely
>rocks (if you are not allergic to the idea of a graphical tool).

Like shellfish, bee-strings, and Perl I'm afraid. :)

>You can even select indvidually inside a file which lines to commit or
>not. A bit risky but very handy when you have a few oneliners to commit
>or not to commit.

You mean, TortoiseHg supports incremental commits on a single file?  That's
kind of neat, but scary. ;)

-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/20110225/7101e0cd/attachment.pgp>

From solipsis at pitrou.net  Fri Feb 25 23:24:56 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Feb 2011 23:24:56 +0100
Subject: [Python-Dev] r88589 -
	python/branches/py3k/Lib/test/test_logging.py
References: <20110225170243.CC07AEE9BD@mail.python.org>
Message-ID: <20110225232456.0be6176a@pitrou.net>

On Fri, 25 Feb 2011 18:02:43 +0100 (CET)
vinay.sajip <python-checkins at python.org> wrote:
> Author: vinay.sajip
> Date: Fri Feb 25 18:02:43 2011
> New Revision: 88589
> 
> Log:
> logging: enabled test which was intermittently failing on buildbots.


Looks like it fails again:

( http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2671/steps/test/logs/stdio )

======================================================================
ERROR: test_compute_rollover_MIDNIGHT (test.test_logging.TimedRotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 1990, in tearDown
    os.unlink(self.fn)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-vhc3k5.log'

======================================================================
FAIL: test_compute_rollover_MIDNIGHT (test.test_logging.TimedRotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 2053, in test_compute_rollover
    self.assertEqual(exp, rh.computeRollover(0.0))
AssertionError: 82800 != 18000.0

======================================================================
FAIL: test_compute_rollover_S (test.test_logging.TimedRotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 1981, in setUp
    BaseTest.setUp(self)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 95, in setUp
    raise AssertionError('Unexpected handlers: %s' % hlist)
AssertionError: Unexpected handlers: [<logging.StreamHandler object at 0x0DAFC5B0>]

======================================================================
FAIL: test_compute_rollover_W0 (test.test_logging.TimedRotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 1981, in setUp
    BaseTest.setUp(self)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 95, in setUp
    raise AssertionError('Unexpected handlers: %s' % hlist)
AssertionError: Unexpected handlers: [<logging.StreamHandler object at 0x0DAFC5B0>]



From guido at python.org  Fri Feb 25 23:43:01 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 25 Feb 2011 14:43:01 -0800
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
Message-ID: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>

Now that the language moratorium is lifted, let's make sure to get PEP
380 implemented for Python 3.3. I think there are some minor issues to
be resolved, but I don't think that should stop someone from doing a
first pass of the implementation (especially since a version for 2.6
already exists).

(OTOH I am not much enamored with cofunctions, PEP 3152.)

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

From greg.ewing at canterbury.ac.nz  Sat Feb 26 00:01:12 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 26 Feb 2011 12:01:12 +1300
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
Message-ID: <D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>

From: Guido van Rossum
 
> (OTOH I am not much enamored with cofunctions, PEP 3152.)

That's okay, I don't like it much myself in its current form.
I plan to revisit it at some point, but there's no hurry.

-- 
Greg

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

From cs at zip.com.au  Sat Feb 26 01:04:59 2011
From: cs at zip.com.au (Cameron Simpson)
Date: Sat, 26 Feb 2011 11:04:59 +1100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225144315.3eebcafc@limelight.wooz.org>
References: <20110225144315.3eebcafc@limelight.wooz.org>
Message-ID: <20110226000459.GA27783@cskk.homeip.net>

On 25Feb2011 14:43, Barry Warsaw <barry at python.org> wrote:
| [...]  And I have to
| remember to fiddle with .hg/hgrc when I clone a new branch working directory,
| but I guess that's mostly a one-time cost.

Hmm. Why do you need to fiddle with the hgrc? Just curious.

| I'll have to remember that 'hg pull' does not update the working copy by
| default, and eventually I'll figure out the whole merge thing.

"hg fetch" does though. That's my usual incanation.

| One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes
| my editor and always shows me a 'diff -u' in the commit message buffer.  This
| is incredibly handy because I don't have to remember to do the diff in a
| different window, and I always have all the information I want right there to
| craft the commit message.  It doesn't look like this is possible with 'hg
| commit' though, right?

CVS had that problem. I had a wrapper somewhere that masquerades as
$EDITOR and writes a diff into the commit buffer as you describe.
[ Digs through my hg repository... ] 
Ok; then it took the form of a script called "cvscommit" that set
$EDITOR to the command "cvscommit-editor", wrote the diff stuff,
invoked "cvs commit". That ran "cvscommit-editor", which invoked the old
$EDITOR and off you went.

I would think editing the hgrc to set the hg editor and using the commit
hooks would streamline this for Mercurial so you could do the usual "hg
commit" command without going through the outer wrapper.

I'll devote a little time today, since I've missed this little hack:-(

Interested?

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

We don't just *borrow* words; on occasion, English has pursued other
languages down alleyways to beat them unconscious and rifle their pockets for
new vocabulary. - James D. Nicoli

From guido at python.org  Sat Feb 26 01:23:09 2011
From: guido at python.org (Guido van Rossum)
Date: Fri, 25 Feb 2011 16:23:09 -0800
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
In-Reply-To: <D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
Message-ID: <AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>

Ok. Will you hvae time to port your patches to 3.3?

On Fri, Feb 25, 2011 at 3:01 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> From: Guido van Rossum
>
>> (OTOH I am not much enamored with cofunctions, PEP 3152.)
>
> That's okay, I don't like it much myself in its current form.
> I plan to revisit it at some point, but there's no hurry.
>
> --
> Greg
>
> This email may be confidential and subject to legal privilege, it may
> not reflect the views of the University of Canterbury, and it is not
> guaranteed to be virus free. If you are not an intended recipient,
> please notify the sender immediately and erase all copies of the message
> and any attachments.
>
> Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
> information.
>



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

From jnoller at gmail.com  Sat Feb 26 01:47:21 2011
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 25 Feb 2011 19:47:21 -0500
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
In-Reply-To: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
Message-ID: <AANLkTinhW=Bb9wovSbRbNFQVnNHHgvvGBH32+oiDB+3u@mail.gmail.com>

On Fri, Feb 25, 2011 at 5:43 PM, 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. I think there are some minor issues to
> be resolved, but I don't think that should stop someone from doing a
> first pass of the implementation (especially since a version for 2.6
> already exists).
>
> (OTOH I am not much enamored with cofunctions, PEP 3152.)
>

Yay!

From jsbueno at python.org.br  Sat Feb 26 01:58:40 2011
From: jsbueno at python.org.br (Joao S. O. Bueno)
Date: Fri, 25 Feb 2011 21:58:40 -0300
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
In-Reply-To: <D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
Message-ID: <AANLkTinkX_w5spszuDrQ5kPeL-46O5Vx0OArhM1ywRZS@mail.gmail.com>

On Fri, Feb 25, 2011 at 8:01 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> From: Guido van Rossum
>
>> (OTOH I am not much enamored with cofunctions, PEP 3152.)
>
> That's okay, I don't like it much myself in its current form.
> I plan to revisit it at some point, but there's no hurry.

I've just gone through PEP 3152 - and the first though that occurred me is
that a decorator is perfectly usable instead of the new proposed
keyword "codef".
(It would need to be able to set special attributes in the function to
indicate its nature)
Besides not adding a new keyword, it would allow for different
(concurrently running? ) types of
co-functions to be created and benefit from the other mechanisms.

But maybe considerations about this should be take place on python-ideas only?



> --
> Greg
>

From merwok at netwok.org  Sat Feb 26 01:49:46 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 26 Feb 2011 01:49:46 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225144315.3eebcafc@limelight.wooz.org>
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>
Message-ID: <4D684E2A.90005@netwok.org>

Hi,

Le 25/02/2011 20:43, Barry Warsaw a ?crit :
> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:
> [snip]
>> Note that each of these branch clones will initially have your local
>> master repo as the default path [3,4]. If you'd like to have the default
>> push/pull path to point to ssh://hg at hg.python.org/cpython instead, you'd
>> want to edit the [paths] section in the .hg/hgrc file in each of the
>> branch repos.

I plan on having one clone per branch but pushing and pulling from only
one repository, so I don?t need to edit hgrcs.

> It does leave me with an empty 'master' directory that I basically won't
> touch, though I suppose I could hide it in a dot-filename.

Or have the master clone do double duty as the py3k clone.  (IOW, I have
2.7 3.1 3.2 py3k, I pull/push in py3k and also do merges and new
features in py3k).

> And I have to remember to fiddle with .hg/hgrc when I clone a new branch
> working directory, but I guess that's mostly a one-time cost.

You don?t, see above.  I?ve wanted to tell you something for a long
time: Mercurial branches are not at all like Bazaar branches.  See
http://mercurial.selenic.com/wiki/Branch and
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Anecdote: I migrated from Subversion to Mercurial a few years ago, and
found Mercurial branches very intuitive.  When I saw mentions of Bazaar
branches I was driven nuts by (what I saw as) the conflation between a
branch and a clone.  Later I understood how it made sense from the
perspective of Bazaar, so I shifted my judgment from ?insanely
confusing? to ?a particular choice that I don?t approve? <wink>.

What I?m saying is that a lot of Bazaar terminology using ?branch? does
not map as-is to Mercurial.  We clone a repo, we pull from a repo/clone,
we have named branches (e.g. 3.2) in a repo, we have unnamed branches on
one named branch.  I think you know that already, since you went from
using Bazaar terms applied to Mercurial to mixing terms from both
(?clone a new branch working directory? ? ?clone a repo?, probably).  I
salute your willingness to learn Mercurial, considering how fluent (and
fluffly) you appear to be with Bazaar.

> I'll have to remember that 'hg pull' does not update the working copy by
> default,

That pull does not update is a feature: The operation between a remote
repo and the local repo (the .hg directory) is separate from the
operation from the local repo to the working directory.  When you know
that you want pull + update (like when you have a clean working
directory), you use ?hg pull -u?.  (I don?t like the fetch command.)

> and eventually I'll figure out the whole merge thing.

Without anything specific, I?ll point to some resources:
Short tuto: http://hginit.com/04.html
Concepts and examples: http://mercurial.selenic.com/wiki/Merge
Longer narratives:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html

> One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes
> my editor and always shows me a 'diff -u' in the commit message buffer.  This
> is incredibly handy because I don't have to remember to do the diff in a
> different window, and I always have all the information I want right there to
> craft the commit message.

You speak to my heart, sir.  In your ~/.hgrc, under the section [ui],
set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs.
I use it and love it.

If you want to commit a subset of your local changes, I use
http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff
selection UI that works like a charm.

Kind regards,
your friendly Mercurial whippersnapper

From martin at v.loewis.de  Sat Feb 26 03:01:52 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 26 Feb 2011 03:01:52 +0100
Subject: [Python-Dev] [Python-checkins] pymigr: Update todo
In-Reply-To: <E1Pt3Cp-000680-Gj@dinsdale.python.org>
References: <E1Pt3Cp-000680-Gj@dinsdale.python.org>
Message-ID: <4D685F10.3090803@v.loewis.de>

>  After migration
>  ===============
>  
> +* set up automatic installation of changes to ssh keys, decide upon
> +  account managers

I would like account managers to be decided before the conversion.
I personally won't be available as an account manager anymore. The new
account managers are then, of course, free to establish any workflow
they deem appropriate.

> +* adapt build identification for Windows build process

I think this should also be done before the migration.

Regards,
Martin

From ezio.melotti at gmail.com  Sat Feb 26 03:08:02 2011
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 26 Feb 2011 04:08:02 +0200
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <loom.20110225T190113-46@post.gmane.org>
References: <loom.20110225T190113-46@post.gmane.org>
Message-ID: <4D686082.8010202@gmail.com>

On 25/02/2011 20.10, Vinay Sajip wrote:
> What's the easiest way of finding which tests failed on buildbot builds? I mean,
> is there anything easier than using the Web interface to browse to failing
> builds and then looking at the stdio output in a browser?
>


You can try bbreport (http://code.google.com/p/bbreport/wiki/Screenshots):

hg clone https://bbreport.googlecode.com/hg/ bbreport
cd bbreport
python bbreport --help
python bbreport 3.x

(There is some issue with hg revision numbers that I haven't fixed yet, 
but the above command should work fine)

Best Regards,
Ezio Melotti


> Thanks,
>
> Vinay Sajip
>
> _______________________________________________
> 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 ncoghlan at gmail.com  Sat Feb 26 03:32:04 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 Feb 2011 12:32:04 +1000
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225011904.3ed09de7@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
Message-ID: <AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>

On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> ? ?$ hg branches
> ? ?default ? ? ? ? ? ? ? ? ? ?68026:f12ef116dd10
> ? ?3.2 ? ? ? ? ? ? ? ? ? ? ? ?68025:cef92ee1a323
> ? ?2.7 ? ? ? ? ? ? ? ? ? ? ? ?68010:8174d00d0797
> ? ?3.1 ? ? ? ? ? ? ? ? ? ? ? ?67955:5be8b695ea86
> ? ?2.6 ? ? ? ? ? ? ? ? ? ? ? ?67287:5e26a860eded
> ? ?2.5 ? ? ? ? ? ? ? ? ? ? ? ?65464:e4ecac76e499
> ? ?trunk ? ? ? ? ? ? ? ? ? ? ?62750:800f6c92c3ed
> ? ?3.0 ? ? ? ? ? ? ? ? ? ? ? ?60075:1d05144224fe
> ? ?2.4 ? ? ? ? ? ? ? ? ? ? ? ?58552:df72cac1899e
> ? ?2.3 ? ? ? ? ? ? ? ? ? ? ? ?45731:a3d9a9730743
> ? ?2.2 ? ? ? ? ? ? ? ? ? ? ? ?40444:d55ddc8c8501
> ? ?2.1 ? ? ? ? ? ? ? ? ? ? ? ?30171:06fcccf6eca8
> ? ?2.0 ? ? ? ? ? ? ? ? ? ? ? ?18214:dc0dfc9565cd
>
> The branch "default" is the current py3k branch from SVN. The branch
> "trunk" represents SVN trunk history until 2.7 was branched for
> maintenance.

Would it be possible to name "trunk" as "2.x" instead? Otherwise I
could see people getting confused and asking why trunk was closed,
and/or not the same as "default".

Looking very nice, though! :)

Cheers,
Nick.

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

From solipsis at pitrou.net  Sat Feb 26 06:36:17 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 06:36:17 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
Message-ID: <20110226063617.3ad5cc6c@pitrou.net>

On Sat, 26 Feb 2011 12:32:04 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > ? ?$ hg branches
> > ? ?default ? ? ? ? ? ? ? ? ? ?68026:f12ef116dd10
> > ? ?3.2 ? ? ? ? ? ? ? ? ? ? ? ?68025:cef92ee1a323
> > ? ?2.7 ? ? ? ? ? ? ? ? ? ? ? ?68010:8174d00d0797
> > ? ?3.1 ? ? ? ? ? ? ? ? ? ? ? ?67955:5be8b695ea86
> > ? ?2.6 ? ? ? ? ? ? ? ? ? ? ? ?67287:5e26a860eded
> > ? ?2.5 ? ? ? ? ? ? ? ? ? ? ? ?65464:e4ecac76e499
> > ? ?trunk ? ? ? ? ? ? ? ? ? ? ?62750:800f6c92c3ed
> > ? ?3.0 ? ? ? ? ? ? ? ? ? ? ? ?60075:1d05144224fe
> > ? ?2.4 ? ? ? ? ? ? ? ? ? ? ? ?58552:df72cac1899e
> > ? ?2.3 ? ? ? ? ? ? ? ? ? ? ? ?45731:a3d9a9730743
> > ? ?2.2 ? ? ? ? ? ? ? ? ? ? ? ?40444:d55ddc8c8501
> > ? ?2.1 ? ? ? ? ? ? ? ? ? ? ? ?30171:06fcccf6eca8
> > ? ?2.0 ? ? ? ? ? ? ? ? ? ? ? ?18214:dc0dfc9565cd
> >
> > The branch "default" is the current py3k branch from SVN. The branch
> > "trunk" represents SVN trunk history until 2.7 was branched for
> > maintenance.
> 
> Would it be possible to name "trunk" as "2.x" instead? Otherwise I
> could see people getting confused and asking why trunk was closed,
> and/or not the same as "default".

That was my first idea, but then I realized that the branch includes 1.x
and even pre-1.0 commits, so "2.x" might actually be more
confusing/misleading and hide the fact that the full trunk history is
there.

I think people should simply get used to the idea that "default" is
/the/ main branch in Mercurial (*). It's even easier to remember IMHO
("trunk" sounds a bit obscure at first, for a non-native English
speaker).

(*) but it's not any special really, it's just the branch you get by...
default ;)

Regards

Antoine.

From g.brandl at gmx.net  Sat Feb 26 07:34:12 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 26 Feb 2011 07:34:12 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
Message-ID: <ika6uc$kkd$2@dough.gmane.org>

On 26.02.2011 03:32, Nick Coghlan wrote:
> On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>    $ hg branches
>>    default                    68026:f12ef116dd10
>>    3.2                        68025:cef92ee1a323
>>    2.7                        68010:8174d00d0797
>>    3.1                        67955:5be8b695ea86
>>    2.6                        67287:5e26a860eded
>>    2.5                        65464:e4ecac76e499
>>    trunk                      62750:800f6c92c3ed
>>    3.0                        60075:1d05144224fe
>>    2.4                        58552:df72cac1899e
>>    2.3                        45731:a3d9a9730743
>>    2.2                        40444:d55ddc8c8501
>>    2.1                        30171:06fcccf6eca8
>>    2.0                        18214:dc0dfc9565cd
>>
>> The branch "default" is the current py3k branch from SVN. The branch
>> "trunk" represents SVN trunk history until 2.7 was branched for
>> maintenance.
> 
> Would it be possible to name "trunk" as "2.x" instead? Otherwise I
> could see people getting confused and asking why trunk was closed,
> and/or not the same as "default".

Problem is, you then have 1.5.2 released from the 2.x branch :)

Georg



From hagen at zhuliguan.net  Sat Feb 26 10:09:33 2011
From: hagen at zhuliguan.net (=?UTF-8?B?SGFnZW4gRsO8cnN0ZW5hdQ==?=)
Date: Sat, 26 Feb 2011 10:09:33 +0100
Subject: [Python-Dev] set iteration order
Message-ID: <ikag0f$nif$1@dough.gmane.org>

Hi,

I just hunted down a change in behaviour between Python 3.1 and 3.2 to
possibly changed iteration order of sets due to the optimization in
issue #8685. Of course, this order shouldn't be relied on in the first
place, but the side effect of the optimization might be worth mentioning
in "What's new", maybe also pointing out that the old behaviour can be
simulated with {x for x in a if x not in b} in place of "a-b".

Cheers,
Hagen


From martin at v.loewis.de  Sat Feb 26 10:29:33 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 26 Feb 2011 10:29:33 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226063617.3ad5cc6c@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<20110226063617.3ad5cc6c@pitrou.net>
Message-ID: <4D68C7FD.6020005@v.loewis.de>

> I think people should simply get used to the idea that "default" is
> /the/ main branch in Mercurial (*). It's even easier to remember IMHO
> ("trunk" sounds a bit obscure at first, for a non-native English
> speaker).

+1. People will recognize "trunk" as a svn think. If that doesn't
clue them in, they will ask, and every other person will know.

Regards,
Martin

From eric at trueblade.com  Sat Feb 26 10:28:58 2011
From: eric at trueblade.com (Eric Smith)
Date: Sat, 26 Feb 2011 04:28:58 -0500
Subject: [Python-Dev] PyEval_InitThreads() no longer safe
 before	Py_Initialize() in 3.2
In-Reply-To: <ik7qdr$l8f$1@dough.gmane.org>
References: <ik7qdr$l8f$1@dough.gmane.org>
Message-ID: <4D68C7DA.30409@trueblade.com>

Can you open an issue in the bug tracker?

Thanks.

On 2/25/2011 3:48 AM, Juraj Ivan?i? wrote:
> It seems that PyEval_InitThreads() can no longer be called before
> Py_Initialize(). I get a fatal error in PyThreadState_GET().
> This contradicts the documentation
>
> http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads
>
> Minimal repro:
>
> #include "Python.h"
> int main()
> {
> PyEval_InitThreads();
> return 0;
> }
>
> _______________________________________________
> 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/eric%2Ba-python-dev%40trueblade.com
>
>


From martin at v.loewis.de  Sat Feb 26 10:52:02 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 26 Feb 2011 10:52:02 +0100
Subject: [Python-Dev] [Python-checkins] cpython (trunk): Close the
	"trunk" branch.
In-Reply-To: <E1PtDxi-0008OO-Os@dinsdale.python.org>
References: <E1PtDxi-0008OO-Os@dinsdale.python.org>
Message-ID: <4D68CD42.5050005@v.loewis.de>

> http://hg.python.org/cpython/rev/41071f447b15
> changeset:   68041:41071f447b15
> branch:      trunk
> tag:         tip
> parent:      62750:800f6c92c3ed
> user:        Georg Brandl <georg at python.org>
> date:        Sat Feb 26 07:48:21 2011 +0100
> summary:
>   Close the "trunk" branch.

What's the effect of "closing" a branch in Mercurial?
I can still commit to it, hg branches still shows it
(but shows 3.2 as "inactive"???). How can I find out
that the branch is closed?

Regards,
Martin

From juraj.ivancic at gmail.com  Sat Feb 26 10:53:00 2011
From: juraj.ivancic at gmail.com (=?ISO-8859-2?Q?Juraj_Ivan=E8i=E6?=)
Date: Sat, 26 Feb 2011 10:53:00 +0100
Subject: [Python-Dev] PyEval_InitThreads() no longer safe before
 Py_Initialize() in 3.2
In-Reply-To: <4D68C7DA.30409@trueblade.com>
References: <ik7qdr$l8f$1@dough.gmane.org> <4D68C7DA.30409@trueblade.com>
Message-ID: <ikaii3$32a$1@dough.gmane.org>

On 26.2.2011 10:28, Eric Smith wrote:
> On 2/25/2011 3:48 AM, Juraj Ivan?i? wrote:
>> It seems that PyEval_InitThreads() can no longer be called before
>> Py_Initialize(). I get a fatal error in PyThreadState_GET().
>> This contradicts the documentation
>>
>> http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads
>>
>> Minimal repro:
>>
>> #include "Python.h"
>> int main()
>> {
>> PyEval_InitThreads();
>> return 0;
>> }
>
> Can you open an issue in the bug tracker?

http://bugs.python.org/issue11329


From vinay_sajip at yahoo.co.uk  Sat Feb 26 10:54:19 2011
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Sat, 26 Feb 2011 09:54:19 +0000 (UTC)
Subject: [Python-Dev] Finding buildbot failures
References: <loom.20110225T190113-46@post.gmane.org>
	<4D686082.8010202@gmail.com>
Message-ID: <loom.20110226T105229-297@post.gmane.org>

Ezio Melotti <ezio.melotti <at> gmail.com> writes:

> You can try bbreport (http://code.google.com/p/bbreport/wiki/Screenshots):
> 
> hg clone https://bbreport.googlecode.com/hg/ bbreport
> cd bbreport
> python bbreport --help
> python bbreport 3.x
> 
> (There is some issue with hg revision numbers that I haven't fixed yet, 
> but the above command should work fine)

Thanks, Ezio, that's really handy! Just what I needed. Example output (for those
who haven't used the tool) is at

https://gist.github.com/845082

Regards,

Vinay Sajip


From cool-rr at cool-rr.com  Sat Feb 26 13:52:34 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Sat, 26 Feb 2011 14:52:34 +0200
Subject: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`?
Message-ID: <AANLkTinx9AoQ=aTHdtyEOZRKXHJ4SpsP523vYFdXsCU7@mail.gmail.com>

Hello,

I noticed that the `TemporaryDirectory` context manager creates the folder
on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and
hackarounds in `__del__`. I assume there's a good reason for this decision.
What is it?


Thanks,
Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/04010e8d/attachment.html>

From fuzzyman at voidspace.org.uk  Sat Feb 26 14:16:33 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 26 Feb 2011 13:16:33 +0000
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain>
References: <loom.20110225T190113-46@post.gmane.org>	<4D67F959.8080701@voidspace.org.uk>
	<20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain>
Message-ID: <4D68FD31.70901@voidspace.org.uk>

On 25/02/2011 19:00, exarkun at twistedmatrix.com wrote:
> On 06:47 pm, fuzzyman at voidspace.org.uk wrote:
>> On 25/02/2011 18:10, Vinay Sajip wrote:
>>> What's the easiest way of finding which tests failed on buildbot 
>>> builds? I mean,
>>> is there anything easier than using the Web interface to browse to 
>>> failing
>>> builds and then looking at the stdio output in a browser?
>>
>> 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. 
(Probably a bit small for a GSOC project on its own.) I've had great 
success using pyjunitxml to generate Hudson compatible reports from 
unittest test runs (extremely easy to use), and if buildbot *can* handle 
junit xml format reports then it may be the path of least resistance:

     https://launchpad.net/pyjunitxml

I tried searching (both google and the buildbot docs) for ways to 
generate more complete reports or to integrate junitxml with builbot, 
but failed. Can you point me at anything?

All the best,

Michael

> Jean-Paul
> _______________________________________________
> 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 exarkun at twistedmatrix.com  Sat Feb 26 14:46:13 2011
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Sat, 26 Feb 2011 13:46:13 -0000
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <4D68FD31.70901@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>
Message-ID: <20110226134613.2231.442001115.divmod.xquotient.66@localhost.localdomain>

On 01:16 pm, fuzzyman at voidspace.org.uk wrote:
>On 25/02/2011 19:00, exarkun at twistedmatrix.com wrote:
>>On 06:47 pm, fuzzyman at voidspace.org.uk wrote:
>>>On 25/02/2011 18:10, Vinay Sajip wrote:
>>>>What's the easiest way of finding which tests failed on buildbot 
>>>>builds? I mean,
>>>>is there anything easier than using the Web interface to browse to 
>>>>failing
>>>>builds and then looking at the stdio output in a browser?
>>>
>>>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. (Probably a bit small for a GSOC project on its own.) 
>I've had great success using pyjunitxml to generate Hudson compatible 
>reports from unittest test runs (extremely easy to use), and if 
>buildbot *can* handle junit xml format reports then it may be the path 
>of least resistance:
>
>     https://launchpad.net/pyjunitxml
>
>I tried searching (both google and the buildbot docs) for ways to 
>generate more complete reports or to integrate junitxml with builbot, 
>but failed. Can you point me at anything?

I think this is the relevant pages in the buildbot manual for custom 
reporting:

  http://buildbot.net/buildbot/docs/latest/BuildStep-LogFiles.html 
#BuildStep-LogFiles

There's also
http://buildbot.net/buildbot/docs/latest/SubunitShellCommand.html#SubunitShellCommand

which is basically the same idea as junitxml, but not actually junitxml 
itself, so I'd probably go that way.  However if you really need 
junitxml for something, there are tools for converting between subunit 
and junitxml.

Jean-Paul

From ethan at stoneleaf.us  Sat Feb 26 15:19:09 2011
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 26 Feb 2011 06:19:09 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226063617.3ad5cc6c@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<20110226063617.3ad5cc6c@pitrou.net>
Message-ID: <4D690BDD.2000600@stoneleaf.us>

Antoine Pitrou wrote:
> On Sat, 26 Feb 2011 12:32:04 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>>    $ hg branches
>>>    default                    68026:f12ef116dd10
>>>    3.2                        68025:cef92ee1a323
>>>    2.7                        68010:8174d00d0797
>>>    3.1                        67955:5be8b695ea86
>>>    2.6                        67287:5e26a860eded
>>>    2.5                        65464:e4ecac76e499
>>>    trunk                      62750:800f6c92c3ed
>>>    3.0                        60075:1d05144224fe
>>>    2.4                        58552:df72cac1899e
>>>    2.3                        45731:a3d9a9730743
>>>    2.2                        40444:d55ddc8c8501
>>>    2.1                        30171:06fcccf6eca8
>>>    2.0                        18214:dc0dfc9565cd
>>>
>>> The branch "default" is the current py3k branch from SVN. The branch
>>> "trunk" represents SVN trunk history until 2.7 was branched for
>>> maintenance.
>> Would it be possible to name "trunk" as "2.x" instead? Otherwise I
>> could see people getting confused and asking why trunk was closed,
>> and/or not the same as "default".
> 
> That was my first idea, but then I realized that the branch includes 1.x
> and even pre-1.0 commits, so "2.x" might actually be more
> confusing/misleading and hide the fact that the full trunk history is
> there.

Maybe prePy3k, then?  Trunk, after all, is not very descriptive.  Or is 
that name also inaccurate?

~Ethan~

From ncoghlan at gmail.com  Sat Feb 26 15:39:16 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Feb 2011 00:39:16 +1000
Subject: [Python-Dev] Why does TemporaryDirectory not wait for
	`__enter__`?
In-Reply-To: <AANLkTinx9AoQ=aTHdtyEOZRKXHJ4SpsP523vYFdXsCU7@mail.gmail.com>
References: <AANLkTinx9AoQ=aTHdtyEOZRKXHJ4SpsP523vYFdXsCU7@mail.gmail.com>
Message-ID: <AANLkTin9pwi29ZB8ZQduouyNmPF5et40AEfG=ix5d=Gr@mail.gmail.com>

On Sat, Feb 26, 2011 at 10:52 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> Hello,
> I noticed that the `TemporaryDirectory` context manager creates the folder
> on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and
> hackarounds in `__del__`. I assume there's a good reason for this decision.
> What is it?

>From the docstring: "This has the same behavior as mkdtemp but can be
used as a context manager." Like files, it *can* be used as a context
manager, but doesn't have to be.

Also, the complexity wouldn't go away even if the directory creation
was delayed until the __enter__ invocation. People can still call
__enter__ directly, so __del__ would still be obliged to try to clear
things up as best it could.

Cheers,
Nick.

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

From merwok at netwok.org  Sat Feb 26 15:40:43 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 26 Feb 2011 15:40:43 +0100
Subject: [Python-Dev] [Python-checkins] r88526 - in
 python/branches/release32-maint/Lib: collections.py
 test/test_collections.py
In-Reply-To: <20110223082806.3AC47EE9E3@mail.python.org>
References: <20110223082806.3AC47EE9E3@mail.python.org>
Message-ID: <4D6910EB.4020908@netwok.org>

Hi,

> Author: raymond.hettinger
> New Revision: 88526
> Log: Add tests for the collections helper class and sync-up with py3k branch.

> Modified: python/branches/release32-maint/Lib/collections.py
> +    def new_child(self):                        # like Django's Context.push()
> +        'New ChainMap with a new dict followed by all previous maps.'
> +        return self.__class__({}, *self.maps)
> +
> +    @property
> +    def parents(self):                          # like Django's Context.pop()
> +        'New ChainMap from maps[1:].'
> +        return self.__class__(*self.maps[1:])

Isn?t this considered a new feature, unsuitable for 3.2?  (I mean no
disrespect, I just want to understand better what kind of changes can go
in each type of branch.)

Regards

From ncoghlan at gmail.com  Sat Feb 26 15:40:59 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Feb 2011 00:40:59 +1000
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <ika6uc$kkd$2@dough.gmane.org>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<ika6uc$kkd$2@dough.gmane.org>
Message-ID: <AANLkTi=0+FQH4qtHsq7eg8-Vn9ju9u+Ow7+xX-MqN7Tm@mail.gmail.com>

On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>> Would it be possible to name "trunk" as "2.x" instead? Otherwise I
>> could see people getting confused and asking why trunk was closed,
>> and/or not the same as "default".
>
> Problem is, you then have 1.5.2 released from the 2.x branch :)

In that case, "legacy-trunk" would seem clearer.

Cheers,
Nick.

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

From ncoghlan at gmail.com  Sat Feb 26 15:42:04 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Feb 2011 00:42:04 +1000
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D68C7FD.6020005@v.loewis.de>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<20110226063617.3ad5cc6c@pitrou.net> <4D68C7FD.6020005@v.loewis.de>
Message-ID: <AANLkTi=4D=5osQb6cupBsAZU8voJaxi9_P1FBqHetKgX@mail.gmail.com>

On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I think people should simply get used to the idea that "default" is
>> /the/ main branch in Mercurial (*). It's even easier to remember IMHO
>> ("trunk" sounds a bit obscure at first, for a non-native English
>> speaker).
>
> +1. People will recognize "trunk" as a svn think. If that doesn't
> clue them in, they will ask, and every other person will know.

But why not choose a name where they don't even have to ask?

Cheers,
Nick.

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

From andy-python at hammerhartes.de  Sat Feb 26 15:42:41 2011
From: andy-python at hammerhartes.de (=?ISO-8859-1?Q?Andreas_St=FChrk?=)
Date: Sat, 26 Feb 2011 14:42:41 +0000
Subject: [Python-Dev] Why does TemporaryDirectory not wait for
	`__enter__`?
In-Reply-To: <AANLkTinx9AoQ=aTHdtyEOZRKXHJ4SpsP523vYFdXsCU7@mail.gmail.com>
References: <AANLkTinx9AoQ=aTHdtyEOZRKXHJ4SpsP523vYFdXsCU7@mail.gmail.com>
Message-ID: <AANLkTimS8vastTDU0REWZAkZTvArHhPtNQY296ntM_TS@mail.gmail.com>

Hi

On Sat, Feb 26, 2011 at 12:52 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> I noticed that the `TemporaryDirectory` context manager creates the folder
> on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and
> hackarounds in `__del__`. I assume there's a good reason for this decision.
> What is it?

The reason is that you can use `TemporaryDirectory` without a context
manager too. Note that creating things in  `__init__` rather than in
`__enter__` isn't unusual -- it is done in the same way for regular
files. I'm not sure what you mean with "hackarounds in `__del__`", but
I assume you mean the code in `cleanup()`. That code tries to do the
right thing on interpreter shutdown when parts of the interpreter are
already gone and it emits a `ResourceWarning` if called implicitly
(IOW: when you didn't use `TemporaryDirectory` as a context manager
and didn't call its `cleanup()` method). So a bit of complexity is
there, but it really isn't about where the directory is created.

Regards,
Andreas

From solipsis at pitrou.net  Sat Feb 26 15:44:08 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 15:44:08 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTi=4D=5osQb6cupBsAZU8voJaxi9_P1FBqHetKgX@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<20110226063617.3ad5cc6c@pitrou.net> <4D68C7FD.6020005@v.loewis.de>
	<AANLkTi=4D=5osQb6cupBsAZU8voJaxi9_P1FBqHetKgX@mail.gmail.com>
Message-ID: <1298731448.3704.1.camel@localhost.localdomain>

Le dimanche 27 f?vrier 2011 ? 00:42 +1000, Nick Coghlan a ?crit :
> On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> >> I think people should simply get used to the idea that "default" is
> >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO
> >> ("trunk" sounds a bit obscure at first, for a non-native English
> >> speaker).
> >
> > +1. People will recognize "trunk" as a svn think. If that doesn't
> > clue them in, they will ask, and every other person will know.
> 
> But why not choose a name where they don't even have to ask?

Doesn't "trunk" represent exactly what it is (the former SVN trunk)?
Other names would probably be less exact or less precise.

Regards

Antoine.



From cool-rr at cool-rr.com  Sat Feb 26 15:45:48 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Sat, 26 Feb 2011 16:45:48 +0200
Subject: [Python-Dev] Why does TemporaryDirectory not wait for
	`__enter__`?
In-Reply-To: <AANLkTin9pwi29ZB8ZQduouyNmPF5et40AEfG=ix5d=Gr@mail.gmail.com>
References: <AANLkTinx9AoQ=aTHdtyEOZRKXHJ4SpsP523vYFdXsCU7@mail.gmail.com>
	<AANLkTin9pwi29ZB8ZQduouyNmPF5et40AEfG=ix5d=Gr@mail.gmail.com>
Message-ID: <AANLkTikrzwvwhwDX-9QgZKbLb9WVDi_zLswLqUov6fdS@mail.gmail.com>

On Sat, Feb 26, 2011 at 4:39 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Sat, Feb 26, 2011 at 10:52 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> > Hello,
> > I noticed that the `TemporaryDirectory` context manager creates the
> folder
> > on `__init__` rather than on `__enter__`, resulting in complexity, bugs,
> and
> > hackarounds in `__del__`. I assume there's a good reason for this
> decision.
> > What is it?
>
> From the docstring: "This has the same behavior as mkdtemp but can be
> used as a context manager." Like files, it *can* be used as a context
> manager, but doesn't have to be.
>
> Also, the complexity wouldn't go away even if the directory creation
> was delayed until the __enter__ invocation. People can still call
> __enter__ directly, so __del__ would still be obliged to try to clear
> things up as best it could.
>
> Cheers,
> Nick.


I think that if someone calls `__enter__` directly, he takes the
responsibility of calling `__exit__`, so we don't really have to help him
with `__del__`.

But other than that I understand the motivation for making it start on
`__init__` rather then `__enter__`. I'll just make my own version of it that
will work on `__enter__` instead.

Thanks,
Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/aaf0e84a/attachment.html>

From solipsis at pitrou.net  Sat Feb 26 15:48:44 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 15:48:44 +0100
Subject: [Python-Dev] Why does TemporaryDirectory not wait for
	`__enter__`?
References: <AANLkTinx9AoQ=aTHdtyEOZRKXHJ4SpsP523vYFdXsCU7@mail.gmail.com>
	<AANLkTin9pwi29ZB8ZQduouyNmPF5et40AEfG=ix5d=Gr@mail.gmail.com>
Message-ID: <20110226154844.220f6468@pitrou.net>

On Sun, 27 Feb 2011 00:39:16 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, Feb 26, 2011 at 10:52 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> > Hello,
> > I noticed that the `TemporaryDirectory` context manager creates the folder
> > on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and
> > hackarounds in `__del__`. I assume there's a good reason for this decision.
> > What is it?
> 
> >From the docstring: "This has the same behavior as mkdtemp but can be
> used as a context manager." Like files, it *can* be used as a context
> manager, but doesn't have to be.
> 
> Also, the complexity wouldn't go away even if the directory creation
> was delayed until the __enter__ invocation. People can still call
> __enter__ directly, so __del__ would still be obliged to try to clear
> things up as best it could.

Calling __enter__ directly without caring to call __exit__ afterwards
should certainly be considered a user bug (not to mention of dubious
utility in this case, since it's easier to spell mkdtemp() than
TemporaryDirectory().__enter__()).

Regards

Antoine.



From fuzzyman at voidspace.org.uk  Sat Feb 26 15:53:30 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 26 Feb 2011 14:53:30 +0000
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <20110226134613.2231.442001115.divmod.xquotient.66@localhost.localdomain>
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>
	<20110226134613.2231.442001115.divmod.xquotient.66@localhost.localdomain>
Message-ID: <4D6913EA.6070405@voidspace.org.uk>

On 26/02/2011 13:46, exarkun at twistedmatrix.com wrote:
> On 01:16 pm, fuzzyman at voidspace.org.uk wrote:
>> On 25/02/2011 19:00, exarkun at twistedmatrix.com wrote:
>>> On 06:47 pm, fuzzyman at voidspace.org.uk wrote:
>>>> On 25/02/2011 18:10, Vinay Sajip wrote:
>>>>> What's the easiest way of finding which tests failed on buildbot 
>>>>> builds? I mean,
>>>>> is there anything easier than using the Web interface to browse to 
>>>>> failing
>>>>> builds and then looking at the stdio output in a browser?
>>>>
>>>> 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. (Probably a bit small for a GSOC project on its own.) 
>> I've had great success using pyjunitxml to generate Hudson compatible 
>> reports from unittest test runs (extremely easy to use), and if 
>> buildbot *can* handle junit xml format reports then it may be the 
>> path of least resistance:
>>
>>     https://launchpad.net/pyjunitxml
>>
>> I tried searching (both google and the buildbot docs) for ways to 
>> generate more complete reports or to integrate junitxml with builbot, 
>> but failed. Can you point me at anything?
>
> I think this is the relevant pages in the buildbot manual for custom 
> reporting:
>
>  http://buildbot.net/buildbot/docs/latest/BuildStep-LogFiles.html 
> #BuildStep-LogFiles
>
> There's also
> http://buildbot.net/buildbot/docs/latest/SubunitShellCommand.html#SubunitShellCommand 
>
>
> which is basically the same idea as junitxml, but not actually 
> junitxml itself, so I'd probably go that way.  However if you really 
> need junitxml for something, there are tools for converting between 
> subunit and junitxml.

Thanks Jean-Paul.

Michael

>
> Jean-Paul
> _______________________________________________
> 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 Feb 26 15:57:16 2011
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 26 Feb 2011 14:57:16 +0000
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <1298731448.3704.1.camel@localhost.localdomain>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<20110226063617.3ad5cc6c@pitrou.net>
	<4D68C7FD.6020005@v.loewis.de>	<AANLkTi=4D=5osQb6cupBsAZU8voJaxi9_P1FBqHetKgX@mail.gmail.com>
	<1298731448.3704.1.camel@localhost.localdomain>
Message-ID: <4D6914CC.70404@voidspace.org.uk>

On 26/02/2011 14:44, Antoine Pitrou wrote:
> Le dimanche 27 f?vrier 2011 ? 00:42 +1000, Nick Coghlan a ?crit :
>> On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis"<martin at v.loewis.de>  wrote:
>>>> I think people should simply get used to the idea that "default" is
>>>> /the/ main branch in Mercurial (*). It's even easier to remember IMHO
>>>> ("trunk" sounds a bit obscure at first, for a non-native English
>>>> speaker).
>>> +1. People will recognize "trunk" as a svn think. If that doesn't
>>> clue them in, they will ask, and every other person will know.
>> But why not choose a name where they don't even have to ask?
> Doesn't "trunk" represent exactly what it is (the former SVN trunk)?
> Other names would probably be less exact or less precise.

Well, except for the prevalence of "trunk" as terminology to mean "place 
where current development happens". It will lead to odd conversations 
like:  "is trunk the trunk?", "no trunk is what used to be trunk, 
default is now trunk".

Renaming it "legacy-trunk" is no less precise, but more explicative.

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  Sat Feb 26 15:57:34 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 15:57:34 +0100
Subject: [Python-Dev] Mercurial conversion repositories
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<20110226063617.3ad5cc6c@pitrou.net> <4D68C7FD.6020005@v.loewis.de>
	<AANLkTi=4D=5osQb6cupBsAZU8voJaxi9_P1FBqHetKgX@mail.gmail.com>
	<1298731448.3704.1.camel@localhost.localdomain>
Message-ID: <20110226155734.54045763@pitrou.net>

On Sat, 26 Feb 2011 15:44:08 +0100
Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le dimanche 27 f?vrier 2011 ? 00:42 +1000, Nick Coghlan a ?crit :
> > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > >> I think people should simply get used to the idea that "default" is
> > >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO
> > >> ("trunk" sounds a bit obscure at first, for a non-native English
> > >> speaker).
> > >
> > > +1. People will recognize "trunk" as a svn think. If that doesn't
> > > clue them in, they will ask, and every other person will know.
> > 
> > But why not choose a name where they don't even have to ask?
> 
> Doesn't "trunk" represent exactly what it is (the former SVN trunk)?
> Other names would probably be less exact or less precise.

Although I now admit "legacy-trunk" sounds quite accurate, and conveys
a clear warning to anyone wondering if they should use it.

Regards

Antoine.



From ncoghlan at gmail.com  Sat Feb 26 16:16:42 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Feb 2011 01:16:42 +1000
Subject: [Python-Dev] [Python-checkins] r88526 - in
 python/branches/release32-maint/Lib: collections.py
 test/test_collections.py
In-Reply-To: <4D6910EB.4020908@netwok.org>
References: <20110223082806.3AC47EE9E3@mail.python.org>
	<4D6910EB.4020908@netwok.org>
Message-ID: <AANLkTint+Emp315ke4huQiQ_sipJg5tn06txtcFmLHM8@mail.gmail.com>

On Sun, Feb 27, 2011 at 12:40 AM, ?ric Araujo <merwok at netwok.org> wrote:
> Isn?t this considered a new feature, unsuitable for 3.2? ?(I mean no
> disrespect, I just want to understand better what kind of changes can go
> in each type of branch.)

collections._ChainMap itself is private, so changes can be made to its
API even in a maintenance branch.

Cheers,
Nick.

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

From merwok at netwok.org  Sat Feb 26 16:17:51 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 26 Feb 2011 16:17:51 +0100
Subject: [Python-Dev] [Python-checkins] r88526 - in
 python/branches/release32-maint/Lib: collections.py
 test/test_collections.py
In-Reply-To: <AANLkTint+Emp315ke4huQiQ_sipJg5tn06txtcFmLHM8@mail.gmail.com>
References: <20110223082806.3AC47EE9E3@mail.python.org>	<4D6910EB.4020908@netwok.org>
	<AANLkTint+Emp315ke4huQiQ_sipJg5tn06txtcFmLHM8@mail.gmail.com>
Message-ID: <4D69199F.7030908@netwok.org>

> collections._ChainMap itself is private, so changes can be made to its
> API even in a maintenance branch.

Makes perfect sense, thanks for the reply :)

Cheers

From martin at v.loewis.de  Sat Feb 26 17:02:07 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 26 Feb 2011 17:02:07 +0100
Subject: [Python-Dev] [Python-checkins] cpython (trunk): Close the
	"trunk" branch.
In-Reply-To: <20110226110612.2766c0da@pitrou.net>
References: <E1PtDxi-0008OO-Os@dinsdale.python.org>	<4D68CD42.5050005@v.loewis.de>
	<20110226110612.2766c0da@pitrou.net>
Message-ID: <4D6923FF.9050204@v.loewis.de>

> Committing reopened it

So what's the point of closing it, then? What effect does that
achieve?

Regards,
Martin

From solipsis at pitrou.net  Sat Feb 26 17:11:13 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 17:11:13 +0100
Subject: [Python-Dev] [Python-checkins] cpython (trunk): Close the
	"trunk" branch.
In-Reply-To: <4D6923FF.9050204@v.loewis.de>
References: <E1PtDxi-0008OO-Os@dinsdale.python.org>
	<4D68CD42.5050005@v.loewis.de> <20110226110612.2766c0da@pitrou.net>
	<4D6923FF.9050204@v.loewis.de>
Message-ID: <1298736673.3704.6.camel@localhost.localdomain>

Le samedi 26 f?vrier 2011 ? 17:02 +0100, "Martin v. L?wis" a ?crit :
> > Committing reopened it
> 
> So what's the point of closing it, then? What effect does that
> achieve?

Again, as I said, it doesn't get displayed anymore with the standard
commands "hg branches" and "hg heads".
Consider it a convention rather than some kind of hard stop against
future commits.

Regards

Antoine.



From martin at v.loewis.de  Sat Feb 26 17:17:35 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 26 Feb 2011 17:17:35 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTi=4D=5osQb6cupBsAZU8voJaxi9_P1FBqHetKgX@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<20110226063617.3ad5cc6c@pitrou.net>	<4D68C7FD.6020005@v.loewis.de>
	<AANLkTi=4D=5osQb6cupBsAZU8voJaxi9_P1FBqHetKgX@mail.gmail.com>
Message-ID: <4D69279F.8030002@v.loewis.de>

Am 26.02.2011 15:42, schrieb Nick Coghlan:
> On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> I think people should simply get used to the idea that "default" is
>>> /the/ main branch in Mercurial (*). It's even easier to remember IMHO
>>> ("trunk" sounds a bit obscure at first, for a non-native English
>>> speaker).
>>
>> +1. People will recognize "trunk" as a svn think. If that doesn't
>> clue them in, they will ask, and every other person will know.
> 
> But why not choose a name where they don't even have to ask?

That could be better. Unfortunately, nobody has proposed a name
that has this property and is also correct.

Regards,
Martin

From martin at v.loewis.de  Sat Feb 26 17:27:20 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 26 Feb 2011 17:27:20 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226155734.54045763@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<20110226063617.3ad5cc6c@pitrou.net>
	<4D68C7FD.6020005@v.loewis.de>	<AANLkTi=4D=5osQb6cupBsAZU8voJaxi9_P1FBqHetKgX@mail.gmail.com>	<1298731448.3704.1.camel@localhost.localdomain>
	<20110226155734.54045763@pitrou.net>
Message-ID: <4D6929E8.1090401@v.loewis.de>

> Although I now admit "legacy-trunk" sounds quite accurate, and conveys
> a clear warning to anyone wondering if they should use it.

To stay in tree terminology, I propose "stump" (*). Or "rotten-trunk".

Bikeshedding is such a fun activity :-)

Regards,
Martin

(*) m-w.com: "the part of a plant and especially a tree remaining
attached to the root after the trunk is cut"

From stutzbach at google.com  Sat Feb 26 17:38:18 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sat, 26 Feb 2011 08:38:18 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
Message-ID: <AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>

On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Would it be possible to name "trunk" as "2.x" instead? Otherwise I
> could see people getting confused and asking why trunk was closed,
> and/or not the same as "default".
>

Can we just get rid of "trunk" altogether?  It's history is a strict subset
of the 2.7 branch's history, isn't it?

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/283fc013/attachment.html>

From solipsis at pitrou.net  Sat Feb 26 17:44:45 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 17:44:45 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
Message-ID: <1298738685.3704.10.camel@localhost.localdomain>

Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a ?crit :
> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
>         Would it be possible to name "trunk" as "2.x" instead?
>         Otherwise I
>         could see people getting confused and asking why trunk was
>         closed,
>         and/or not the same as "default".
> 
> 
> Can we just get rid of "trunk" altogether?  It's history is a strict
> subset of the 2.7 branch's history, isn't it?

Named branches are exclusive, they can't be a subset of each other ;)
(in other words: 2.7 starts where trunk stops; trunk changesets are
strict ancestors of 2.7)

Regards

Antoine.



From merwok at netwok.org  Sat Feb 26 17:49:32 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 26 Feb 2011 17:49:32 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <1298738685.3704.10.camel@localhost.localdomain>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
Message-ID: <4D692F1C.8090200@netwok.org>

Le 26/02/2011 17:44, Antoine Pitrou a ?crit :
>> Can we just get rid of "trunk" altogether?  It's history is a strict
>> subset of the 2.7 branch's history, isn't it?
> 
> Named branches are exclusive, they can't be a subset of each other ;)

Can we just use default for trunk and py3k?  For the time when both
trunk and py3k were active, it would create two unnamed branches on the
default branch, but one merge would solve that.

Regards

From ncoghlan at gmail.com  Sat Feb 26 17:57:23 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Feb 2011 02:57:23 +1000
Subject: [Python-Dev] [Python-checkins] r88601 - peps/trunk/pep-0385.txt
In-Reply-To: <20110225191207.51301EE985@mail.python.org>
References: <20110225191207.51301EE985@mail.python.org>
Message-ID: <AANLkTimonCD3w=x8KDvLhdeA4ji1473EgzXq04ZBh8gq@mail.gmail.com>

On Sat, Feb 26, 2011 at 5:12 AM, antoine.pitrou
<python-checkins at python.org> wrote:
> +In practice, most Mercurial users under Windows don't seem to have a need
> +for the ``eol`` extension, though, and personal experience using a
> +Linux-generated SVN checkout through a shared folder under Windows seems
> +to confirm that modern tools work well without it.

Feedback from the Mozilla and XEmacs folks at the time of that
discussion suggested that EOL issues *were* a potential issue, and
that having to revert unintentional commits of CRLF line endings was
an annoyingly common problem.

Cheers,
Nick.

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

From solipsis at pitrou.net  Sat Feb 26 18:00:19 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 18:00:19 +0100
Subject: [Python-Dev] Mercurial conversion repositories
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D692F1C.8090200@netwok.org>
Message-ID: <20110226180019.337a7057@pitrou.net>

On Sat, 26 Feb 2011 17:49:32 +0100
?ric Araujo <merwok at netwok.org> wrote:
> Le 26/02/2011 17:44, Antoine Pitrou a ?crit :
> >> Can we just get rid of "trunk" altogether?  It's history is a strict
> >> subset of the 2.7 branch's history, isn't it?
> > 
> > Named branches are exclusive, they can't be a subset of each other ;)
> 
> Can we just use default for trunk and py3k?  For the time when both
> trunk and py3k were active, it would create two unnamed branches on the
> default branch, but one merge would solve that.

IMO, a dummy merge at the tip of the default branch may confuse users
looking at the history, especially if they try a graphical display of
the DAG (e.g. "hg glog" or the graph page in the Web UI).

Besides, it would precisely make it harder to distinguish between
trunk and py3k development at the time both took place in parallel.

Regards

Antoine.



From ncoghlan at gmail.com  Sat Feb 26 18:11:27 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Feb 2011 03:11:27 +1000
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226180019.337a7057@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D692F1C.8090200@netwok.org> <20110226180019.337a7057@pitrou.net>
Message-ID: <AANLkTikx9dGE4fuBU+vVE86BZX44Ax0ZANTqj0UFvPPE@mail.gmail.com>

On Sun, Feb 27, 2011 at 3:00 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Besides, it would precisely make it harder to distinguish between
> trunk and py3k development at the time both took place in parallel.

With the legacy branches now being closed so they don't appear in the
default output from hg commands, I'm fine with keeping the old "trunk"
name from SVN. It was only when those commands were displaying both
"trunk" and "default" that it bothered me.

Cheers,
Nick.

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

From merwok at netwok.org  Sat Feb 26 18:11:45 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 26 Feb 2011 18:11:45 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226180019.337a7057@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>	<1298738685.3704.10.camel@localhost.localdomain>	<4D692F1C.8090200@netwok.org>
	<20110226180019.337a7057@pitrou.net>
Message-ID: <4D693451.3040001@netwok.org>

>> Can we just use default for trunk and py3k?  For the time when both
>> trunk and py3k were active, it would create two unnamed branches on the
>> default branch, but one merge would solve that.
> 
> IMO, a dummy merge at the tip of the default branch may confuse users
> looking at the history, especially if they try a graphical display of
> the DAG (e.g. "hg glog" or the graph page in the Web UI).

The dummy merge would not stay long: The commits targeted at 3.3 would
be its children.

> Besides, it would precisely make it harder to distinguish between
> trunk and py3k development at the time both took place in parallel.

IIUC, there would be two parallel lines of history (unnnamed branches).
 Would that be hard to read?

Regards

From tjreedy at udel.edu  Sat Feb 26 18:25:20 2011
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 26 Feb 2011 12:25:20 -0500
Subject: [Python-Dev] set iteration order
In-Reply-To: <ikag0f$nif$1@dough.gmane.org>
References: <ikag0f$nif$1@dough.gmane.org>
Message-ID: <ikbd1t$umd$1@dough.gmane.org>

On 2/26/2011 4:09 AM, Hagen F?rstenau wrote:
> Hi,
>
> I just hunted down a change in behaviour between Python 3.1 and 3.2 to
> possibly changed iteration order of sets due to the optimization in
> issue #8685. Of course, this order shouldn't be relied on in the first
> place, but the side effect of the optimization might be worth mentioning
> in "What's new", maybe also pointing out that the old behaviour can be
> simulated with {x for x in a if x not in b} in place of "a-b".

-1
Code with any dependence on the iteration order of unordered collections 
(other than the guarantee that d.keys() and d.values() match at any 
given time as long as d is unchanged) is buggy.
It is not the place of What's new to cater to buggy code.
Besides which, there is no guarantee that the 'x in a' part of the 
suggestion will will remain the same from version to version or even 
from run to run.

-- 
Terry Jan Reedy



From stutzbach at google.com  Sat Feb 26 18:27:56 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sat, 26 Feb 2011 09:27:56 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <1298738685.3704.10.camel@localhost.localdomain>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
Message-ID: <AANLkTi=NpS0px5Pkn8meKqNNru6fcE+pL6f2P=83Ommi@mail.gmail.com>

On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a ?crit :
> > Can we just get rid of "trunk" altogether?  It's history is a strict
> > subset of the 2.7 branch's history, isn't it?
>
> Named branches are exclusive, they can't be a subset of each other ;)
> (in other words: 2.7 starts where trunk stops; trunk changesets are
> strict ancestors of 2.7)
>

Maybe I don't fully understand how Mercurial branches work or how it defines
terminology (in fact, that is likely :) ).  What's the difference between
the statement "trunk changesets are strict ancestors of 2.7" and the
statement "trunk's history is a strict subset of 2.7's history"?

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/470555f0/attachment.html>

From merwok at netwok.org  Sat Feb 26 18:32:01 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 26 Feb 2011 18:32:01 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTi=NpS0px5Pkn8meKqNNru6fcE+pL6f2P=83Ommi@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>	<1298738685.3704.10.camel@localhost.localdomain>
	<AANLkTi=NpS0px5Pkn8meKqNNru6fcE+pL6f2P=83Ommi@mail.gmail.com>
Message-ID: <4D693911.4000004@netwok.org>

>> Named branches are exclusive, they can't be a subset of each other ;)

Actually, they can.  Take the example of the Mercurial repo itself. They
fix bugs in the stable branch and add features in default.  When they
merge stable into default and commit, default becomes a superset of
stable.  That is to say, someone pulling default also gets the
changesets from stable that are ancestors of the merge changset.  Or in
other words, if you check out default, you get all bug fixes from stable.

HTH

From solipsis at pitrou.net  Sat Feb 26 18:32:26 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 18:32:26 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTi=NpS0px5Pkn8meKqNNru6fcE+pL6f2P=83Ommi@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<AANLkTi=NpS0px5Pkn8meKqNNru6fcE+pL6f2P=83Ommi@mail.gmail.com>
Message-ID: <1298741546.3704.11.camel@localhost.localdomain>

Le samedi 26 f?vrier 2011 ? 09:27 -0800, Daniel Stutzbach a ?crit :
> On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
>         Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a
>         ?crit :
>         
>         > Can we just get rid of "trunk" altogether?  It's history is
>         a strict
>         > subset of the 2.7 branch's history, isn't it?
>         
>         
>         Named branches are exclusive, they can't be a subset of each
>         other ;)
>         (in other words: 2.7 starts where trunk stops; trunk
>         changesets are
>         strict ancestors of 2.7)
> 
> 
> Maybe I don't fully understand how Mercurial branches work or how it
> defines terminology (in fact, that is likely :) ).  What's the
> difference between the statement "trunk changesets are strict
> ancestors of 2.7" and the statement "trunk's history is a strict
> subset of 2.7's history"?

Apparently you overlooked the first statement:
"Named branches are exclusive".
In other words, a changeset can be in only one named branch.
So it's impossible for a branch to be a subset or superset of another.
(except the trivial case of an empty branch :-)).




From martin at v.loewis.de  Sat Feb 26 18:36:02 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 26 Feb 2011 18:36:02 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <1298738685.3704.10.camel@localhost.localdomain>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
Message-ID: <4D693A02.4000104@v.loewis.de>

Am 26.02.2011 17:44, schrieb Antoine Pitrou:
> Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a ?crit :
>> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan <ncoghlan at gmail.com>
>> wrote:
>>         Would it be possible to name "trunk" as "2.x" instead?
>>         Otherwise I
>>         could see people getting confused and asking why trunk was
>>         closed,
>>         and/or not the same as "default".
>>
>>
>> Can we just get rid of "trunk" altogether?  It's history is a strict
>> subset of the 2.7 branch's history, isn't it?
> 
> Named branches are exclusive, they can't be a subset of each other ;)
> (in other words: 2.7 starts where trunk stops; trunk changesets are
> strict ancestors of 2.7)

But is there a need to have any changesets in the "trunk" named branch?
Couldn't the historical changesets just be in an unnamed branch, being
ancestor of so many named branches?

I'd like to prevent people from mistakenly committing onto the trunk,
which would be easiest if trunk didn't exist at all.

Regards,
Martin

From solipsis at pitrou.net  Sat Feb 26 18:54:02 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 18:54:02 +0100
Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook.
References: <E1PtOFd-0000wb-8X@dinsdale.python.org>
Message-ID: <20110226185402.14b66d79@pitrou.net>

On Sat, 26 Feb 2011 18:48:17 +0100
martin.v.loewis <python-checkins at python.org> wrote:
>  * some hook should prevent pushing python files indented by tabs.
>  * some hook should prevent pushing to the 2.x trunk.
> +* some hook should prevent breaking EOL conventions.

We don't have such hook in SVN, why would we need one with Mercurial ?



From solipsis at pitrou.net  Sat Feb 26 18:55:40 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 18:55:40 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D693A02.4000104@v.loewis.de>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D693A02.4000104@v.loewis.de>
Message-ID: <1298742940.3704.17.camel@localhost.localdomain>

Le samedi 26 f?vrier 2011 ? 18:36 +0100, "Martin v. L?wis" a ?crit :
> Am 26.02.2011 17:44, schrieb Antoine Pitrou:
> > Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a ?crit :
> >> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan <ncoghlan at gmail.com>
> >> wrote:
> >>         Would it be possible to name "trunk" as "2.x" instead?
> >>         Otherwise I
> >>         could see people getting confused and asking why trunk was
> >>         closed,
> >>         and/or not the same as "default".
> >>
> >>
> >> Can we just get rid of "trunk" altogether?  It's history is a strict
> >> subset of the 2.7 branch's history, isn't it?
> > 
> > Named branches are exclusive, they can't be a subset of each other ;)
> > (in other words: 2.7 starts where trunk stops; trunk changesets are
> > strict ancestors of 2.7)
> 
> But is there a need to have any changesets in the "trunk" named branch?
> Couldn't the historical changesets just be in an unnamed branch, being
> ancestor of so many named branches?

There is no such thing as an "unnamed branch". What would "hg branches"
show? An empty space?

> I'd like to prevent people from mistakenly committing onto the trunk,
> which would be easiest if trunk didn't exist at all.

Well, the push you request in the todo should do the trick.
We can also call it "legacy-trunk", too :)

Regards

Antoine.



From martin at v.loewis.de  Sat Feb 26 19:05:50 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 26 Feb 2011 19:05:50 +0100
Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook.
In-Reply-To: <20110226185402.14b66d79@pitrou.net>
References: <E1PtOFd-0000wb-8X@dinsdale.python.org>
	<20110226185402.14b66d79@pitrou.net>
Message-ID: <4D6940FE.509@v.loewis.de>

Am 26.02.2011 18:54, schrieb Antoine Pitrou:
> On Sat, 26 Feb 2011 18:48:17 +0100
> martin.v.loewis <python-checkins at python.org> wrote:
>>  * some hook should prevent pushing python files indented by tabs.
>>  * some hook should prevent pushing to the 2.x trunk.
>> +* some hook should prevent breaking EOL conventions.
> 
> We don't have such hook in SVN, why would we need one with Mercurial ?

In subversion, it's a builtin feature of subversion (svn:eol-style);
subversion will automatically convert all files correctly (if
svn:eol-style is specified correctly, which it is, for most of the
files).

In Mercurial, it's just a hook, and optional. So we can't be sure all
users use it correctly - and in my (limited) experience with Mercurial,
chances are high that users will make mistakes in that respect (i.e.
in one out of one cross-platform projects, a committer had issues
with CRLF, leading to catastrophic repository corruption).

So I think it's absolutely necessary that files with incorrect
eol-style are blocked from being pushed. Or else we will all
suffer and eventually die :-)

Regards,
Martin

From barry at python.org  Sat Feb 26 19:08:47 2011
From: barry at python.org (Barry Warsaw)
Date: Sat, 26 Feb 2011 13:08:47 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D684E2A.90005@netwok.org>
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>
Message-ID: <20110226130847.05daf511@limelight.wooz.org>

On Feb 26, 2011, at 01:49 AM, ?ric Araujo wrote:

>Le 25/02/2011 20:43, Barry Warsaw a ?crit :
>> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:
>> [snip]
>>> Note that each of these branch clones will initially have your local
>>> master repo as the default path [3,4]. If you'd like to have the default
>>> push/pull path to point to ssh://hg at hg.python.org/cpython instead, you'd
>>> want to edit the [paths] section in the .hg/hgrc file in each of the
>>> branch repos.
>
>I plan on having one clone per branch but pushing and pulling from only
>one repository, so I don?t need to edit hgrcs.

So let's start from the basics.  I want separate working directories for each
active line-of-development (I'll use that term instead of "branch"),
e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, and
3.3.  I will not be doing feature or bug development in any of these
directories.  They are purely for local tracking of the remote masters.  Thus,
I want to be able to synchronize any one of those LoDs against the remote
master with one command, like I would using Subversion's 'svn up'.

I clone the remote repository using the command in the devguide, so I now have
a 'cpython' directory containing the history of all LoDs, but with a working
directory that reflects the 'default' LoD.  Now, in the parent of 'cpython', I
do the following to get my separate-directory-LoDs:

$ hg clone -u 2.6 cpython py26
$ hg clone -u 2.7 cpython py27
# repeat and rinse for all other active LoDs

(Aside: that cpython directory still bugs me.  It doesn't naturally reflect a
LoD, so why do I have to stare at it?  Yes, I can make it play double duty by
naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels
artificial.)

Now I want to synchronize my local py27 directory with the state of that LoD
on python.org.  This is a two step process:

$ cd py27 # now I want to synchronize
$ (cd ../cpython && hg pull)
$ hg pull -u

Editing hgrc to point to hg.python.org means the sync-to-remote-master
operation is one command.

I could do this:

$ cd py27 # now I want to synchronize
$ hg pull -u ssh://hg at hg.python.org/cpython

but I'm not going to remember that url every time.  It wouldn't be so bad if
Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.

>Anecdote: I migrated from Subversion to Mercurial a few years ago, and
>found Mercurial branches very intuitive.  When I saw mentions of Bazaar
>branches I was driven nuts by (what I saw as) the conflation between a
>branch and a clone.  Later I understood how it made sense from the
>perspective of Bazaar, so I shifted my judgment from ?insanely
>confusing? to ?a particular choice that I don?t approve? <wink>.

That's funny because to my eyes, Mercurial conflates "branches" and "clones".
Why a clone operation should give me the history for all lines-of-development
inside a working directory for one "arbitrary" one strikes me as bizarre
(pardon the pun :).  I get that for folks who like the "svn switch" method of
working on multiple LoDs, this probably makes a lot of sense.  I don't
personally like or trust that approach much though.

>What I?m saying is that a lot of Bazaar terminology using ?branch? does
>not map as-is to Mercurial.  We clone a repo, we pull from a repo/clone,
>we have named branches (e.g. 3.2) in a repo, we have unnamed branches on
>one named branch.  I think you know that already, since you went from
>using Bazaar terms applied to Mercurial to mixing terms from both
>(?clone a new branch working directory? ? ?clone a repo?, probably).  I
>salute your willingness to learn Mercurial, considering how fluent (and
>fluffly) you appear to be with Bazaar.

This is an inevitable problem with trying to converse fluently about three
major dVCSs and at least one or two other non-dVCSs.  They all use the same
words to mean vaguely similar things, but quickly get bogged down in the
implementation details assigned to those words.  It all makes perfect sense
when you've been immersed in those technologies, but it makes discussions and
comparisons exceedingly difficult.  I've no doubt it's doubly painful to many
people who have no prior experience with a dVCS.

(Aside: Bazaar could have potentially eased these folks transition because you
can use Bazaar just like you would Subversion - as a centralized VCS --
without stopping others from using it with full dVCS features on the same code
base.  I don't know if Mercurial offers the same flexibility.)

It's a little like trying to teach Python to a Java programmer.  "Object",
"Class", "Instance", "Import" all mean roughly similar things, which lulls you
into a false sense of understanding.  We learn by holding up the new to the
light of the familiar and looking for interference patterns. :)

>> I'll have to remember that 'hg pull' does not update the working copy by
>> default,
>
>That pull does not update is a feature: The operation between a remote
>repo and the local repo (the .hg directory) is separate from the
>operation from the local repo to the working directory.  When you know
>that you want pull + update (like when you have a clean working
>directory), you use ?hg pull -u?.  (I don?t like the fetch command.)

Sure, I get that.  Again, this feature appears odd because I have the full
history of all LoDs embedded in a working directory of a single LoD.  With the
arrangement I outlined above (which is independent of the dVCS backing it), it
makes no sense for each LoD working directory to contain all the history of
all the other LoDs.

In Bazaar, a "branch" is an independent LoD and it's "repository" contains
only its own history.  Sure, it might have identical history with other LoDs
up to the point of divergence, and I have ways to efficiently share that
history across multiple LoD working directories, but they are still separate
and I don't need them if I don't care about them.  With Mercurial, all history
for all LoDs in a repository always come along for the ride.

>You speak to my heart, sir.  In your ~/.hgrc, under the section [ui],
>set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs.
>I use it and love it.

Great, I'll try that, thanks.  One thing Mercurial and Bazaar definitely share
is a wealth of magical awesomeness hidden in manpages, wiki pages, mailing
list posts, people's heads, configuration files, and source code. :)

>If you want to commit a subset of your local changes, I use
>http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff
>selection UI that works like a charm.

I very rarely want to do that.  It's more common (but still, IME not *that*
common) to commit the changes to just a few files at a time.  One thing Bazaar
has that's very nice is the ability to "shelve" some changes for a time.
Let's say I'm working on a bug and I want to merge your changes in or sync to
the master.  I can shelve some or all of my uncommitted changes, which saves
them essentially out-of-the-way patch files, and then reverts my uncommitted
changes.  Unshelving then is the process of re-applying those patch files, and
yes, resolving conflicts.

This is also a great way to work when you want to do test-driven-development
but need to do some exploration first.  You can hack around non-TDD until
you're confident of your approach, shelve all your changes, then incrementally
apply them back as you write each test.  I'm sure Mercurial has something
equally awesome lurking about. :)

-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/20110226/67324f4a/attachment.pgp>

From barry at python.org  Sat Feb 26 19:12:25 2011
From: barry at python.org (Barry Warsaw)
Date: Sat, 26 Feb 2011 13:12:25 -0500
Subject: [Python-Dev] [Python-checkins] cpython: improve license
In-Reply-To: <E1PtOWG-0002W6-30@dinsdale.python.org>
References: <E1PtOWG-0002W6-30@dinsdale.python.org>
Message-ID: <20110226131225.2f310fc4@limelight.wooz.org>

Notice the subject line.  Can we make commit messages contain the named branch
that the change applies to?  The 'cpython' in the header doesn't really tell
me whether I should care about this diff or not.

Say the change applied to 2.6 but I only care about Python 3.  It would be
nice if I could just delete this message without reading the body.

I guess it's possible for change notifications to encompass multiple named
branches though, right?  I'm not sure what to do about that, but it seems like
a less common use case.

-Barry

On Feb 26, 2011, at 07:05 PM, benjamin.peterson wrote:

>benjamin.peterson pushed 0873fb83f1e2 to cpython:
>
>http://hg.python.org/cpython/rev/0873fb83f1e2
>changeset:   68052:0873fb83f1e2
>tag:         tip
>user:        Benjamin Peterson <benjamin at python.org>
>date:        Sat Feb 26 12:06:36 2011 -0600
>summary:
>  improve license
>
>files:
>  LICENSE
-------------- 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/20110226/2ce210fe/attachment-0001.pgp>

From solipsis at pitrou.net  Sat Feb 26 19:13:29 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 19:13:29 +0100
Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook.
In-Reply-To: <4D6940FE.509@v.loewis.de>
References: <E1PtOFd-0000wb-8X@dinsdale.python.org>
	<20110226185402.14b66d79@pitrou.net>  <4D6940FE.509@v.loewis.de>
Message-ID: <1298744009.3704.25.camel@localhost.localdomain>


> In Mercurial, it's just a hook, and optional. So we can't be sure all
> users use it correctly - and in my (limited) experience with Mercurial,
> chances are high that users will make mistakes in that respect (i.e.
> in one out of one cross-platform projects, a committer had issues
> with CRLF, leading to catastrophic repository corruption).

?Catastrophic? repository ?corruption?? This sounds very strongly like
an urban legend.
Perhaps some files had later to be fixed. But that shouldn't be out of
the realm of normal Mercurial commands (aka "edit file to fix endings,
then hg commit and hg push").

> So I think it's absolutely necessary that files with incorrect
> eol-style are blocked from being pushed. Or else we will all
> suffer and eventually die :-)

Well, the latter is a given, isn't it? ;)

Anyway, hgeol actually seems to include such a hook. I'll try to enable
it.

Regards

Antoine.



From martin at v.loewis.de  Sat Feb 26 19:18:41 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 26 Feb 2011 19:18:41 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <1298742940.3704.17.camel@localhost.localdomain>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>	<1298738685.3704.10.camel@localhost.localdomain>	<4D693A02.4000104@v.loewis.de>
	<1298742940.3704.17.camel@localhost.localdomain>
Message-ID: <4D694401.1000009@v.loewis.de>

>> But is there a need to have any changesets in the "trunk" named branch?
>> Couldn't the historical changesets just be in an unnamed branch, being
>> ancestor of so many named branches?
> 
> There is no such thing as an "unnamed branch". What would "hg branches"
> show? An empty space?

hg branches doesn't list unnamed branches. "hg heads" omits any branch
name for unnamed branches. See the cpythonextras repository for examples:

changeset:   72694:e65daae6cf44
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Mon Feb 21 21:30:55 2011 +0000
summary:     Try s/UINT_MAX/INT_MAX/

This is listed as a head, but not of a named branch.

>> I'd like to prevent people from mistakenly committing onto the trunk,
>> which would be easiest if trunk didn't exist at all.
> 
> Well, the push you request in the todo should do the trick.

Yes, that would also work. However, when then somebody proposed that
we may not need the trunk branch at all in the conversion result
(which I still think is the case - we don't need it), I noticed
that this would solve the problem in a more clean manner.

> We can also call it "legacy-trunk", too :)

I think we can do better. I also dislike "hg log --only-branch default"
to only go back to 2006 (to aeefba456e4d), when this revision actually
does have a parent (namely, on the trunk branch, 4b41806a0326).

So I would propose this attribution to branches:
- everything that is ancestor of the default branch is attributed
  to the default branch, back to the very beginning of the repository.
- Everything currently on trunk that wouldn't be on default is then
  attributed to the oldest branch that it is an ancestor of, in the
  order 2.0, 2.1, 2.2, ... 2.7.

So e.g. the 2.7 branch would go back to where it branched from the 2.6
branch (after the actual creation of the 2.6 branch in svn), which
would go back to where it branched from 2.5, and so on.

Regards,
Martin

From martin at v.loewis.de  Sat Feb 26 19:19:37 2011
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 26 Feb 2011 19:19:37 +0100
Subject: [Python-Dev] [Python-checkins] cpython: improve license
In-Reply-To: <20110226131225.2f310fc4@limelight.wooz.org>
References: <E1PtOWG-0002W6-30@dinsdale.python.org>
	<20110226131225.2f310fc4@limelight.wooz.org>
Message-ID: <4D694439.5010004@v.loewis.de>

Am 26.02.2011 19:12, schrieb Barry Warsaw:
> Notice the subject line.  Can we make commit messages contain the named branch
> that the change applies to? 

If you don't want this request to be forgotten, add it to todo.txt in
the pymigr repo.

Regards,
Martin

From barry at python.org  Sat Feb 26 19:23:10 2011
From: barry at python.org (Barry Warsaw)
Date: Sat, 26 Feb 2011 13:23:10 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D693911.4000004@netwok.org>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<AANLkTi=NpS0px5Pkn8meKqNNru6fcE+pL6f2P=83Ommi@mail.gmail.com>
	<4D693911.4000004@netwok.org>
Message-ID: <20110226132310.3dc2da5f@limelight.wooz.org>

On Feb 26, 2011, at 06:32 PM, ?ric Araujo wrote:

>>> Named branches are exclusive, they can't be a subset of each other ;)
>
>Actually, they can.  Take the example of the Mercurial repo itself. They
>fix bugs in the stable branch and add features in default.  When they
>merge stable into default and commit, default becomes a superset of
>stable.  That is to say, someone pulling default also gets the
>changesets from stable that are ancestors of the merge changset.  Or in
>other words, if you check out default, you get all bug fixes from stable.

That makes sense, but correct me if I'm wrong, it's the 'merge' operation that
made this happen, right?  A merge essentially brings the changesets from one
branch into another.

-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/20110226/5ef57450/attachment.pgp>

From martin at v.loewis.de  Sat Feb 26 19:23:49 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 26 Feb 2011 19:23:49 +0100
Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook.
In-Reply-To: <1298744009.3704.25.camel@localhost.localdomain>
References: <E1PtOFd-0000wb-8X@dinsdale.python.org>	<20110226185402.14b66d79@pitrou.net>
	<4D6940FE.509@v.loewis.de>
	<1298744009.3704.25.camel@localhost.localdomain>
Message-ID: <4D694535.6070207@v.loewis.de>

Am 26.02.2011 19:13, schrieb Antoine Pitrou:
> 
>> In Mercurial, it's just a hook, and optional. So we can't be sure all
>> users use it correctly - and in my (limited) experience with Mercurial,
>> chances are high that users will make mistakes in that respect (i.e.
>> in one out of one cross-platform projects, a committer had issues
>> with CRLF, leading to catastrophic repository corruption).
> 
> ?Catastrophic? repository ?corruption?? This sounds very strongly like
> an urban legend.
> Perhaps some files had later to be fixed. But that shouldn't be out of
> the realm of normal Mercurial commands (aka "edit file to fix endings,
> then hg commit and hg push").

It actually happened to me, so please trust me that it's not a legend.
Yes, I could fix it with hg commands, and a lot of text editing.
It took me a day, I considered the repository corrupted so that I
actually had to branch from the last ok revision, and redo all checkins
since (I also discarded changes which I didn't chose to redo). It was
a real catastrophe to me.

Since the changes actually changed all lines, "hg blame" became useless,
which was unacceptable.

Regards,
Martin

From solipsis at pitrou.net  Sat Feb 26 19:39:13 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 19:39:13 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D694401.1000009@v.loewis.de>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D693A02.4000104@v.loewis.de>
	<1298742940.3704.17.camel@localhost.localdomain>
	<4D694401.1000009@v.loewis.de>
Message-ID: <1298745553.3704.31.camel@localhost.localdomain>


> >> But is there a need to have any changesets in the "trunk" named branch?
> >> Couldn't the historical changesets just be in an unnamed branch, being
> >> ancestor of so many named branches?
> > 
> > There is no such thing as an "unnamed branch". What would "hg branches"
> > show? An empty space?
> 
> hg branches doesn't list unnamed branches. "hg heads" omits any branch
> name for unnamed branches. See the cpythonextras repository for examples:
> 
> changeset:   72694:e65daae6cf44
> user:        Antoine Pitrou <solipsis at pitrou.net>
> date:        Mon Feb 21 21:30:55 2011 +0000
> summary:     Try s/UINT_MAX/INT_MAX/

It's not on an unnamed branch, it's on the "default" branch (which is
omitted for concision by "hg log" and other commands with a similar
output).

> >> I'd like to prevent people from mistakenly committing onto the trunk,
> >> which would be easiest if trunk didn't exist at all.
> > 
> > Well, the push you request in the todo should do the trick.
> 
> Yes, that would also work. However, when then somebody proposed that
> we may not need the trunk branch at all in the conversion result
> (which I still think is the case - we don't need it), I noticed
> that this would solve the problem in a more clean manner.

But you *need* the changesets from the trunk branch. You are just
arguing for giving them another label (including "" or "default"),
hence:

> > We can also call it "legacy-trunk", too :)
> 
> I think we can do better. I also dislike "hg log --only-branch default"
> to only go back to 2006 (to aeefba456e4d), when this revision actually
> does have a parent (namely, on the trunk branch, 4b41806a0326).

I'm not convinced that small quirks of using "hg log" are important at
this point. Also, you could try other options of "hg log" such as
"--follow".

If we called ex-trunk the same name as ex-py3k ("default"), things would
probably be quite more confusing, since inspecting a changeset wouldn't
tell you immediately where it comes from (2.x or 3.x development).

Regards

Antoine.



From robertc at robertcollins.net  Sat Feb 26 19:48:29 2011
From: robertc at robertcollins.net (Robert Collins)
Date: Sun, 27 Feb 2011 07:48:29 +1300
Subject: [Python-Dev] Why does TemporaryDirectory not wait for
	`__enter__`?
In-Reply-To: <AANLkTikrzwvwhwDX-9QgZKbLb9WVDi_zLswLqUov6fdS@mail.gmail.com>
References: <AANLkTinx9AoQ=aTHdtyEOZRKXHJ4SpsP523vYFdXsCU7@mail.gmail.com>
	<AANLkTin9pwi29ZB8ZQduouyNmPF5et40AEfG=ix5d=Gr@mail.gmail.com>
	<AANLkTikrzwvwhwDX-9QgZKbLb9WVDi_zLswLqUov6fdS@mail.gmail.com>
Message-ID: <AANLkTin3HWQT8rAEyRWvZJJEpGLj=KfnD80-ohWS6ZmJ@mail.gmail.com>

On Sun, Feb 27, 2011 at 3:45 AM, cool-RR <cool-rr at cool-rr.com> wrote:

> I think that if someone calls `__enter__` directly, he takes the
> responsibility of calling `__exit__`, so we don't really have to help him
> with `__del__`.
> But other than that I understand the motivation for making it start on
> `__init__` rather then `__enter__`. I'll just make my own version of it that
> will work on `__enter__` instead.
> Thanks,
> Ram.

TempDir from 'fixtures' (http://pypi.python.org/pypi/fixtures) will do
what you want - __enter__ creates the directory, __exit__ deletes it.

Cheers,
Rob

From stutzbach at google.com  Sat Feb 26 19:40:03 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sat, 26 Feb 2011 10:40:03 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <1298742940.3704.17.camel@localhost.localdomain>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D693A02.4000104@v.loewis.de>
	<1298742940.3704.17.camel@localhost.localdomain>
Message-ID: <AANLkTimhsnQe4JtLcPaAUo6FOk5-5=TBNFMYSWsOQpM-@mail.gmail.com>

On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> There is no such thing as an "unnamed branch". What would "hg branches"
> show? An empty space?
>

I understand now why I was confused.  I had previously read the sentence
"Both Git and Mercurial support unnamed local branches." at
http://mercurial.selenic.com/wiki/BranchingExplained

But as I dig deeper, I see that there is only one unnamed branch, and it
actually does have an implicit name: "default".

It appears Mercurial supports at least three different kinds of branching:
cloning (similar to Bazaar), bookmarks (similar to git), and named branches.
 So a named branch can contain more than one branch.

Were there reasons for going with named branches over bookmarks?  PEP 385
discusses only cloning and named branches.  I'm just curious, not trying to
start a long discussion. :-)

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/47adf97d/attachment.html>

From santoso.wijaya at gmail.com  Sat Feb 26 19:54:00 2011
From: santoso.wijaya at gmail.com (Santoso Wijaya)
Date: Sat, 26 Feb 2011 10:54:00 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226132310.3dc2da5f@limelight.wooz.org>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<AANLkTi=NpS0px5Pkn8meKqNNru6fcE+pL6f2P=83Ommi@mail.gmail.com>
	<4D693911.4000004@netwok.org>
	<20110226132310.3dc2da5f@limelight.wooz.org>
Message-ID: <AANLkTinHJE-RLBhTkEECXVQq8P0bPv5ysL8c=OLTR1cZ@mail.gmail.com>

A Mercurial 'merge' <http://mercurial.selenic.com/wiki/Branch> is simply a
creation of another changeset, which has two parents: the current tip of the
branch you're working on, and the changeset you are merging with.

~/santa


On Sat, Feb 26, 2011 at 10:23 AM, Barry Warsaw <barry at python.org> wrote:

> On Feb 26, 2011, at 06:32 PM, ?ric Araujo wrote:
>
> >>> Named branches are exclusive, they can't be a subset of each other ;)
> >
> >Actually, they can.  Take the example of the Mercurial repo itself. They
> >fix bugs in the stable branch and add features in default.  When they
> >merge stable into default and commit, default becomes a superset of
> >stable.  That is to say, someone pulling default also gets the
> >changesets from stable that are ancestors of the merge changset.  Or in
> >other words, if you check out default, you get all bug fixes from stable.
>
> That makes sense, but correct me if I'm wrong, it's the 'merge' operation
> that
> made this happen, right?  A merge essentially brings the changesets from
> one
> branch into another.
>
> -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/santoso.wijaya%40gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/cdbbfb6a/attachment.html>

From santoso.wijaya at gmail.com  Sat Feb 26 19:56:59 2011
From: santoso.wijaya at gmail.com (Santoso Wijaya)
Date: Sat, 26 Feb 2011 10:56:59 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTimhsnQe4JtLcPaAUo6FOk5-5=TBNFMYSWsOQpM-@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D693A02.4000104@v.loewis.de>
	<1298742940.3704.17.camel@localhost.localdomain>
	<AANLkTimhsnQe4JtLcPaAUo6FOk5-5=TBNFMYSWsOQpM-@mail.gmail.com>
Message-ID: <AANLkTimbZuLiAjM5FcberrL20ULquxGbjA_1-ZVK8V1t@mail.gmail.com>

>From http://mercurial.selenic.com/wiki/Branch#Named_branches:

[...] a good rule of thumb is to use branch names sparingly and for rather
longer lived concepts like "release branches" (rel-1, rel-2, etc) and rather
not for short lived work of single developers

So I think named branches make sense here. Bookmarks are really for
potential branches, experimental features, for example, for easier
navigation for the developer's convenience. Named branches, on the other
hand, are better for posterity reasons.

~/santa


On Sat, Feb 26, 2011 at 10:40 AM, Daniel Stutzbach <stutzbach at google.com>wrote:

> On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou <solipsis at pitrou.net>wrote:
>
>> There is no such thing as an "unnamed branch". What would "hg branches"
>> show? An empty space?
>>
>
> I understand now why I was confused.  I had previously read the sentence
> "Both Git and Mercurial support unnamed local branches." at
> http://mercurial.selenic.com/wiki/BranchingExplained
>
> But as I dig deeper, I see that there is only one unnamed branch, and it
> actually does have an implicit name: "default".
>
> It appears Mercurial supports at least three different kinds of branching:
> cloning (similar to Bazaar), bookmarks (similar to git), and named branches.
>  So a named branch can contain more than one branch.
>
> Were there reasons for going with named branches over bookmarks?  PEP 385
> discusses only cloning and named branches.  I'm just curious, not trying to
> start a long discussion. :-)
>
> --
>  Daniel Stutzbach
>
> _______________________________________________
> 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/20110226/0cf40ddb/attachment.html>

From rdmurray at bitdance.com  Sat Feb 26 20:05:18 2011
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 26 Feb 2011 14:05:18 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226130847.05daf511@limelight.wooz.org>
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>
	<20110226130847.05daf511@limelight.wooz.org>
Message-ID: <20110226190518.37F381FF8A4@kimball.webabinitio.net>

On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw <barry at python.org> wrote:
> $ cd py27 # now I want to synchronize
> $ hg pull -u ssh://hg at hg.python.org/cpython
> 
> but I'm not going to remember that url every time.  It wouldn't be so bad if
> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.

How does setting it in the hgrc differ from "remebering" it?  I've never
been comfortable with the bzr --remember option because I'm never
sure what it is remembering.  Much easier for me to see it in a config
file.  But, then, that's how my brain works, and other people's will
work differently.

> On Feb 26, 2011, at 01:49 AM, ??ric Araujo wrote:
> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and
> >found Mercurial branches very intuitive.  When I saw mentions of Bazaar
> >branches I was driven nuts by (what I saw as) the conflation between a
> >branch and a clone.  Later I understood how it made sense from the
> >perspective of Bazaar, so I shifted my judgment from ???insanely
> >confusing??? to ???a particular choice that I don???t approve??? <wink>.
> 
> That's funny because to my eyes, Mercurial conflates "branches" and "clones".
> Why a clone operation should give me the history for all lines-of-development
> inside a working directory for one "arbitrary" one strikes me as bizarre
> (pardon the pun :).  I get that for folks who like the "svn switch" method of
> working on multiple LoDs, this probably makes a lot of sense.  I don't
> personally like or trust that approach much though.

I agree with you that I don't trust the 'svn switch' style.  I also find
it slow.  However....

> >That pull does not update is a feature: The operation between a remote
> >repo and the local repo (the .hg directory) is separate from the
> >operation from the local repo to the working directory.  When you know
> >that you want pull + update (like when you have a clean working
> >directory), you use ???hg pull -u???.  (I don???t like the fetch command.)
> 
> Sure, I get that.  Again, this feature appears odd because I have the full
> history of all LoDs embedded in a working directory of a single LoD.  With the
> arrangement I outlined above (which is independent of the dVCS backing it), it
> makes no sense for each LoD working directory to contain all the history of
> all the other LoDs.
> 
> In Bazaar, a "branch" is an independent LoD and it's "repository" contains
> only its own history.  Sure, it might have identical history with other LoDs
> up to the point of divergence, and I have ways to efficiently share that
> history across multiple LoD working directories, but they are still separate
> and I don't need them if I don't care about them.  With Mercurial, all history
> for all LoDs in a repository always come along for the ride.

I find bazaar's model confusing, and hg's intuitive, just like ??ric.
And consider that I learned bazaar before mercurial.  To me, it makes
perfect sense that in a DVCS the "unit" is a directory containing
a repository and a working copy, and that the repository is *the*
repository.  That is, it has everything related to the project in it,
just like the master SVN repository does (plus, since it is a DVCS,
whatever I've committed locally but not pushed to the master).  To have
a repository that only has some of the stuff in it is, IMO, confusing.
I advocated for having all the Python history in one repo partly for
that reason.

I can intellectually see your point about not really *needing* the stuff
for the LODs if you are only working on LOD X, but just like 'svn switch'
makes me uncomfortable, I'm just not *comfortable* not having the whole
repo in there :)

As an example, with mercurial, I feel comfortable moving directories
around and renaming them (with the help of google it took me about 1
minute to figure out how to keep the association between the repository
instances intact).  With bazaar I got in trouble trying to do that,
because the interrelationship between the working copy directories
(and their subsets of the repo?) and the master repo(?) was not clear.
I never did figure out how to make it work, I ended up starting over
with a new clone.

Now, as I get farther into learning mercurial I may well find things that
are just as confusing as I found that aspect of bazaar, but at least I
am comfortable with the outermost layer: the repo is the repo is the repo.

--
R. David Murray                                      www.bitdance.com

From solipsis at pitrou.net  Sat Feb 26 20:29:12 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 20:29:12 +0100
Subject: [Python-Dev] of branches and heads
In-Reply-To: <AANLkTimhsnQe4JtLcPaAUo6FOk5-5=TBNFMYSWsOQpM-@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D693A02.4000104@v.loewis.de>
	<1298742940.3704.17.camel@localhost.localdomain>
	<AANLkTimhsnQe4JtLcPaAUo6FOk5-5=TBNFMYSWsOQpM-@mail.gmail.com>
Message-ID: <20110226202912.7d4813ba@pitrou.net>

On Sat, 26 Feb 2011 10:40:03 -0800
Daniel Stutzbach <stutzbach at google.com> wrote:
> On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 
> > There is no such thing as an "unnamed branch". What would "hg branches"
> > show? An empty space?
> 
> I understand now why I was confused.  I had previously read the sentence
> "Both Git and Mercurial support unnamed local branches." at
> http://mercurial.selenic.com/wiki/BranchingExplained
> 
> But as I dig deeper, I see that there is only one unnamed branch, and it
> actually does have an implicit name: "default".


Ok, so beware, the term "branch" can conflate two concepts:
- a path in the topology (or line of development)
- a "named branch" in hg terminology

So, actually, hg promotes a slightly different terminology:
- a "head" is a changeset without a child in the topology
- a "branch" usually means a "named branch": a set of changesets
  bearing the same label (e.g. "default"); that label is freely chosen
  by the committer at any point, and enforces no topological
  characteristic (even though in practice it will have, since it's the
  whole point from the user's perspective, and also because hg's
  default behaviour and concept of a "current branch" encourages it)

A (named) branch can have zero, one, or several heads:
- zero head: if all branch-local heads have a child in another named
  branch (for example, "trunk" is linearly followed by "2.7")
- several heads: if several lines of development were started in this
  branch without bothering to give them separate names

When you have several heads on a branch, you can merge them together if
you want to reconcile the lines of development they represent.

When you have several branches with at least one head each, you can
also merge them together: you must be careful to choose which named 
branch the merge changeset will be part of (for example, if you want
to merge "3.1" into "3.2", you will certainly want the merge changeset
to be part of "3.2", otherwise "3.1" will get a lot of unwanted
features ;-)).

Note: a branch with zero head is marked "inactive" in "hg branches".
This basically means that it has already been merged in another branch.
(of course, you can still develop in that branch, which will certainly
create a new head as soon as you commit your first new changeset)

Regards

Antoine.

From solipsis at pitrou.net  Sat Feb 26 20:30:41 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 20:30:41 +0100
Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook.
In-Reply-To: <4D694535.6070207@v.loewis.de>
References: <E1PtOFd-0000wb-8X@dinsdale.python.org>
	<20110226185402.14b66d79@pitrou.net> <4D6940FE.509@v.loewis.de>
	<1298744009.3704.25.camel@localhost.localdomain>
	<4D694535.6070207@v.loewis.de>
Message-ID: <20110226203041.79e378c4@pitrou.net>


Martin, I have now enabled the eol hook on the test repo (a quick test
seemed to show it works). Could you test again?

Regards

Antoine.


On Sat, 26 Feb 2011 19:23:49 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 26.02.2011 19:13, schrieb Antoine Pitrou:
> > 
> >> In Mercurial, it's just a hook, and optional. So we can't be sure all
> >> users use it correctly - and in my (limited) experience with Mercurial,
> >> chances are high that users will make mistakes in that respect (i.e.
> >> in one out of one cross-platform projects, a committer had issues
> >> with CRLF, leading to catastrophic repository corruption).
> > 
> > ?Catastrophic? repository ?corruption?? This sounds very strongly like
> > an urban legend.
> > Perhaps some files had later to be fixed. But that shouldn't be out of
> > the realm of normal Mercurial commands (aka "edit file to fix endings,
> > then hg commit and hg push").
> 
> It actually happened to me, so please trust me that it's not a legend.
> Yes, I could fix it with hg commands, and a lot of text editing.
> It took me a day, I considered the repository corrupted so that I
> actually had to branch from the last ok revision, and redo all checkins
> since (I also discarded changes which I didn't chose to redo). It was
> a real catastrophe to me.
> 
> Since the changes actually changed all lines, "hg blame" became useless,
> which was unacceptable.
> 
> Regards,
> Martin

From brett at python.org  Sat Feb 26 20:45:36 2011
From: brett at python.org (Brett Cannon)
Date: Sat, 26 Feb 2011 11:45:36 -0800
Subject: [Python-Dev] r88589 -
	python/branches/py3k/Lib/test/test_logging.py
In-Reply-To: <20110225232456.0be6176a@pitrou.net>
References: <20110225170243.CC07AEE9BD@mail.python.org>
	<20110225232456.0be6176a@pitrou.net>
Message-ID: <AANLkTimWTtGoy3eOb5okyx-TthWXncJCR6wD3gftu7h7@mail.gmail.com>

And if it gets disabled again it should be a skipped test instead of a
commented-out test to better keep track that it's turned off.

On Fri, Feb 25, 2011 at 14:24, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Fri, 25 Feb 2011 18:02:43 +0100 (CET)
> vinay.sajip <python-checkins at python.org> wrote:
> > Author: vinay.sajip
> > Date: Fri Feb 25 18:02:43 2011
> > New Revision: 88589
> >
> > Log:
> > logging: enabled test which was intermittently failing on buildbots.
>
>
> Looks like it fails again:
>
> (
> http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2671/steps/test/logs/stdio)
>
> ======================================================================
> ERROR: test_compute_rollover_MIDNIGHT
> (test.test_logging.TimedRotatingFileHandlerTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 1990, in tearDown
>    os.unlink(self.fn)
> WindowsError: [Error 32] The process cannot access the file because it is
> being used by another process:
> 'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-vhc3k5.log'
>
> ======================================================================
> FAIL: test_compute_rollover_MIDNIGHT
> (test.test_logging.TimedRotatingFileHandlerTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 2053, in test_compute_rollover
>    self.assertEqual(exp, rh.computeRollover(0.0))
> AssertionError: 82800 != 18000.0
>
> ======================================================================
> FAIL: test_compute_rollover_S
> (test.test_logging.TimedRotatingFileHandlerTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 1981, in setUp
>    BaseTest.setUp(self)
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 95, in setUp
>    raise AssertionError('Unexpected handlers: %s' % hlist)
> AssertionError: Unexpected handlers: [<logging.StreamHandler object at
> 0x0DAFC5B0>]
>
> ======================================================================
> FAIL: test_compute_rollover_W0
> (test.test_logging.TimedRotatingFileHandlerTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 1981, in setUp
>    BaseTest.setUp(self)
>  File
> "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
> line 95, in setUp
>    raise AssertionError('Unexpected handlers: %s' % hlist)
> AssertionError: Unexpected handlers: [<logging.StreamHandler object at
> 0x0DAFC5B0>]
>
>
> _______________________________________________
> 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/20110226/ca1e3694/attachment.html>

From brett at python.org  Sat Feb 26 20:56:18 2011
From: brett at python.org (Brett Cannon)
Date: Sat, 26 Feb 2011 11:56:18 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225164600.415f8e04@limelight.wooz.org>
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>
	<4D680B3C.4040209@freehackers.org>
	<20110225164600.415f8e04@limelight.wooz.org>
Message-ID: <AANLkTi=yU-w59GzaX71=RHsfgXUZEzOWZNvZoz89=6+C@mail.gmail.com>

On Fri, Feb 25, 2011 at 13:46, Barry Warsaw <barry at python.org> wrote:

> On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote:
>
> >What you are asking for is available in TortoiseHg which absolutely
> >rocks (if you are not allergic to the idea of a graphical tool).
>
> Like shellfish, bee-strings, and Perl I'm afraid. :)
>
> >You can even select indvidually inside a file which lines to commit or
> >not. A bit risky but very handy when you have a few oneliners to commit
> >or not to commit.
>
> You mean, TortoiseHg supports incremental commits on a single file?  That's
> kind of neat, but scary. ;)
>

The record extension lets regular Mercurial do that as well. I think git
supports a similar thing.

-Brett


>
> -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/brett%40python.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/42d77e31/attachment.html>

From brett at python.org  Sat Feb 26 21:09:58 2011
From: brett at python.org (Brett Cannon)
Date: Sat, 26 Feb 2011 12:09:58 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226130847.05daf511@limelight.wooz.org>
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>
	<20110226130847.05daf511@limelight.wooz.org>
Message-ID: <AANLkTinq7svDrMK+M21-GrMB=ZjSByG-KmSd8_tYDofr@mail.gmail.com>

On Sat, Feb 26, 2011 at 10:08, Barry Warsaw <barry at python.org> wrote:

> On Feb 26, 2011, at 01:49 AM, ?ric Araujo wrote:
>
> >Le 25/02/2011 20:43, Barry Warsaw a ?crit :
> >> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:
> >> [snip]
> >>> Note that each of these branch clones will initially have your local
> >>> master repo as the default path [3,4]. If you'd like to have the
> default
> >>> push/pull path to point to ssh://hg at hg.python.org/cpython instead,
> you'd
> >>> want to edit the [paths] section in the .hg/hgrc file in each of the
> >>> branch repos.
> >
> >I plan on having one clone per branch but pushing and pulling from only
> >one repository, so I don?t need to edit hgrcs.
>
> So let's start from the basics.  I want separate working directories for
> each
> active line-of-development (I'll use that term instead of "branch"),
> e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2,
> and
> 3.3.  I will not be doing feature or bug development in any of these
> directories.  They are purely for local tracking of the remote masters.
>  Thus,
> I want to be able to synchronize any one of those LoDs against the remote
> master with one command, like I would using Subversion's 'svn up'.
>

For other people's benefit, LoD == line of development (I think).


>
> I clone the remote repository using the command in the devguide, so I now
> have
> a 'cpython' directory containing the history of all LoDs, but with a
> working
> directory that reflects the 'default' LoD.  Now, in the parent of
> 'cpython', I
> do the following to get my separate-directory-LoDs:
>
> $ hg clone -u 2.6 cpython py26
> $ hg clone -u 2.7 cpython py27
> # repeat and rinse for all other active LoDs
>
>
That's one way of doing it.


> (Aside: that cpython directory still bugs me.  It doesn't naturally reflect
> a
> LoD, so why do I have to stare at it?  Yes, I can make it play double duty
> by
> naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels
> artificial.)
>

It's a clone repository of CPython; the name makes perfect sense. You are
focusing on what the repository happens to be updated to ATM, not the fact
that the repository itself represents any and all LoDs.


>
> Now I want to synchronize my local py27 directory with the state of that
> LoD
> on python.org.  This is a two step process:
>
> $ cd py27 # now I want to synchronize
> $ (cd ../cpython && hg pull)
> $ hg pull -u
>
> Editing hgrc to point to hg.python.org means the sync-to-remote-master
> operation is one command.
>
> I could do this:
>
> $ cd py27 # now I want to synchronize
> $ hg pull -u ssh://hg at hg.python.org/cpython
>
> but I'm not going to remember that url every time.  It wouldn't be so bad
> if
> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar
> does.
>

So does Hg: simply edit your .hgrc to have it both pull and push to the same
URL.

Or you can save yourself some trouble, and simply clone the repository at a
specific branch:

  hg clone ssh://hg at hg.python.org/cpython#2.7

I believe that might even strip out other history outside the scope of the
branch.


>
> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and
> >found Mercurial branches very intuitive.  When I saw mentions of Bazaar
> >branches I was driven nuts by (what I saw as) the conflation between a
> >branch and a clone.  Later I understood how it made sense from the
> >perspective of Bazaar, so I shifted my judgment from ?insanely
> >confusing? to ?a particular choice that I don?t approve? <wink>.
>
> That's funny because to my eyes, Mercurial conflates "branches" and
> "clones".
> Why a clone operation should give me the history for all
> lines-of-development
> inside a working directory for one "arbitrary" one strikes me as bizarre
> (pardon the pun :).


Because Hg views a clone as that: a clone of the entire repository. A branch
just happens to be a part of the repository. And because it is the entire
repository it has to have you point somewhere, so it goes with default since
a lot of people never even work somewhere other than on default.


>  I get that for folks who like the "svn switch" method of
> working on multiple LoDs, this probably makes a lot of sense.  I don't
> personally like or trust that approach much though.
>

Neither do I in an svn context and why Hg does let you check out just a
branch and have all pulls and pushes only go to that branch.


>
> >What I?m saying is that a lot of Bazaar terminology using ?branch? does
> >not map as-is to Mercurial.  We clone a repo, we pull from a repo/clone,
> >we have named branches (e.g. 3.2) in a repo, we have unnamed branches on
> >one named branch.  I think you know that already, since you went from
> >using Bazaar terms applied to Mercurial to mixing terms from both
> >(?clone a new branch working directory? ? ?clone a repo?, probably).  I
> >salute your willingness to learn Mercurial, considering how fluent (and
> >fluffly) you appear to be with Bazaar.
>
> This is an inevitable problem with trying to converse fluently about three
> major dVCSs and at least one or two other non-dVCSs.  They all use the same
> words to mean vaguely similar things, but quickly get bogged down in the
> implementation details assigned to those words.  It all makes perfect sense
> when you've been immersed in those technologies, but it makes discussions
> and
> comparisons exceedingly difficult.  I've no doubt it's doubly painful to
> many
> people who have no prior experience with a dVCS.
>
> (Aside: Bazaar could have potentially eased these folks transition because
> you
> can use Bazaar just like you would Subversion - as a centralized VCS --
> without stopping others from using it with full dVCS features on the same
> code
> base.  I don't know if Mercurial offers the same flexibility.)
>
> It's a little like trying to teach Python to a Java programmer.  "Object",
> "Class", "Instance", "Import" all mean roughly similar things, which lulls
> you
> into a false sense of understanding.  We learn by holding up the new to the
> light of the familiar and looking for interference patterns. :)
>

Yes, fun isn't it? Makes me that much more glad I don't have to care about
other DVCSs anymore; make the decision of which one to go through was
painful partially for this reason.


>
> >> I'll have to remember that 'hg pull' does not update the working copy by
> >> default,
> >
> >That pull does not update is a feature: The operation between a remote
> >repo and the local repo (the .hg directory) is separate from the
> >operation from the local repo to the working directory.  When you know
> >that you want pull + update (like when you have a clean working
> >directory), you use ?hg pull -u?.  (I don?t like the fetch command.)
>
> Sure, I get that.  Again, this feature appears odd because I have the full
> history of all LoDs embedded in a working directory of a single LoD.


Not single, _current_. I know you don't like the whole svn switch approach
that this is like, but Hg is very much about "don't forget a thing", which
is why you need to view a clone as a clone repository that you are choosing
to view in a certain way at any moment in time instead of as a single branch
that just happens to be carrying around the weight of other branches.
Totally different approaches to VCS.


>  With the
> arrangement I outlined above (which is independent of the dVCS backing it),
> it
> makes no sense for each LoD working directory to contain all the history of
> all the other LoDs.
>

As I said above, use the #<branch> format and you skip this issue (I think).


>
> In Bazaar, a "branch" is an independent LoD and it's "repository" contains
> only its own history.  Sure, it might have identical history with other
> LoDs
> up to the point of divergence, and I have ways to efficiently share that
> history across multiple LoD working directories, but they are still
> separate
> and I don't need them if I don't care about them.  With Mercurial, all
> history
> for all LoDs in a repository always come along for the ride.
>
> >You speak to my heart, sir.  In your ~/.hgrc, under the section [ui],
> >set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs.
> >I use it and love it.
>
> Great, I'll try that, thanks.  One thing Mercurial and Bazaar definitely
> share
> is a wealth of magical awesomeness hidden in manpages, wiki pages, mailing
> list posts, people's heads, configuration files, and source code. :)
>
> >If you want to commit a subset of your local changes, I use
> >http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff
> >selection UI that works like a charm.
>
> I very rarely want to do that.  It's more common (but still, IME not *that*
> common) to commit the changes to just a few files at a time.  One thing
> Bazaar
> has that's very nice is the ability to "shelve" some changes for a time.
> Let's say I'm working on a bug and I want to merge your changes in or sync
> to
> the master.  I can shelve some or all of my uncommitted changes, which
> saves
> them essentially out-of-the-way patch files, and then reverts my
> uncommitted
> changes.  Unshelving then is the process of re-applying those patch files,
> and
> yes, resolving conflicts.
>

Hg's is the mq (Mercurial Queue) extension.


>
> This is also a great way to work when you want to do
> test-driven-development
> but need to do some exploration first.  You can hack around non-TDD until
> you're confident of your approach, shelve all your changes, then
> incrementally
> apply them back as you write each test.  I'm sure Mercurial has something
> equally awesome lurking about. :)



They all have the same history from the Linux kernel for the patch queue
concept. I suspect it's pretty universally implemented, just with different
command names (of course as gods forbid it be consistent).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/46aacbc0/attachment-0001.html>

From timothy.c.delaney at gmail.com  Sat Feb 26 21:25:51 2011
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Sun, 27 Feb 2011 07:25:51 +1100
Subject: [Python-Dev] [Python-checkins] cpython (trunk): Close the
	"trunk" branch.
In-Reply-To: <4D6923FF.9050204@v.loewis.de>
References: <E1PtDxi-0008OO-Os@dinsdale.python.org>
	<4D68CD42.5050005@v.loewis.de> <20110226110612.2766c0da@pitrou.net>
	<4D6923FF.9050204@v.loewis.de>
Message-ID: <AANLkTimuTALUJCQffQCaF2hGCnrc=Ne7bjNxofnn4-EM@mail.gmail.com>

On 27 February 2011 03:02, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> > Committing reopened it
>
> So what's the point of closing it, then? What effect does that
> achieve?


http://stackoverflow.com/questions/4099345/is-it-possible-to-reopen-a-closed-branch-in-mercurial/4101279#4101279

The closed flag is just used to filter out closed branches from hg branches
and hg heads unless you use the --closed option - it doesn't prevent you
from using the branches.

Basically, it reduces the noise, especially if you have very branchy
development like I personally prefer (a named branch per task/issue). If you
only use anonymous branches, except for your feature branches (e.g. 3.2,
2.7) then you'd probably never close a branch.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110227/bf023db0/attachment.html>

From timothy.c.delaney at gmail.com  Sat Feb 26 21:32:05 2011
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Sun, 27 Feb 2011 07:32:05 +1100
Subject: [Python-Dev] [Python-checkins] cpython: improve license
In-Reply-To: <20110226131225.2f310fc4@limelight.wooz.org>
References: <E1PtOWG-0002W6-30@dinsdale.python.org>
	<20110226131225.2f310fc4@limelight.wooz.org>
Message-ID: <AANLkTi=qvJW-+pKsna_x1Bc7=oWvHq8PXaotRMUU9nQk@mail.gmail.com>

On 27 February 2011 05:12, Barry Warsaw <barry at python.org> wrote:

> I guess it's possible for change notifications to encompass multiple named
> branches though, right?  I'm not sure what to do about that, but it seems
> like
> a less common use case.
>

Are the change notifications per-commit? If so, there's no way that a single
change notification could be for more than one named branch.

If the notifications are per-pull/per-push, then yes it could be for
multiple branches.

In either case, it should definitely be possible to put the name(s) of the
branches in the change notifications - in either type of hook you can
inspect the changesets and determine what branch they are on.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110227/74e5946f/attachment.html>

From timothy.c.delaney at gmail.com  Sat Feb 26 21:43:36 2011
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Sun, 27 Feb 2011 07:43:36 +1100
Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook.
In-Reply-To: <4D694535.6070207@v.loewis.de>
References: <E1PtOFd-0000wb-8X@dinsdale.python.org>
	<20110226185402.14b66d79@pitrou.net> <4D6940FE.509@v.loewis.de>
	<1298744009.3704.25.camel@localhost.localdomain>
	<4D694535.6070207@v.loewis.de>
Message-ID: <AANLkTimimOMLnuZ__ikfMH54fkhzYMBcTq2MR2=ict-8@mail.gmail.com>

On 27 February 2011 05:23, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> It actually happened to me, so please trust me that it's not a legend.
> Yes, I could fix it with hg commands, and a lot of text editing.
> It took me a day, I considered the repository corrupted so that I
> actually had to branch from the last ok revision, and redo all checkins
> since (I also discarded changes which I didn't chose to redo). It was
> a real catastrophe to me.
>
> Since the changes actually changed all lines, "hg blame" became useless,
> which was unacceptable.
>

I'd disagree that that is catastrophic repository corruption - it's fixable
by creating a new clone from before the "corruption", discarding the old one
and redoing the changes (possibly via cherry-picking).

Catastrophic corruption of a mercurial repository happens when the history
itself becomes corrupted. This should never happen under normal usage, but
it is possible to happen if you commit using an older version of hg to a
repo that's been created (or modified) by a newer version.

You can pull from a newer version repo using the older version, but you
shouldn't ever commit to it (including pushing) except through the "remote"
interfaces (where the remote hg is the one doing the actual commits).

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110227/9d1ab932/attachment.html>

From barry at python.org  Sat Feb 26 21:49:39 2011
From: barry at python.org (Barry Warsaw)
Date: Sat, 26 Feb 2011 15:49:39 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D684E2A.90005@netwok.org>
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>
Message-ID: <20110226154939.41972d08@limelight.wooz.org>

On Feb 26, 2011, at 01:49 AM, ?ric Araujo wrote:

>You speak to my heart, sir.  In your ~/.hgrc, under the section [ui],
>set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs.
>I use it and love it.

Except it doesn't quite work the way I want it to (hg 1.6.3).  It opens your
editor with two files, one is the commit message and the other is the diff.
(The script itself is a bit buggy too. ;)

But it's a good clue, and I've modified the default hgeditor script to get
closer, and fix the bug I noticed.  I basically append the diff to the
temporary log message file.  It's still not right though because if the diff
lines aren't prepended with 'HG:', they end up in the commit message.  Arg.

Oh well, I can clearly hack a more complicated script together.  It's such a
blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by
default.

-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/20110226/a426e1a8/attachment.pgp>

From timothy.c.delaney at gmail.com  Sat Feb 26 21:49:55 2011
From: timothy.c.delaney at gmail.com (Tim Delaney)
Date: Sun, 27 Feb 2011 07:49:55 +1100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTi=0+FQH4qtHsq7eg8-Vn9ju9u+Ow7+xX-MqN7Tm@mail.gmail.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<ika6uc$kkd$2@dough.gmane.org>
	<AANLkTi=0+FQH4qtHsq7eg8-Vn9ju9u+Ow7+xX-MqN7Tm@mail.gmail.com>
Message-ID: <AANLkTi=WhDcDooXW1uQcby0B+oxJB=PqbV2ZqOo_GfkK@mail.gmail.com>

On 27 February 2011 01:40, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> >> Would it be possible to name "trunk" as "2.x" instead? Otherwise I
> >> could see people getting confused and asking why trunk was closed,
> >> and/or not the same as "default".
> >
> > Problem is, you then have 1.5.2 released from the 2.x branch :)
>
> In that case, "legacy-trunk" would seem clearer.


+1

Exactly what I was about to suggest.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110227/b6306821/attachment.html>

From barry at python.org  Sat Feb 26 22:06:45 2011
From: barry at python.org (Barry Warsaw)
Date: Sat, 26 Feb 2011 16:06:45 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226190518.37F381FF8A4@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>
	<20110226130847.05daf511@limelight.wooz.org>
	<20110226190518.37F381FF8A4@kimball.webabinitio.net>
Message-ID: <20110226160645.5c5d28e6@limelight.wooz.org>

On Feb 26, 2011, at 02:05 PM, R. David Murray wrote:

>On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw <barry at python.org> wrote:
>> $ cd py27 # now I want to synchronize
>> $ hg pull -u ssh://hg at hg.python.org/cpython
>> 
>> but I'm not going to remember that url every time.  It wouldn't be so bad if
>> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.
>
>How does setting it in the hgrc differ from "remebering" it?

It's different because you don't use a familiar interface to set it (i.e hg).
You have to know to hack a file to make it work.  That's not awesome user
interface. ;)

>I've never been comfortable with the bzr --remember option because I'm never
>sure what it is remembering.  Much easier for me to see it in a config file.
>But, then, that's how my brain works, and other people's will work
>differently.

It's easy to tell what it remembers because it's exactly what you told it to
remember ;).  But I guess you're talking about push and pull automatically
remembering the location when none was previously set.  I love that feature.

And of course, bzr 'remembers' by setting a value in a config file, which of
course you *could* hack if you wanted to.  It's just that you don't normally
have to open your editor and remember which value in which config file you
have to manually modify to set the push and pull locations.  I think that's a
win, but YMMV. :)

Oh, and 'bzr info' always tells you what the push and pull locations are.

>I find bazaar's model confusing, and hg's intuitive, just like ??ric.
>And consider that I learned bazaar before mercurial.  To me, it makes
>perfect sense that in a DVCS the "unit" is a directory containing
>a repository and a working copy, and that the repository is *the*
>repository.  That is, it has everything related to the project in it,
>just like the master SVN repository does (plus, since it is a DVCS,
>whatever I've committed locally but not pushed to the master).  To have
>a repository that only has some of the stuff in it is, IMO, confusing.
>I advocated for having all the Python history in one repo partly for
>that reason.

I would feel better about Mercurial's if the repo where not intimately tied
with a default working tree (yes, I know -U).  In a sense, that's what
Bazaar's shared repositories are: a place where all your history goes.  In
Bazaar's model though, it's not tied to a specific working tree, and it's
hidden in a dot-directory.

It's still kind of beside the point - this is the way Mercurial works, and I
don't really mean this thread to be an in-depth comparison between the two.

-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/20110226/d1a6d395/attachment.pgp>

From solipsis at pitrou.net  Sat Feb 26 22:20:04 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 22:20:04 +0100
Subject: [Python-Dev] 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>
	<20110226130847.05daf511@limelight.wooz.org>
	<20110226190518.37F381FF8A4@kimball.webabinitio.net>
	<20110226160645.5c5d28e6@limelight.wooz.org>
Message-ID: <20110226222004.1d9e0596@pitrou.net>

On Sat, 26 Feb 2011 16:06:45 -0500
Barry Warsaw <barry at python.org> wrote:
> 
> >I find bazaar's model confusing, and hg's intuitive, just like ??ric.
> >And consider that I learned bazaar before mercurial.  To me, it makes
> >perfect sense that in a DVCS the "unit" is a directory containing
> >a repository and a working copy, and that the repository is *the*
> >repository.  That is, it has everything related to the project in it,
> >just like the master SVN repository does (plus, since it is a DVCS,
> >whatever I've committed locally but not pushed to the master).  To have
> >a repository that only has some of the stuff in it is, IMO, confusing.
> >I advocated for having all the Python history in one repo partly for
> >that reason.
> 
> I would feel better about Mercurial's if the repo where not intimately tied
> with a default working tree (yes, I know -U).  In a sense, that's what
> Bazaar's shared repositories are: a place where all your history goes.  In
> Bazaar's model though, it's not tied to a specific working tree, and it's
> hidden in a dot-directory.

Often (but not always), when you're wanting to do something, there's an
extension for Mercurial which can be enabled ;)
http://mercurial.selenic.com/wiki/ShareExtension

Regards

Antoine.



From grigory.javadyan at gmail.com  Sat Feb 26 22:23:16 2011
From: grigory.javadyan at gmail.com (Grigory Javadyan)
Date: Sun, 27 Feb 2011 01:23:16 +0400
Subject: [Python-Dev] Unbinding a name referenced by an enclosing scope -
	error in documentation?
Message-ID: <AANLkTin1sXmLM8_wWuqH3rGOsknKDEjiGWyboUrLB3Yw@mail.gmail.com>

Hi, guys
I'm not sure if python-dev is the right place to write to, but I'm
really curious about this:

>From the Python Language reference:
> It is illegal to unbind a name referenced by an enclosing scope; the compiler will report a SyntaxError.

But when I run the following code:

a = 3
def x():
 global a
 del(a)

print(a)
x()

it works fine; and when I change the order of calls:

x()
print(a)

I get a NameError, not a SyntaxError.

Now I asked the same question on python-list and people suggested that
the true meaning of that rule is:

>>> def f():
...     a = 42
...     def g():
...             nonlocal a
...             del a
...
SyntaxError: can not delete variable 'a' referenced in nested scope

Which looks weird, because the name is referenced in the _enclosed_
scope, not the _enclosing_ scope. Is there a typo in the documentation
or am I missing something?

From barry at python.org  Sat Feb 26 22:30:47 2011
From: barry at python.org (Barry Warsaw)
Date: Sat, 26 Feb 2011 16:30:47 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTinq7svDrMK+M21-GrMB=ZjSByG-KmSd8_tYDofr@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>
	<20110226130847.05daf511@limelight.wooz.org>
	<AANLkTinq7svDrMK+M21-GrMB=ZjSByG-KmSd8_tYDofr@mail.gmail.com>
Message-ID: <20110226163047.66140688@limelight.wooz.org>

On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote:

>For other people's benefit, LoD == line of development (I think).

Yes.  It's just a word that isn't intimately tied to the implementation
details of a specific dVCS.

>> I clone the remote repository using the command in the devguide, so I now
>> have
>> a 'cpython' directory containing the history of all LoDs, but with a
>> working
>> directory that reflects the 'default' LoD.  Now, in the parent of
>> 'cpython', I
>> do the following to get my separate-directory-LoDs:
>>
>> $ hg clone -u 2.6 cpython py26
>> $ hg clone -u 2.7 cpython py27
>> # repeat and rinse for all other active LoDs
>>
>>
>That's one way of doing it.

I'm sure there are many different ways of setting things up.  I am totally in
favor of the devguide documenting and encouraging one particular way, and I'm
sure Mercurial will prove to be a flexible tool that can conform to user's
preferences rather than the other way 'round.

>> (Aside: that cpython directory still bugs me.  It doesn't naturally reflect
>> a
>> LoD, so why do I have to stare at it?  Yes, I can make it play double duty
>> by
>> naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels
>> artificial.)
>>
>It's a clone repository of CPython; the name makes perfect sense. You are
>focusing on what the repository happens to be updated to ATM, not the fact
>that the repository itself represents any and all LoDs.

No, I get all that.  I'm just not sure why I should care where all the history
is stored.  I'm not actually going to do any coding in the cpython directory,
so it just seems like a wart I have to carry around.  But as I said before,
this is the Mercurial Way, so be it.

>> Now I want to synchronize my local py27 directory with the state of that
>> LoD
>> on python.org.  This is a two step process:
>>
>> $ cd py27 # now I want to synchronize
>> $ (cd ../cpython && hg pull)
>> $ hg pull -u
>>
>> Editing hgrc to point to hg.python.org means the sync-to-remote-master
>> operation is one command.
>>
>> I could do this:
>>
>> $ cd py27 # now I want to synchronize
>> $ hg pull -u ssh://hg at hg.python.org/cpython
>>
>> but I'm not going to remember that url every time.  It wouldn't be so bad
>> if
>> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar
>> does.
>>
>
>So does Hg: simply edit your .hgrc to have it both pull and push to the same
>URL.

Right, see my follow up to RDM.

>Or you can save yourself some trouble, and simply clone the repository at a
>specific branch:
>
>  hg clone ssh://hg at hg.python.org/cpython#2.7
>
>I believe that might even strip out other history outside the scope of the
>branch.

That might be a better way if it doesn't slurp down the entire repository
history.

>> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and
>> >found Mercurial branches very intuitive.  When I saw mentions of Bazaar
>> >branches I was driven nuts by (what I saw as) the conflation between a
>> >branch and a clone.  Later I understood how it made sense from the
>> >perspective of Bazaar, so I shifted my judgment from ?insanely
>> >confusing? to ?a particular choice that I don?t approve? <wink>.
>>
>> That's funny because to my eyes, Mercurial conflates "branches" and
>> "clones".
>> Why a clone operation should give me the history for all
>> lines-of-development
>> inside a working directory for one "arbitrary" one strikes me as bizarre
>> (pardon the pun :).
>
>Because Hg views a clone as that: a clone of the entire repository. A branch
>just happens to be a part of the repository. And because it is the entire
>repository it has to have you point somewhere, so it goes with default since
>a lot of people never even work somewhere other than on default.

Yep, I get all that.  It's Mercurial's model of the world.

>Yes, fun isn't it? Makes me that much more glad I don't have to care about
>other DVCSs anymore; make the decision of which one to go through was
>painful partially for this reason.

Lucky you!  I interact with tons of projects, so I still have to deal with
everything from CVS to git.  This will be my first serious foray into hg, and
for that I'm glad.  And really, *any* dVCS is better than a non-dVCS, so I'm
really happy this is finally happening, despite any initial grumbling you're
reading into my posts. :)

>> >> I'll have to remember that 'hg pull' does not update the working copy by
>> >> default,
>> >
>> >That pull does not update is a feature: The operation between a remote
>> >repo and the local repo (the .hg directory) is separate from the
>> >operation from the local repo to the working directory.  When you know
>> >that you want pull + update (like when you have a clean working
>> >directory), you use ?hg pull -u?.  (I don?t like the fetch command.)
>>
>> Sure, I get that.  Again, this feature appears odd because I have the full
>> history of all LoDs embedded in a working directory of a single LoD.
>
>Not single, _current_. I know you don't like the whole svn switch approach
>that this is like, but Hg is very much about "don't forget a thing", which
>is why you need to view a clone as a clone repository that you are choosing
>to view in a certain way at any moment in time instead of as a single branch
>that just happens to be carrying around the weight of other branches.
>Totally different approaches to VCS.

No really, I do get all that!  I just don't like it much.  Maybe it'll grow on
me though.

>> I very rarely want to do that.  It's more common (but still, IME not *that*
>> common) to commit the changes to just a few files at a time.  One thing
>> Bazaar
>> has that's very nice is the ability to "shelve" some changes for a time.
>> Let's say I'm working on a bug and I want to merge your changes in or sync
>> to
>> the master.  I can shelve some or all of my uncommitted changes, which
>> saves
>> them essentially out-of-the-way patch files, and then reverts my
>> uncommitted
>> changes.  Unshelving then is the process of re-applying those patch files,
>> and
>> yes, resolving conflicts.
>>
>
>Hg's is the mq (Mercurial Queue) extension.

I think mq is more like quilt than shelve.  The moral equivalents in Bazaar
would probably be the loom and pipeline extensions.

>> This is also a great way to work when you want to do
>> test-driven-development
>> but need to do some exploration first.  You can hack around non-TDD until
>> you're confident of your approach, shelve all your changes, then
>> incrementally
>> apply them back as you write each test.  I'm sure Mercurial has something
>> equally awesome lurking about. :)
>
>They all have the same history from the Linux kernel for the patch queue
>concept. I suspect it's pretty universally implemented, just with different
>command names (of course as gods forbid it be consistent).

Truth to that.

I've often advocated for the big three to converge on repository format and
wire protocol, and for them to innovate and differentiate on ui.  The models
might be different enough that you couldn't do it 100%, but the existence of
mapping extensions (e.g. hg-git, bzr-hg) seems to imply that they're pretty
darn close.

If we had this, then all the hand wringing about which dVCS to choose would be
essentially moot.  You'd just pick the cli and gui clients you preferred.
Really, sweating over the dVCS tool detracts from what you do care about,
which is developing 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/20110226/419bf994/attachment.pgp>

From barry at python.org  Sat Feb 26 22:32:23 2011
From: barry at python.org (Barry Warsaw)
Date: Sat, 26 Feb 2011 16:32:23 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226222004.1d9e0596@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>
	<20110226130847.05daf511@limelight.wooz.org>
	<20110226190518.37F381FF8A4@kimball.webabinitio.net>
	<20110226160645.5c5d28e6@limelight.wooz.org>
	<20110226222004.1d9e0596@pitrou.net>
Message-ID: <20110226163223.78e020b2@limelight.wooz.org>

On Feb 26, 2011, at 10:20 PM, Antoine Pitrou wrote:

>Often (but not always), when you're wanting to do something, there's an
>extension for Mercurial which can be enabled ;)
>http://mercurial.selenic.com/wiki/ShareExtension

You sound like an iPhone commercial: "There's an app for that."

:)

-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/20110226/3c5a0b3e/attachment-0001.pgp>

From benjamin at python.org  Sat Feb 26 22:33:57 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 26 Feb 2011 15:33:57 -0600
Subject: [Python-Dev] Unbinding a name referenced by an enclosing scope
 - error in documentation?
In-Reply-To: <AANLkTin1sXmLM8_wWuqH3rGOsknKDEjiGWyboUrLB3Yw@mail.gmail.com>
References: <AANLkTin1sXmLM8_wWuqH3rGOsknKDEjiGWyboUrLB3Yw@mail.gmail.com>
Message-ID: <AANLkTin8ZUodvcVu9-=whABGbn7gkx5Xquw3_8VHrjWB@mail.gmail.com>

2011/2/26 Grigory Javadyan <grigory.javadyan at gmail.com>:
>>>> def f():
> ... ? ? a = 42
> ... ? ? def g():
> ... ? ? ? ? ? ? nonlocal a
> ... ? ? ? ? ? ? del a
> ...
> SyntaxError: can not delete variable 'a' referenced in nested scope
>
> Which looks weird, because the name is referenced in the _enclosed_
> scope, not the _enclosing_ scope. Is there a typo in the documentation
> or am I missing something?

Actually you can do that now 3.2+. I've now removed that sentence;.



-- 
Regards,
Benjamin

From merwok at netwok.org  Sat Feb 26 22:36:47 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 26 Feb 2011 22:36:47 +0100
Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook
In-Reply-To: <E1PtQhM-0005Fn-MU@dinsdale.python.org>
References: <E1PtQhM-0005Fn-MU@dinsdale.python.org>
Message-ID: <4D69726F.5000803@netwok.org>

> +        if branch in ('trunk', 'legacy-trunk',
> +                      '2.0', '2.1', '2.2', '2.3', '2.4', '3.0'):

Wouldn?t using a whitelist instead of a blacklist protect against new
named branches too?

From brett at python.org  Sat Feb 26 22:37:04 2011
From: brett at python.org (Brett Cannon)
Date: Sat, 26 Feb 2011 13:37:04 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226163047.66140688@limelight.wooz.org>
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>
	<20110226130847.05daf511@limelight.wooz.org>
	<AANLkTinq7svDrMK+M21-GrMB=ZjSByG-KmSd8_tYDofr@mail.gmail.com>
	<20110226163047.66140688@limelight.wooz.org>
Message-ID: <AANLkTi=oWYGdHW-jifqFfS6PAY6oKcTxNz+1MT4Kv5ic@mail.gmail.com>

On Sat, Feb 26, 2011 at 13:30, Barry Warsaw <barry at python.org> wrote:

> On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote:
>
> >For other people's benefit, LoD == line of development (I think).
>
> Yes.  It's just a word that isn't intimately tied to the implementation
> details of a specific dVCS.
>
> >> I clone the remote repository using the command in the devguide, so I
> now
> >> have
> >> a 'cpython' directory containing the history of all LoDs, but with a
> >> working
> >> directory that reflects the 'default' LoD.  Now, in the parent of
> >> 'cpython', I
> >> do the following to get my separate-directory-LoDs:
> >>
> >> $ hg clone -u 2.6 cpython py26
> >> $ hg clone -u 2.7 cpython py27
> >> # repeat and rinse for all other active LoDs
> >>
> >>
> >That's one way of doing it.
>
> I'm sure there are many different ways of setting things up.  I am totally
> in
> favor of the devguide documenting and encouraging one particular way, and
> I'm
> sure Mercurial will prove to be a flexible tool that can conform to user's
> preferences rather than the other way 'round.
>
> >> (Aside: that cpython directory still bugs me.  It doesn't naturally
> reflect
> >> a
> >> LoD, so why do I have to stare at it?  Yes, I can make it play double
> duty
> >> by
> >> naming it "3.3" or whatever and updating it to the 3.3 LoD, but that
> feels
> >> artificial.)
> >>
> >It's a clone repository of CPython; the name makes perfect sense. You are
> >focusing on what the repository happens to be updated to ATM, not the fact
> >that the repository itself represents any and all LoDs.
>
> No, I get all that.  I'm just not sure why I should care where all the
> history
> is stored.  I'm not actually going to do any coding in the cpython
> directory,
> so it just seems like a wart I have to carry around.  But as I said before,
> this is the Mercurial Way, so be it.
>
> >> Now I want to synchronize my local py27 directory with the state of that
> >> LoD
> >> on python.org.  This is a two step process:
> >>
> >> $ cd py27 # now I want to synchronize
> >> $ (cd ../cpython && hg pull)
> >> $ hg pull -u
> >>
> >> Editing hgrc to point to hg.python.org means the sync-to-remote-master
> >> operation is one command.
> >>
> >> I could do this:
> >>
> >> $ cd py27 # now I want to synchronize
> >> $ hg pull -u ssh://hg at hg.python.org/cpython
> >>
> >> but I'm not going to remember that url every time.  It wouldn't be so
> bad
> >> if
> >> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar
> >> does.
> >>
> >
> >So does Hg: simply edit your .hgrc to have it both pull and push to the
> same
> >URL.
>
> Right, see my follow up to RDM.
>
> >Or you can save yourself some trouble, and simply clone the repository at
> a
> >specific branch:
> >
> >  hg clone ssh://hg at hg.python.org/cpython#2.7
> >
> >I believe that might even strip out other history outside the scope of the
> >branch.
>
> That might be a better way if it doesn't slurp down the entire repository
> history.
>
> >> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and
> >> >found Mercurial branches very intuitive.  When I saw mentions of Bazaar
> >> >branches I was driven nuts by (what I saw as) the conflation between a
> >> >branch and a clone.  Later I understood how it made sense from the
> >> >perspective of Bazaar, so I shifted my judgment from ?insanely
> >> >confusing? to ?a particular choice that I don?t approve? <wink>.
> >>
> >> That's funny because to my eyes, Mercurial conflates "branches" and
> >> "clones".
> >> Why a clone operation should give me the history for all
> >> lines-of-development
> >> inside a working directory for one "arbitrary" one strikes me as bizarre
> >> (pardon the pun :).
> >
> >Because Hg views a clone as that: a clone of the entire repository. A
> branch
> >just happens to be a part of the repository. And because it is the entire
> >repository it has to have you point somewhere, so it goes with default
> since
> >a lot of people never even work somewhere other than on default.
>
> Yep, I get all that.  It's Mercurial's model of the world.
>
> >Yes, fun isn't it? Makes me that much more glad I don't have to care about
> >other DVCSs anymore; make the decision of which one to go through was
> >painful partially for this reason.
>
> Lucky you!  I interact with tons of projects, so I still have to deal with
> everything from CVS to git.  This will be my first serious foray into hg,
> and
> for that I'm glad.  And really, *any* dVCS is better than a non-dVCS, so
> I'm
> really happy this is finally happening, despite any initial grumbling
> you're
> reading into my posts. :)
>
> >> >> I'll have to remember that 'hg pull' does not update the working copy
> by
> >> >> default,
> >> >
> >> >That pull does not update is a feature: The operation between a remote
> >> >repo and the local repo (the .hg directory) is separate from the
> >> >operation from the local repo to the working directory.  When you know
> >> >that you want pull + update (like when you have a clean working
> >> >directory), you use ?hg pull -u?.  (I don?t like the fetch command.)
> >>
> >> Sure, I get that.  Again, this feature appears odd because I have the
> full
> >> history of all LoDs embedded in a working directory of a single LoD.
> >
> >Not single, _current_. I know you don't like the whole svn switch approach
> >that this is like, but Hg is very much about "don't forget a thing", which
> >is why you need to view a clone as a clone repository that you are
> choosing
> >to view in a certain way at any moment in time instead of as a single
> branch
> >that just happens to be carrying around the weight of other branches.
> >Totally different approaches to VCS.
>
> No really, I do get all that!  I just don't like it much.  Maybe it'll grow
> on
> me though.
>
> >> I very rarely want to do that.  It's more common (but still, IME not
> *that*
> >> common) to commit the changes to just a few files at a time.  One thing
> >> Bazaar
> >> has that's very nice is the ability to "shelve" some changes for a time.
> >> Let's say I'm working on a bug and I want to merge your changes in or
> sync
> >> to
> >> the master.  I can shelve some or all of my uncommitted changes, which
> >> saves
> >> them essentially out-of-the-way patch files, and then reverts my
> >> uncommitted
> >> changes.  Unshelving then is the process of re-applying those patch
> files,
> >> and
> >> yes, resolving conflicts.
> >>
> >
> >Hg's is the mq (Mercurial Queue) extension.
>
> I think mq is more like quilt than shelve.  The moral equivalents in Bazaar
> would probably be the loom and pipeline extensions.
>
> >> This is also a great way to work when you want to do
> >> test-driven-development
> >> but need to do some exploration first.  You can hack around non-TDD
> until
> >> you're confident of your approach, shelve all your changes, then
> >> incrementally
> >> apply them back as you write each test.  I'm sure Mercurial has
> something
> >> equally awesome lurking about. :)
> >
> >They all have the same history from the Linux kernel for the patch queue
> >concept. I suspect it's pretty universally implemented, just with
> different
> >command names (of course as gods forbid it be consistent).
>
> Truth to that.
>
> I've often advocated for the big three to converge on repository format and
> wire protocol, and for them to innovate and differentiate on ui.  The
> models
> might be different enough that you couldn't do it 100%, but the existence
> of
> mapping extensions (e.g. hg-git, bzr-hg) seems to imply that they're pretty
> darn close.
>
> If we had this, then all the hand wringing about which dVCS to choose would
> be
> essentially moot.  You'd just pick the cli and gui clients you preferred.
> Really, sweating over the dVCS tool detracts from what you do care about,
> which is developing Python!


There is hg-git, but that is hg on top of git.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/b405a77a/attachment.html>

From nyamatongwe at gmail.com  Sat Feb 26 22:39:29 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Sun, 27 Feb 2011 08:39:29 +1100
Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook.
In-Reply-To: <4D694535.6070207@v.loewis.de>
References: <E1PtOFd-0000wb-8X@dinsdale.python.org>
	<20110226185402.14b66d79@pitrou.net> <4D6940FE.509@v.loewis.de>
	<1298744009.3704.25.camel@localhost.localdomain>
	<4D694535.6070207@v.loewis.de>
Message-ID: <AANLkTikkoWiMpb7C36f8x7PGprX9BpbQp0B5MNeNC_k3@mail.gmail.com>

   Line end problems do occur in real projects. A scintilla-cocoa
project was branched off Scintilla to support the Cocoa GUI framework
on OS X. Here is one of the revisions in that project:
http://bazaar.launchpad.net/~mike-lischke/scintilla-cocoa/trunk/revision/5#include/ScintillaWidget.h

   If the ScintillaWidget.h changes aren't visible (after a brief
wait) then click on the arrow next to it. There are only 3 real
changed lines in this file (which are changing comments from C++ to C)
but the whole file appears to have been changed.

   This is far from the worst I have seen with some revisions showing
almost every line in a project changed.

   There are several effects from this:
1) The blame command loses usefulness as all lines in the file appear
to be from this revision.
2) Downloads become bigger, and take longer.
3) Fixing the issues takes time, effort and junks the history further.

   Neil

From digitalxero at gmail.com  Sat Feb 26 22:48:05 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 26 Feb 2011 16:48:05 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTinq7svDrMK+M21-GrMB=ZjSByG-KmSd8_tYDofr@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>
	<20110226130847.05daf511@limelight.wooz.org>
	<AANLkTinq7svDrMK+M21-GrMB=ZjSByG-KmSd8_tYDofr@mail.gmail.com>
Message-ID: <AANLkTimA1-MtkTUL9mmGYo-ktSWxAsLwU+u2Ez=zC32W@mail.gmail.com>

On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon <brett at python.org> wrote:
> Hg's is the mq (Mercurial Queue) extension.

I prefer the hg shelve plugin
(http://mercurial.selenic.com/wiki/ShelveExtension) for this, more
intuitive to me

From solipsis at pitrou.net  Sat Feb 26 22:50:25 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 26 Feb 2011 22:50:25 +0100
Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook
References: <E1PtQhM-0005Fn-MU@dinsdale.python.org>
	<4D69726F.5000803@netwok.org>
Message-ID: <20110226225025.691466c8@pitrou.net>

On Sat, 26 Feb 2011 22:36:47 +0100
?ric Araujo <merwok at netwok.org> wrote:
> > +        if branch in ('trunk', 'legacy-trunk',
> > +                      '2.0', '2.1', '2.2', '2.3', '2.4', '3.0'):
> 
> Wouldn?t using a whitelist instead of a blacklist protect against new
> named branches too?

Then we will have to fix the hook each time we want to add a new
legitimate branch.  I have no preference really.

Regards

Antoine.



From greg.ewing at canterbury.ac.nz  Sat Feb 26 23:26:42 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 27 Feb 2011 11:26:42 +1300
Subject: [Python-Dev] of branches and heads
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D693A02.4000104@v.loewis.de>
	<1298742940.3704.17.camel@localhost.localdomain>
	<AANLkTimhsnQe4JtLcPaAUo6FOk5-5=TBNFMYSWsOQpM-@mail.gmail.com>
	<20110226202912.7d4813ba@pitrou.net>
Message-ID: <D85EA30224A3CC40ACA1E2FE6D4D6914351732@cantwe3.canterbury.ac.nz>

From: Antoine Pitrou
> - a "branch" usually means a "named branch": a set of changesets
>   bearing the same label (e.g. "default"); that label is freely chosen
>   by the committer at any point, and enforces no topological
>   characteristic

There are *some* topological restrictions, because hg won't
let you assign a branch name that's been used before to a node
unless one of its parents has that name. So you can't create
two disconnected subgraphs whose nodes have the same branch
name.

-- 
Greg

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

From greg.ewing at canterbury.ac.nz  Sat Feb 26 23:30:43 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 27 Feb 2011 11:30:43 +1300
Subject: [Python-Dev] Unbinding a name referenced by an enclosing scope
 - error in documentation?
References: <AANLkTin1sXmLM8_wWuqH3rGOsknKDEjiGWyboUrLB3Yw@mail.gmail.com>
Message-ID: <D85EA30224A3CC40ACA1E2FE6D4D6914351734@cantwe3.canterbury.ac.nz>

From: Grigory Javadyan
> ... def f():
> ...     a = 42
> ...     def g():
> ...             nonlocal a
> ...             del a
> ...
> SyntaxError: can not delete variable 'a' referenced in nested scope

Is there a rational for this? It seems inconsistent -- if you can
assign to names in outer scopes, you should be able to del them
as well.

-- 
Greg

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

From benjamin at python.org  Sat Feb 26 23:36:12 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 26 Feb 2011 16:36:12 -0600
Subject: [Python-Dev] Unbinding a name referenced by an enclosing scope
 - error in documentation?
In-Reply-To: <D85EA30224A3CC40ACA1E2FE6D4D6914351734@cantwe3.canterbury.ac.nz>
References: <AANLkTin1sXmLM8_wWuqH3rGOsknKDEjiGWyboUrLB3Yw@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351734@cantwe3.canterbury.ac.nz>
Message-ID: <AANLkTimnvN4rkD9sgfvYOZ4+xLVyheC5eXHRzXT9K22N@mail.gmail.com>

2011/2/26 Greg Ewing <greg.ewing at canterbury.ac.nz>:
> From: Grigory Javadyan
>> ... def f():
>> ... ? ? a = 42
>> ... ? ? def g():
>> ... ? ? ? ? ? ? nonlocal a
>> ... ? ? ? ? ? ? del a
>> ...
>> SyntaxError: can not delete variable 'a' referenced in nested scope
>
> Is there a rational for this? It seems inconsistent -- if you can
> assign to names in outer scopes, you should be able to del them
> as well.

Notice that it's now been changed...


-- 
Regards,
Benjamin

From adrian at cadifra.com  Sat Feb 26 23:45:24 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Sat, 26 Feb 2011 23:45:24 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226160645.5c5d28e6@limelight.wooz.org>
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>	<20110226130847.05daf511@limelight.wooz.org>	<20110226190518.37F381FF8A4@kimball.webabinitio.net>
	<20110226160645.5c5d28e6@limelight.wooz.org>
Message-ID: <4D698284.60305@cadifra.com>

On 2011-02-26 22:06, Barry Warsaw wrote:
> On Feb 26, 2011, at 02:05 PM, R. David Murray wrote:
> 
>> On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw <barry at python.org> wrote:
>>> $ cd py27 # now I want to synchronize
>>> $ hg pull -u ssh://hg at hg.python.org/cpython
>>>
>>> but I'm not going to remember that url every time.  It wouldn't be so bad if
>>> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.
>>
>> How does setting it in the hgrc differ from "remebering" it?
> 
> It's different because you don't use a familiar interface to set it (i.e hg).
> You have to know to hack a file to make it work.  That's not awesome user
> interface. ;)

You'd have to take this up with Mercurial's BDFL Matt. He is a strong
advocate for teaching users to learn edit their .hg/hgrc files.

And he's quite firm on not wanting to have Mercurial touch .hg/hgrc --
with the single exception being to write a initial .hg/hgrc on 'hg
clone', containing the default path with the location from where the
repo was cloned.

Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check'
- and always gave up again looking at bzr due to the horrible slowness
of that command. If I have to use a DVCS I want to be able to check the
integrity of my clones in reasonable time. I do it with a cron job on
our internal server here and I expect it to have finished checking all
our repos when I get to my desk in the morning and look into my email
inbox, reading the daily email with the result of the verify runs.

After all, we do have everything secured with hashes, so we can use
them, don't we?

>> I've never been comfortable with the bzr --remember option because I'm never
>> sure what it is remembering.  Much easier for me to see it in a config file.
>> But, then, that's how my brain works, and other people's will work
>> differently.
> 
> It's easy to tell what it remembers because it's exactly what you told it to
> remember ;).  But I guess you're talking about push and pull automatically
> remembering the location when none was previously set.  I love that feature.
> 
> And of course, bzr 'remembers' by setting a value in a config file, which of
> course you *could* hack if you wanted to.  It's just that you don't normally
> have to open your editor and remember which value in which config file you
> have to manually modify to set the push and pull locations.  I think that's a
> win, but YMMV. :)
> 
> Oh, and 'bzr info' always tells you what the push and pull locations are.

You can use 'hg paths' for that:

See http://selenic.com/repo/hg/help/paths or 'hg help paths' on the
command line.

>> I find bazaar's model confusing, and hg's intuitive, just like ??ric.
>> And consider that I learned bazaar before mercurial.  To me, it makes
>> perfect sense that in a DVCS the "unit" is a directory containing
>> a repository and a working copy, and that the repository is *the*
>> repository.  That is, it has everything related to the project in it,
>> just like the master SVN repository does (plus, since it is a DVCS,
>> whatever I've committed locally but not pushed to the master).  To have
>> a repository that only has some of the stuff in it is, IMO, confusing.
>> I advocated for having all the Python history in one repo partly for
>> that reason.
> 
> I would feel better about Mercurial's if the repo where not intimately tied
> with a default working tree (yes, I know -U).  In a sense, that's what
> Bazaar's shared repositories are: a place where all your history goes.  In
> Bazaar's model though, it's not tied to a specific working tree, and it's
> hidden in a dot-directory.
> 
> It's still kind of beside the point - this is the way Mercurial works, and I
> don't really mean this thread to be an in-depth comparison between the two.

I'm quite surprised indeed to read that much about Bazaar in this thread
here :)

From stutzbach at google.com  Sun Feb 27 00:08:19 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sat, 26 Feb 2011 15:08:19 -0800
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <AANLkTi=oWYGdHW-jifqFfS6PAY6oKcTxNz+1MT4Kv5ic@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>
	<20110226130847.05daf511@limelight.wooz.org>
	<AANLkTinq7svDrMK+M21-GrMB=ZjSByG-KmSd8_tYDofr@mail.gmail.com>
	<20110226163047.66140688@limelight.wooz.org>
	<AANLkTi=oWYGdHW-jifqFfS6PAY6oKcTxNz+1MT4Kv5ic@mail.gmail.com>
Message-ID: <AANLkTimKghaEi+oEN8Qb8fCa8EaD8z4OdDV_5J=cTh2_@mail.gmail.com>

On Sat, Feb 26, 2011 at 1:37 PM, Brett Cannon <brett at python.org> wrote:

> There is hg-git, but that is hg on top of git.
>

Actually, hg-git is bidirectional.  The hg-git documentation is written from
the perspective of an hg client talking to a git server, but for a DVCS
"client" and "server" are  a matter of perspective.

I spent some time on Friday setting up hg-git on my workstation and making a
few test commits.  It took me awhile to figure out how to get everything
working, but it seems to work smoothly now.  At some point I'll update
http://wiki.python.org/moin/Git with instructions.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/87e2fc7b/attachment.html>

From digitalxero at gmail.com  Sun Feb 27 00:13:15 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 26 Feb 2011 18:13:15 -0500
Subject: [Python-Dev] hg extensions was  Mercurial conversion repositories
Message-ID: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>

So reading the thread about the conversion and the dev guide at
http://potrou.net/hgdevguide/ there seems to not be a list of
recommended extensions that the python devs should have and use, only
a few examples of their use. so I figured I would build up a list for
other people to add to / comment on

File Format Management
    eol
        http://mercurial.selenic.com/wiki/EolExtension
        required

    flake8
        http://pypi.python.org/pypi/flake8/
        recommended especially for new commiters as it will validate
pep8 compliance and check for common errors
        *Maybe update it to do pep7 compliance checks on the c files as well?

Patch Management
    mq
        http://mercurial.selenic.com/wiki/MqExtension
        This is the one the devguide uses in examples

    rebase
        http://mercurial.selenic.com/wiki/RebaseExtension
        used with the --collapse option it is very easy to build up a
patch patch with incremental commits, but discard the private history
of the developer
        This one makes more sense to me personally then mq and fits
how my standard workflow goes better

    shelve
        http://mercurial.selenic.com/wiki/ShelveExtension
        Store un commited changes away so they dont affect generation
of the patch

    transplant
        http://mercurial.selenic.com/wiki/TransplantExtension
        required to port patches between major versions

    record
        http://mercurial.selenic.com/wiki/RecordExtension
        Allows cherry picking of commits to build a patch, Also works with mq

    Crecord
        http://mercurial.selenic.com/wiki/CrecordExtension
        appears to be a c optimized version or record

Branch Management
    bookmarks
        http://mercurial.selenic.com/wiki/BookmarksExtension
        Great for tracking bug fix work without needing to create a
separate working directory
        recommended that the central repo NOT have the extension
enabled so as to ensure bookmarks are a local only tracking system

From merwok at netwok.org  Sun Feb 27 00:19:56 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 27 Feb 2011 00:19:56 +0100
Subject: [Python-Dev] hg extensions (was: Mercurial conversion
	repositories)
In-Reply-To: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
Message-ID: <4D698A9C.3010505@netwok.org>

Hi,

>     shelve
>         http://mercurial.selenic.com/wiki/ShelveExtension
>         Store un commited changes away so they dont affect generation
> of the patch
I never use it.

>    transplant
>         http://mercurial.selenic.com/wiki/TransplantExtension
>         required to port patches between major versions
That?s actually not clear in the current PEP / devguide.

>     record
>         http://mercurial.selenic.com/wiki/RecordExtension
>         Allows cherry picking of commits to build a patch, Also works with mq
?Cherry-picking? means ?selecting some changesets for pull?, not
?selecting some diff hunks for commit?.

>     Crecord
>         http://mercurial.selenic.com/wiki/CrecordExtension
>         appears to be a c optimized version or record
Not at all.  It has the same functionality as record, only in a curses
UI instead of an unusable line-based interface.

> Branch Management
>     bookmarks
>         http://mercurial.selenic.com/wiki/BookmarksExtension
>         Great for tracking bug fix work without needing to create a
> separate working directory
Never use them.  Clones are okay.

Regards

From merwok at netwok.org  Sun Feb 27 00:21:23 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 27 Feb 2011 00:21:23 +0100
Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook
In-Reply-To: <20110226225025.691466c8@pitrou.net>
References: <E1PtQhM-0005Fn-MU@dinsdale.python.org>	<4D69726F.5000803@netwok.org>
	<20110226225025.691466c8@pitrou.net>
Message-ID: <4D698AF3.1010207@netwok.org>

> Then we will have to fix the hook each time we want to add a new
> legitimate branch.
The alternative is to edit the hook each time we want to remove a former
legitimate branch, plus have another hook to refuse new named branches.

>  I have no preference really.
Looks like a ?0 to me :)

Regards

From merwok at netwok.org  Sun Feb 27 00:24:10 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 27 Feb 2011 00:24:10 +0100
Subject: [Python-Dev] hg extensions
In-Reply-To: <4D698A9C.3010505@netwok.org>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
	<4D698A9C.3010505@netwok.org>
Message-ID: <4D698B9A.5070102@netwok.org>

> Never use them.  Clones are okay.
s/use/used/

From digitalxero at gmail.com  Sun Feb 27 00:37:15 2011
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 26 Feb 2011 18:37:15 -0500
Subject: [Python-Dev] hg extensions (was: Mercurial conversion
	repositories)
In-Reply-To: <4D698A9C.3010505@netwok.org>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
	<4D698A9C.3010505@netwok.org>
Message-ID: <AANLkTinvDYK2LguErwFv=HM7gKEUFeB1crVxNjC8eseS@mail.gmail.com>

On Sat, Feb 26, 2011 at 6:19 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> ? ?transplant
>> ? ? ? ? http://mercurial.selenic.com/wiki/TransplantExtension
>> ? ? ? ? required to port patches between major versions
> That?s actually not clear in the current PEP / devguide.

http://potrou.net/hgdevguide/committing.html#porting-between-major-versions

>
>> ? ? record
>> ? ? ? ? http://mercurial.selenic.com/wiki/RecordExtension
>> ? ? ? ? Allows cherry picking of commits to build a patch, Also works with mq
> ?Cherry-picking? means ?selecting some changesets for pull?, not
> ?selecting some diff hunks for commit?.

/shrug to me you cherry pick what you want to commit, shelve the rest,
create your patch then unshelve and continue development. Just a
matter of semantics :)

>
>> ? ? Crecord
>> ? ? ? ? http://mercurial.selenic.com/wiki/CrecordExtension
>> ? ? ? ? appears to be a c optimized version or record
> Not at all. ?It has the same functionality as record, only in a curses
> UI instead of an unusable line-based interface.

Ya I have never used either of them

>
>> Branch Management
>> ? ? bookmarks
>> ? ? ? ? http://mercurial.selenic.com/wiki/BookmarksExtension
>> ? ? ? ? Great for tracking bug fix work without needing to create a
>> separate working directory
> Never use them. ?Clones are okay.

Same here but not everyone likes to do that and in the dev guide they
use an example of working with only 1 working directory so the
bookmark extension would be useful to people who want to follow that
method of development

From adrian at cadifra.com  Sun Feb 27 00:41:05 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Sun, 27 Feb 2011 00:41:05 +0100
Subject: [Python-Dev] hg extensions was Mercurial conversion repositories
In-Reply-To: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
Message-ID: <4D698F91.4060602@cadifra.com>

On 2011-02-27 00:13, Dj Gilcrease wrote:
> Branch Management
>     bookmarks
>         http://mercurial.selenic.com/wiki/BookmarksExtension

Bookmarks will be in Mercurial core for Mercurial 1.8, which will be
released in a few days (March 1st). So, with 1.8 it's no longer needed
to enable this extension in the configuration -- the feature will be
built-in.

From hagen at zhuliguan.net  Sun Feb 27 00:44:17 2011
From: hagen at zhuliguan.net (=?ISO-8859-1?Q?Hagen_F=FCrstenau?=)
Date: Sun, 27 Feb 2011 00:44:17 +0100
Subject: [Python-Dev] set iteration order
In-Reply-To: <ikbd1t$umd$1@dough.gmane.org>
References: <ikag0f$nif$1@dough.gmane.org> <ikbd1t$umd$1@dough.gmane.org>
Message-ID: <ikc38h$5mp$1@dough.gmane.org>

> Code with any dependence on the iteration order of unordered collections
> (other than the guarantee that d.keys() and d.values() match at any
> given time as long as d is unchanged) is buggy.

It's not a matter of dependence on iteration order, but of
reproducibility (in my case there were minor numerical differences due
to different iteration orders). I think we also warn about changes in
pseudorandom number sequences, although you could argue that no code
should depend on specific pseudorandom numbers.

Cheers,
Hagen


From merwok at netwok.org  Sun Feb 27 00:55:42 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 27 Feb 2011 00:55:42 +0100
Subject: [Python-Dev] set iteration order
In-Reply-To: <ikc38h$5mp$1@dough.gmane.org>
References: <ikag0f$nif$1@dough.gmane.org> <ikbd1t$umd$1@dough.gmane.org>
	<ikc38h$5mp$1@dough.gmane.org>
Message-ID: <4D6992FE.5060801@netwok.org>

> It's not a matter of dependence on iteration order, but of
> reproducibility (in my case there were minor numerical differences due
> to different iteration orders).

Can you give a code example?  I don?t understand your case.

Regards

From steve at pearwood.info  Sun Feb 27 01:06:04 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 27 Feb 2011 11:06:04 +1100
Subject: [Python-Dev] set iteration order
In-Reply-To: <ikc38h$5mp$1@dough.gmane.org>
References: <ikag0f$nif$1@dough.gmane.org> <ikbd1t$umd$1@dough.gmane.org>
	<ikc38h$5mp$1@dough.gmane.org>
Message-ID: <4D69956C.2060902@pearwood.info>

Hagen F?rstenau wrote:
>> Code with any dependence on the iteration order of unordered collections
>> (other than the guarantee that d.keys() and d.values() match at any
>> given time as long as d is unchanged) is buggy.
> 
> It's not a matter of dependence on iteration order, but of
> reproducibility (in my case there were minor numerical differences due
> to different iteration orders). 

If those differences are insignificant to you, then why do you care?

If they are significant enough that (say) tests were failing, then your 
results depend on the iteration order of a set, and your code is buggy 
and should be fixed. Or perhaps your tests are too strict.


> I think we also warn about changes in
> pseudorandom number sequences, although you could argue that no code
> should depend on specific pseudorandom numbers.

The random module provides an API for repeating sequences of 
pseudorandom numbers: the seed. So you *can* depend on specific numbers, 
if you need to.

Sets and dicts do not provide any such API. The order even changes with 
the history of the object: two equal sets can have different iteration 
orders.

Personally, I don't care whether or not we mention that set iteration 
order has changed. It seems too trivial to worry much about it.

+0



-- 
Steven


From solipsis at pitrou.net  Sun Feb 27 01:06:57 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Feb 2011 01:06:57 +0100
Subject: [Python-Dev] hg extensions (was: Mercurial conversion
	repositories)
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
	<4D698A9C.3010505@netwok.org>
	<AANLkTinvDYK2LguErwFv=HM7gKEUFeB1crVxNjC8eseS@mail.gmail.com>
Message-ID: <20110227010657.12c047da@pitrou.net>

> >> Branch Management
> >> ? ? bookmarks
> >> ? ? ? ? http://mercurial.selenic.com/wiki/BookmarksExtension
> >> ? ? ? ? Great for tracking bug fix work without needing to create a
> >> separate working directory
> > Never use them. ?Clones are okay.
> 
> Same here but not everyone likes to do that and in the dev guide they
> use an example of working with only 1 working directory so the
> bookmark extension would be useful to people who want to follow that
> method of development

I've just tried bookmarks and I find them very cumbersome compared to
named branches (which, unfortunately, can't remain local). I wonder
what guided their design.

(the core issue being that a bookmark blindly follows every commit you
do, while you would need it to follow upstream instead!)

Regards

Antoine.



From solipsis at pitrou.net  Sun Feb 27 01:09:45 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Feb 2011 01:09:45 +0100
Subject: [Python-Dev] set iteration order
References: <ikag0f$nif$1@dough.gmane.org>
Message-ID: <20110227010945.2cb57e45@pitrou.net>

On Sat, 26 Feb 2011 10:09:33 +0100
Hagen F?rstenau <hagen at zhuliguan.net> wrote:
> 
> I just hunted down a change in behaviour between Python 3.1 and 3.2 to
> possibly changed iteration order of sets due to the optimization in
> issue #8685. Of course, this order shouldn't be relied on in the first
> place, but the side effect of the optimization might be worth mentioning
> in "What's new", maybe also pointing out that the old behaviour can be
> simulated with {x for x in a if x not in b} in place of "a-b".

I'm against such a mention. It would give the impression that we
support some semblance of reproduceability in iteration order, which is
not true. If you use sets or dicts, you must deal with the fact that
the iteration order will be totally random from your (the programmer's)
POV.

Regards

Antoine.



From merwok at netwok.org  Sun Feb 27 01:25:12 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 27 Feb 2011 01:25:12 +0100
Subject: [Python-Dev] hg extensions
In-Reply-To: <20110227010657.12c047da@pitrou.net>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>	<4D698A9C.3010505@netwok.org>	<AANLkTinvDYK2LguErwFv=HM7gKEUFeB1crVxNjC8eseS@mail.gmail.com>
	<20110227010657.12c047da@pitrou.net>
Message-ID: <4D6999E8.3050406@netwok.org>

> I've just tried bookmarks and I find them very cumbersome compared to
> named branches (which, unfortunately, can't remain local). I wonder
> what guided their design.

Mimicking git branches.

> (the core issue being that a bookmark blindly follows every commit you
> do, while you would need it to follow upstream instead!)

I don?t really understand (I don?t really want to, I don?t care for
bookmarks), but maybe this will help:
http://mercurial.selenic.com/wiki/BookmarksExtension#Configuration

Regards

From barry at python.org  Sun Feb 27 01:50:26 2011
From: barry at python.org (Barry Warsaw)
Date: Sat, 26 Feb 2011 19:50:26 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D698284.60305@cadifra.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>
	<20110226130847.05daf511@limelight.wooz.org>
	<20110226190518.37F381FF8A4@kimball.webabinitio.net>
	<20110226160645.5c5d28e6@limelight.wooz.org>
	<4D698284.60305@cadifra.com>
Message-ID: <20110226195026.5dc7eb3b@limelight.wooz.org>

On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote:

>You'd have to take this up with Mercurial's BDFL Matt. He is a strong
>advocate for teaching users to learn edit their .hg/hgrc files.

Well, I guess it's doubtful I'd change his mind then. :)

>Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check'
>- and always gave up again looking at bzr due to the horrible slowness
>of that command. If I have to use a DVCS I want to be able to check the
>integrity of my clones in reasonable time. I do it with a cron job on
>our internal server here and I expect it to have finished checking all
>our repos when I get to my desk in the morning and look into my email
>inbox, reading the daily email with the result of the verify runs.
>
>After all, we do have everything secured with hashes, so we can use
>them, don't we?

Do you know how thorough 'bzr check' is?  I don't, but then I've never used it
or felt the need to. ;)

>> Oh, and 'bzr info' always tells you what the push and pull locations are.
>
>You can use 'hg paths' for that:

Nice, 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/20110226/4efcfb80/attachment-0001.pgp>

From solipsis at pitrou.net  Sun Feb 27 01:51:38 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Feb 2011 01:51:38 +0100
Subject: [Python-Dev] hg extensions
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
	<4D698A9C.3010505@netwok.org>
	<AANLkTinvDYK2LguErwFv=HM7gKEUFeB1crVxNjC8eseS@mail.gmail.com>
	<20110227010657.12c047da@pitrou.net> <4D6999E8.3050406@netwok.org>
Message-ID: <20110227015138.2bec54fa@pitrou.net>

On Sun, 27 Feb 2011 01:25:12 +0100
?ric Araujo <merwok at netwok.org> wrote:
> > I've just tried bookmarks and I find them very cumbersome compared to
> > named branches (which, unfortunately, can't remain local). I wonder
> > what guided their design.
> 
> Mimicking git branches.

I've hardly ever used git but I would be surprised if its change
tracking abilities were so poor.

> > (the core issue being that a bookmark blindly follows every commit you
> > do, while you would need it to follow upstream instead!)
> 
> I don?t really understand (I don?t really want to, I don?t care for
> bookmarks), but maybe this will help:
> http://mercurial.selenic.com/wiki/BookmarksExtension#Configuration

That's vaguely better (since it allows to advance one bookmark instead
of both), but it still doesn't allow tracking incoming upstream changes.
Meaning that as soon as I "hg pull" (not to mention "hg merge"), I lose
the ability to easily make a collapsed diff of my local changes.

Regards

Antoine.



From solipsis at pitrou.net  Sun Feb 27 01:59:48 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Feb 2011 01:59:48 +0100
Subject: [Python-Dev] hg extensions was Mercurial conversion repositories
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
Message-ID: <20110227015948.5906fd2f@pitrou.net>


Hi,

On Sat, 26 Feb 2011 18:13:15 -0500
Dj Gilcrease <digitalxero at gmail.com> wrote:
> 
> File Format Management
>     eol
>         http://mercurial.selenic.com/wiki/EolExtension
>         required

Actually, it isn't *required* on each developer's setup, since we
now have a hook that refuses bogus changegroups (if needed, we can even
refuse individual changesets).  In most situations, even without the
eol extension line endings won't get modified anyway.

>     flake8
>         http://pypi.python.org/pypi/flake8/
>         recommended especially for new commiters as it will validate
> pep8 compliance and check for common errors

IMHO, nothing replaces human reviews and communication for style
and other likewise issues.

> Patch Management
>     mq
>     rebase
>     shelve

All these depend on each developer's taste, as long as only collapsed
patches get submitted and committed.

>     transplant
>         http://mercurial.selenic.com/wiki/TransplantExtension
>         required to port patches between major versions

Not really required, and actually controversial since it commits
automatically (we would like people to commit and test *before*
committing, otherwise buildbots can get bogus changesets and spurious
failures).

>     bookmarks
>         http://mercurial.selenic.com/wiki/BookmarksExtension
>         Great for tracking bug fix work without needing to create a
> separate working directory
>         recommended that the central repo NOT have the extension
> enabled so as to ensure bookmarks are a local only tracking system

Actually quite poor for tracking bug fix work (see my other messages in
this thread :-)).

Regards

Antoine.



From adrian at cadifra.com  Sun Feb 27 02:15:51 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Sun, 27 Feb 2011 02:15:51 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226195026.5dc7eb3b@limelight.wooz.org>
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>	<20110226130847.05daf511@limelight.wooz.org>	<20110226190518.37F381FF8A4@kimball.webabinitio.net>	<20110226160645.5c5d28e6@limelight.wooz.org>	<4D698284.60305@cadifra.com>
	<20110226195026.5dc7eb3b@limelight.wooz.org>
Message-ID: <4D69A5C7.2000903@cadifra.com>

On 2011-02-27 01:50, Barry Warsaw wrote:
> On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote:
> 
>> You'd have to take this up with Mercurial's BDFL Matt. He is a strong
>> advocate for teaching users to learn edit their .hg/hgrc files.
> 
> Well, I guess it's doubtful I'd change his mind then. :)

Yep.

>> Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check'
>> - and always gave up again looking at bzr due to the horrible slowness
>> of that command. If I have to use a DVCS I want to be able to check the
>> integrity of my clones in reasonable time. I do it with a cron job on
>> our internal server here and I expect it to have finished checking all
>> our repos when I get to my desk in the morning and look into my email
>> inbox, reading the daily email with the result of the verify runs.
>>
>> After all, we do have everything secured with hashes, so we can use
>> them, don't we?
> 
> Do you know how thorough 'bzr check' is?  I don't, but then I've never used it
> or felt the need to. ;)

That's quite amazing. If I talk with people about that, it often turns
out that they don't check the integrity of their repos.

Well, hg verify *is* through and fast enough. That's good enough for me.

And being slow is not sufficient to earn my trust.

FWIW, be aware that Mercurial does not do integrity checks on normal
operations, so chances are you will be able to use a repo that fails
verify for quite a while -- without even noticing it.

For example you can remove *some* file X inside .hg/store/data and
continue to add history to that repo without any sign of errors, as long
as the file X isn't used during the operations you do.

From raymond.hettinger at gmail.com  Sun Feb 27 02:30:58 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 26 Feb 2011 17:30:58 -0800
Subject: [Python-Dev] set iteration order
In-Reply-To: <20110227010945.2cb57e45@pitrou.net>
References: <ikag0f$nif$1@dough.gmane.org> <20110227010945.2cb57e45@pitrou.net>
Message-ID: <4D6DE8DD-94A4-427E-8B7A-3C502C0B84B7@gmail.com>


On Feb 26, 2011, at 4:09 PM, Antoine Pitrou wrote:

> On Sat, 26 Feb 2011 10:09:33 +0100
> Hagen F?rstenau <hagen at zhuliguan.net> wrote:
>> 
>> I just hunted down a change in behaviour between Python 3.1 and 3.2 to
>> possibly changed iteration order of sets due to the optimization in
>> issue #8685. Of course, this order shouldn't be relied on in the first
>> place, but the side effect of the optimization might be worth mentioning
>> in "What's new", maybe also pointing out that the old behaviour can be
>> simulated with {x for x in a if x not in b} in place of "a-b".
> 
> I'm against such a mention. It would give the impression that we
> support some semblance of reproduceability in iteration order, which is
> not true. If you use sets or dicts, you must deal with the fact that
> the iteration order will be totally random from your (the programmer's)
> POV.

I concur with Antoine.

Also, it wasn't the iteration order that changed; sets still iterate in the same order.
What changed was the algorithm for creating a new set using a set difference operation.

Raymond

From barry at python.org  Sun Feb 27 03:21:07 2011
From: barry at python.org (Barry Warsaw)
Date: Sat, 26 Feb 2011 21:21:07 -0500
Subject: [Python-Dev] hg commit with diff -u output (was Re: hg extensions
 was Mercurial conversion repositories)
In-Reply-To: <20110227015948.5906fd2f@pitrou.net>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
	<20110227015948.5906fd2f@pitrou.net>
Message-ID: <20110226212107.670b907e@limelight.wooz.org>

FWIW, this modification to hgeditor does a reasonable approximation of 'bzr
commit' including the diff -u output.

Cheers,
-Barry

#!/bin/sh
#
# This is an example of using HGEDITOR to create of diff to review the
# changes while commiting.

# If you want to pass your favourite editor some other parameters
# only for Mercurial, modify this:
case "${EDITOR}" in
    "")
        EDITOR="sensible-editor"
        ;;
    emacs)
        EDITOR="$EDITOR -nw"
        ;;
    gvim|vim)
        EDITOR="$EDITOR -f -o"
        ;;
esac


HGTMP=""
cleanup_exit() {
    rm -rf "$HGTMP"
}

# Remove temporary files even if we get interrupted
trap "cleanup_exit" 0 # normal exit
trap "exit 255" HUP INT QUIT ABRT TERM

HGTMP=$(mktemp -d ${TMPDIR-/tmp}/hgeditor.XXXXXX)
[ x$HGTMP != x -a -d $HGTMP ] || {
  echo "Could not create temporary directory! Exiting." 1>&2
  exit 1
}

(
    grep '^HG: changed' "$1" | cut -b 13- | while read changed; do
        "$HG" diff "$changed" >> "$HGTMP/diff"
    done
)

cat "$1" > "$HGTMP/msg"
LINES=`wc -l $HGTMP/msg`
echo "" >> "$HGTMP/msg"
cat "$HGTMP/diff" >> "$HGTMP/msg"

MD5=$(which md5sum 2>/dev/null) || MD5=$(which md5 2>/dev/null)
[ -x "${MD5}" ] && CHECKSUM=`${MD5} "$HGTMP/msg"`
$EDITOR "$HGTMP/msg" || exit $?

if [ -x "${MD5}" ]
then
    echo "$CHECKSUM" | ${MD5} -c >/dev/null 2>&1 && exit 13
fi

cat "$HGTMP/msg" | head -n $LINES > "$HGTMP/commit"
mv "$HGTMP/commit" "$1"

exit $?
-------------- 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/20110226/5c7a18c9/attachment.pgp>

From martin at v.loewis.de  Sun Feb 27 07:46:51 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 27 Feb 2011 07:46:51 +0100
Subject: [Python-Dev] hg extensions was Mercurial conversion repositories
In-Reply-To: <20110227015948.5906fd2f@pitrou.net>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
	<20110227015948.5906fd2f@pitrou.net>
Message-ID: <4D69F35B.3020602@v.loewis.de>

> Actually, it isn't *required* on each developer's setup, since we
> now have a hook that refuses bogus changegroups (if needed, we can even
> refuse individual changesets).  In most situations, even without the
> eol extension line endings won't get modified anyway.

I think this is overly optimistic. Visual Studio will break all your
files if you don't use that extension (and you actually use it to
modify source code).

Regards,
Martin

From martin at v.loewis.de  Sun Feb 27 08:09:21 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 27 Feb 2011 08:09:21 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <1298745553.3704.31.camel@localhost.localdomain>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>	<1298738685.3704.10.camel@localhost.localdomain>	<4D693A02.4000104@v.loewis.de>	<1298742940.3704.17.camel@localhost.localdomain>	<4D694401.1000009@v.loewis.de>
	<1298745553.3704.31.camel@localhost.localdomain>
Message-ID: <4D69F8A1.7030109@v.loewis.de>

>> changeset:   72694:e65daae6cf44
>> user:        Antoine Pitrou <solipsis at pitrou.net>
>> date:        Mon Feb 21 21:30:55 2011 +0000
>> summary:     Try s/UINT_MAX/INT_MAX/
> 
> It's not on an unnamed branch, it's on the "default" branch (which is
> omitted for concision by "hg log" and other commands with a similar
> output).

It's probably a terminology issue, but: the changeset can't be "on"
the default "branch", because the head of the default branch (called
"tip", IIUC) isn't a descendant of that changeset. It's parent is

changeset:   72693:d9769c8a828b
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Mon Feb 21 21:25:39 2011 +0000
summary:     temp branch to debug crashes on snow leopard buildbot

so you have called it "temporary branch" in subversion. I got go with
that term also, if "unnamed branch" is confusing.

>> I think we can do better. I also dislike "hg log --only-branch default"
>> to only go back to 2006 (to aeefba456e4d), when this revision actually
>> does have a parent (namely, on the trunk branch, 4b41806a0326).
> 
> I'm not convinced that small quirks of using "hg log" are important at
> this point. Also, you could try other options of "hg log" such as
> "--follow".

IIUC, --follow doesn't help. It traces history across renames and
copies, which is not what I want to overcome when trying to produce the
full history of the py3k branch.

As for "small quirks ... important at this point": this point is the
*only* chance to get it right. If you get it wrong now, we will have
to deal with it forever (or rather until we switch to the next
version control system).

If you chose to convert in the way it currently does:
fine with me, as long as the choice was deliberate (rather than
coincidental).

> If we called ex-trunk the same name as ex-py3k ("default"), things would
> probably be quite more confusing, since inspecting a changeset wouldn't
> tell you immediately where it comes from (2.x or 3.x development).

I would it call default only up to the point where the py3k branch was
branched off trunk. All changes up to this point actually *do* belong
to both branches. Python 3's history goes all the way back to 0.9,
and I'm sure you can still find code in 3.2 which was written 20 years
ago.

Change sets created after 3.x was forked off should certainly live
on a separate mercurial branch - it would be reasonable to call this
branch then 2.x.

Regards,
Martin

From martin at v.loewis.de  Sun Feb 27 08:12:10 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 27 Feb 2011 08:12:10 +0100
Subject: [Python-Dev] of branches and heads
In-Reply-To: <20110226202912.7d4813ba@pitrou.net>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>	<1298738685.3704.10.camel@localhost.localdomain>	<4D693A02.4000104@v.loewis.de>	<1298742940.3704.17.camel@localhost.localdomain>	<AANLkTimhsnQe4JtLcPaAUo6FOk5-5=TBNFMYSWsOQpM-@mail.gmail.com>
	<20110226202912.7d4813ba@pitrou.net>
Message-ID: <4D69F94A.1060805@v.loewis.de>

> So, actually, hg promotes a slightly different terminology:
> - a "head" is a changeset without a child in the topology

So what do you call the LoD leading up to a head? (i.e. the set of
changesets that are ancestors of a head and not ancestors of any other head)

Regards,
Martin



From martin at v.loewis.de  Sun Feb 27 08:17:40 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sun, 27 Feb 2011 08:17:40 +0100
Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook.
In-Reply-To: <20110226203041.79e378c4@pitrou.net>
References: <E1PtOFd-0000wb-8X@dinsdale.python.org>	<20110226185402.14b66d79@pitrou.net>
	<4D6940FE.509@v.loewis.de>	<1298744009.3704.25.camel@localhost.localdomain>	<4D694535.6070207@v.loewis.de>
	<20110226203041.79e378c4@pitrou.net>
Message-ID: <4D69FA94.4050201@v.loewis.de>

Am 26.02.2011 20:30, schrieb Antoine Pitrou:
> 
> Martin, I have now enabled the eol hook on the test repo (a quick test
> seemed to show it works). Could you test again?

It seems to work fine, thanks. I modified a file with Visual Studio, and
that changed all line endings. I then decided to "fix" it by changing
the line endings again. It now thinks I last edited every line in the
file...

I think we should ask Windows users to enable the eol extension before
they start editing with Visual Studio, and we should ask people to redo
the changes if a change is rejected by that hook (rather than trying
to fix the line endings with another commit).

Regards,
Martin

From martin at v.loewis.de  Sun Feb 27 08:26:36 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sun, 27 Feb 2011 08:26:36 +0100
Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook
In-Reply-To: <4D698AF3.1010207@netwok.org>
References: <E1PtQhM-0005Fn-MU@dinsdale.python.org>	<4D69726F.5000803@netwok.org>	<20110226225025.691466c8@pitrou.net>
	<4D698AF3.1010207@netwok.org>
Message-ID: <4D69FCAC.8000808@v.loewis.de>

Am 27.02.2011 00:21, schrieb ?ric Araujo:
>> Then we will have to fix the hook each time we want to add a new
>> legitimate branch.
> The alternative is to edit the hook each time we want to remove a former
> legitimate branch, plus have another hook to refuse new named branches.

The question is whether developers would create named branches if they
are asked not to (except when they are release manager).

There is nothing that prevents people from tagging the tree currently
in subversion, but most of the time, only the release manager does any
tagging.

If you think that it's a likely problem that people create named
branches by mistake, then we should have a hook.

Regards,
Martin

From ncoghlan at gmail.com  Sun Feb 27 08:48:34 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Feb 2011 17:48:34 +1000
Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook
In-Reply-To: <4D69FCAC.8000808@v.loewis.de>
References: <E1PtQhM-0005Fn-MU@dinsdale.python.org>
	<4D69726F.5000803@netwok.org> <20110226225025.691466c8@pitrou.net>
	<4D698AF3.1010207@netwok.org> <4D69FCAC.8000808@v.loewis.de>
Message-ID: <AANLkTimtn2uHeYCFeQLZ=L_LGdxcHriW8+Z5O7aUxoBc@mail.gmail.com>

On Sun, Feb 27, 2011 at 5:26 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> There is nothing that prevents people from tagging the tree currently
> in subversion, but most of the time, only the release manager does any
> tagging.
>
> If you think that it's a likely problem that people create named
> branches by mistake, then we should have a hook.

I suspect the concern is that people may create named branches locally
as part of their own workflow, then mistakenly push those branches
instead of collapsing back to a single commit against the relevant
line of development.

Cheers,
Nick.

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

From hagen at zhuliguan.net  Sun Feb 27 09:41:28 2011
From: hagen at zhuliguan.net (=?UTF-8?B?SGFnZW4gRsO8cnN0ZW5hdQ==?=)
Date: Sun, 27 Feb 2011 09:41:28 +0100
Subject: [Python-Dev] set iteration order
In-Reply-To: <4D6992FE.5060801@netwok.org>
References: <ikag0f$nif$1@dough.gmane.org>
	<ikbd1t$umd$1@dough.gmane.org>	<ikc38h$5mp$1@dough.gmane.org>
	<4D6992FE.5060801@netwok.org>
Message-ID: <ikd2no$p04$1@dough.gmane.org>

>> It's not a matter of dependence on iteration order, but of
>> reproducibility (in my case there were minor numerical differences due
>> to different iteration orders).
> 
> Can you give a code example?  I don?t understand your case.

It's a bit involved (that's why it took me a while to locate the
difference in behavior), but it boils down to a (learning) algorithm
that in principle should not care about order of input data, but will in
practice show slightly different numerical behavior. I ran into the
problem when trying to exactly reproduce previously published
experimental results. Of course, I should have anticipated this and
fixed some arbitrary order in the first place. I just thought a note
about this change might save someone in a similar situation some confusion.

Cheers,
Hagen


From adrian at cadifra.com  Sun Feb 27 11:42:21 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Sun, 27 Feb 2011 11:42:21 +0100
Subject: [Python-Dev] of branches and heads
In-Reply-To: <D85EA30224A3CC40ACA1E2FE6D4D6914351732@cantwe3.canterbury.ac.nz>
References: <20110225011904.3ed09de7@pitrou.net>	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>	<1298738685.3704.10.camel@localhost.localdomain>	<4D693A02.4000104@v.loewis.de>	<1298742940.3704.17.camel@localhost.localdomain>	<AANLkTimhsnQe4JtLcPaAUo6FOk5-5=TBNFMYSWsOQpM-@mail.gmail.com>	<20110226202912.7d4813ba@pitrou.net>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351732@cantwe3.canterbury.ac.nz>
Message-ID: <4D6A2A8D.9000301@cadifra.com>

On 2011-02-26 23:26, Greg Ewing wrote:
> From: Antoine Pitrou
>> - a "branch" usually means a "named branch": a set of changesets
>>   bearing the same label (e.g. "default"); that label is freely chosen
>>   by the committer at any point, and enforces no topological
>>   characteristic
> 
> There are *some* topological restrictions, because hg won't
> let you assign a branch name that's been used before to a node
> unless one of its parents has that name. So you can't create
> two disconnected subgraphs whose nodes have the same branch
> name.

That's not completely correct. You *can* do that.

Mercurial by default assumes you're probably in error if you are
trying to create such disconnected branch name subgraphs, but you
can convince it that it's really what you want by doing:

  hg branch --force <existing branch name>

Example (glog command requires the graphlog extension enabled [1]):

  $ hg init a
  $ cd a
  $ echo foo > bla
  $ hg ci -Am1
  adding bla
  $ hg branch b1
  marked working directory as branch b1
  $ hg ci -m2
  $ hg branch default
  abort: a branch of the same name already exists (use 'hg update' to switch to it)
  $ hg branch --force default
  marked working directory as branch default
  $ hg ci -m3
  created new head
  $ hg glog --template "{rev}, {branch}\n"
  @  2, default
  |
  o  1, b1
  |
  o  0, default

[1] http://mercurial.selenic.com/wiki/GraphlogExtension

From sandro.tosi at gmail.com  Sun Feb 27 15:05:25 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 27 Feb 2011 14:05:25 +0000
Subject: [Python-Dev] [Python-checkins] devguide (hg_transition):
	patchcheck does work
In-Reply-To: <E1PtX87-0005mo-HI@dinsdale.python.org>
References: <E1PtX87-0005mo-HI@dinsdale.python.org>
Message-ID: <AANLkTin0-wqnHTwzA1sBqqSSk-igzMpKDaZvW0eNFL-O@mail.gmail.com>

On Sun, Feb 27, 2011 at 03:17, eric.araujo <python-checkins at python.org> wrote:
> eric.araujo pushed f325d743c385 to devguide:
>
> http://hg.python.org/devguide/rev/f325d743c385
> changeset: ? 331:f325d743c385
> branch: ? ? ?hg_transition
> user: ? ? ? ??ric Araujo <merwok at netwok.org>
> date: ? ? ? ?Sat Feb 26 17:30:51 2011 +0100
> summary:
> ?patchcheck does work
>
> files:
> ?patch.rst
>
> diff --git a/patch.rst b/patch.rst
> --- a/patch.rst
> +++ b/patch.rst
> @@ -114,15 +114,13 @@
> ?Generation
> ?''''''''''
>
> -.. XXX [commented out] make patchcheck doesn't work with non-SVN workflow
> +To perform a quick sanity check on your patch, you can run::
>
> - ? To perform a quick sanity check on your patch, you can run::
> + ? make patchcheck
>
> - ? ? ? make patchcheck
> -
> - ? This will check and/or fix various common things people forget to do for
> - ? patches, such as adding any new files needing for the patch to work (do not
> - ? that not all checks apply to non-core developers).
> +This will check and/or fix various common things people forget to do for
> +patches, such as adding any new files needing for the patch to work (do not

(do note

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

From sandro.tosi at gmail.com  Sun Feb 27 15:27:02 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 27 Feb 2011 14:27:02 +0000
Subject: [Python-Dev] [Python-checkins] devguide: List common gotchas
 people might come across when doing coverage work.
In-Reply-To: <E1PtaAF-0006Md-F1@dinsdale.python.org>
References: <E1PtaAF-0006Md-F1@dinsdale.python.org>
Message-ID: <AANLkTinkbfJbrOu3eVRCsFHQfsWxCtarfcZiamjXkzCf@mail.gmail.com>

On Sun, Feb 27, 2011 at 06:31, brett.cannon <python-checkins at python.org> wrote:
> +When writing new tests to increase coverage, do take note of the style of tests
> +already provided for a module (e.g., whitebox, blackbox, etc.). As
> +some modules are primarily maintained by a single core developer they may have
> +a specific preference as to what kind of test is used (e.g., whitebox) and
> +prefer that other types of tests not be used (e.g., blackbox). When in doubt,
> +stick with whitebox testing in order to properly exercise the code.

Do you think it could be nice to have a reference to what
whitebox/blackbox testing is, ie

http://en.wikipedia.org/wiki/White-box_testing
http://en.wikipedia.org/wiki/Black-box_testing

?

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

From solipsis at pitrou.net  Sun Feb 27 16:08:21 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Feb 2011 16:08:21 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <4D69F8A1.7030109@v.loewis.de>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D693A02.4000104@v.loewis.de>
	<1298742940.3704.17.camel@localhost.localdomain>
	<4D694401.1000009@v.loewis.de>
	<1298745553.3704.31.camel@localhost.localdomain>
	<4D69F8A1.7030109@v.loewis.de>
Message-ID: <20110227160821.15bd2922@pitrou.net>

On Sun, 27 Feb 2011 08:09:21 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> >> changeset:   72694:e65daae6cf44
> >> user:        Antoine Pitrou <solipsis at pitrou.net>
> >> date:        Mon Feb 21 21:30:55 2011 +0000
> >> summary:     Try s/UINT_MAX/INT_MAX/
> > 
> > It's not on an unnamed branch, it's on the "default" branch (which is
> > omitted for concision by "hg log" and other commands with a similar
> > output).
> 
> It's probably a terminology issue, but: the changeset can't be "on"
> the default "branch", because the head of the default branch (called
> "tip", IIUC) isn't a descendant of that changeset.

Well, a branch (or named branch) in hg terminology can have several
heads (see the other email about heads and branches).

Also, just so you know, "tip" is simply the latest (in pull or commit
order) changeset in the local repository. It can be in any branch (for
example, if you pull of bunch of changesets someone made in "3.2",
then your tip will be in branch "3.2").

I hope it all starts to make sense ;)

Regards

Antoine.

From solipsis at pitrou.net  Sun Feb 27 16:12:01 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Feb 2011 16:12:01 +0100
Subject: [Python-Dev] hg extensions was Mercurial conversion repositories
In-Reply-To: <4D69F35B.3020602@v.loewis.de>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
	<20110227015948.5906fd2f@pitrou.net> <4D69F35B.3020602@v.loewis.de>
Message-ID: <20110227161201.0d0b215d@pitrou.net>

On Sun, 27 Feb 2011 07:46:51 +0100
"Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Actually, it isn't *required* on each developer's setup, since we
> > now have a hook that refuses bogus changegroups (if needed, we can even
> > refuse individual changesets).  In most situations, even without the
> > eol extension line endings won't get modified anyway.
> 
> I think this is overly optimistic. Visual Studio will break all your
> files if you don't use that extension (and you actually use it to
> modify source code).

My assumption was that most developers don't use MSVC, so most of them
don't risk breaking eols ;)
True, for Windows devs it might be necessary to promote it.

Regards

Antoine.

From solipsis at pitrou.net  Sun Feb 27 16:18:43 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Feb 2011 16:18:43 +0100
Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over
	patch.
References: <E1PtX86-0005mN-Gt@dinsdale.python.org>
Message-ID: <20110227161843.6c71f8d1@pitrou.net>

On Sun, 27 Feb 2011 04:17:06 +0100
eric.araujo <python-checkins at python.org> wrote:
>   Advertise hg import over patch.
> 
> hg import understands the extended git diff format, which supports renames,
> changes to the executable bit and changes in binary files.

Yes, but it's too easy to forget the awkward "--no-commit" option.
"patch" doesn't involve such quirks.

>  patch doesn?t
> do anything useful with that information, and also requires downloading and
> setup on Windows.

Well, chances are TortoiseHG comes with an UI to apply patches
(TortoiseSVN had one), so the command-line instructions may be of
little use to them.

Regards

Antoine.



From stutzbach at google.com  Sun Feb 27 16:23:18 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sun, 27 Feb 2011 07:23:18 -0800
Subject: [Python-Dev] of branches and heads
In-Reply-To: <4D6A2A8D.9000301@cadifra.com>
References: <20110225011904.3ed09de7@pitrou.net>
	<AANLkTim2K5UDMo1u2m23NdHv1MQftq5TqWnWVa-7qZ75@mail.gmail.com>
	<AANLkTi=qYd_=8aJ=APz179UEC8t8tMP9LZTxbkixP9FK@mail.gmail.com>
	<1298738685.3704.10.camel@localhost.localdomain>
	<4D693A02.4000104@v.loewis.de>
	<1298742940.3704.17.camel@localhost.localdomain>
	<AANLkTimhsnQe4JtLcPaAUo6FOk5-5=TBNFMYSWsOQpM-@mail.gmail.com>
	<20110226202912.7d4813ba@pitrou.net>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351732@cantwe3.canterbury.ac.nz>
	<4D6A2A8D.9000301@cadifra.com>
Message-ID: <AANLkTikvG73g5-VmDN4sLt8aLua7fDuk_QsE8Zj9Max7@mail.gmail.com>

On Sun, Feb 27, 2011 at 2:42 AM, Adrian Buehlmann <adrian at cadifra.com>wrote:

> On 2011-02-26 23:26, Greg Ewing wrote:
> > There are *some* topological restrictions, because hg won't
> > let you assign a branch name that's been used before to a node
> > unless one of its parents has that name. So you can't create
> > two disconnected subgraphs whose nodes have the same branch
> > name.
>
> That's not completely correct. You *can* do that.
>

Can we create a hook on the server to reject changesets like that?

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110227/dad92e15/attachment.html>

From ncoghlan at gmail.com  Sun Feb 27 16:23:29 2011
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 28 Feb 2011 01:23:29 +1000
Subject: [Python-Dev] hg extensions was Mercurial conversion repositories
In-Reply-To: <20110227161201.0d0b215d@pitrou.net>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>
	<20110227015948.5906fd2f@pitrou.net> <4D69F35B.3020602@v.loewis.de>
	<20110227161201.0d0b215d@pitrou.net>
Message-ID: <AANLkTikfUaKJyXqpVLv7AM-OFxkjLcAucsAq2anNHU7Z@mail.gmail.com>

On Mon, Feb 28, 2011 at 1:12 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 27 Feb 2011 07:46:51 +0100
> "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> > Actually, it isn't *required* on each developer's setup, since we
>> > now have a hook that refuses bogus changegroups (if needed, we can even
>> > refuse individual changesets). ?In most situations, even without the
>> > eol extension line endings won't get modified anyway.
>>
>> I think this is overly optimistic. Visual Studio will break all your
>> files if you don't use that extension (and you actually use it to
>> modify source code).
>
> My assumption was that most developers don't use MSVC, so most of them
> don't risk breaking eols ;)
> True, for Windows devs it might be necessary to promote it.

Windows devs were the original target audience, yes :)

Cheers,
Nick.

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

From solipsis at pitrou.net  Sun Feb 27 16:21:15 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Feb 2011 16:21:15 +0100
Subject: [Python-Dev] devguide (hg_transition): patchcheck does work
References: <E1PtX87-0005mo-HI@dinsdale.python.org>
Message-ID: <20110227162115.0a2cda9f@pitrou.net>

On Sun, 27 Feb 2011 04:17:07 +0100
eric.araujo <python-checkins at python.org> wrote:
> summary:
>   patchcheck does work

How does it find out which changesets it should operate on?



From stutzbach at google.com  Sun Feb 27 16:25:41 2011
From: stutzbach at google.com (Daniel Stutzbach)
Date: Sun, 27 Feb 2011 07:25:41 -0800
Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook
In-Reply-To: <AANLkTimtn2uHeYCFeQLZ=L_LGdxcHriW8+Z5O7aUxoBc@mail.gmail.com>
References: <E1PtQhM-0005Fn-MU@dinsdale.python.org>
	<4D69726F.5000803@netwok.org> <20110226225025.691466c8@pitrou.net>
	<4D698AF3.1010207@netwok.org> <4D69FCAC.8000808@v.loewis.de>
	<AANLkTimtn2uHeYCFeQLZ=L_LGdxcHriW8+Z5O7aUxoBc@mail.gmail.com>
Message-ID: <AANLkTikiQz2ewhgfrkY-iaSC5RfgCKHzHYG=w0snf8xq@mail.gmail.com>

On Sat, Feb 26, 2011 at 11:48 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Sun, Feb 27, 2011 at 5:26 PM, "Martin v. L?wis" <martin at v.loewis.de>
> wrote:
> > If you think that it's a likely problem that people create named
> > branches by mistake, then we should have a hook.
>
> I suspect the concern is that people may create named branches locally
> as part of their own workflow, then mistakenly push those branches
> instead of collapsing back to a single commit against the relevant
> line of development.
>

+1

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110227/64641a08/attachment.html>

From solipsis at pitrou.net  Sun Feb 27 16:22:48 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 27 Feb 2011 16:22:48 +0100
Subject: [Python-Dev] devguide (hg_transition): Minor edits and typo
	fixes.
References: <E1PtX89-0005nQ-1V@dinsdale.python.org>
Message-ID: <20110227162248.70b2195b@pitrou.net>

On Sun, 27 Feb 2011 04:17:09 +0100
eric.araujo <python-checkins at python.org> wrote:
> 
> - Move a link target after its use
> - Add a todo about tracker markup
> - Remove one XXX that was in a warning block, not a comment

Well, this is a XXX because that means we could find something else to
advocate, not because the reader must take it as a warning.



From scott+python-dev at scottdial.com  Sun Feb 27 16:35:43 2011
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Sun, 27 Feb 2011 10:35:43 -0500
Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over
 patch.
In-Reply-To: <20110227161843.6c71f8d1@pitrou.net>
References: <E1PtX86-0005mN-Gt@dinsdale.python.org>
	<20110227161843.6c71f8d1@pitrou.net>
Message-ID: <4D6A6F4F.40907@scottdial.com>

On 2/27/2011 10:18 AM, Antoine Pitrou wrote:
> Well, chances are TortoiseHG comes with an UI to apply patches
> (TortoiseSVN had one), so the command-line instructions may be of
> little use to them.

I don't believe TortoiseHG has such a feature (or I can't find it),
although if you have TortoiseSVN, you can still use that as a patch tool.

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

From adrian at cadifra.com  Sun Feb 27 17:01:37 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Sun, 27 Feb 2011 17:01:37 +0100
Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over
 patch.
In-Reply-To: <4D6A6F4F.40907@scottdial.com>
References: <E1PtX86-0005mN-Gt@dinsdale.python.org>	<20110227161843.6c71f8d1@pitrou.net>
	<4D6A6F4F.40907@scottdial.com>
Message-ID: <4D6A7561.8040801@cadifra.com>

On 2011-02-27 16:35, Scott Dial wrote:
> On 2/27/2011 10:18 AM, Antoine Pitrou wrote:
>> Well, chances are TortoiseHG comes with an UI to apply patches
>> (TortoiseSVN had one), so the command-line instructions may be of
>> little use to them.
> 
> I don't believe TortoiseHG has such a feature (or I can't find it),
> although if you have TortoiseSVN, you can still use that as a patch tool.

TortoiseHg can import patches just fine.

FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st),
which ported the current Gtk based TortoiseHg to Qt (although, it was
more like a rewrite :-).

For the old Gtk TortoiseHg, see the online docs here:

  http://tortoisehg.bitbucket.org/manual/1.1/patches.html#import-patches

Homepage for the Qt port:
https://bitbucket.org/tortoisehg/thg/wiki/Home

For people on Windows, we have beta installers for the new Qt based
TortoiseHg at:

   https://bitbucket.org/tortoisehg/thg/downloads

Feedback is welcome on

  thg-dev at googlegroups.com or
  tortoisehg-discuss at lists.sourceforge.net

(we moved the development list to google groups)





From merwok at netwok.org  Sun Feb 27 17:20:46 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 27 Feb 2011 17:20:46 +0100
Subject: [Python-Dev] devguide (hg_transition): patchcheck does work
In-Reply-To: <20110227162115.0a2cda9f@pitrou.net>
References: <E1PtX87-0005mo-HI@dinsdale.python.org>
	<20110227162115.0a2cda9f@pitrou.net>
Message-ID: <4D6A79DE.1030909@netwok.org>

Le 27/02/2011 16:21, Antoine Pitrou a ?crit :
>> summary:
>>   patchcheck does work
> How does it find out which changesets it should operate on?

It operates on changed files, just like with Subversion:
http://hg.python.org/cpython/file/tip/Tools/scripts/patchcheck.py#l40
? hg status --added --modified --no-status

You can use it while making a commit, or when you collapse many commits
into one diff (and apply it with hg import --no-commit).

Rewriting patchcheck to work on diffs is another thing, see
http://bugs.python.org/issue8999#msg109255

I agree that the part about patchcheck should have a note to explain
that it works with uncommitted changes, not MQ patches or changesets.

Regards

From merwok at netwok.org  Sun Feb 27 17:23:44 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 27 Feb 2011 17:23:44 +0100
Subject: [Python-Dev] devguide (hg_transition): Minor edits and typo
	fixes.
In-Reply-To: <20110227162248.70b2195b@pitrou.net>
References: <E1PtX89-0005nQ-1V@dinsdale.python.org>
	<20110227162248.70b2195b@pitrou.net>
Message-ID: <4D6A7A90.8020002@netwok.org>

Le 27/02/2011 16:22, Antoine Pitrou a ?crit :
>> - Remove one XXX that was in a warning block, not a comment
> Well, this is a XXX because that means we could find something else to
> advocate, not because the reader must take it as a warning.

My point was that that should be either a comment with an XXX marker or
a user-visible reST warning.  I chose the latter, I have no problem
changing it to the former.

Regards

From g.brandl at gmx.net  Sun Feb 27 17:38:26 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 27 Feb 2011 17:38:26 +0100
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110226154939.41972d08@limelight.wooz.org>
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>
Message-ID: <ikduo2$qm2$1@dough.gmane.org>

On 26.02.2011 21:49, Barry Warsaw wrote:
> On Feb 26, 2011, at 01:49 AM, ?ric Araujo wrote:
> 
>>You speak to my heart, sir.  In your ~/.hgrc, under the section [ui],
>>set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs.
>>I use it and love it.
> 
> Except it doesn't quite work the way I want it to (hg 1.6.3).  It opens your
> editor with two files, one is the commit message and the other is the diff.
> (The script itself is a bit buggy too. ;)
> 
> But it's a good clue, and I've modified the default hgeditor script to get
> closer, and fix the bug I noticed.  I basically append the diff to the
> temporary log message file.  It's still not right though because if the diff
> lines aren't prepended with 'HG:', they end up in the commit message.  Arg.
> 
> Oh well, I can clearly hack a more complicated script together.  It's such a
> blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by
> default.

While I understand the usefulness of the diff feature, it is not useful to
everyone, e.g. those using almost exclusively ``commit -m message``.

Of course it would be nice if hg made it easier (a hgrc option, for example)
to do this.

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.

Georg


From martin at v.loewis.de  Sun Feb 27 19:20:04 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 27 Feb 2011 19:20:04 +0100
Subject: [Python-Dev] hg extensions was Mercurial conversion repositories
In-Reply-To: <20110227161201.0d0b215d@pitrou.net>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>	<20110227015948.5906fd2f@pitrou.net>
	<4D69F35B.3020602@v.loewis.de> <20110227161201.0d0b215d@pitrou.net>
Message-ID: <4D6A95D4.5030902@v.loewis.de>

>> I think this is overly optimistic. Visual Studio will break all your
>> files if you don't use that extension (and you actually use it to
>> modify source code).
> 
> My assumption was that most developers don't use MSVC, so most of them
> don't risk breaking eols ;)
> True, for Windows devs it might be necessary to promote it.

If I change code on Windows, I always use MSVC to edit it. It's best
integrated with the build process and the debugger. If I change Python
code on Windows, I use vim or IDLE.

Different MSVC releases took different approaches wrt. LF-separated
files. For a long time, new lines added would be CRLF, whereas existing
line endings would remain unchanged, resulting in a mix of line endings.
It appears that VS 2008 now uniformly converts the entire file to CRLF
on first edit.

Regards,
Martin

From martin at v.loewis.de  Sun Feb 27 19:22:28 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 27 Feb 2011 19:22:28 +0100
Subject: [Python-Dev] hg extensions was Mercurial conversion repositories
In-Reply-To: <AANLkTikfUaKJyXqpVLv7AM-OFxkjLcAucsAq2anNHU7Z@mail.gmail.com>
References: <AANLkTimUOya_+P9S2UUmnuQy8zgytxmWXmCWwS-vZft3@mail.gmail.com>	<20110227015948.5906fd2f@pitrou.net>
	<4D69F35B.3020602@v.loewis.de>	<20110227161201.0d0b215d@pitrou.net>
	<AANLkTikfUaKJyXqpVLv7AM-OFxkjLcAucsAq2anNHU7Z@mail.gmail.com>
Message-ID: <4D6A9664.6070204@v.loewis.de>

>> My assumption was that most developers don't use MSVC, so most of them
>> don't risk breaking eols ;)
>> True, for Windows devs it might be necessary to promote it.
> 
> Windows devs were the original target audience, yes :)

I meant to say that earlier: thanks to everybody involved in the
original development of the eol extension. It originated from
python-dev, and, with the switchover taking so long as it took,
it's a standard extension of Mercurial releases by now. In the
Tortoise Global Settings GUI, there is even a checkbox to activate
it.

Regards,
Martin

From greg.ewing at canterbury.ac.nz  Sun Feb 27 21:28:57 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 28 Feb 2011 09:28:57 +1300
Subject: [Python-Dev] Let's get PEP 380 into Python 3.3
In-Reply-To: <AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
References: <AANLkTimKOfU1YbzgWosdM=Ad+hU53ts3hA=1NqfE3evV@mail.gmail.com>
	<D85EA30224A3CC40ACA1E2FE6D4D6914351730@cantwe3.canterbury.ac.nz>
	<AANLkTinz6YNCyzaJ+=YSDkxNBdVR=SDDbRvfFDRSz1g2@mail.gmail.com>
Message-ID: <4D6AB409.40001@canterbury.ac.nz>

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.

-- 
Greg

From nyamatongwe at gmail.com  Sun Feb 27 23:11:47 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Mon, 28 Feb 2011 09:11:47 +1100
Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over
	patch.
In-Reply-To: <4D6A6F4F.40907@scottdial.com>
References: <E1PtX86-0005mN-Gt@dinsdale.python.org>
	<20110227161843.6c71f8d1@pitrou.net> <4D6A6F4F.40907@scottdial.com>
Message-ID: <AANLkTi=_fv45KV+EZJXwExRQsC2mZYajXXsVrMMMqkB0@mail.gmail.com>

Scott Dial:

> I don't believe TortoiseHG has such a feature (or I can't find it),
> although if you have TortoiseSVN, you can still use that as a patch tool.

   The Import... command is in the Synchronize menu of Hg Repository Explorer.

   There is no GUI equivalent to --no-commit but you can exit the
commit message editor without saving which causes the commit to be
abandoned with the patch still having been applied.

   Neil

From nyamatongwe at gmail.com  Sun Feb 27 23:21:51 2011
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Mon, 28 Feb 2011 09:21:51 +1100
Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over
	patch.
In-Reply-To: <4D6A7561.8040801@cadifra.com>
References: <E1PtX86-0005mN-Gt@dinsdale.python.org>
	<20110227161843.6c71f8d1@pitrou.net> <4D6A6F4F.40907@scottdial.com>
	<4D6A7561.8040801@cadifra.com>
Message-ID: <AANLkTin6UB450n6rx8eTP9erSYhvPZXQ+4pLgy+gtrC=@mail.gmail.com>

Adrian Buehlmann:

> FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st),
> which ported the current Gtk based TortoiseHg to Qt (although, it was
> more like a rewrite :-).

   I hope this is going to be fast. One of the reasons I chose Hg over
Bzr for another project was that the Bzr GUI tools which are written
using Qt are much slower, particularly when starting. A cold start of
Bazaar Explorer takes around 7 seconds on a new fast machine compared
with under a second to launch Hg Repository Explorer. Warm starts and
internal actions are better but the Hg GUI tools are still much
smoother than Bzr's.

   This slowness is quite common for Qt applications and I think is
because of the large set of DLLs that are loaded. Qt Creator is better
at around 4 seconds for a cold launch but, naturally, it doesn't
matter for an environment which you use for an extended period like Qt
Creator. It does matter for a VCS tool that you may invoke hundreds of
times in a day.

   Neil

From adrian at cadifra.com  Mon Feb 28 00:10:10 2011
From: adrian at cadifra.com (Adrian Buehlmann)
Date: Mon, 28 Feb 2011 00:10:10 +0100
Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over
 patch.
In-Reply-To: <AANLkTin6UB450n6rx8eTP9erSYhvPZXQ+4pLgy+gtrC=@mail.gmail.com>
References: <E1PtX86-0005mN-Gt@dinsdale.python.org>	<20110227161843.6c71f8d1@pitrou.net>	<4D6A6F4F.40907@scottdial.com>	<4D6A7561.8040801@cadifra.com>
	<AANLkTin6UB450n6rx8eTP9erSYhvPZXQ+4pLgy+gtrC=@mail.gmail.com>
Message-ID: <4D6AD9D2.7060901@cadifra.com>

On 2011-02-27 23:21, Neil Hodgson wrote:
> Adrian Buehlmann:
> 
>> FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st),
>> which ported the current Gtk based TortoiseHg to Qt (although, it was
>> more like a rewrite :-).
> 
>    I hope this is going to be fast.

Here, the Workbench window [1] starts in under 2s (Windows 7 x64 on
Intel Core2 Quad). As installed with the x64 msi (installs true 64 bit
exe's, including 64 bit command line hg).

There's quite a lot of demand loading behind the scenes. So it's fast
even for repos with many changesets.

[1] http://tortoisehg.bitbucket.org/manual/2.0/workbench.html

(brand new first manual version by Steve was just uploaded a few minutes
ago :)

From stephen at xemacs.org  Mon Feb 28 04:29:24 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 28 Feb 2011 12:29:24 +0900
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110225164600.415f8e04@limelight.wooz.org>
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>
	<4D680B3C.4040209@freehackers.org>
	<20110225164600.415f8e04@limelight.wooz.org>
Message-ID: <87lj10degb.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > You mean, TortoiseHg supports incremental commits on a single file?  That's
 > kind of neat, but scary. ;)

Darcs people have been doing this for, well, for as long as Darcs has
existed.  It's not scary at all.  In fact, in Darcs you can select
hunks across files, too.



From barry at python.org  Mon Feb 28 16:08:26 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Feb 2011 10:08:26 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <ikduo2$qm2$1@dough.gmane.org>
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>
Message-ID: <20110228100826.6812ad30@limelight.wooz.org>

On Feb 27, 2011, at 05:38 PM, Georg Brandl wrote:

>While I understand the usefulness of the diff feature, it is not useful to
>everyone, e.g. those using almost exclusively ``commit -m message``.

The editor window doesn't pop up when you provide the -m flag, so the diff
output is not relevant.

>Of course it would be nice if hg made it easier (a hgrc option, for example)
>to do this.

Sure.

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

-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/20110228/716c9661/attachment.pgp>

From solipsis at pitrou.net  Mon Feb 28 16:15:38 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Feb 2011 16:15:38 +0100
Subject: [Python-Dev] 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>
Message-ID: <20110228161538.36b825ac@pitrou.net>

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.

Regards

Antoine.



From solipsis at pitrou.net  Mon Feb 28 16:19:10 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Feb 2011 16:19:10 +0100
Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over
	patch.
References: <E1PtX86-0005mN-Gt@dinsdale.python.org>
	<20110227161843.6c71f8d1@pitrou.net> <4D6A6F4F.40907@scottdial.com>
	<4D6A7561.8040801@cadifra.com>
	<AANLkTin6UB450n6rx8eTP9erSYhvPZXQ+4pLgy+gtrC=@mail.gmail.com>
	<4D6AD9D2.7060901@cadifra.com>
Message-ID: <20110228161910.4f88407a@pitrou.net>

On Mon, 28 Feb 2011 00:10:10 +0100
Adrian Buehlmann <adrian at cadifra.com> wrote:
> 
> Here, the Workbench window [1] starts in under 2s (Windows 7 x64 on
> Intel Core2 Quad). As installed with the x64 msi (installs true 64 bit
> exe's, including 64 bit command line hg).
> 
> There's quite a lot of demand loading behind the scenes. So it's fast
> even for repos with many changesets.
> 
> [1] http://tortoisehg.bitbucket.org/manual/2.0/workbench.html

I have to say the TortoiseHg manual looks impressively comprehensive!

Regards

Antoine.



From solipsis at pitrou.net  Mon Feb 28 19:15:58 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Feb 2011 19:15:58 +0100
Subject: [Python-Dev] Please sync your feature branches
Message-ID: <20110228191558.6cfeaef7@pitrou.net>


Hello,

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

For the record, and as mentioned in the updated PEP 385, we plan to do
the final conversion on the 5th (that is next Saturday).

Regards

Antoine.



From g.brandl at gmx.net  Mon Feb 28 19:51:04 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 28 Feb 2011 19:51:04 +0100
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <20110228191558.6cfeaef7@pitrou.net>
References: <20110228191558.6cfeaef7@pitrou.net>
Message-ID: <ikgqsj$ffh$1@dough.gmane.org>

On 28.02.2011 19:15, Antoine Pitrou wrote:
> 
> Hello,
> 
> 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).
> 
> For the record, and as mentioned in the updated PEP 385, we plan to do
> the final conversion on the 5th (that is next Saturday).

And similarly, please backport any pending changesets (using svnmerge or
not), so that we're prepared for the new workflow.

Georg


From solipsis at pitrou.net  Mon Feb 28 20:54:42 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Feb 2011 20:54:42 +0100
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
References: <20110228182236.5F675EE982@mail.python.org>
	<4D6BEB1B.1040004@udel.edu>
Message-ID: <20110228205442.257dcae1@pitrou.net>

On Mon, 28 Feb 2011 13:36:11 -0500
Terry Reedy <tjreedy at udel.edu> wrote:
> 
> > +  an existing branch.  The pusher then has to merge the superfetatory heads
> 
> 'superfetatory'? I have no idea of what this is, neither does 
> merriam-webster.com ;-).

There are some Google hits, though... Not sure if they are of people
making the same mistakes as I do ;)

Regards

Antoine.




From benjamin at python.org  Mon Feb 28 20:56:23 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 28 Feb 2011 13:56:23 -0600
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <20110228205442.257dcae1@pitrou.net>
References: <20110228182236.5F675EE982@mail.python.org>
	<4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net>
Message-ID: <AANLkTinBcW5_QkSJ6QvHR5WE1DRKhappUoq3q0aVMV41@mail.gmail.com>

2011/2/28 Antoine Pitrou <solipsis at pitrou.net>:
> On Mon, 28 Feb 2011 13:36:11 -0500
> Terry Reedy <tjreedy at udel.edu> wrote:
>>
>> > + ?an existing branch. ?The pusher then has to merge the superfetatory heads
>>
>> 'superfetatory'? I have no idea of what this is, neither does
>> merriam-webster.com ;-).
>
> There are some Google hits, though... Not sure if they are of people
> making the same mistakes as I do ;)

Endly, perhaps it will be adopted. Did you mean "superfluous" though?



-- 
Regards,
Benjamin

From solipsis at pitrou.net  Mon Feb 28 20:58:56 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Feb 2011 20:58:56 +0100
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <AANLkTinBcW5_QkSJ6QvHR5WE1DRKhappUoq3q0aVMV41@mail.gmail.com>
References: <20110228182236.5F675EE982@mail.python.org>
	<4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net>
	<AANLkTinBcW5_QkSJ6QvHR5WE1DRKhappUoq3q0aVMV41@mail.gmail.com>
Message-ID: <1298923136.3692.4.camel@localhost.localdomain>

Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit :
> 2011/2/28 Antoine Pitrou <solipsis at pitrou.net>:
> > On Mon, 28 Feb 2011 13:36:11 -0500
> > Terry Reedy <tjreedy at udel.edu> wrote:
> >>
> >> > +  an existing branch.  The pusher then has to merge the superfetatory heads
> >>
> >> 'superfetatory'? I have no idea of what this is, neither does
> >> merriam-webster.com ;-).
> >
> > There are some Google hits, though... Not sure if they are of people
> > making the same mistakes as I do ;)
> 
> Endly, perhaps it will be adopted. Did you mean "superfluous" though?

I really meant superfetatory (it's slightly different: superfluous is
simply useless, while superfetatory implies that it's in excess).



From benjamin at python.org  Mon Feb 28 21:01:19 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 28 Feb 2011 14:01:19 -0600
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <1298923136.3692.4.camel@localhost.localdomain>
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>
Message-ID: <AANLkTim9dUPV1f_=mAkARBhS1yeJaArto3sYiai4brOg@mail.gmail.com>

2011/2/28 Antoine Pitrou <solipsis at pitrou.net>:
> Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit :
>> 2011/2/28 Antoine Pitrou <solipsis at pitrou.net>:
>> > On Mon, 28 Feb 2011 13:36:11 -0500
>> > Terry Reedy <tjreedy at udel.edu> wrote:
>> >>
>> >> > + ?an existing branch. ?The pusher then has to merge the superfetatory heads
>> >>
>> >> 'superfetatory'? I have no idea of what this is, neither does
>> >> merriam-webster.com ;-).
>> >
>> > There are some Google hits, though... Not sure if they are of people
>> > making the same mistakes as I do ;)
>>
>> Endly, perhaps it will be adopted. Did you mean "superfluous" though?
>
> I really meant superfetatory (it's slightly different: superfluous is
> simply useless, while superfetatory implies that it's in excess).

superfluous - "in excess of what is required or sufficient"



-- 
Regards,
Benjamin

From g.brandl at gmx.net  Mon Feb 28 21:07:58 2011
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 28 Feb 2011 21:07:58 +0100
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <1298923136.3692.4.camel@localhost.localdomain>
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>
Message-ID: <ikgvcq$9bm$1@dough.gmane.org>

On 28.02.2011 20:58, Antoine Pitrou wrote:
> Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit :
>> 2011/2/28 Antoine Pitrou <solipsis at pitrou.net>:
>> > On Mon, 28 Feb 2011 13:36:11 -0500
>> > Terry Reedy <tjreedy at udel.edu> wrote:
>> >>
>> >> > +  an existing branch.  The pusher then has to merge the superfetatory heads
>> >>
>> >> 'superfetatory'? I have no idea of what this is, neither does
>> >> merriam-webster.com ;-).
>> >
>> > There are some Google hits, though... Not sure if they are of people
>> > making the same mistakes as I do ;)
>> 
>> Endly, perhaps it will be adopted. Did you mean "superfluous" though?
> 
> I really meant superfetatory (it's slightly different: superfluous is
> simply useless, while superfetatory implies that it's in excess).

Maybe "supernumerary" serves?

Georg


From raymond.hettinger at gmail.com  Mon Feb 28 21:53:14 2011
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 28 Feb 2011 12:53:14 -0800
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <ikgvcq$9bm$1@dough.gmane.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>
	<ikgvcq$9bm$1@dough.gmane.org>
Message-ID: <9774EE64-D7E2-40BB-B1D1-892B70652E4F@gmail.com>


On Feb 28, 2011, at 12:07 PM, Georg Brandl wrote:

> On 28.02.2011 20:58, Antoine Pitrou wrote:
>> Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit :
>>> 2011/2/28 Antoine Pitrou <solipsis at pitrou.net>:
>>>> On Mon, 28 Feb 2011 13:36:11 -0500
>>>> Terry Reedy <tjreedy at udel.edu> wrote:
>>>>> 
>>>>>> +  an existing branch.  The pusher then has to merge the superfetatory heads
>>>>> 
>>>>> 'superfetatory'? I have no idea of what this is, neither does
>>>>> merriam-webster.com ;-).
>>>> 
>>>> There are some Google hits, though... Not sure if they are of people
>>>> making the same mistakes as I do ;)
>>> 
>>> Endly, perhaps it will be adopted. Did you mean "superfluous" though?
>> 
>> I really meant superfetatory (it's slightly different: superfluous is
>> simply useless, while superfetatory implies that it's in excess).
> 
> Maybe "supernumerary" serves?


Plain, everyday English would serve better than using words which people need to look-up.

How about:   "The pusher should the merge extra, unused heads" or somesuch.


Raymond


From barry at python.org  Mon Feb 28 22:07:48 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 28 Feb 2011 16:07:48 -0500
Subject: [Python-Dev] Mercurial conversion repositories
In-Reply-To: <20110228161538.36b825ac@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>
Message-ID: <20110228160748.1be8b814@limelight.wooz.org>

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.

-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/20110228/b81e4f6d/attachment.pgp>

From solipsis at pitrou.net  Mon Feb 28 22:10:34 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Feb 2011 22:10:34 +0100
Subject: [Python-Dev] 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>
Message-ID: <20110228221034.53ebe810@pitrou.net>

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.



From martin at v.loewis.de  Mon Feb 28 22:59:43 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Feb 2011 22:59:43 +0100
Subject: [Python-Dev] Finding buildbot failures
In-Reply-To: <4D68FD31.70901@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>
Message-ID: <4D6C1ACF.3030503@v.loewis.de>

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

Regards,
Martin

From martin at v.loewis.de  Mon Feb 28 23:26:19 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Feb 2011 23:26:19 +0100
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <20110228191558.6cfeaef7@pitrou.net>
References: <20110228191558.6cfeaef7@pitrou.net>
Message-ID: <4D6C210B.2010709@v.loewis.de>

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

Regards,
Martin

From solipsis at pitrou.net  Mon Feb 28 23:45:06 2011
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Feb 2011 23:45:06 +0100
Subject: [Python-Dev] Please sync your feature branches
In-Reply-To: <4D6C210B.2010709@v.loewis.de>
References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de>
Message-ID: <1298933106.3692.10.camel@localhost.localdomain>

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 it should be as simple as
"apply your current patch" where the text says "You can now work on your
feature".

A caveat of these instructions is that pushing a whole cpython-based
repo will be quite slow unless you have a large upload bandwidth (most
users have asymmetric connections). So we would like to offer a special
command for committers to make a clone of a repository *from the server,
to the server*.
In my current prototype this is spelled as:

  ssh hg at hg.python.org clone <srcrepo> <dstrepo>

for example:

  ssh hg at hg.python.org clone cpython features/pep-382

where "features/pep-382" will be a new repo on hg.python.org cloned from
the cpython repo on hg.python.org. Meaning no heavy network transfer
occurs. Then you clone the dest repo and the only changesets will have
to push will be those representing your own work.

If you think the "remote clone" trick above is good enough, I'll
publicize it in the devguide.

Regards

Antoine.



From steve at pearwood.info  Mon Feb 28 23:40:56 2011
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 01 Mar 2011 09:40:56 +1100
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <1298923136.3692.4.camel@localhost.localdomain>
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>
Message-ID: <4D6C2478.2070201@pearwood.info>

Antoine Pitrou wrote:
> Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit :
>> 2011/2/28 Antoine Pitrou <solipsis at pitrou.net>:
>>> On Mon, 28 Feb 2011 13:36:11 -0500
>>> Terry Reedy <tjreedy at udel.edu> wrote:
>>>>> +  an existing branch.  The pusher then has to merge the superfetatory heads
>>>> 'superfetatory'? I have no idea of what this is, neither does
>>>> merriam-webster.com ;-).
>>> There are some Google hits, though... Not sure if they are of people
>>> making the same mistakes as I do ;)
>> Endly, perhaps it will be adopted. Did you mean "superfluous" though?
> 
> I really meant superfetatory (it's slightly different: superfluous is
> simply useless, while superfetatory implies that it's in excess).


My wife has a copy of the shorter Oxford English dictionary, so we 
looked it up. There's no listing for superfetatory, but there is 
"superfetation":

1. a second conception occurring during pregnancy; the formation of a 
second fetus in a uterus already pregnant;
1b. botany the fertilization of the same ovule by two different kinds of 
pollen;
2. (figurative) additional or super-abundant production or occurrence; 
the growth or accretion of one thing on another; and instance of this; 
an accretion; an excrescence.

She commented that sesquipedalian words like superfetation are probably 
either specialised jargon, or known by people like Clive James and very 
few others :)

I think that superfluous simply means "excess to requirements but merely 
useless", while superfetatory would imply harmfully in excess. In any 
case, it's a wonderful word and I will try to casually drop it into 
conversation every now and then to annoy people *wink*



-- 
Steven

From martin at v.loewis.de  Mon Feb 28 23:54:46 2011
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 28 Feb 2011 23:54:46 +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: <4D6C27B6.5000601@v.loewis.de>

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

Regards,
Martin

From merwok at netwok.org  Mon Feb 28 23:56:56 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 28 Feb 2011 23:56:56 +0100
Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt
In-Reply-To: <4D6C2478.2070201@pearwood.info>
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>
Message-ID: <4D6C2838.4000706@netwok.org>

> I really meant superfetatory

Those damn French people with their foreign words.