From guido at python.org  Tue Jul  1 01:14:18 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 30 Jun 2008 16:14:18 -0700
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <486927B0.60300@trueblade.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>
	<483EAF95.5050503@trueblade.com>
	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>
	<483F06FF.9090007@trueblade.com>
	<78b3a9580805291634t3ed65ab3x29bedc80be887f8@mail.gmail.com>
	<483F4E3A.9090403@trueblade.com>
	<ca471dc20805301209j67c3e2a5nf819297680cbf3fb@mail.gmail.com>
	<48405420.8010800@trueblade.com>
	<ca471dc20805301237p4a30dd5du4f3ecb2771a967ca@mail.gmail.com>
	<486927B0.60300@trueblade.com>
Message-ID: <ca471dc20806301614g7fd1eba1v5488bd8b5c08be61@mail.gmail.com>

I'd check with Barry, but given that .format() is a new feature in
these releases anyway and this is a pretty small addition to one tiny
bit of code I would have been okay with it if I were release manager.

On Mon, Jun 30, 2008 at 11:36 AM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> I finally have some cycles for this.  Is it okay to add '#' to hex, bin, and
> oct for str.format(), even though it's now after the beta?
>
> Eric.
>
> Guido van Rossum wrote:
>>
>> Of course.
>>
>> On Fri, May 30, 2008 at 12:23 PM, Eric Smith
>> <eric+python-dev at trueblade.com> wrote:
>>>
>>> Guido van Rossum wrote:
>>>>
>>>> I'd be fine with adding '#' back to the formatting language for hex and
>>>> oct.
>>>
>>> And bin, I assume?
>>>
>>>> On Thu, May 29, 2008 at 5:45 PM, Eric Smith
>>>> <eric+python-dev at trueblade.com> wrote:
>>>>>
>>>>> wesley chun wrote:
>>>>>>
>>>>>> On 5/29/08, Eric Smith <eric+python-dev at trueblade.com> wrote:
>>>>>>>
>>>>>>> Marcin 'Qrczak' Kowalczyk wrote:
>>>>>>>>
>>>>>>>> Except that it works incorrectly for negative numbers.
>>>>>>
>>>>>> wow, that is a great point.  i didn't think of this either. it makes
>>>>>> it very inconvenient (see below) and makes it more difficult to say
>>>>>> we've completed replaced the '%' operator.
>>>>>>
>>>>>>
>>>>>>>  I can't really think of any other way that doesn't involve
>>>>>>> converting
>>>>>>> the
>>>>>>> number to a string and then operating on that, just to get the sign.
>>>>>>
>>>>>> here's one way of doing it without converting to a string first (it's
>>>>>> ugly
>>>>>> too):
>>>>>>
>>>>>>>>> i = -45
>>>>>>>>> '{0}0x{1:x}'.format('-' if i < 0 else '', abs(i))
>>>>>>
>>>>>> '-0x2d'
>>>>>
>>>>> Agreed, ick!
>>>>>
>>>>>> thx for putting it (back) in,
>>>>>
>>>>> I didn't say I would, I said I would if a decision was reached :)  I'd
>>>>> like
>>>>> to see some more consensus, and I hope that Talin (the PEP author)
>>>>> chimes
>>>>> in.
>>>>>
>>>>> Eric.
>>>>>
>>>>> _______________________________________________
>>>>> Python-3000 mailing list
>>>>> Python-3000 at python.org
>>>>> http://mail.python.org/mailman/listinfo/python-3000
>>>>> Unsubscribe:
>>>>> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From eric+python-dev at trueblade.com  Tue Jul  1 01:45:38 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Mon, 30 Jun 2008 19:45:38 -0400
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <ca471dc20806301614g7fd1eba1v5488bd8b5c08be61@mail.gmail.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>	
	<483EAF95.5050503@trueblade.com>	
	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>	
	<483F06FF.9090007@trueblade.com>	
	<78b3a9580805291634t3ed65ab3x29bedc80be887f8@mail.gmail.com>	
	<483F4E3A.9090403@trueblade.com>	
	<ca471dc20805301209j67c3e2a5nf819297680cbf3fb@mail.gmail.com>	
	<48405420.8010800@trueblade.com>	
	<ca471dc20805301237p4a30dd5du4f3ecb2771a967ca@mail.gmail.com>	
	<486927B0.60300@trueblade.com>
	<ca471dc20806301614g7fd1eba1v5488bd8b5c08be61@mail.gmail.com>
Message-ID: <48697022.9010207@trueblade.com>

Barry?

Guido van Rossum wrote:
> I'd check with Barry, but given that .format() is a new feature in
> these releases anyway and this is a pretty small addition to one tiny
> bit of code I would have been okay with it if I were release manager.
> 
> On Mon, Jun 30, 2008 at 11:36 AM, Eric Smith
> <eric+python-dev at trueblade.com> wrote:
>> I finally have some cycles for this.  Is it okay to add '#' to hex, bin, and
>> oct for str.format(), even though it's now after the beta?
>>
>> Eric.
>>
>> Guido van Rossum wrote:
>>> Of course.
>>>
>>> On Fri, May 30, 2008 at 12:23 PM, Eric Smith
>>> <eric+python-dev at trueblade.com> wrote:
>>>> Guido van Rossum wrote:
>>>>> I'd be fine with adding '#' back to the formatting language for hex and
>>>>> oct.
>>>> And bin, I assume?
>>>>
>>>>> On Thu, May 29, 2008 at 5:45 PM, Eric Smith
>>>>> <eric+python-dev at trueblade.com> wrote:
>>>>>> wesley chun wrote:
>>>>>>> On 5/29/08, Eric Smith <eric+python-dev at trueblade.com> wrote:
>>>>>>>> Marcin 'Qrczak' Kowalczyk wrote:
>>>>>>>>> Except that it works incorrectly for negative numbers.
>>>>>>> wow, that is a great point.  i didn't think of this either. it makes
>>>>>>> it very inconvenient (see below) and makes it more difficult to say
>>>>>>> we've completed replaced the '%' operator.
>>>>>>>
>>>>>>>
>>>>>>>>  I can't really think of any other way that doesn't involve
>>>>>>>> converting
>>>>>>>> the
>>>>>>>> number to a string and then operating on that, just to get the sign.
>>>>>>> here's one way of doing it without converting to a string first (it's
>>>>>>> ugly
>>>>>>> too):
>>>>>>>
>>>>>>>>>> i = -45
>>>>>>>>>> '{0}0x{1:x}'.format('-' if i < 0 else '', abs(i))
>>>>>>> '-0x2d'
>>>>>> Agreed, ick!
>>>>>>
>>>>>>> thx for putting it (back) in,
>>>>>> I didn't say I would, I said I would if a decision was reached :)  I'd
>>>>>> like
>>>>>> to see some more consensus, and I hope that Talin (the PEP author)
>>>>>> chimes
>>>>>> in.
>>>>>>
>>>>>> Eric.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Python-3000 mailing list
>>>>>> Python-3000 at python.org
>>>>>> http://mail.python.org/mailman/listinfo/python-3000
>>>>>> Unsubscribe:
>>>>>> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>>>>>>
>>>>>
>>>
>>>
>>
> 
> 
> 


From eric at trueblade.com  Tue Jul  1 01:46:55 2008
From: eric at trueblade.com (Eric Smith)
Date: Mon, 30 Jun 2008 19:46:55 -0400
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <48697022.9010207@trueblade.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>		<483EAF95.5050503@trueblade.com>		<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>		<483F06FF.9090007@trueblade.com>		<78b3a9580805291634t3ed65ab3x29bedc80be887f8@mail.gmail.com>		<483F4E3A.9090403@trueblade.com>		<ca471dc20805301209j67c3e2a5nf819297680cbf3fb@mail.gmail.com>		<48405420.8010800@trueblade.com>		<ca471dc20805301237p4a30dd5du4f3ecb2771a967ca@mail.gmail.com>		<486927B0.60300@trueblade.com>	<ca471dc20806301614g7fd1eba1v5488bd8b5c08be61@mail.gmail.com>
	<48697022.9010207@trueblade.com>
Message-ID: <4869706F.7090404@trueblade.com>

Eric Smith wrote:
> Barry?

By which I meant "Barry, what's your opinion?", not "who is Barry?" 
(which I well know).  Geez, I write the worst email sometimes.

ERic.

> 
> Guido van Rossum wrote:
>> I'd check with Barry, but given that .format() is a new feature in
>> these releases anyway and this is a pretty small addition to one tiny
>> bit of code I would have been okay with it if I were release manager.
>>
>> On Mon, Jun 30, 2008 at 11:36 AM, Eric Smith
>> <eric+python-dev at trueblade.com> wrote:
>>> I finally have some cycles for this.  Is it okay to add '#' to hex, 
>>> bin, and
>>> oct for str.format(), even though it's now after the beta?
>>>
>>> Eric.
>>>
>>> Guido van Rossum wrote:
>>>> Of course.
>>>>
>>>> On Fri, May 30, 2008 at 12:23 PM, Eric Smith
>>>> <eric+python-dev at trueblade.com> wrote:
>>>>> Guido van Rossum wrote:
>>>>>> I'd be fine with adding '#' back to the formatting language for 
>>>>>> hex and
>>>>>> oct.
>>>>> And bin, I assume?
>>>>>
>>>>>> On Thu, May 29, 2008 at 5:45 PM, Eric Smith
>>>>>> <eric+python-dev at trueblade.com> wrote:
>>>>>>> wesley chun wrote:
>>>>>>>> On 5/29/08, Eric Smith <eric+python-dev at trueblade.com> wrote:
>>>>>>>>> Marcin 'Qrczak' Kowalczyk wrote:
>>>>>>>>>> Except that it works incorrectly for negative numbers.
>>>>>>>> wow, that is a great point.  i didn't think of this either. it 
>>>>>>>> makes
>>>>>>>> it very inconvenient (see below) and makes it more difficult to say
>>>>>>>> we've completed replaced the '%' operator.
>>>>>>>>
>>>>>>>>
>>>>>>>>>  I can't really think of any other way that doesn't involve
>>>>>>>>> converting
>>>>>>>>> the
>>>>>>>>> number to a string and then operating on that, just to get the 
>>>>>>>>> sign.
>>>>>>>> here's one way of doing it without converting to a string first 
>>>>>>>> (it's
>>>>>>>> ugly
>>>>>>>> too):
>>>>>>>>
>>>>>>>>>>> i = -45
>>>>>>>>>>> '{0}0x{1:x}'.format('-' if i < 0 else '', abs(i))
>>>>>>>> '-0x2d'
>>>>>>> Agreed, ick!
>>>>>>>
>>>>>>>> thx for putting it (back) in,
>>>>>>> I didn't say I would, I said I would if a decision was reached 
>>>>>>> :)  I'd
>>>>>>> like
>>>>>>> to see some more consensus, and I hope that Talin (the PEP author)
>>>>>>> chimes
>>>>>>> in.
>>>>>>>
>>>>>>> Eric.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Python-3000 mailing list
>>>>>>> Python-3000 at python.org
>>>>>>> http://mail.python.org/mailman/listinfo/python-3000
>>>>>>> Unsubscribe:
>>>>>>> http://mail.python.org/mailman/options/python-3000/guido%40python.org 
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
> 
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-3000/eric%2Bpython-dev%40trueblade.com 
> 
> 


From amauryfa at gmail.com  Tue Jul  1 14:37:06 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 1 Jul 2008 14:37:06 +0200
Subject: [Python-3000] Get rid of Py_FindMethod
Message-ID: <e27efe130807010537s6b3feaf4j8a2b1fcf70e8b016@mail.gmail.com>

Hello,

http://bugs.python.org/issue3247 complains that with python 3.0, dir()
of a SRE_Match object returns an empty list.

This type has the particularity to not define a tp_methods; instead,
its tp_getattr slot calls Py_FindMethod(match_methods, self, name)
where "match_methods" is a PyMethodDef[] array that looks very very
similar to a typical tp_methods slot.

Py_FindMethod has a trick: when the requested name is "__methods__",
it returns the names of the PyMethodDef items.

__methods__ has disappeared with python 3.0, and indeed if I enable
the "-3" warning flag on python2.6,
dir() on a SRE_Match object raises two (!) warnings:
__main__:1: DeprecationWarning: __methods__ not supported in 3.x
__main__:1: DeprecationWarning: __members__ and __methods__ not supported in 3.x

According to previous discussions:
http://mail.python.org/pipermail/python-3000/2007-July/008787.html
Py_FindMethod is not needed any more in modern modules, and should go away.
Note that PyMember_Get has already disappeared, because the few
modules using them were deleted...

Is it still time for such a change after beta1?
There are ~30 occurrences of Py_FindMethod in the code base.
Most of the time, it is enough to remove the call, and set the
tp_methods members.


Another thing: why was traceback.__dir__ added?
the current 3.0 produces:
>>> dir(b.__traceback__)
['tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']

When I remove the __dir__ method, I get the special methods as well:
>>> dir(b.__traceback__)
['__class__', '__delattr__', '__doc__', '__eq__', '__format__',
'__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
'__le__', '__lt__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__', 'tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']

It's more verbose, but most types have the same list of special
members. I suggest to remove it, to enhance consistency (loosing some
2.6 compatibility, but it's python3.0 after all)

-- 
Amaury Forgeot d'Arc

From guido at python.org  Tue Jul  1 19:06:49 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Jul 2008 10:06:49 -0700
Subject: [Python-3000] Get rid of Py_FindMethod
In-Reply-To: <e27efe130807010537s6b3feaf4j8a2b1fcf70e8b016@mail.gmail.com>
References: <e27efe130807010537s6b3feaf4j8a2b1fcf70e8b016@mail.gmail.com>
Message-ID: <ca471dc20807011006o64e9a31fm78beadfa63e58342@mail.gmail.com>

On Tue, Jul 1, 2008 at 5:37 AM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> http://bugs.python.org/issue3247 complains that with python 3.0, dir()
> of a SRE_Match object returns an empty list.
>
> This type has the particularity to not define a tp_methods; instead,
> its tp_getattr slot calls Py_FindMethod(match_methods, self, name)
> where "match_methods" is a PyMethodDef[] array that looks very very
> similar to a typical tp_methods slot.
>
> Py_FindMethod has a trick: when the requested name is "__methods__",
> it returns the names of the PyMethodDef items.
>
> __methods__ has disappeared with python 3.0, and indeed if I enable
> the "-3" warning flag on python2.6,
> dir() on a SRE_Match object raises two (!) warnings:
> __main__:1: DeprecationWarning: __methods__ not supported in 3.x
> __main__:1: DeprecationWarning: __members__ and __methods__ not supported in 3.x
>
> According to previous discussions:
> http://mail.python.org/pipermail/python-3000/2007-July/008787.html
> Py_FindMethod is not needed any more in modern modules, and should go away.
> Note that PyMember_Get has already disappeared, because the few
> modules using them were deleted...
>
> Is it still time for such a change after beta1?

I'd say definitely. This just fell through the cracks.

> There are ~30 occurrences of Py_FindMethod in the code base.
> Most of the time, it is enough to remove the call, and set the
> tp_methods members.

Good!

> Another thing: why was traceback.__dir__ added?
> the current 3.0 produces:
>>>> dir(b.__traceback__)
> ['tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
>
> When I remove the __dir__ method, I get the special methods as well:
>>>> dir(b.__traceback__)
> ['__class__', '__delattr__', '__doc__', '__eq__', '__format__',
> '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
> '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
> '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
> '__subclasshook__', 'tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
>
> It's more verbose, but most types have the same list of special
> members. I suggest to remove it, to enhance consistency (loosing some
> 2.6 compatibility, but it's python3.0 after all)

Can't tell you why -- looks odd to me too. Hopefully Collin Winter remembers.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From barry at python.org  Tue Jul  1 22:16:37 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Jul 2008 16:16:37 -0400
Subject: [Python-3000] Second betas tomorrow
Message-ID: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>

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

Wow, I bet this one crept up on you as quickly as it did me!

We have our second planned beta releases for 2.6 and 3.0 tomorrow.  As  
usual I will start looking at blockers and buildbots tomorrow  
afternoon (UTC-4 time) with a plan to start building things at about  
6pm.  Also, I will of course be in #python-dev on freenode to answer  
any questions, or get second opinions.

PEP 361 claims that these will be the last betas.  Whether that's true  
or not depends on how well the beta2's go.  Please help review code or  
fix bugs.  If you know of things that absolutely must go into beta2,  
be sure there is an open release-blocker bug on the issue.

Thanks,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGqQpnEjvBPtnXfVAQLdagP/VooK8+AoPrb1bR7xAxGqg0vC1HOKw5qZ
8VQArzgldz1OnoG24PuKGdaEw7PbHjCMkD0/CyZWjH8/yWawcxV7hKl6RYHJ3GX9
keroo7wz3/NaptJtA9ldoKA5ekV8WVVC5OElgtjKr+v6HorPQSHzUgJiDHYUS1FW
A8fdHipyZds=
=vwYy
-----END PGP SIGNATURE-----

From g.brandl at gmx.net  Tue Jul  1 22:23:57 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 01 Jul 2008 22:23:57 +0200
Subject: [Python-3000] Second betas tomorrow
In-Reply-To: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
Message-ID: <g4e3p1$77m$1@ger.gmane.org>

Barry Warsaw schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Wow, I bet this one crept up on you as quickly as it did me!
> 
> We have our second planned beta releases for 2.6 and 3.0 tomorrow.  As  
> usual I will start looking at blockers and buildbots tomorrow  
> afternoon (UTC-4 time) with a plan to start building things at about  
> 6pm.  Also, I will of course be in #python-dev on freenode to answer  
> any questions, or get second opinions.
> 
> PEP 361 claims that these will be the last betas.  Whether that's true  
> or not depends on how well the beta2's go.  Please help review code or  
> fix bugs.  If you know of things that absolutely must go into beta2,  
> be sure there is an open release-blocker bug on the issue.

May I ask if it really makes sense to release the beta tomorrow? Looking
at the Misc/NEWS files for 2.6 and 3.0, there are around 3-5 entries
for each release. I know it's good to follow the release plan, but it
also may save you, the release manager, work for the third beta (which
I think will be necessary if beta2 is released tomorrow).

Georg


From guido at python.org  Tue Jul  1 22:25:27 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Jul 2008 13:25:27 -0700
Subject: [Python-3000] Second betas tomorrow
In-Reply-To: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
Message-ID: <ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>

I think we should put this one off. The previous betas were done on June 18,
and IMO the next beta should be about a month afterwards, not 2 weeks.

On Tue, Jul 1, 2008 at 1:16 PM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wow, I bet this one crept up on you as quickly as it did me!
>
> We have our second planned beta releases for 2.6 and 3.0 tomorrow.  As
> usual I will start looking at blockers and buildbots tomorrow afternoon
> (UTC-4 time) with a plan to start building things at about 6pm.  Also, I
> will of course be in #python-dev on freenode to answer any questions, or get
> second opinions.
>
> PEP 361 claims that these will be the last betas.  Whether that's true or
> not depends on how well the beta2's go.  Please help review code or fix
> bugs.  If you know of things that absolutely must go into beta2, be sure
> there is an open release-blocker bug on the issue.
>
> Thanks,
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
>
> iQCVAwUBSGqQpnEjvBPtnXfVAQLdagP/VooK8+AoPrb1bR7xAxGqg0vC1HOKw5qZ
> 8VQArzgldz1OnoG24PuKGdaEw7PbHjCMkD0/CyZWjH8/yWawcxV7hKl6RYHJ3GX9
> keroo7wz3/NaptJtA9ldoKA5ekV8WVVC5OElgtjKr+v6HorPQSHzUgJiDHYUS1FW
> A8fdHipyZds=
> =vwYy
> -----END PGP SIGNATURE-----
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080701/dda8165a/attachment.htm>

From jnoller at gmail.com  Tue Jul  1 22:28:11 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Tue, 1 Jul 2008 16:28:11 -0400
Subject: [Python-3000] Second betas tomorrow
In-Reply-To: <g4e3p1$77m$1@ger.gmane.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<g4e3p1$77m$1@ger.gmane.org>
Message-ID: <4222a8490807011328v4df3eb9fl7de44be415b334ff@mail.gmail.com>

On Tue, Jul 1, 2008 at 4:23 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> Barry Warsaw schrieb:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Wow, I bet this one crept up on you as quickly as it did me!
>>
>> We have our second planned beta releases for 2.6 and 3.0 tomorrow.  As
>>  usual I will start looking at blockers and buildbots tomorrow  afternoon
>> (UTC-4 time) with a plan to start building things at about  6pm.  Also, I
>> will of course be in #python-dev on freenode to answer  any questions, or
>> get second opinions.
>>
>> PEP 361 claims that these will be the last betas.  Whether that's true  or
>> not depends on how well the beta2's go.  Please help review code or  fix
>> bugs.  If you know of things that absolutely must go into beta2,  be sure
>> there is an open release-blocker bug on the issue.
>
> May I ask if it really makes sense to release the beta tomorrow? Looking
> at the Misc/NEWS files for 2.6 and 3.0, there are around 3-5 entries
> for each release. I know it's good to follow the release plan, but it
> also may save you, the release manager, work for the third beta (which
> I think will be necessary if beta2 is released tomorrow).
>
> Georg
>

Speaking from my minor perspective - I've been sick and MIA, so there
has not been a lot of movement on the pep 371 issues / multiprocessing
bugs since Beta 1, there's still a fair amount of issues to close out.

-jesse

From barry at python.org  Tue Jul  1 22:40:35 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Jul 2008 16:40:35 -0400
Subject: [Python-3000] Second betas tomorrow
In-Reply-To: <ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
Message-ID: <A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>

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

On Jul 1, 2008, at 4:25 PM, Guido van Rossum wrote:

> I think we should put this one off. The previous betas were done on  
> June 18, and IMO the next beta should be about a month afterwards,  
> not 2 weeks.

I will not be able to make releases the weeks of July 21st and 28th.   
The next scheduled beta is August 6th.

There are two options.  I could shift everything forward 2 weeks and  
do the next betas on July 16th.  Or we could wait until August 6th.   
That would mean 6 weeks between betas.  It's fine with me either way.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGqWQ3EjvBPtnXfVAQK5owP/Yd1pwWtwelbstnb6xh/dEtILirAyhfyo
kcfQSSFBX+GgkDIx99cxgmJ7nB+xSNSy1MlkXukDj41O2m+dCqcQaxhyim4yqBYC
r/Zc7IIiPT/nNQ/l97z8w0FqBoS/bmk9pqckBzrJfRRW14LZD8m2E/aU+OZeGi6z
0GZn/zwQbYk=
=yC2a
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Tue Jul  1 22:43:17 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 1 Jul 2008 20:43:17 +0000 (UTC)
Subject: [Python-3000] Second betas tomorrow
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<g4e3p1$77m$1@ger.gmane.org>
Message-ID: <loom.20080701T202751-81@post.gmane.org>


Hello,

> I know it's good to follow the release plan, but it
> also may save you, the release manager, work for the third beta (which
> I think will be necessary if beta2 is released tomorrow).

Yes, there are a lot of things remaining to do before Python 3.0 is sufficiently
polished. For example, chained exception reporting isn't in yet (see
http://bugs.python.org/issue3112).

(and I thought I would propose revamping some of the exception-related APIs
after that last patch is committed... the (type, value, traceback) idiom has
become pointlessly cumbersome, and even rather strange because it can lead you
to override the exception's __traceback__ attribute)

By the way, Barry, did you read the thread about regexps behaviour vis-?-vis
bytes and unicode? Your advice was requested :-)
See http://mail.python.org/pipermail/python-3000/2008-June/014247.html

Regards

Antoine.



From musiccomposition at gmail.com  Tue Jul  1 22:45:21 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 1 Jul 2008 15:45:21 -0500
Subject: [Python-3000] Second betas tomorrow
In-Reply-To: <A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
Message-ID: <1afaf6160807011345n650a645fq661908f75a1f6a03@mail.gmail.com>

On Tue, Jul 1, 2008 at 3:40 PM, Barry Warsaw <barry at python.org> wrote:
>
> There are two options.  I could shift everything forward 2 weeks and do the
> next betas on July 16th.  Or we could wait until August 6th.  That would
> mean 6 weeks between betas.  It's fine with me either way.

I vote for shifting things 2 weeks forward.

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From python at rcn.com  Tue Jul  1 22:51:17 2008
From: python at rcn.com (Raymond Hettinger)
Date: Tue, 1 Jul 2008 13:51:17 -0700
Subject: [Python-3000] [Python-Dev]  Second betas tomorrow
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org><ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
Message-ID: <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>

From: "Barry Warsaw" <barry at python.org>
> There are two options.  I could shift everything forward 2 weeks and  
> do the next betas on July 16th.  Or we could wait until August 6th.   
> That would mean 6 weeks between betas.  It's fine with me either way.

+1 for six weeks to allow the code to be more thoroughly exercised.


Raymond

From guido at python.org  Tue Jul  1 22:54:54 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Jul 2008 13:54:54 -0700
Subject: [Python-3000] [Python-Dev]  Second betas tomorrow
In-Reply-To: <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
Message-ID: <ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>

On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger <python at rcn.com> wrote:

> From: "Barry Warsaw" <barry at python.org>
>
>> There are two options.  I could shift everything forward 2 weeks and  do
>> the next betas on July 16th.  Or we could wait until August 6th.   That
>> would mean 6 weeks between betas.  It's fine with me either way.
>>
>
> +1 for six weeks to allow the code to be more thoroughly exercised.
>

In that case I'd rather insert an extra beta -- one in 2 weeks and one in 6
weeks.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080701/641c2c52/attachment.htm>

From barry at python.org  Wed Jul  2 00:55:16 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Jul 2008 18:55:16 -0400
Subject: [Python-3000] [Python-Dev]  Second betas tomorrow
In-Reply-To: <ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
Message-ID: <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>

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

On Jul 1, 2008, at 4:54 PM, Guido van Rossum wrote:

> On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger <python at rcn.com>  
> wrote:
> From: "Barry Warsaw" <barry at python.org>
>
> There are two options.  I could shift everything forward 2 weeks  
> and  do the next betas on July 16th.  Or we could wait until August  
> 6th.   That would mean 6 weeks between betas.  It's fine with me  
> either way.
>
> +1 for six weeks to allow the code to be more thoroughly exercised.
>
> In that case I'd rather insert an extra beta -- one in 2 weeks and  
> one in 6 weeks.

Okay.  I can't actually do it on July 16th, so the revised schedule  
will be:

15-Jul-2008 beta 2
23-Aug-2008 beta 3
03-Sep-2008 rc1
17-Sep-2008 rc2
01-Oct-2008 final releases

I will update PEP 361 now.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGq11HEjvBPtnXfVAQJdYgP8DFVvCHeDzIDliY0bQuw+DXxMuGAxHWFO
BZR2b4sEGFzMRfbGCJOi7wVubc4imwYDIpFXgzFHpWFMfUdBHGaSpnZJhGDxURqp
0vQQ3/nJLy7lpWfDYBy0Sps6XjANQF5SaqeW8KMVsa3X6Spw0fHTmF4xBIjiUaBy
MvydyLNszY4=
=9/s1
-----END PGP SIGNATURE-----

From guido at python.org  Wed Jul  2 01:04:04 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Jul 2008 16:04:04 -0700
Subject: [Python-3000] [Python-Dev]  Second betas tomorrow
In-Reply-To: <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
	<8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
Message-ID: <ca471dc20807011604q77c00e59kdf0d8b86312a03e6@mail.gmail.com>

On Tue, Jul 1, 2008 at 3:55 PM, Barry Warsaw <barry at python.org> wrote:
> On Jul 1, 2008, at 4:54 PM, Guido van Rossum wrote:
>> On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger <python at rcn.com> wrote:
>> From: "Barry Warsaw" <barry at python.org>
>>
>> There are two options.  I could shift everything forward 2 weeks and  do
>> the next betas on July 16th.  Or we could wait until August 6th.   That
>> would mean 6 weeks between betas.  It's fine with me either way.
>>
>> +1 for six weeks to allow the code to be more thoroughly exercised.
>>
>> In that case I'd rather insert an extra beta -- one in 2 weeks and one in
>> 6 weeks.
>
> Okay.  I can't actually do it on July 16th, so the revised schedule will be:
>
> 15-Jul-2008 beta 2
> 23-Aug-2008 beta 3
> 03-Sep-2008 rc1
> 17-Sep-2008 rc2
> 01-Oct-2008 final releases
>
> I will update PEP 361 now.

+1

Thanks for being flexible!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From barry at python.org  Wed Jul  2 01:13:57 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Jul 2008 19:13:57 -0400
Subject: [Python-3000] [Python-Dev]  Second betas tomorrow
In-Reply-To: <ca471dc20807011604q77c00e59kdf0d8b86312a03e6@mail.gmail.com>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
	<8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
	<ca471dc20807011604q77c00e59kdf0d8b86312a03e6@mail.gmail.com>
Message-ID: <535961AE-BCFE-4563-96E0-B883D97A1188@python.org>

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

On Jul 1, 2008, at 7:04 PM, Guido van Rossum wrote:

> On Tue, Jul 1, 2008 at 3:55 PM, Barry Warsaw <barry at python.org> wrote:
>> On Jul 1, 2008, at 4:54 PM, Guido van Rossum wrote:
>>> On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger <python at rcn.com>  
>>> wrote:
>>> From: "Barry Warsaw" <barry at python.org>
>>>
>>> There are two options.  I could shift everything forward 2 weeks  
>>> and  do
>>> the next betas on July 16th.  Or we could wait until August 6th.    
>>> That
>>> would mean 6 weeks between betas.  It's fine with me either way.
>>>
>>> +1 for six weeks to allow the code to be more thoroughly exercised.
>>>
>>> In that case I'd rather insert an extra beta -- one in 2 weeks and  
>>> one in
>>> 6 weeks.
>>
>> Okay.  I can't actually do it on July 16th, so the revised schedule  
>> will be:
>>
>> 15-Jul-2008 beta 2
>> 23-Aug-2008 beta 3
>> 03-Sep-2008 rc1
>> 17-Sep-2008 rc2
>> 01-Oct-2008 final releases
>>
>> I will update PEP 361 now.
>
> +1
>
> Thanks for being flexible!

Anything for a great release!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGq6NnEjvBPtnXfVAQKOlQP/RYlj6vxHEmlW/mVNIWqBYy/SmmMA6Qw4
hE3Bhb9QYGC5F0kEKyY5BmBVwETe70ahE1X3AOgmLrnHh5XwvGh8sNrFka/3s9sh
vt6XAZh9IoXekZBIOGO4Gz0EtcURVUvAbCzCSXkHCQyL3qoV1r+mxsXVLRV2S4q0
UifMzkOm6WI=
=wDrk
-----END PGP SIGNATURE-----

From brett at python.org  Wed Jul  2 01:27:03 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 1 Jul 2008 16:27:03 -0700
Subject: [Python-3000] [Python-Dev]  Second betas tomorrow
In-Reply-To: <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
	<8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
Message-ID: <bbaeab100807011627p658d0aeax5cdcbdf0dec2c244@mail.gmail.com>

On Tue, Jul 1, 2008 at 3:55 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jul 1, 2008, at 4:54 PM, Guido van Rossum wrote:
>
>> On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger <python at rcn.com> wrote:
>> From: "Barry Warsaw" <barry at python.org>
>>
>> There are two options.  I could shift everything forward 2 weeks and  do
>> the next betas on July 16th.  Or we could wait until August 6th.   That
>> would mean 6 weeks between betas.  It's fine with me either way.
>>
>> +1 for six weeks to allow the code to be more thoroughly exercised.
>>
>> In that case I'd rather insert an extra beta -- one in 2 weeks and one in
>> 6 weeks.
>
> Okay.  I can't actually do it on July 16th, so the revised schedule will be:
>
> 15-Jul-2008 beta 2
> 23-Aug-2008 beta 3
> 03-Sep-2008 rc1
> 17-Sep-2008 rc2
> 01-Oct-2008 final releases
>
> I will update PEP 361 now.

Is a Google Calendar kept by anyone that lists stuff like planned
release dates, etc.?

-Brett

From musiccomposition at gmail.com  Wed Jul  2 01:28:59 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 1 Jul 2008 18:28:59 -0500
Subject: [Python-3000] [Python-Dev] Second betas tomorrow
In-Reply-To: <bbaeab100807011627p658d0aeax5cdcbdf0dec2c244@mail.gmail.com>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
	<8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
	<bbaeab100807011627p658d0aeax5cdcbdf0dec2c244@mail.gmail.com>
Message-ID: <1afaf6160807011628m43738e85x3f03064a6df307ef@mail.gmail.com>

On Tue, Jul 1, 2008 at 6:27 PM, Brett Cannon <brett at python.org> wrote:
> Is a Google Calendar kept by anyone that lists stuff like planned
> release dates, etc.?

It's on my personal one. :)



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From kkwweett at hotmail.fr  Tue Jul  1 22:50:09 2008
From: kkwweett at hotmail.fr (Paul Langevin)
Date: Tue, 1 Jul 2008 22:50:09 +0200
Subject: [Python-3000] wrong md5 checksum
Message-ID: <BAY119-W464F2822593420A37BDD1EBA9E0@phx.gbl>


Hi,



the download page (http://www.python.org/download/releases/3.0/) for 
Python 3000 shows :



9119625244b17aa35ed94b655a2b2135  13491200  python-3.0b1.msi



but I got



9119625244a57aa35ed94b655a2b2135  13491200  python-3.0b1.msi



(44a57 rather than 44b17 )



with several md5 checkers ( MdChecker (http://getmd5checker.com/) or a C 
 prog I've written)


Wrong md5 checksum even with Python2.5 :



import md5

m=md5.new()

message=open("python-3.0b1.msi","rb").read()

m.update(message)

m.hexdigest()



Answer : '9119625244a57aa35ed94b655a2b2135'





what's wrong ? the file or the sum ?

_________________________________________________________________
Faites vous de nouveaux amis gr?ce ? l'annuaire des profils Messenger !
http://home.services.spaces.live.com/search/?page=searchresults&ss=true&FormId=AdvPeopleSearch&form=SPXFRM&tp=3&sc=2&pg=0&Search.DisplayName=Nom+public&search.gender=&search.age=&Search.FirstName=Pr%C3%A9nom&Search.LastName=Nom&search.location=Lieu&search.occupation=Profession&search.interests=amis&submit=Rechercher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080701/8e5b024c/attachment.htm>

From barry at python.org  Wed Jul  2 03:44:16 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Jul 2008 21:44:16 -0400
Subject: [Python-3000] [Python-Dev]  Second betas tomorrow
In-Reply-To: <bbaeab100807011627p658d0aeax5cdcbdf0dec2c244@mail.gmail.com>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
	<8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
	<bbaeab100807011627p658d0aeax5cdcbdf0dec2c244@mail.gmail.com>
Message-ID: <79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org>

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

On Jul 1, 2008, at 7:27 PM, Brett Cannon wrote:

> On Tue, Jul 1, 2008 at 3:55 PM, Barry Warsaw <barry at python.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Jul 1, 2008, at 4:54 PM, Guido van Rossum wrote:
>>
>>> On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger <python at rcn.com>  
>>> wrote:
>>> From: "Barry Warsaw" <barry at python.org>
>>>
>>> There are two options.  I could shift everything forward 2 weeks  
>>> and  do
>>> the next betas on July 16th.  Or we could wait until August 6th.    
>>> That
>>> would mean 6 weeks between betas.  It's fine with me either way.
>>>
>>> +1 for six weeks to allow the code to be more thoroughly exercised.
>>>
>>> In that case I'd rather insert an extra beta -- one in 2 weeks and  
>>> one in
>>> 6 weeks.
>>
>> Okay.  I can't actually do it on July 16th, so the revised schedule  
>> will be:
>>
>> 15-Jul-2008 beta 2
>> 23-Aug-2008 beta 3
>> 03-Sep-2008 rc1
>> 17-Sep-2008 rc2
>> 01-Oct-2008 final releases
>>
>> I will update PEP 361 now.
>
> Is a Google Calendar kept by anyone that lists stuff like planned
> release dates, etc.?

http://www.google.com/calendar/ical/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic.ics

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGrdcHEjvBPtnXfVAQJYxgQAh/+j8pF21H0k1vp+1znOh57MohU7gVP6
7fMnLSzOoA+9w7+pVvJVzWbr09vg41kO6OzqEAoMUPV2BK8ZHePuHZkLDwhCAAYk
nixu2vRZZEGmT6aC0jejwOCY7vy5giTHelX442drKZcuSdNl4x1kvyohBnm0flIH
6B7HRL3Oo2Q=
=5yqD
-----END PGP SIGNATURE-----

From brett at python.org  Wed Jul  2 04:01:33 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 1 Jul 2008 19:01:33 -0700
Subject: [Python-3000] [Python-Dev]  Second betas tomorrow
In-Reply-To: <79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
	<8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
	<bbaeab100807011627p658d0aeax5cdcbdf0dec2c244@mail.gmail.com>
	<79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org>
Message-ID: <bbaeab100807011901s5fd992cdn87c548bfdaa0866d@mail.gmail.com>

On Tue, Jul 1, 2008 at 6:44 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jul 1, 2008, at 7:27 PM, Brett Cannon wrote:
>
>> On Tue, Jul 1, 2008 at 3:55 PM, Barry Warsaw <barry at python.org> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Jul 1, 2008, at 4:54 PM, Guido van Rossum wrote:
>>>
>>>> On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger <python at rcn.com>
>>>> wrote:
>>>> From: "Barry Warsaw" <barry at python.org>
>>>>
>>>> There are two options.  I could shift everything forward 2 weeks and  do
>>>> the next betas on July 16th.  Or we could wait until August 6th.   That
>>>> would mean 6 weeks between betas.  It's fine with me either way.
>>>>
>>>> +1 for six weeks to allow the code to be more thoroughly exercised.
>>>>
>>>> In that case I'd rather insert an extra beta -- one in 2 weeks and one
>>>> in
>>>> 6 weeks.
>>>
>>> Okay.  I can't actually do it on July 16th, so the revised schedule will
>>> be:
>>>
>>> 15-Jul-2008 beta 2
>>> 23-Aug-2008 beta 3
>>> 03-Sep-2008 rc1
>>> 17-Sep-2008 rc2
>>> 01-Oct-2008 final releases
>>>
>>> I will update PEP 361 now.
>>
>> Is a Google Calendar kept by anyone that lists stuff like planned
>> release dates, etc.?
>
> http://www.google.com/calendar/ical/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic.ics

Thanks, Barry!

-Brett

From musiccomposition at gmail.com  Wed Jul  2 04:42:33 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 1 Jul 2008 21:42:33 -0500
Subject: [Python-3000] [Python-Dev] Second betas tomorrow
In-Reply-To: <79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
	<8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
	<bbaeab100807011627p658d0aeax5cdcbdf0dec2c244@mail.gmail.com>
	<79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org>
Message-ID: <1afaf6160807011942r738aae8u6c84aab03d463d76@mail.gmail.com>

On Tue, Jul 1, 2008 at 8:44 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jul 1, 2008, at 7:27 PM, Brett Cannon wrote:
>>
>> Is a Google Calendar kept by anyone that lists stuff like planned
>> release dates, etc.?
>
> http://www.google.com/calendar/ical/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic.ics

Can I get the non-iCal version?


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From barry at python.org  Wed Jul  2 05:29:10 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Jul 2008 23:29:10 -0400
Subject: [Python-3000] [Python-Dev] Second betas tomorrow
In-Reply-To: <1afaf6160807011942r738aae8u6c84aab03d463d76@mail.gmail.com>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
	<8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
	<bbaeab100807011627p658d0aeax5cdcbdf0dec2c244@mail.gmail.com>
	<79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org>
	<1afaf6160807011942r738aae8u6c84aab03d463d76@mail.gmail.com>
Message-ID: <D8E48735-E192-486B-A3D3-CD50C5F99DBF@python.org>

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


On Jul 1, 2008, at 10:42 PM, Benjamin Peterson wrote:

> On Tue, Jul 1, 2008 at 8:44 PM, Barry Warsaw <barry at python.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Jul 1, 2008, at 7:27 PM, Brett Cannon wrote:
>>>
>>> Is a Google Calendar kept by anyone that lists stuff like planned
>>> release dates, etc.?
>>
>> http://www.google.com/calendar/ical/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic.ics
>
> Can I get the non-iCal version?

http://www.google.com/calendar/feeds/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic

http://www.google.com/calendar/embed?src=b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com&ctz=America/New_York

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGr2BnEjvBPtnXfVAQJKBQP/bme7XNFS74SSmNNYX6Wz7Dq83VSQ8J6A
hZf6k7tTx6I3qv0Xgc2jD9NnNuLmqG+Rw8Ag5CjBtZXgzAoyszluzddJfz3G0032
zPofZx/ekp22u4XJo9iQyrDKinp+qTlDqlQntsscY5l+KXR5P9ahWeWWM9aQw707
VYkxQ2yAA7g=
=fzdc
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jul  2 05:34:14 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Jul 2008 23:34:14 -0400
Subject: [Python-3000] Second betas tomorrow
In-Reply-To: <loom.20080701T202751-81@post.gmane.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<g4e3p1$77m$1@ger.gmane.org>
	<loom.20080701T202751-81@post.gmane.org>
Message-ID: <EC929143-5DD6-47F5-8084-B0C37C36673D@python.org>

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

On Jul 1, 2008, at 4:43 PM, Antoine Pitrou wrote:

> By the way, Barry, did you read the thread about regexps behaviour  
> vis-?-vis
> bytes and unicode? Your advice was requested :-)
> See http://mail.python.org/pipermail/python-3000/2008-June/014247.html

I missed it the first time through, but I guess leaving it for bytes  
makes the most sense.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGr3NnEjvBPtnXfVAQJk/QP7BTduV0Vfk+3R0ixVjvTaDm+fQE2qpr/9
TB6GC/lJHghrEqjFx4JG5VetNR7K0/c1Qnj6mTRDDioDZqgKZNuj4jGZtmjS0+df
irCiyAxwZSHqlMLGKyWtxXIKl6Db21SeGJlMhi8iBlvKWNINR4y4YQsXkndH7hUP
83IKyIMUHd4=
=b6S/
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jul  2 14:57:14 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 2 Jul 2008 08:57:14 -0400
Subject: [Python-3000] [Fwd: Re: PEP 3101 str.format() equivalent of
	'%#o/x/X'?]
In-Reply-To: <486B41DF.9090507@trueblade.com>
References: <486B41DF.9090507@trueblade.com>
Message-ID: <0B5F0AB8-2547-411C-A150-7E627E6923FB@python.org>

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

[Thanks Eric Smith for pinging me on this one - BAW]

> -------- Original Message --------
> Subject: Re: [Python-3000] PEP 3101 str.format() equivalent of '%#o/ 
> x/X'?
> Date: Mon, 30 Jun 2008 16:14:18 -0700
> From: Guido van Rossum <guido at python.org>
> To: Eric Smith <eric+python-dev at trueblade.com>
> CC: python-3000 at python.org
> References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4 at mail.gmail.com 
> >	 <483EAF95.5050503 at trueblade.com>	 <3f4107910805291116w37af38e3qb2c5145539d7e23e at mail.gmail.com 
> >	 <483F06FF.9090007 at trueblade.com>	 <78b3a9580805291634t3ed65ab3x29bedc80be887f8 at mail.gmail.com 
> >	 <483F4E3A.9090403 at trueblade.com>	 <ca471dc20805301209j67c3e2a5nf819297680cbf3fb at mail.gmail.com 
> >	 <48405420.8010800 at trueblade.com>	 <ca471dc20805301237p4a30dd5du4f3ecb2771a967ca at mail.gmail.com 
> >	 <486927B0.60300 at trueblade.com>
>
> I'd check with Barry, but given that .format() is a new feature in
> these releases anyway and this is a pretty small addition to one tiny
> bit of code I would have been okay with it if I were release manager.

> On Mon, Jun 30, 2008 at 11:36 AM, Eric Smith
> <eric+python-dev at trueblade.com> wrote:
>> I finally have some cycles for this.  Is it okay to add '#' to hex,  
>> bin, and
>> oct for str.format(), even though it's now after the beta?

>>>>>> I didn't say I would, I said I would if a decision was  
>>>>>> reached :)  I'd
>>>>>> like
>>>>>> to see some more consensus, and I hope that Talin (the PEP  
>>>>>> author)
>>>>>> chimes
>>>>>> in.

I agree with Guido; this change is fine to make.

Thanks,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGt7K3EjvBPtnXfVAQKoAwQAgUBvU2IiBgcMKk5dvvfL8/hbplKWyhnC
EXA/GX7tsNSMXzMminC3K8sBtLH+oYP0qU8PNvtjHo+Zb0nbZgoqt3pU1EBs3LAp
5zn5DFAjsiCmZ1C7O5DQF9I8RXYvFQEQSZkP1pa73jGnVayLhCa00Y3PFntV1+EG
0OzX1hopPFY=
=JWdq
-----END PGP SIGNATURE-----

From nick at craig-wood.com  Wed Jul  2 21:36:06 2008
From: nick at craig-wood.com (Nick Craig-Wood)
Date: Wed, 2 Jul 2008 20:36:06 +0100
Subject: [Python-3000] wrong md5 checksum
In-Reply-To: <BAY119-W464F2822593420A37BDD1EBA9E0@phx.gbl>
References: <BAY119-W464F2822593420A37BDD1EBA9E0@phx.gbl>
Message-ID: <20080702193609.3381614C6FB@irishsea.home.craig-wood.com>

Paul Langevin <kkwweett at hotmail.fr> wrote:
>  the download page (http://www.python.org/download/releases/3.0/) for=20
>  Python 3000 shows :
> 
>  9119625244b17aa35ed94b655a2b2135  13491200  python-3.0b1.msi
> 
>  but I got
> 
>  9119625244a57aa35ed94b655a2b2135  13491200  python-3.0b1.msi
> 
>  (44a57 rather than 44b17 )

I downloaded the file with firefox on linux.  My md5sum agrees with
yours.  I'd say there is a typo on the downloads page as the chance of
an incorrect file with an md5sum which differs by only 2 bits is
astronomically small.

  >>> "%X" % (0x9119625244b17aa35ed94b655a2b2135 ^ 0x9119625244a57aa35ed94b655a2b2135)
  '1400000000000000000000'
  >>>

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick

From martin at v.loewis.de  Wed Jul  2 22:14:30 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Jul 2008 22:14:30 +0200
Subject: [Python-3000] wrong md5 checksum
In-Reply-To: <20080702193609.3381614C6FB@irishsea.home.craig-wood.com>
References: <BAY119-W464F2822593420A37BDD1EBA9E0@phx.gbl>
	<20080702193609.3381614C6FB@irishsea.home.craig-wood.com>
Message-ID: <486BE1A6.7010800@v.loewis.de>

> I downloaded the file with firefox on linux.  My md5sum agrees with
> yours.  I'd say there is a typo on the downloads page as the chance of
> an incorrect file with an md5sum which differs by only 2 bits is
> astronomically small.

I can confirm that the result that you all got is the correct one,
and I just corrected it on the web page.

I'm puzzled how this might have happened. It's clearly not a typo,
since I copy-pasted the md5sum from the shell output to the text
editor. In the subversion source of the page, it was already
incorrect, so some bit loss must have occurred in the editor, or
the cut-n-paste - which in itself is frightening.

Regards,
Martin

From musiccomposition at gmail.com  Wed Jul  2 22:17:54 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 2 Jul 2008 15:17:54 -0500
Subject: [Python-3000] to be merged
Message-ID: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>

I just merged a good chunk of the trunk -> py3k queue, but there are
still some things to be dealt with:

- bsddb It seesm bsddb still has yet to be ported to Py3k. See #2887.

- The asyncore/asynchat patches. Josiah, can you do this?

- The Mac 4-way arch build.

- The bin/hex/oct float things. (These can just be blocked, right?)

- SSL changes



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From qrczak at knm.org.pl  Wed Jul  2 22:20:10 2008
From: qrczak at knm.org.pl (=?UTF-8?Q?Marcin_=E2=80=98Qrczak=E2=80=99_Kowalczyk?=)
Date: Wed, 2 Jul 2008 22:20:10 +0200
Subject: [Python-3000] wrong md5 checksum
In-Reply-To: <486BE1A6.7010800@v.loewis.de>
References: <BAY119-W464F2822593420A37BDD1EBA9E0@phx.gbl>
	<20080702193609.3381614C6FB@irishsea.home.craig-wood.com>
	<486BE1A6.7010800@v.loewis.de>
Message-ID: <3f4107910807021320g40ba6c62lc655d01c375ea40c@mail.gmail.com>

2008/7/2 "Martin v. L?wis" <martin at v.loewis.de>:

> I'm puzzled how this might have happened.

Someone obviously did search & replace a5 -> b1, intended for Python
version, but applied to md5 too.

-- 
Marcin Kowalczyk
qrczak at knm.org.pl
http://qrnik.knm.org.pl/~qrczak/

From martin at v.loewis.de  Wed Jul  2 22:27:05 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 02 Jul 2008 22:27:05 +0200
Subject: [Python-3000] wrong md5 checksum
In-Reply-To: <3f4107910807021320g40ba6c62lc655d01c375ea40c@mail.gmail.com>
References: <BAY119-W464F2822593420A37BDD1EBA9E0@phx.gbl>	<20080702193609.3381614C6FB@irishsea.home.craig-wood.com>	<486BE1A6.7010800@v.loewis.de>
	<3f4107910807021320g40ba6c62lc655d01c375ea40c@mail.gmail.com>
Message-ID: <486BE499.4020701@v.loewis.de>

>> I'm puzzled how this might have happened.
> 
> Someone obviously did search & replace a5 -> b1, intended for Python
> version, but applied to md5 too.

Ah, ok. Thanks for the explanation. That might have been me, as well :-(

Regards,
Martin


From barry at python.org  Wed Jul  2 22:34:21 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 2 Jul 2008 16:34:21 -0400
Subject: [Python-3000] wrong md5 checksum
In-Reply-To: <3f4107910807021320g40ba6c62lc655d01c375ea40c@mail.gmail.com>
References: <BAY119-W464F2822593420A37BDD1EBA9E0@phx.gbl>
	<20080702193609.3381614C6FB@irishsea.home.craig-wood.com>
	<486BE1A6.7010800@v.loewis.de>
	<3f4107910807021320g40ba6c62lc655d01c375ea40c@mail.gmail.com>
Message-ID: <0F87140C-C5E2-4CD2-9DCF-0E5196D924ED@python.org>

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

On Jul 2, 2008, at 4:20 PM, Marcin ?Qrczak? Kowalczyk wrote:

> 2008/7/2 "Martin v. L?wis" <martin at v.loewis.de>:
>
>> I'm puzzled how this might have happened.
>
> Someone obviously did search & replace a5 -> b1, intended for Python
> version, but applied to md5 too.

Oh jeebus, that was probably me.  I thought I was careful about that  
though.  Next time I'll remember to drink more alcohol before I do the  
release.  Yeah, that'll definitely help.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGvmTXEjvBPtnXfVAQKP+gQAh5fNhqsk6pNL0rtBOC732Q13dQt8jbDj
8w6PVaMw9rsdzPtVX9jeJqRvlL+putYd14b5hgzPAPMgKJBlTREkUDRoerTS730n
KTvkvkSHXnnVqiAJHCh+oLFgCEKczYbxKiH8s0s2V55BIb68j0cug4uQmcFSWam7
9pO4hUh4saM=
=vr3S
-----END PGP SIGNATURE-----

From guido at python.org  Wed Jul  2 22:46:53 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 2 Jul 2008 13:46:53 -0700
Subject: [Python-3000] to be merged
In-Reply-To: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
Message-ID: <ca471dc20807021346j64f657d4ncc75d72baaa89c6f@mail.gmail.com>

On Wed, Jul 2, 2008 at 1:17 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> I just merged a good chunk of the trunk -> py3k queue, but there are
> still some things to be dealt with:
>
> - bsddb It seesm bsddb still has yet to be ported to Py3k. See #2887.
>
> - The asyncore/asynchat patches. Josiah, can you do this?
>
> - The Mac 4-way arch build.
>
> - The bin/hex/oct float things. (These can just be blocked, right?)

The current state should be the same before Raymond added float
support for these. The code was quite different in 2.6 as in 3.0, and
hence so were the rollbacks. Possibly Raymond forgot to block the 2.6
changes.

> - SSL changes

Talk to Bill Janssen.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From janssen at parc.com  Wed Jul  2 22:50:14 2008
From: janssen at parc.com (Bill Janssen)
Date: Wed, 2 Jul 2008 13:50:14 PDT
Subject: [Python-3000] to be merged
In-Reply-To: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com> 
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
Message-ID: <08Jul2.135015pdt."58698"@synergy1.parc.xerox.com>

> - SSL changes

I've been maintaining the Lib/ssl.py, Lib/test/test_ssl.py and
Modules/_ssl.c files separately for the two trees.  I think the
underlying changes in socket.py, and the IO subsystem, still make this
a good idea, but I'm willing to be convinced differently.

There's yet a third variant of this code for pre-2.6 in the PyPI
distribution of it.

Bill

From josiah.carlson at gmail.com  Wed Jul  2 22:57:53 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Wed, 2 Jul 2008 13:57:53 -0700
Subject: [Python-3000] to be merged
In-Reply-To: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
Message-ID: <e6511dbf0807021357p7ac855eag7b0bbe427ea20792@mail.gmail.com>

On Wed, Jul 2, 2008 at 1:17 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> I just merged a good chunk of the trunk -> py3k queue, but there are
> still some things to be dealt with:
>
> - bsddb It seesm bsddb still has yet to be ported to Py3k. See #2887.
>
> - The asyncore/asynchat patches. Josiah, can you do this?
>
> - The Mac 4-way arch build.
>
> - The bin/hex/oct float things. (These can just be blocked, right?)
>
> - SSL changes

I will try with asyncore/asynchat, but I have no experience with py3k
or the 2to3 converter.

 - Josiah

From josiah.carlson at gmail.com  Thu Jul  3 00:50:20 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Wed, 2 Jul 2008 15:50:20 -0700
Subject: [Python-3000] to be merged
In-Reply-To: <e6511dbf0807021357p7ac855eag7b0bbe427ea20792@mail.gmail.com>
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
	<e6511dbf0807021357p7ac855eag7b0bbe427ea20792@mail.gmail.com>
Message-ID: <e6511dbf0807021550n365bfb69u9b46f9b739aa7b5e@mail.gmail.com>

On Wed, Jul 2, 2008 at 1:57 PM, Josiah Carlson <josiah.carlson at gmail.com> wrote:
> On Wed, Jul 2, 2008 at 1:17 PM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
>> I just merged a good chunk of the trunk -> py3k queue, but there are
>> still some things to be dealt with:
>>
>> - bsddb It seesm bsddb still has yet to be ported to Py3k. See #2887.
>>
>> - The asyncore/asynchat patches. Josiah, can you do this?
>>
>> - The Mac 4-way arch build.
>>
>> - The bin/hex/oct float things. (These can just be blocked, right?)
>>
>> - SSL changes
>
> I will try with asyncore/asynchat, but I have no experience with py3k
> or the 2to3 converter.

I'm in the process of doing the conversion.  asyncore.py was no
problem, but asynchat.py relies heavily on the 2.x buffer() object
(specifically the slicing aspects thereof), which went away, to be
replaced by the seemingly incomplete memoryview object.  Are
memoryviews going to be gaining slicing ability (in the case of
1-dimensional memory views, which also have step forced to 1)?  Are we
just waiting for an implementation?  Or because of the ability to
offer a memoryview into just about any object now, "slicing" only some
objects (1-dimensional in particular) breaks consistency for all other
objects?

 - Josiah

From musiccomposition at gmail.com  Thu Jul  3 01:00:56 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 2 Jul 2008 18:00:56 -0500
Subject: [Python-3000] to be merged
In-Reply-To: <e6511dbf0807021550n365bfb69u9b46f9b739aa7b5e@mail.gmail.com>
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
	<e6511dbf0807021357p7ac855eag7b0bbe427ea20792@mail.gmail.com>
	<e6511dbf0807021550n365bfb69u9b46f9b739aa7b5e@mail.gmail.com>
Message-ID: <1afaf6160807021600u302abbddife6e3518a8321015@mail.gmail.com>

On Wed, Jul 2, 2008 at 5:50 PM, Josiah Carlson <josiah.carlson at gmail.com> wrote:
>
> I'm in the process of doing the conversion.  asyncore.py was no
> problem, but asynchat.py relies heavily on the 2.x buffer() object
> (specifically the slicing aspects thereof), which went away, to be
> replaced by the seemingly incomplete memoryview object.  Are
> memoryviews going to be gaining slicing ability (in the case of
> 1-dimensional memory views, which also have step forced to 1)?  Are we
> just waiting for an implementation?  Or because of the ability to
> offer a memoryview into just about any object now, "slicing" only some
> objects (1-dimensional in particular) breaks consistency for all other
> objects?

It's in the PEP [1]. However, we've had the unfortunate experience of
finding that much of the PEP hasn't been implemented.

[1] http://www.python.org/dev/peps/pep-3118/
>
>  - Josiah
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From musiccomposition at gmail.com  Thu Jul  3 01:06:17 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 2 Jul 2008 18:06:17 -0500
Subject: [Python-3000] to be merged
In-Reply-To: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
Message-ID: <1afaf6160807021606g5eb73ed3jadecb96c9787919@mail.gmail.com>

P.S. Can people please remember to block commits that shouldn't be
merged into 3.0? (Or even better, merge the ones you make that
should.) I feel rather nervous deciding whether something should be
merged or not when it's an edge case.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From janssen at parc.com  Thu Jul  3 01:58:22 2008
From: janssen at parc.com (Bill Janssen)
Date: Wed, 2 Jul 2008 16:58:22 PDT
Subject: [Python-3000] to be merged
In-Reply-To: <1afaf6160807021606g5eb73ed3jadecb96c9787919@mail.gmail.com> 
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
	<1afaf6160807021606g5eb73ed3jadecb96c9787919@mail.gmail.com>
Message-ID: <08Jul2.165826pdt."58698"@synergy1.parc.xerox.com>

> P.S. Can people please remember to block commits that shouldn't be
> merged into 3.0?

Can you remind me how to do that?  Thanks.

Bill

From musiccomposition at gmail.com  Thu Jul  3 02:03:01 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 2 Jul 2008 19:03:01 -0500
Subject: [Python-3000] to be merged
In-Reply-To: <-4523414105488443036@unknownmsgid>
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
	<1afaf6160807021606g5eb73ed3jadecb96c9787919@mail.gmail.com>
	<-4523414105488443036@unknownmsgid>
Message-ID: <1afaf6160807021703x944c6cao53eb1a84fe1b135d@mail.gmail.com>

On Wed, Jul 2, 2008 at 6:58 PM, Bill Janssen <janssen at parc.com> wrote:
>> P.S. Can people please remember to block commits that shouldn't be
>> merged into 3.0?
>
> Can you remind me how to do that?  Thanks.

Certainly! Just run "svnmerge block -r [a revision]" [1] in your py3k
working copy and then "svn ci -F svnmerge-commit-message.txt."

[1] http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge
>
> Bill
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From ncoghlan at gmail.com  Thu Jul  3 13:04:21 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 03 Jul 2008 21:04:21 +1000
Subject: [Python-3000] to be merged
In-Reply-To: <1afaf6160807021703x944c6cao53eb1a84fe1b135d@mail.gmail.com>
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>	<1afaf6160807021606g5eb73ed3jadecb96c9787919@mail.gmail.com>	<-4523414105488443036@unknownmsgid>
	<1afaf6160807021703x944c6cao53eb1a84fe1b135d@mail.gmail.com>
Message-ID: <486CB235.4020601@gmail.com>

Benjamin Peterson wrote:
> On Wed, Jul 2, 2008 at 6:58 PM, Bill Janssen <janssen at parc.com> wrote:
>>> P.S. Can people please remember to block commits that shouldn't be
>>> merged into 3.0?
>> Can you remind me how to do that?  Thanks.
> 
> Certainly! Just run "svnmerge block -r [a revision]" [1] in your py3k
> working copy and then "svn ci -F svnmerge-commit-message.txt."

This is also in the dev FAQ:
http://www.python.org/dev/faq/#how-do-i-block-a-specific-revision-from-being-merged-into-a-branch

Cheers,
Nick.

P.S. "apt-get install subversion-tools" will install svnmerge on an 
Ubuntu box.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From liori at exroot.org  Thu Jul  3 23:33:16 2008
From: liori at exroot.org (Tomasz Melcer)
Date: Thu, 03 Jul 2008 23:33:16 +0200
Subject: [Python-3000] __contains__ automatic coercion / unit conversion lib
Message-ID: <486D459C.5010507@exroot.org>

Hello,

Python 2.x automatically converts the return value of __contains__ into
bool. There was a thread here about changing this in py3k
(http://mail.python.org/pipermail/python-3000/2008-January/011780.html),
but I cannot find whether this change has been accepted. It isn't in
recent tarball. If it was, this could be used f.e. to make a unit
conversion library with a natural API:

#v+
>>> from units import *
>>> radius_of_earth = Kilometers(6600)
>>> radius_of_earth in Meters
6600000 Meters
#v-

I guess it is a bit late for making this change now. I don't know python
source code well enough to make a patch, but I hope maybe this will
motivate someone to do so. Here's example code:

#v+
class Unit(object):
    class __metaclass__(type):
       def __contains__(dest_unit, value):
          if isinstance(value, Unit):
             return dest_unit(unit_convert(value.__class__,Unit,value))
          else:
             return Unit(value)

    def __init__(self, value):
       self.value = value

    def __repr__(self):
       return "%d %s" % (self.value, self.__class__.__name__)

class Meters(Unit): pass
class Kilometers(Unit): pass
class Centimeters(Unit): pass

# read as "Kilometer is 1000 Meters"
conv = [
    [Kilometers, 1000.0, Meters],
    [Meters, 100.0, Centimeters]
]

class CannotConvert(Exception): pass

def unit_convert(funit, tunit, value):
    for f, m, t in conv:
        if (funit is f) and (tunit is t):
            return m*value
        elif (funit is t) and (tunit is f):
            return value/m
    raise CannotConvert
#v-

Greetings,
Tomasz Melcer

From greg at krypto.org  Sat Jul  5 21:00:35 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sat, 5 Jul 2008 12:00:35 -0700
Subject: [Python-3000] [Python-Dev] Second betas tomorrow
In-Reply-To: <D8E48735-E192-486B-A3D3-CD50C5F99DBF@python.org>
References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org>
	<ca471dc20807011325p693e47b1v104e134ec4d21c6f@mail.gmail.com>
	<A072A9E2-D3C9-4737-992A-3373FC8634A0@python.org>
	<9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1>
	<ca471dc20807011354v2499a923yd52da679c6c1cb73@mail.gmail.com>
	<8A43F3E7-BEE8-4656-833D-867328D16D52@python.org>
	<bbaeab100807011627p658d0aeax5cdcbdf0dec2c244@mail.gmail.com>
	<79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org>
	<1afaf6160807011942r738aae8u6c84aab03d463d76@mail.gmail.com>
	<D8E48735-E192-486B-A3D3-CD50C5F99DBF@python.org>
Message-ID: <52dc1c820807051200v9bb3673g967aa6d596520f6a@mail.gmail.com>

On Tue, Jul 1, 2008 at 8:29 PM, Barry Warsaw <barry at python.org> wrote:

> On Jul 1, 2008, at 10:42 PM, Benjamin Peterson wrote:
>
>> On Tue, Jul 1, 2008 at 8:44 PM, Barry Warsaw <barry at python.org> wrote:
>>
>>> On Jul 1, 2008, at 7:27 PM, Brett Cannon wrote:
>>>
>>>>
>>>> Is a Google Calendar kept by anyone that lists stuff like planned
>>>> release dates, etc.?
>>>>
>>>
>>>
>>> http://www.google.com/calendar/ical/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic.ics
>>>
>>
>> Can I get the non-iCal version?
>>
>
>
> http://www.google.com/calendar/feeds/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic
>
>
> http://www.google.com/calendar/embed?src=b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com&ctz=America/New_York
>
> - -Barry
>
>
And for anyone who hasn't already figured it out.. you can just add
b6v58qvojllt0i6ql654r1vh00 at group.calendar.google.com<http://www.google.com/calendar/embed?src=b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com&ctz=America/New_York>as
a friend in your existing google calendar to see the release schedule
calendar alongside your own.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080705/ed3611be/attachment.htm>

From collinw at gmail.com  Sun Jul  6 05:07:38 2008
From: collinw at gmail.com (Collin Winter)
Date: Sat, 5 Jul 2008 20:07:38 -0700
Subject: [Python-3000] Get rid of Py_FindMethod
In-Reply-To: <ca471dc20807011006o64e9a31fm78beadfa63e58342@mail.gmail.com>
References: <e27efe130807010537s6b3feaf4j8a2b1fcf70e8b016@mail.gmail.com>
	<ca471dc20807011006o64e9a31fm78beadfa63e58342@mail.gmail.com>
Message-ID: <43aa6ff70807052007g6ea3a182uf0e337cc70f31773@mail.gmail.com>

On Tue, Jul 1, 2008 at 10:06 AM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Jul 1, 2008 at 5:37 AM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
>> http://bugs.python.org/issue3247 complains that with python 3.0, dir()
>> of a SRE_Match object returns an empty list.
>>
>> This type has the particularity to not define a tp_methods; instead,
>> its tp_getattr slot calls Py_FindMethod(match_methods, self, name)
>> where "match_methods" is a PyMethodDef[] array that looks very very
>> similar to a typical tp_methods slot.
>>
>> Py_FindMethod has a trick: when the requested name is "__methods__",
>> it returns the names of the PyMethodDef items.
>>
>> __methods__ has disappeared with python 3.0, and indeed if I enable
>> the "-3" warning flag on python2.6,
>> dir() on a SRE_Match object raises two (!) warnings:
>> __main__:1: DeprecationWarning: __methods__ not supported in 3.x
>> __main__:1: DeprecationWarning: __members__ and __methods__ not supported in 3.x
>>
>> According to previous discussions:
>> http://mail.python.org/pipermail/python-3000/2007-July/008787.html
>> Py_FindMethod is not needed any more in modern modules, and should go away.
>> Note that PyMember_Get has already disappeared, because the few
>> modules using them were deleted...
>>
>> Is it still time for such a change after beta1?
>
> I'd say definitely. This just fell through the cracks.
>
>> There are ~30 occurrences of Py_FindMethod in the code base.
>> Most of the time, it is enough to remove the call, and set the
>> tp_methods members.
>
> Good!
>
>> Another thing: why was traceback.__dir__ added?
>> the current 3.0 produces:
>>>>> dir(b.__traceback__)
>> ['tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
>>
>> When I remove the __dir__ method, I get the special methods as well:
>>>>> dir(b.__traceback__)
>> ['__class__', '__delattr__', '__doc__', '__eq__', '__format__',
>> '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
>> '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
>> '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
>> '__subclasshook__', 'tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
>>
>> It's more verbose, but most types have the same list of special
>> members. I suggest to remove it, to enhance consistency (loosing some
>> 2.6 compatibility, but it's python3.0 after all)
>
> Can't tell you why -- looks odd to me too. Hopefully Collin Winter remembers.

My recollection is that this was done to preserve compatibility with
2.x, which has this behaviour; there were some tests that iterated the
list of members or something like that.

Collin

From josiah.carlson at gmail.com  Mon Jul  7 06:25:09 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Sun, 6 Jul 2008 21:25:09 -0700
Subject: [Python-3000] to be merged
In-Reply-To: <e6511dbf0807021550n365bfb69u9b46f9b739aa7b5e@mail.gmail.com>
References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com>
	<e6511dbf0807021357p7ac855eag7b0bbe427ea20792@mail.gmail.com>
	<e6511dbf0807021550n365bfb69u9b46f9b739aa7b5e@mail.gmail.com>
Message-ID: <e6511dbf0807062125m59c3657dhb7397dc59a2d67cd@mail.gmail.com>

On Wed, Jul 2, 2008 at 3:50 PM, Josiah Carlson <josiah.carlson at gmail.com> wrote:
> On Wed, Jul 2, 2008 at 1:57 PM, Josiah Carlson <josiah.carlson at gmail.com> wrote:
>> On Wed, Jul 2, 2008 at 1:17 PM, Benjamin Peterson
>> <musiccomposition at gmail.com> wrote:
>>> I just merged a good chunk of the trunk -> py3k queue, but there are
>>> still some things to be dealt with:
>>>
>>> - bsddb It seesm bsddb still has yet to be ported to Py3k. See #2887.
>>>
>>> - The asyncore/asynchat patches. Josiah, can you do this?
>>>
>>> - The Mac 4-way arch build.
>>>
>>> - The bin/hex/oct float things. (These can just be blocked, right?)
>>>
>>> - SSL changes
>>
>> I will try with asyncore/asynchat, but I have no experience with py3k
>> or the 2to3 converter.
>
> I'm in the process of doing the conversion.  asyncore.py was no
> problem, but asynchat.py relies heavily on the 2.x buffer() object
> (specifically the slicing aspects thereof), which went away, to be
> replaced by the seemingly incomplete memoryview object.  Are
> memoryviews going to be gaining slicing ability (in the case of
> 1-dimensional memory views, which also have step forced to 1)?  Are we
> just waiting for an implementation?  Or because of the ability to
> offer a memoryview into just about any object now, "slicing" only some
> objects (1-dimensional in particular) breaks consistency for all other
> objects?

See changelist 64764 that updates asyncore, asynchat, and smtpd (which
also required changes), their tests, and documentation.

 - Josiah

From carl at carlsensei.com  Wed Jul  9 16:49:50 2008
From: carl at carlsensei.com (Carl Johnson)
Date: Wed, 9 Jul 2008 23:49:50 +0900
Subject: [Python-3000] Is this a bug with list comprehensions or not?
Message-ID: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>

Python 3.0a5 (r30a5:62856, May 10 2008, 10:34:28)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> def f(x):
...  if x > 5: raise StopIteration
...
 >>> [x for x in range(100) if not f(x)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
  File "<stdin>", line 2, in f
StopIteration
 >>> list(x for x in range(100) if not f(x))
[0, 1, 2, 3, 4, 5]

Certainly, it's an inconsistency compared to generator expressions,  
but is it a bug? I know that Python 3000 is making it so that list  
comprehension variables don't leak anymore, so I take it that the goal  
is to have them be more similar to generator expressions than not.  
Then again, maybe there are good reasons for this behavior? My own  
feeling is that these two cases should behave the same way, but I  
could be wrong.

I hope this isn't an old issue, but I've been lurking for a few months  
and haven't heard any discussion of this.

-- Carl Johnson

From aahz at pythoncraft.com  Wed Jul  9 17:35:02 2008
From: aahz at pythoncraft.com (Aahz)
Date: Wed, 9 Jul 2008 08:35:02 -0700
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
Message-ID: <20080709153502.GA27153@panix.com>

On Wed, Jul 09, 2008, Carl Johnson wrote:
>
> Python 3.0a5 (r30a5:62856, May 10 2008, 10:34:28)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> def f(x):
> ...  if x > 5: raise StopIteration
> ...
> >>> [x for x in range(100) if not f(x)]
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "<stdin>", line 1, in <listcomp>
>  File "<stdin>", line 2, in f
> StopIteration
> >>> list(x for x in range(100) if not f(x))
> [0, 1, 2, 3, 4, 5]
> 
> Certainly, it's an inconsistency compared to generator expressions,  
> but is it a bug? 

Dunno whether it's a bug, but please file a bug report to track this
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha

From guido at python.org  Wed Jul  9 18:22:37 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 9 Jul 2008 09:22:37 -0700
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
Message-ID: <ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>

It's suspect, please file a bug. Thanks for noticing!

On Wed, Jul 9, 2008 at 7:49 AM, Carl Johnson <carl at carlsensei.com> wrote:
> Python 3.0a5 (r30a5:62856, May 10 2008, 10:34:28)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> def f(x):
> ...  if x > 5: raise StopIteration
> ...
>>>> [x for x in range(100) if not f(x)]
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "<stdin>", line 1, in <listcomp>
>  File "<stdin>", line 2, in f
> StopIteration
>>>> list(x for x in range(100) if not f(x))
> [0, 1, 2, 3, 4, 5]
>
> Certainly, it's an inconsistency compared to generator expressions, but is
> it a bug? I know that Python 3000 is making it so that list comprehension
> variables don't leak anymore, so I take it that the goal is to have them be
> more similar to generator expressions than not. Then again, maybe there are
> good reasons for this behavior? My own feeling is that these two cases
> should behave the same way, but I could be wrong.
>
> I hope this isn't an old issue, but I've been lurking for a few months and
> haven't heard any discussion of this.
>
> -- Carl Johnson
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From carl at carlsensei.com  Thu Jul 10 11:44:01 2008
From: carl at carlsensei.com (Carl Johnson)
Date: Thu, 10 Jul 2008 18:44:01 +0900
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
Message-ID: <C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>

Filed http://bugs.python.org/issue3331

I added this to the bottom of the report, but perhaps it should be a  
discussion topic, not a "bug" per se:

----

One might object that the behavior of the list comprehension is
identical to that of a for-loop:

     >>> r = []
     >>> for x in range(100):
     ...  if not f(x):
     ...   r.append(x)
     ...
     Traceback (most recent call last):
       File "<stdin>", line 2, in <module>
       File "<stdin>", line 2, in f
     StopIteration

However, it can be argued that in Python 3 list comprehensions should be
thought of as "syntatic sugar" for ``list(generator expression)`` not a
for-loop with an accumulator. (This seems to be the motivation for no
longer "leaking" variables from list comprehensions into their enclosing
namespace.)

One interesting question that this raises (for me at least) is whether
the for-loop should also behave like a generator expression. Of course,
the behavior of the generator expression can already be simulated by
writing:

     >>> r = []
     >>> for x in range(100):
     ...  try:
     ...   if f(x):
     ...    r.append(x)
     ...  except StopIteration:
     ...   break
     ...
     >>> r
     [0, 1, 2, 3, 4, 5]

This raises the question, do we need both a ``break`` statement and
``raise StopIteration``? Can the former just be made into syntatic sugar
for the later? Or is this the hobgoblin of a little mind?


From oren at hishome.net  Thu Jul 10 14:17:30 2008
From: oren at hishome.net (Oren Tirosh)
Date: Thu, 10 Jul 2008 15:17:30 +0300
Subject: [Python-3000] Get rid of Py_FindMethod
In-Reply-To: <ca471dc20807011006o64e9a31fm78beadfa63e58342@mail.gmail.com>
References: <e27efe130807010537s6b3feaf4j8a2b1fcf70e8b016@mail.gmail.com>
	<ca471dc20807011006o64e9a31fm78beadfa63e58342@mail.gmail.com>
Message-ID: <19fbc9880807100517w74108317o1b7b7858aa7291ca@mail.gmail.com>

The primary use of Py_FindMethod was to implement a tp_getattr slot
handler. Now that it has been removed, there is nothing remaining in
the py3k codebase that actually uses the tp_getattr slot!

It has been 12 years since tp_getattro was introduced. Is it time to
finally phase out tp_getattr?

Oren


On Tue, Jul 1, 2008 at 8:06 PM, Guido van Rossum <guido at python.org> wrote:
>
> On Tue, Jul 1, 2008 at 5:37 AM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> > http://bugs.python.org/issue3247 complains that with python 3.0, dir()
> > of a SRE_Match object returns an empty list.
> >
> > This type has the particularity to not define a tp_methods; instead,
> > its tp_getattr slot calls Py_FindMethod(match_methods, self, name)
> > where "match_methods" is a PyMethodDef[] array that looks very very
> > similar to a typical tp_methods slot.
> >
> > Py_FindMethod has a trick: when the requested name is "__methods__",
> > it returns the names of the PyMethodDef items.
> >
> > __methods__ has disappeared with python 3.0, and indeed if I enable
> > the "-3" warning flag on python2.6,
> > dir() on a SRE_Match object raises two (!) warnings:
> > __main__:1: DeprecationWarning: __methods__ not supported in 3.x
> > __main__:1: DeprecationWarning: __members__ and __methods__ not supported in 3.x
> >
> > According to previous discussions:
> > http://mail.python.org/pipermail/python-3000/2007-July/008787.html
> > Py_FindMethod is not needed any more in modern modules, and should go away.
> > Note that PyMember_Get has already disappeared, because the few
> > modules using them were deleted...
> >
> > Is it still time for such a change after beta1?
>
> I'd say definitely. This just fell through the cracks.
>
> > There are ~30 occurrences of Py_FindMethod in the code base.
> > Most of the time, it is enough to remove the call, and set the
> > tp_methods members.
>
> Good!
>
> > Another thing: why was traceback.__dir__ added?
> > the current 3.0 produces:
> >>>> dir(b.__traceback__)
> > ['tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
> >
> > When I remove the __dir__ method, I get the special methods as well:
> >>>> dir(b.__traceback__)
> > ['__class__', '__delattr__', '__doc__', '__eq__', '__format__',
> > '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
> > '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
> > '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
> > '__subclasshook__', 'tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
> >
> > It's more verbose, but most types have the same list of special
> > members. I suggest to remove it, to enhance consistency (loosing some
> > 2.6 compatibility, but it's python3.0 after all)
>
> Can't tell you why -- looks odd to me too. Hopefully Collin Winter remembers.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)

From solipsis at pitrou.net  Thu Jul 10 15:28:01 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 10 Jul 2008 13:28:01 +0000 (UTC)
Subject: [Python-3000] Is this a bug with list comprehensions or not?
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
Message-ID: <loom.20080710T130828-461@post.gmane.org>

Carl Johnson <carl <at> carlsensei.com> writes:
> 
> However, it can be argued that in Python 3 list comprehensions should be
> thought of as "syntatic sugar" for ``list(generator expression)`` not a
> for-loop with an accumulator. (This seems to be the motivation for no
> longer "leaking" variables from list comprehensions into their enclosing
> namespace.)

I don't know the exact history but I think leaking the iteration variable
didn't have any practical use and could be the possible cause of subtle bugs,
which is a sufficient reason for changing that behaviour. Consistency is an
added bonus :-)

> This raises the question, do we need both a ``break`` statement and
> ``raise StopIteration``? Can the former just be made into syntatic sugar
> for the later? Or is this the hobgoblin of a little mind?

I'd say the latter :-)

Also, I don't see where consistency is improved. IMO, StopIteration is meant to
be raised by the code which produces the iterator, not by the code consuming it
- and even less by third-party, non-iterator related code. Otherwise it's an
application bug.

That is, in your example:

 >>> def f(x):
...  if x > 5: raise StopIteration
...
 >>> list(x for x in range(100) if not f(x))
[0, 1, 2, 3, 4, 5]

f() certainly shouldn't raise a StopIteration. There's no reason for doing
that, other than taking dirty implementation shortcuts and ending up with
difficult to maintain code.

(if you want to stop an iterator based on some predicate you can use
itertools.takewhile())

Regards

Antoine.



From guido at python.org  Thu Jul 10 18:45:27 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 10 Jul 2008 09:45:27 -0700
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <loom.20080710T130828-461@post.gmane.org>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
Message-ID: <ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>

On Thu, Jul 10, 2008 at 6:28 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Carl Johnson <carl <at> carlsensei.com> writes:
>>
>> However, it can be argued that in Python 3 list comprehensions should be
>> thought of as "syntatic sugar" for ``list(generator expression)`` not a
>> for-loop with an accumulator. (This seems to be the motivation for no
>> longer "leaking" variables from list comprehensions into their enclosing
>> namespace.)
>
> I don't know the exact history but I think leaking the iteration variable
> didn't have any practical use and could be the possible cause of subtle bugs,
> which is a sufficient reason for changing that behaviour. Consistency is an
> added bonus :-)
>
>> This raises the question, do we need both a ``break`` statement and
>> ``raise StopIteration``? Can the former just be made into syntatic sugar
>> for the later? Or is this the hobgoblin of a little mind?
>
> I'd say the latter :-)
>
> Also, I don't see where consistency is improved. IMO, StopIteration is meant to
> be raised by the code which produces the iterator, not by the code consuming it
> - and even less by third-party, non-iterator related code. Otherwise it's an
> application bug.
>
> That is, in your example:
>
>  >>> def f(x):
> ...  if x > 5: raise StopIteration
> ...
>  >>> list(x for x in range(100) if not f(x))
> [0, 1, 2, 3, 4, 5]
>
> f() certainly shouldn't raise a StopIteration. There's no reason for doing
> that, other than taking dirty implementation shortcuts and ending up with
> difficult to maintain code.
>
> (if you want to stop an iterator based on some predicate you can use
> itertools.takewhile())

To be sure, IMO the generator expression is wrong in interpreting the
StopIteration exception! It should fail the same way the list
comprehension fails.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From tjreedy at udel.edu  Thu Jul 10 19:11:12 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 10 Jul 2008 13:11:12 -0400
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <loom.20080710T130828-461@post.gmane.org>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
Message-ID: <g55fre$fsf$1@ger.gmane.org>



Antoine Pitrou wrote:

 > Carl Johnson <carl <at> carlsensei.com> writes:
 >> This raises the question, do we need both a ``break`` statement and
 >> ``raise StopIteration``?
 >> Can the former just be made into syntatic sugar
 >> for the later? Or is this the hobgoblin of a little mind?

Yes, no, and ??.

One reason to use an iterator within a while loop instead of a for loop 
is to do something other than break when the iterator signals that it 
has nothing more.  Similarly, if one iterates through it1 with a for 
loop and uses it2.next() within the body, magically breaking when it2 
ends could also be the wrong thing.  In either case, 'continue' or 
something else might be the right thing.  One might be able to work 
around magical breaks with clever use of iterator-oriented built-ins and 
itertools, but such should not be required.


> Also, I don't see where consistency is improved. IMO, StopIteration is meant to
> be raised by the code which produces the iterator, not by the code consuming it
> - and even less by third-party, non-iterator related code. Otherwise it's an
> application bug.
> 
> That is, in your example:
> 
>  >>> def f(x):
> ...  if x > 5: raise StopIteration
> ...
>  >>> list(x for x in range(100) if not f(x))
> [0, 1, 2, 3, 4, 5]
> 
> f() certainly shouldn't raise a StopIteration. There's no reason for doing
> that, other than taking dirty implementation shortcuts and ending up with
> difficult to maintain code.

I had essentially the same thought about this.  As I understood it, the 
purpose of introducing a new built-in exception, StopIteration, along 
with the new iterator protocol, was to give iterators a unique signal to 
send to consumers that would not conflict with anything else then 
existing.  So it seems either a bug or abuse for non-iterators to hijack 
the signal.

Terry Jan Reedy



From greg.ewing at canterbury.ac.nz  Fri Jul 11 01:47:56 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 11 Jul 2008 11:47:56 +1200
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <loom.20080710T130828-461@post.gmane.org>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
Message-ID: <48769FAC.4030702@canterbury.ac.nz>

Antoine Pitrou wrote:

> That is, in your example:
> 
>  >>> def f(x):
> ...  if x > 5: raise StopIteration
> ...
>  >>> list(x for x in range(100) if not f(x))
> [0, 1, 2, 3, 4, 5]
> 
> f() certainly shouldn't raise a StopIteration. There's no reason for doing
> that, other than taking dirty implementation shortcuts and ending up with
> difficult to maintain code.

I'm inclined to agree. This code seems to be designed
to cause the LC to exit early, which IMO is an abuse
of LCs. If you need a loop that doesn't run to
completion, you should write it out as a for-loop.

So no, this is not a bug, since in well-designed code
the difference in behaviour shouldn't matter.

-- 
Greg

From python at rcn.com  Thu Jul 10 23:26:15 2008
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 11 Jul 2008 00:26:15 +0300
Subject: [Python-3000] Is this a bug with list comprehensions or not?
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com><ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com><C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com><loom.20080710T130828-461@post.gmane.org>
	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>
Message-ID: <CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>

From: "Guido van Rossum" <guido at python.org>
> To be sure, IMO the generator expression is wrong in interpreting the
> StopIteration exception! It should fail the same way the list
> comprehension fails.

When exercising 2-to-3 on Zodb at the EuroPython sprints, we also found another oddity.  This code works in 2.6 but fails in 3.0 (it 
looks for the free variable in the global scope instead of the enclosing local scope):

class A(object):
    v = 8
    x = [v for i in range(6)]



Raymond




From guido at python.org  Fri Jul 11 04:58:45 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 10 Jul 2008 19:58:45 -0700
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>
	<CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>
Message-ID: <ca471dc20807101958k35f40a24tb5cfb1b495af4ec4@mail.gmail.com>

On Thu, Jul 10, 2008 at 2:26 PM, Raymond Hettinger <python at rcn.com> wrote:
> When exercising 2-to-3 on Zodb at the EuroPython sprints, we also found
> another oddity.  This code works in 2.6 but fails in 3.0 (it looks for the
> free variable in the global scope instead of the enclosing local scope):
>
> class A(object):
>   v = 8
>   x = [v for i in range(6)]

This is in a sense not new, and I believe we decided not to do
anything about it. You can get the same error in 2.6 by using a genexp
instead of a listcomp, like this:

class A:
  v = 8
  x = list(v for i in range(6))

The new failure in 3.0 is a side effect of the translation (mostly) of
list comps into genexps. The underlying problem is that the genexp
creates a function scope, and function scopes don't have access to the
surrounding class body scope. (There's a really good but extremely
subtle reason for that.)

I think there are old threads about this.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From stefan_ml at behnel.de  Fri Jul 11 07:45:32 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 11 Jul 2008 07:45:32 +0200
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <48769FAC.4030702@canterbury.ac.nz>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>
	<48769FAC.4030702@canterbury.ac.nz>
Message-ID: <g56s1s$6g5$1@ger.gmane.org>

Greg Ewing wrote:
> Antoine Pitrou wrote:
> 
>> That is, in your example:
>>
>>  >>> def f(x):
>> ...  if x > 5: raise StopIteration
>> ...
>>  >>> list(x for x in range(100) if not f(x))
>> [0, 1, 2, 3, 4, 5]
>>
>> f() certainly shouldn't raise a StopIteration. There's no reason for
>> doing
>> that, other than taking dirty implementation shortcuts and ending up with
>> difficult to maintain code.
> 
> I'm inclined to agree. This code seems to be designed
> to cause the LC to exit early, which IMO is an abuse
> of LCs. If you need a loop that doesn't run to
> completion, you should write it out as a for-loop.
> 
> So no, this is not a bug, since in well-designed code
> the difference in behaviour shouldn't matter.

While I agree with this being bad design, I do think that the above is a bug.
It's a different thing if the iterable in the list comp/genexp raises a
StopIteration, or if the conditional does it. And not silently catching
anything raised by the latter sounds like the right thing to me.

Stefan


From python at rcn.com  Fri Jul 11 09:00:36 2008
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 11 Jul 2008 10:00:36 +0300
Subject: [Python-3000] Is this a bug with list comprehensions or not?
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>
	<CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>
	<ca471dc20807101958k35f40a24tb5cfb1b495af4ec4@mail.gmail.com>
Message-ID: <775965700EF44A1F967430F94451B273@RaymondLaptop1>

From: "Guido van Rossum" <guido at python.org>
> The new failure in 3.0 is a side effect of the translation (mostly) of
> list comps into genexps. The underlying problem is that the genexp
> creates a function scope, and function scopes don't have access to the
> surrounding class body scope. (There's a really good but extremely
> subtle reason for that.)

Would you be open to an alternate implementation for list/set/dict comps
that doesn't use a genexps?  That would solve the scope problem, 
the performance hit, and make tracing more straight-forward.

If you're open to it, I can see if the EuroPython sprinters can find an 
implementation closer to what we had before but using the compiler 
to create an invisible induction variable.

Not sure if the current implementation was really a winning trade. 
It may have been better to have the minor but easy to explain nuisance
of exposing the induction variable instead of having the harder-to-explain
subtleties associated with a slower underlying genexp.


Raymond

From ncoghlan at gmail.com  Fri Jul 11 12:16:06 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Jul 2008 20:16:06 +1000
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <775965700EF44A1F967430F94451B273@RaymondLaptop1>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>	<CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>	<ca471dc20807101958k35f40a24tb5cfb1b495af4ec4@mail.gmail.com>
	<775965700EF44A1F967430F94451B273@RaymondLaptop1>
Message-ID: <487732E6.6000408@gmail.com>

Raymond Hettinger wrote:
> Would you be open to an alternate implementation for list/set/dict comps
> that doesn't use a genexps?  That would solve the scope problem, the 
> performance hit, and make tracing more straight-forward.
> 
> If you're open to it, I can see if the EuroPython sprinters can find an 
> implementation closer to what we had before but using the compiler to 
> create an invisible induction variable.

Georg and I tried doing it that way and had major problems trying to get 
it to work - the hard part is that the body of the list comp (which may 
include nested list comps, lambda functions and generator expressions) 
needs to be able to see the iteration variables exactly as they are, but 
the surrounding code shouldn't be able to see them at all.

By leveraging off the genexp implementation, the scoping rules we want 
"just work": they are exactly the same as if the list comp was written 
using the equivalent generator expression. [1]

As for whether or not this is worth fixing, I think getting rid of the 
current subtle differences between the scoping rules for list 
comprehensions and generator expressions is a very worthwhile outcome, 
even at the possible performance cost.

For example, why should this work:

class A(object):
    v = 8
    x = [v for i in range(6)]

And these fail:

class A(object):
    v = 8
    x = list(v for i in range(6))

class A(object):
    v = 8
    x = tuple(v for i in range(6))

> Not sure if the current implementation was really a winning trade. It may have been better to have the minor but easy to explain nuisance
> of exposing the induction variable instead of having the harder-to-explain
> subtleties associated with a slower underlying genexp. 

Finding ways to speed up all generator expression invocations would 
strike me as a more worthwhile use of sprint time rather than creating 
complicated special cases in the compiler that would benefit only list 
and set comprehensions.

Cheers,
Nick.

[1] Guido's original OK of the class variable semantic change:
http://mail.python.org/pipermail/python-3000/2007-March/006077.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From python at rcn.com  Fri Jul 11 13:13:55 2008
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 11 Jul 2008 14:13:55 +0300
Subject: [Python-3000] Is this a bug with list comprehensions or not?
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>	<CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>	<ca471dc20807101958k35f40a24tb5cfb1b495af4ec4@mail.gmail.com>
	<775965700EF44A1F967430F94451B273@RaymondLaptop1>
	<487732E6.6000408@gmail.com>
Message-ID: <430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1>

From: "Nick Coghlan" <ncoghlan at gmail.com>
> Georg and I tried doing it that way and had major problems trying to get it to work - the hard part is that the body of the list 
> comp (which may include nested list comps, lambda functions and generator expressions) needs to be able to see the iteration 
> variables exactly as they are, but the surrounding code shouldn't be able to see them at all.

Did you try just saving and restoring the variable so that hiding wouldn't be necessary.

[for x in s]
   -->
   save(x) if it exists
   do the listcomp
   restore(x) if it was saved


> As for whether or not this is worth fixing, I think getting rid of the current subtle differences between the scoping rules for 
> list comprehensions and generator expressions is a very worthwhile outcome, even at the possible performance cost.

Difference of opinion here.
All 2-to-3 conversions don't automatically work
and when they don't, the reason is subtle, surprising, and weird.
With genexps, you expect function scoping rules to apply
(we explain genexps in terms of an equivalent generator).
With set/list/dict comps, that is unnecessary, slow, and unexpected
(we should be able to explain those in terms of an equivalent
in-lined for-loop with the loop variable restricted to the scope of the loop).
The current code is also surprising and difficult to work with when you run in through pdb.
Genexps are fundamentally different from the other three comps.
It's a bummer that the genexp implementation was borrowed
for this purpose.  IMO, what we had before was cleaner,
faster, obvious, and simple.

BTW, the performance cost isn't "possible", it's a guaranteed,
non-trivial regression.  It becomes a reason to not upgrade to 3.0.

All I'm asking Guido is whether he is open to an alternate patch
that doesn't create an inner function.


Raymond

P.S.  I know this group doesn't care about Psyco, but it was
nice that psyco could handle listcomps just like it could with
regular for-loops.  Turning it into a genexp stops psyco in its tracks.
Likewise, Cython won't be able to handle the semantics.
ISTM, we've made something hard out of something that
used to be simple.  What was gained?






>
> For example, why should this work:
>
> class A(object):
>    v = 8
>    x = [v for i in range(6)]
>
> And these fail:
>
> class A(object):
>    v = 8
>    x = list(v for i in range(6))
>
> class A(object):
>    v = 8
>    x = tuple(v for i in range(6))
>
>> Not sure if the current implementation was really a winning trade. It may have been better to have the minor but easy to explain 
>> nuisance
>> of exposing the induction variable instead of having the harder-to-explain
>> subtleties associated with a slower underlying genexp.
>
> Finding ways to speed up all generator expression invocations would strike me as a more worthwhile use of sprint time rather than 
> creating complicated special cases in the compiler that would benefit only list and set comprehensions.
>
> Cheers,
> Nick.
>
> [1] Guido's original OK of the class variable semantic change:
> http://mail.python.org/pipermail/python-3000/2007-March/006077.html
>
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> ---------------------------------------------------------------
>             http://www.boredomandlaziness.org 


From ncoghlan at gmail.com  Fri Jul 11 14:59:04 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Jul 2008 22:59:04 +1000
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>	<CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>	<ca471dc20807101958k35f40a24tb5cfb1b495af4ec4@mail.gmail.com>
	<775965700EF44A1F967430F94451B273@RaymondLaptop1>
	<487732E6.6000408@gmail.com>
	<430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1>
Message-ID: <48775918.8070105@gmail.com>

Raymond Hettinger wrote:
> From: "Nick Coghlan" <ncoghlan at gmail.com>
>> Georg and I tried doing it that way and had major problems trying to 
>> get it to work - the hard part is that the body of the list comp 
>> (which may include nested list comps, lambda functions and generator 
>> expressions) needs to be able to see the iteration variables exactly 
>> as they are, but the surrounding code shouldn't be able to see them at 
>> all.
> 
> Did you try just saving and restoring the variable so that hiding 
> wouldn't be necessary.
> 
> [for x in s]
>   -->
>   save(x) if it exists
>   do the listcomp
>   restore(x) if it was saved

And watch any generator expressions or lambda functions returned from 
the body of the list comprehension that reference the iteration variable 
fail inexplicably. Either we revert to 2.x behaviour and leak the 
iteration variable or we keep the extra scope that is added by the 
current implementation. Otherwise it just doesn't work.

> It's a bummer that the genexp implementation was borrowed
> for this purpose.  IMO, what we had before was cleaner,
> faster, obvious, and simple.

Then argue for a reversion to the 2.x behaviour: if we want to continue 
to explain list comprehensions in terms of an equivalent for loop, then 
we need to leak the iteration variables just like a for loop would.

A version which hid the iteration variable from the containing scope but 
didn't share the other scoping characteristics of generator expressions 
would just be strange.

> BTW, the performance cost isn't "possible", it's a guaranteed,
> non-trivial regression.  It becomes a reason to not upgrade to 3.0.

Time it and then say that. For module and class scope code, the 
performance gain from using function locals for the iteration variables 
inside the body of the list comp quickly outstrips the overhead from the 
single function call needed to invoke the implicitly created function.

For list comprehensions that are already at function scope (and hence 
already benefiting from the function local optimisations), I agree the 
new implementation is a guaranteed regression (the overhead of a single 
function call).

> All I'm asking Guido is whether he is open to an alternate patch
> that doesn't create an inner function.

Create the patch and have it pass all the current Py3k list 
comprehension tests and I'll support this. Without code in hand, I 
believe what you're suggesting simply isn't practical to implement (i,e, 
you would have to rewrite large chunks of the compiler to make it work 
properly).

> P.S.  I know this group doesn't care about Psyco, but it was
> nice that psyco could handle listcomps just like it could with
> regular for-loops.  Turning it into a genexp stops psyco in its tracks.
> Likewise, Cython won't be able to handle the semantics.
> ISTM, we've made something hard out of something that
> used to be simple.  What was gained?

Exactly what was asked for: the iteration variable doesn't leak into the 
surrounding scope anymore. The behaviour you're currently objecting to 
is the natural consequence of hiding list comprehension iteration 
variables from the local scope given Python's lexical scoping rules.

So if you want to get "simple" back, then I firmly believe you need to 
argue in favour of continuing to leak the iteration variables from list 
comprehensions.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From guido at python.org  Fri Jul 11 15:03:37 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 11 Jul 2008 06:03:37 -0700
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <775965700EF44A1F967430F94451B273@RaymondLaptop1>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>
	<CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>
	<ca471dc20807101958k35f40a24tb5cfb1b495af4ec4@mail.gmail.com>
	<775965700EF44A1F967430F94451B273@RaymondLaptop1>
Message-ID: <ca471dc20807110603w3410794fte84dee57ba3fefd2@mail.gmail.com>

On Fri, Jul 11, 2008 at 12:00 AM, Raymond Hettinger <python at rcn.com> wrote:
> From: "Guido van Rossum" <guido at python.org>
>>
>> The new failure in 3.0 is a side effect of the translation (mostly) of
>> list comps into genexps. The underlying problem is that the genexp
>> creates a function scope, and function scopes don't have access to the
>> surrounding class body scope. (There's a really good but extremely
>> subtle reason for that.)
>
> Would you be open to an alternate implementation for list/set/dict comps
> that doesn't use a genexps?  That would solve the scope problem, the
> performance hit, and make tracing more straight-forward.

Well, the problem is that we specifically decided that the difference
between listcomps and genexps is a source of problems and confusion,
and that consequently a listcomp [<genexp>] should be implemented as
completely equivalent to list(<genexp>).

I'd be happy to see a solution that implements genexps more
efficiently without changes in semantics (and then listcomps would
also benefit).

> If you're open to it, I can see if the EuroPython sprinters can find an
> implementation closer to what we had before but using the compiler to create
> an invisible induction variable.
>
> Not sure if the current implementation was really a winning trade. It may
> have been better to have the minor but easy to explain nuisance
> of exposing the induction variable instead of having the harder-to-explain
> subtleties associated with a slower underlying genexp.

No, based on feedback over the years the exposure of the induction
variable is a real problem that needs to be rooted out.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From rhamph at gmail.com  Fri Jul 11 21:23:29 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Fri, 11 Jul 2008 13:23:29 -0600
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <g56s1s$6g5$1@ger.gmane.org>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
	<48769FAC.4030702@canterbury.ac.nz> <g56s1s$6g5$1@ger.gmane.org>
Message-ID: <aac2c7cb0807111223x455da44cg5c0a145264af2d29@mail.gmail.com>

On Thu, Jul 10, 2008 at 11:45 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Greg Ewing wrote:
>> Antoine Pitrou wrote:
>>
>>> That is, in your example:
>>>
>>>  >>> def f(x):
>>> ...  if x > 5: raise StopIteration
>>> ...
>>>  >>> list(x for x in range(100) if not f(x))
>>> [0, 1, 2, 3, 4, 5]
>>>
>>> f() certainly shouldn't raise a StopIteration. There's no reason for
>>> doing
>>> that, other than taking dirty implementation shortcuts and ending up with
>>> difficult to maintain code.
>>
>> I'm inclined to agree. This code seems to be designed
>> to cause the LC to exit early, which IMO is an abuse
>> of LCs. If you need a loop that doesn't run to
>> completion, you should write it out as a for-loop.
>>
>> So no, this is not a bug, since in well-designed code
>> the difference in behaviour shouldn't matter.
>
> While I agree with this being bad design, I do think that the above is a bug.
> It's a different thing if the iterable in the list comp/genexp raises a
> StopIteration, or if the conditional does it. And not silently catching
> anything raised by the latter sounds like the right thing to me.

Since all exceptions from a genexp go up through .next(), you can't
distinguish a proper StopIteration from an improper StopIteration.
However, since the genexp considers all improper ones to be in error,
it could wrap them with a RuntimeError and pass it through .next()
instead.

Once genexps are fixed to do that then there's no reason not to make
listcomps match, which seems to be a goal here.


-- 
Adam Olsen, aka Rhamphoryncus

From greg.ewing at canterbury.ac.nz  Sat Jul 12 02:11:02 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 12 Jul 2008 12:11:02 +1200
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <g56s1s$6g5$1@ger.gmane.org>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
	<48769FAC.4030702@canterbury.ac.nz> <g56s1s$6g5$1@ger.gmane.org>
Message-ID: <4877F696.1000405@canterbury.ac.nz>

Stefan Behnel wrote:

> While I agree with this being bad design, I do think that the above is a bug.
> It's a different thing if the iterable in the list comp/genexp raises a
> StopIteration, or if the conditional does it. And not silently catching
> anything raised by the latter sounds like the right thing to me.

 From some experiments I just did using bare genexps and calling
next() on them, I don't think anything is being silently caught
in the genexp. What's happening is that the surrounding list()
constructor is performing another level of iteration over the
results of the genexp, and *that* is what's being stopped by
the StopIteration.

I don't see how this can be fixed, because there's no way for
the list() constructor to know where the StopIteration is coming
from.

Or maybe I misunderstand what you think the resolution of this
should be. What behaviour do you want to see in this situation?

-- 
Greg

From ncoghlan at gmail.com  Sat Jul 12 02:43:03 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Jul 2008 10:43:03 +1000
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>	<CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>	<ca471dc20807101958k35f40a24tb5cfb1b495af4ec4@mail.gmail.com>
	<775965700EF44A1F967430F94451B273@RaymondLaptop1>
	<487732E6.6000408@gmail.com>
	<430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1>
Message-ID: <4877FE17.4090502@gmail.com>

Raymond Hettinger wrote:
> From: "Nick Coghlan" <ncoghlan at gmail.com>
>> Georg and I tried doing it that way and had major problems trying to 
>> get it to work - the hard part is that the body of the list comp 
>> (which may include nested list comps, lambda functions and generator 
>> expressions) needs to be able to see the iteration variables exactly 
>> as they are, but the surrounding code shouldn't be able to see them at 
>> all.
> 
> Did you try just saving and restoring the variable so that hiding 
> wouldn't be necessary.
> 
> [for x in s]
>   -->
>   save(x) if it exists
>   do the listcomp
>   restore(x) if it was saved
> 
> 
>> As for whether or not this is worth fixing, I think getting rid of the 
>> current subtle differences between the scoping rules for list 
>> comprehensions and generator expressions is a very worthwhile outcome, 
>> even at the possible performance cost.
> 
> Difference of opinion here.
> All 2-to-3 conversions don't automatically work
> and when they don't, the reason is subtle, surprising, and weird.

2to3 should be able to detect and warn about the cases which don't work 
though (specifically, list comprehensions at module or class scope which 
refer to local variables somewhere other than in the outermost iterable 
expression). A patch to add such a warning would be very welcome.

There's nothing it can do about code which deletes the no longer leaked 
local variable, but that failure isn't subtle (and is also fairly easily 
fixed by changing the code to "var = None; del var").

> With genexps, you expect function scoping rules to apply
> (we explain genexps in terms of an equivalent generator).
> With set/list/dict comps, that is unnecessary, slow, and unexpected

I should probably add in to this discussion what the Py3k expansions of 
list, set and dict comprehensions actually *are* (they don't implicitly 
build genexps because that would be stupid and incredibly slow, but they 
do each build a single implicit function in order to get the scoping 
rules right):

 >>> import dis
 >>> def f():
...     return [x for x in range(10)]
...
 >>> dis.dis(f)
   2           0 LOAD_CONST               1 (<code object <listcomp> at 
0xb7c41260, file "<stdin>", line 2>)
               3 MAKE_FUNCTION            0
               6 LOAD_GLOBAL              0 (range)
               9 LOAD_CONST               2 (10)
              12 CALL_FUNCTION            1
              15 GET_ITER
              16 CALL_FUNCTION            1
              19 RETURN_VALUE
 >>> dis.dis(f.__code__.co_consts[1])
   2           0 BUILD_LIST               0
               3 DUP_TOP
               4 STORE_FAST               1 (_[1])
               7 LOAD_FAST                0 (.0)
         >>   10 FOR_ITER                13 (to 26)
              13 STORE_FAST               2 (x)
              16 LOAD_FAST                1 (_[1])
              19 LOAD_FAST                2 (x)
              22 LIST_APPEND
              23 JUMP_ABSOLUTE           10
         >>   26 RETURN_VALUE

So [x for x in range(10)] is shorthand for:

   def _f(itr):
       _[1] = []
       for x in itr:
           _[1].append(x)
       return _[1]
   expr_result = _f(range(10))

{x for x in range(10)} is shorthand for:

   def _f(itr):
       _[1] = set()
       for x in itr:
           _[1].add(x)
       return _[1]
   expr_result = _f(range(10))

And {x:x*x for x in range(10)} is shorthand for:

   def _f(itr):
       _[1] = {}
       for x in itr:
           _[1][x] = x*x
       return _[1]
   expr_result = _f(range(10))

While (x for x in range(10)) continues to be shorthand for:

   def _g(itr):
       for x in itr:
         yield x
   expr_result = _g(range(10))

It all looks simple, consistent and pretty straightforward to me. If pdb 
doesn't understand it, then it may be a good idea for someone to teach 
pdb what a disassembled comprehension looks like in Py3k.

Those expansions should also make it clear why this change actually 
results in a speed increase of module and class level list 
comprehensions above a certain size - the iteration variables become 
function locals, so they benefit from function local speedups. The exact 
point where the speedup from that is greater than the cost of a single 
function call will vary based on the complexity of the body of the list 
comprehension (most notable the number of times the iteration variables 
are referred to).

$ ./python -m timeit "exec('[x*x for x in range(100)]')"
10000 loops, best of 3: 125 usec per loop
$ python -m timeit "exec '[x*x for x in range(100)]'"
10000 loops, best of 3: 121 usec per loop
$ ./python -m timeit "exec('[x*x for x in range(1000)]')"
1000 loops, best of 3: 418 usec per loop
$ python -m timeit "exec '[x*x for x in range(1000)]'"
1000 loops, best of 3: 723 usec per loop

(exec is used in the above examples because the timeit module otherwise 
runs all supplied code in a function scope, so the speedup in Py3k list 
comprehensions isn't visible. The version of Python in the local 
directory is a fairly up to date build from the Py3k branch, the system 
Python is 2.5.1)

 > (we should be able to explain those in terms of an equivalent
 > in-lined for-loop with the loop variable restricted to the scope of
 > the loop).

That only sounds reasonable until you try to get the following two 
pieces of code to produce the same answer (example lifted from 
test_listcomps.py):

def test_func_listcomp():
     items = [(lambda: i) for i in range(5)]
     i = 20
     return [x() for x in items]

def test_func_genexp():
     items = list((lambda: i) for i in range(5))
     i = 20
     return [x() for x in items]

In current Py3k, they do produce the same answer ([4]*5) and in current 
2.x they produce different, but sensible answers ([20]*5 for the list 
comprehension, [4]*5 for the generator expression).

With the "just hide the iteration variable" approach it is highly 
unclear what the list comprehension version should produce.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Sat Jul 12 02:50:59 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Jul 2008 10:50:59 +1000
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
Message-ID: <4877FFF3.5090900@gmail.com>

Carl Johnson wrote:
> Certainly, it's an inconsistency compared to generator expressions, but 
> is it a bug? I know that Python 3000 is making it so that list 
> comprehension variables don't leak anymore, so I take it that the goal 
> is to have them be more similar to generator expressions than not. Then 
> again, maybe there are good reasons for this behavior? My own feeling is 
> that these two cases should behave the same way, but I could be wrong.

Comprehensions and generator expressions in Py3k are more similar than 
they are in 2.x, but they still aren't identical.

[x for x in range(10) if f(x)] is shorthand for:

   def _f(itr):
       _[1] = []
       for x in itr:
           if f(x):
               _[1].append(x)
       return _[1]
   expr_result = _f(range(10))

While (x for x in range(10) if f(x)) is shorthand for:

   def _g(itr):
       for x in itr:
           if f(x):
               yield x
   expr_result = _g(range(10))

 From those expansions, I think it's pretty clear that the implicit 
generator function in the second case is going to swallow the 
StopIteration and treat it as the end of the iteration process, but no 
such thing is going to happen with the implicit standard function in the 
list comprehension case.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From rhamph at gmail.com  Sat Jul 12 02:59:47 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Fri, 11 Jul 2008 18:59:47 -0600
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <4877F696.1000405@canterbury.ac.nz>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
	<48769FAC.4030702@canterbury.ac.nz> <g56s1s$6g5$1@ger.gmane.org>
	<4877F696.1000405@canterbury.ac.nz>
Message-ID: <aac2c7cb0807111759y42a5556g8265ea46359ba85f@mail.gmail.com>

On Fri, Jul 11, 2008 at 6:11 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Stefan Behnel wrote:
>
>> While I agree with this being bad design, I do think that the above is a
>> bug.
>> It's a different thing if the iterable in the list comp/genexp raises a
>> StopIteration, or if the conditional does it. And not silently catching
>> anything raised by the latter sounds like the right thing to me.
>
> From some experiments I just did using bare genexps and calling
> next() on them, I don't think anything is being silently caught
> in the genexp. What's happening is that the surrounding list()
> constructor is performing another level of iteration over the
> results of the genexp, and *that* is what's being stopped by
> the StopIteration.
>
> I don't see how this can be fixed, because there's no way for
> the list() constructor to know where the StopIteration is coming
> from.

It can be fixed in the genexp by declaring it erroneous and raising a
RuntimeError when encountered.  The list() constructor will see the
RuntimeError instead, which will get propagated properly.


-- 
Adam Olsen, aka Rhamphoryncus

From greg.ewing at canterbury.ac.nz  Sat Jul 12 03:10:49 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 12 Jul 2008 13:10:49 +1200
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <aac2c7cb0807111223x455da44cg5c0a145264af2d29@mail.gmail.com>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
	<48769FAC.4030702@canterbury.ac.nz> <g56s1s$6g5$1@ger.gmane.org>
	<aac2c7cb0807111223x455da44cg5c0a145264af2d29@mail.gmail.com>
Message-ID: <48780499.2060800@canterbury.ac.nz>

Adam Olsen wrote:
> However, since the genexp considers all improper ones to be in error,
> it could wrap them with a RuntimeError and pass it through .next()
> instead.

Would you do that only for genexps, or for generators
in general?

The current behaviour seems to be that if you explicitly
raise StopIteration in a generator, the generator then
considers itself to be exhausted (i.e. all subsequent
calls to next() raise StopIteration as well).

Is that behaviour deliberate? If so, do the reasons for
it also apply to genexps?

-- 
Greg

From rhamph at gmail.com  Sat Jul 12 05:02:11 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Fri, 11 Jul 2008 21:02:11 -0600
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <48780499.2060800@canterbury.ac.nz>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
	<48769FAC.4030702@canterbury.ac.nz> <g56s1s$6g5$1@ger.gmane.org>
	<aac2c7cb0807111223x455da44cg5c0a145264af2d29@mail.gmail.com>
	<48780499.2060800@canterbury.ac.nz>
Message-ID: <aac2c7cb0807112002g30f7a66cm2abf560066b03ea@mail.gmail.com>

On Fri, Jul 11, 2008 at 7:10 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Adam Olsen wrote:
>>
>> However, since the genexp considers all improper ones to be in error,
>> it could wrap them with a RuntimeError and pass it through .next()
>> instead.
>
> Would you do that only for genexps, or for generators
> in general?
>
> The current behaviour seems to be that if you explicitly
> raise StopIteration in a generator, the generator then
> considers itself to be exhausted (i.e. all subsequent
> calls to next() raise StopIteration as well).
>
> Is that behaviour deliberate? If so, do the reasons for
> it also apply to genexps?

My intent was to only do so for genexps - the behaviour there seems
accidental, has no use case, and shouldn't have many people dependent
on it.

Although, upon rereading PEP 255 it seems that despite being
documented, the behaviour of raising StopIteration is an accident
there too.  "return" doesn't use it and no use case is given.  Since
the current behaviour is confusing, I would like to see it changed
here too.  Might need to be a warning first though.


-- 
Adam Olsen, aka Rhamphoryncus

From stefan_ml at behnel.de  Sat Jul 12 05:59:07 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 12 Jul 2008 05:59:07 +0200
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <aac2c7cb0807111759y42a5556g8265ea46359ba85f@mail.gmail.com>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>	<48769FAC.4030702@canterbury.ac.nz>
	<g56s1s$6g5$1@ger.gmane.org>	<4877F696.1000405@canterbury.ac.nz>
	<aac2c7cb0807111759y42a5556g8265ea46359ba85f@mail.gmail.com>
Message-ID: <g59a6b$f3i$1@ger.gmane.org>

Adam Olsen wrote:
> On Fri, Jul 11, 2008 at 6:11 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Stefan Behnel wrote:
>>
>>> While I agree with this being bad design, I do think that the above is a
>>> bug.
>>> It's a different thing if the iterable in the list comp/genexp raises a
>>> StopIteration, or if the conditional does it. And not silently catching
>>> anything raised by the latter sounds like the right thing to me.
>> From some experiments I just did using bare genexps and calling
>> next() on them, I don't think anything is being silently caught
>> in the genexp. What's happening is that the surrounding list()
>> constructor is performing another level of iteration over the
>> results of the genexp, and *that* is what's being stopped by
>> the StopIteration.
>>
>> I don't see how this can be fixed, because there's no way for
>> the list() constructor to know where the StopIteration is coming
>> from.

That makes sense. In that case, I consider the genexp behaviour correct, as it
just passes on the raised exception, without caring about its type.


> It can be fixed in the genexp by declaring it erroneous and raising a
> RuntimeError when encountered.  The list() constructor will see the
> RuntimeError instead, which will get propagated properly.

I think this kind of special casing would make the interface worse than it
currently is. If this is the only way to work around weird code, I'd rather
let people raise plain StopIterations if they think they have to, without
caring about it any further in the genexp implementation.

Stefan


From tjreedy at udel.edu  Sat Jul 12 06:09:19 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Jul 2008 00:09:19 -0400
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <4877FFF3.5090900@gmail.com>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<4877FFF3.5090900@gmail.com>
Message-ID: <g59apd$g9b$1@ger.gmane.org>



Nick Coghlan wrote:
> Carl Johnson wrote:
>> Certainly, it's an inconsistency compared to generator expressions, 
>> but is it a bug? I know that Python 3000 is making it so that list 
>> comprehension variables don't leak anymore, so I take it that the goal 
>> is to have them be more similar to generator expressions than not. 
>> Then again, maybe there are good reasons for this behavior? My own 
>> feeling is that these two cases should behave the same way, but I 
>> could be wrong.
> 
> Comprehensions and generator expressions in Py3k are more similar than 
> they are in 2.x, but they still aren't identical.
> 
> [x for x in range(10) if f(x)] is shorthand for:
> 
>   def _f(itr):
>       _[1] = []
>       for x in itr:
>           if f(x):
>               _[1].append(x)
>       return _[1]
>   expr_result = _f(range(10))
> 
> While (x for x in range(10) if f(x)) is shorthand for:
> 
>   def _g(itr):
>       for x in itr:
>           if f(x):
>               yield x
>   expr_result = _g(range(10))
> 
>  From those expansions, I think it's pretty clear that the implicit 
> generator function in the second case is going to swallow the 
> StopIteration and treat it as the end of the iteration process, but no 
> such thing is going to happen with the implicit standard function in the 
> list comprehension case.

The idea I had, and which is what I believe Adam Olsen posted, is to 
augment the genexp to
    def _g(itr):
      try:
        for x in itr:
            if f(x):
                yield x
      except StopIteration: # possibly add 'as si'
        raise RuntimeError(<msg>) # <msg> might incorporate si msg

To me, it is more important that list(genexp) == corresponding_listcomp 
than that the definition of genexp be minimal.

tjr


From tjreedy at udel.edu  Sat Jul 12 06:29:36 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 12 Jul 2008 00:29:36 -0400
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <48780499.2060800@canterbury.ac.nz>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>	<48769FAC.4030702@canterbury.ac.nz>
	<g56s1s$6g5$1@ger.gmane.org>	<aac2c7cb0807111223x455da44cg5c0a145264af2d29@mail.gmail.com>
	<48780499.2060800@canterbury.ac.nz>
Message-ID: <g59bve$i4k$1@ger.gmane.org>



Greg Ewing wrote:
> Adam Olsen wrote:
>> However, since the genexp considers all improper ones to be in error,
>> it could wrap them with a RuntimeError and pass it through .next()
>> instead.
> 
> Would you do that only for genexps, or for generators
> in general?

For me, the former.  For generators in general, it seems too magical. 
Anyone who writes a generator function that calls an unknown function as 
input and who worries about getting a spurious StopIteration, can choose 
to wrap with try/except in the same way as genexps.  And leaving the 
choice explicit means that it would be an explicit part of the 
definition of genexps.

> The current behaviour seems to be that if you explicitly
> raise StopIteration in a generator, the generator then
> considers itself to be exhausted (i.e. all subsequent
> calls to next() raise StopIteration as well).
> 
> Is that behaviour deliberate? If so, do the reasons for
> it also apply to genexps?
> 


From stefan_ml at behnel.de  Sat Jul 12 06:37:29 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 12 Jul 2008 06:37:29 +0200
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>	<CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>	<ca471dc20807101958k35f40a24tb5cfb1b495af4ec4@mail.gmail.com>	<775965700EF44A1F967430F94451B273@RaymondLaptop1>	<487732E6.6000408@gmail.com>
	<430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1>
Message-ID: <g59cea$j90$1@ger.gmane.org>

Raymond Hettinger wrote:
> I know this group doesn't care about Psyco, but it was
> nice that psyco could handle listcomps just like it could with
> regular for-loops.  Turning it into a genexp stops psyco in its tracks.
> Likewise, Cython won't be able to handle the semantics.

Regarding Cython, I expect that we will be able to implement this pretty soon,
by translating the generator expression into an iterable extension class with
local variables.

However, such an approach will obviously be a lot slower than a plain embedded
C loop for literal list/tuple/set comprehension (as we currently generate for
list comprehensions). So a better approach might be to actually apply a
separate scoping rule to the iteration variable, such as renaming it into
something that just can't be retrieved from the outside world. That way, it
would still be available to everything inside the comprehension, but it can't
leak anymore.

The only semantic difference I see with this is:

    >>> def test():
    ...     return [locals()['x'] for x in range(10)]
    ...
    >>> test()
    [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

This actually works in Py3k, although I wonder if it really should work...

Stefan


From ncoghlan at gmail.com  Sat Jul 12 11:06:41 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Jul 2008 19:06:41 +1000
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <g59cea$j90$1@ger.gmane.org>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>	<ca471dc20807100945p50c7c66al6a0bec3d510e79dd@mail.gmail.com>	<CFFCFDFFF0484B10B72DE96E9FED9F91@RaymondLaptop1>	<ca471dc20807101958k35f40a24tb5cfb1b495af4ec4@mail.gmail.com>	<775965700EF44A1F967430F94451B273@RaymondLaptop1>	<487732E6.6000408@gmail.com>	<430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1>
	<g59cea$j90$1@ger.gmane.org>
Message-ID: <48787421.70900@gmail.com>

Stefan Behnel wrote:
> Raymond Hettinger wrote:
>> I know this group doesn't care about Psyco, but it was
>> nice that psyco could handle listcomps just like it could with
>> regular for-loops.  Turning it into a genexp stops psyco in its tracks.

List/set/dict comprehensions in Py3k now have the same lexical scoping 
behaviour as generator expressions, but they do NOT create or execute 
any generators. They create a nested function to do the accumulation, 
call it, then use the return value from the function call as the result 
of the expression. While I've never used psyco myself, I'd be fairly 
surprised if some simple nested functions caused it any serious problems.

I apologise for not correcting that particular misapprehension earlier 
in the thread, but I haven't really thought about any of this for over a 
year so it has taken me a while to recall the details of the implementation.

>> Likewise, Cython won't be able to handle the semantics.
> 
> Regarding Cython, I expect that we will be able to implement this pretty soon,
> by translating the generator expression into an iterable extension class with
> local variables.
> 
> However, such an approach will obviously be a lot slower than a plain embedded
> C loop for literal list/tuple/set comprehension (as we currently generate for
> list comprehensions).

Comprehensions in Py3k are still just a simple accumulation loop at the 
Python level - they merely execute inside their own function scope now, 
rather than executing in the containing scope.

> So a better approach might be to actually apply a
> separate scoping rule to the iteration variable, such as renaming it into
> something that just can't be retrieved from the outside world. That way, it
> would still be available to everything inside the comprehension, but it can't
> leak anymore.

Until someone comes up with a mechanism other than creating an implicit 
function that allows closures that reference the iteration variables to 
continue to work, people are just retreading ground that we went over 
more than a year ago when this change was first implemented.

People are welcome to try of course, but please don't make the mistake 
of thinking that it will be easy or that we added the implicit function 
scopes just because we felt like it - they were added because they were 
the simplest and cleanest way we could find to allow closures in the 
body of the list comprehension to continue to work correctly while still 
hiding the iteration variables from the containing scope.

The additional overhead imposed by the Py3k approach relative to the 2.x 
approach is one function call plus the cost of constructing the function 
object. A list comprehension is still far faster than the equivalent 
generator expression:

$ ./python -m timeit "list; [x for x in [1]]"
1000000 loops, best of 3: 1.81 usec per loop
$ ./python -m timeit "list(x for x in [1])"
100000 loops, best of 3: 4.85 usec per loop

In addition, as I've noted elsewhere in this thread, the function 
creation and call overhead can be counterbalanced in module and class 
level code by the fact that the body of the comprehension will now 
benefit from the optimisations that are used for function local variables.

Cheers,
Nick.

P.S. For interest, I ran the above examples a few times using the other 
versions of Python I have on this machine. The results below were fairly 
typical of what I saw:

Python 2.5.1 (system python):
$ python -m timeit "list; [x for x in [1]]"
1000000 loops, best of 3: 1.11 usec per loop
$ python -m timeit "list(x for x in [1])"
100000 loops, best of 3: 5.91 usec per loop

Python 2.6b1+ (local build):
$ ./python -m timeit "list; [x for x in [1]]"
1000000 loops, best of 3: 1.1 usec per loop
$ ./python -m timeit "list(x for x in [1])"
100000 loops, best of 3: 4.32 usec per loop

(Interestingly, the Py3k genexps are currently coming up as consistently 
slower than their 2.6 counterparts for me. I'm not sure what could be 
causing that)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From carlmj at hawaii.edu  Wed Jul  9 16:46:18 2008
From: carlmj at hawaii.edu (Carl Johnson)
Date: Wed, 9 Jul 2008 23:46:18 +0900
Subject: [Python-3000] Is this a bug with list comprehensions or not?
Message-ID: <FFB3E05E-46F3-4EB7-A231-C5164D68E03F@hawaii.edu>

Python 3.0a5 (r30a5:62856, May 10 2008, 10:34:28)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> def f(x):
...  if x > 5: raise StopIteration
...
 >>> [x for x in range(100) if not f(x)]
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 1, in <listcomp>
   File "<stdin>", line 2, in f
StopIteration
 >>> list(x for x in range(100) if not f(x))
[0, 1, 2, 3, 4, 5]

Certainly, it's an inconsistency compared to generator expressions,  
but is it a bug? I know that Python 3000 is making it so that list  
comprehension variables don't leak anymore, so I take it that the goal  
is to have them be more similar to generator expressions than not.  
Then again, maybe there are good reasons for this behavior? My own  
feeling is that these two cases should behave the same way, but I  
could be wrong.

I hope this isn't an old issue, but I've been lurking for a few months  
and haven't heard any discussion of this.

-- Carl Johnson

From greg.ewing at canterbury.ac.nz  Sun Jul 13 01:52:54 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 13 Jul 2008 11:52:54 +1200
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <g59apd$g9b$1@ger.gmane.org>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<4877FFF3.5090900@gmail.com> <g59apd$g9b$1@ger.gmane.org>
Message-ID: <487943D6.1060203@canterbury.ac.nz>

Terry Reedy wrote:

> To me, it is more important that list(genexp) == corresponding_listcomp 
> than that the definition of genexp be minimal.

Then listcomps would also have to catch StopIterations
and transmute them correspondingly.

This seems like a lot of trouble to go to in order to
fix a rather obscure problem. Is it really a serious
enough problem in practice? Anyone have any real-life
stories about this?

-- 
Greg

From brett at python.org  Sun Jul 13 03:36:53 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Jul 2008 18:36:53 -0700
Subject: [Python-3000] Remove sunaudio?
Message-ID: <bbaeab100807121836u16881a2ft212b72231ab49891@mail.gmail.com>

I just noticed that sunaudio was never broken out as a separate module
to remove in PEP 3108. It is mentioned in the rationale of audiodev to
remove if audiodev itself is taken out.

I assume no one objects to sunaudio's removal, but I just wanted to
double-check as it was not explicitly made its own list item in the
PEP.

-Brett

From solipsis at pitrou.net  Sun Jul 13 14:37:50 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 13 Jul 2008 12:37:50 +0000 (UTC)
Subject: [Python-3000] Is this a bug with list comprehensions or not?
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<4877FFF3.5090900@gmail.com> <g59apd$g9b$1@ger.gmane.org>
	<487943D6.1060203@canterbury.ac.nz>
Message-ID: <loom.20080713T123323-273@post.gmane.org>

Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:
> 
> This seems like a lot of trouble to go to in order to
> fix a rather obscure problem. Is it really a serious
> enough problem in practice? Anyone have any real-life
> stories about this?

Agreed. I think it is ok for some behaviours to be unspecified and seemingly
"inconsistent" if one goes beyond the prescripted use of certain constructs.
One classical example is:

>>> 1+1 is 1+1
True
>>> 1000+1000 is 1000+1000
False

Solving the problem at hand would require carefully flagging StopIteration
exceptions to know whether they were raised in an iterator implementation
context or not, or even downright forbidding raising them in a non-iterator
implementation context. It's a lot of complication for such a corner case.



From ncoghlan at gmail.com  Sun Jul 13 14:56:21 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 13 Jul 2008 22:56:21 +1000
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <loom.20080713T123323-273@post.gmane.org>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<4877FFF3.5090900@gmail.com>
	<g59apd$g9b$1@ger.gmane.org>	<487943D6.1060203@canterbury.ac.nz>
	<loom.20080713T123323-273@post.gmane.org>
Message-ID: <4879FB75.9090201@gmail.com>

Antoine Pitrou wrote:
> Solving the problem at hand would require carefully flagging StopIteration
> exceptions to know whether they were raised in an iterator implementation
> context or not, or even downright forbidding raising them in a non-iterator
> implementation context. It's a lot of complication for such a corner case.

Particularly when the current behaviour is trivial to explain given the 
expanded forms of the two expressions as nested functions.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From solipsis at pitrou.net  Sun Jul 13 22:56:33 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 13 Jul 2008 20:56:33 +0000 (UTC)
Subject: [Python-3000] PEP 3134 exception reporting
Message-ID: <loom.20080713T205145-628@post.gmane.org>


I would like to say that the patch is ready for review here:
http://codereview.appspot.com/2448

And the corresponding issue: http://bugs.python.org/issue3112

It's probably a bit short for inclusion in beta2, although it would be nice to
exercise it in the wild before it's too late... Right now we don't know whether
the new chained tracebacks will appear useful in practice, and whether long
traceback chains will be frequent or not (although intuitively they shouldn't).

Regards

Antoine.



From musiccomposition at gmail.com  Tue Jul 15 00:19:25 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Mon, 14 Jul 2008 17:19:25 -0500
Subject: [Python-3000] [Python-Dev] PEP: Consolidating names and classes
	in the `unittest` module
In-Reply-To: <87vdz8a983.fsf@benfinney.id.au>
References: <87vdz8a983.fsf@benfinney.id.au>
Message-ID: <1afaf6160807141519g42ea554dt2b437698b4382a68@mail.gmail.com>

On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Use new-style classes throughout
> --------------------------------
>
> The following classes will inherit explicitly from the built-in
> `object` type, to make all classes in the module part of the new-style
> type hierarchy.
>
> * ``TestResult``
> * ``TestCase``
> * ``TestSuite``
> * ``TestLoader``
> * ``_WritelnDecorator``
> * ``TextTestRunner``
> * ``TestProgram``

They already do. __metaclass__ = type is found in unittest.py.



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From musiccomposition at gmail.com  Tue Jul 15 01:22:08 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Mon, 14 Jul 2008 18:22:08 -0500
Subject: [Python-3000] [Python-Dev] PEP: Consolidating names and classes
	in the `unittest` module
In-Reply-To: <87abgk9hr2.fsf@benfinney.id.au>
References: <87vdz8a983.fsf@benfinney.id.au>
	<1afaf6160807141519g42ea554dt2b437698b4382a68@mail.gmail.com>
	<87abgk9hr2.fsf@benfinney.id.au>
Message-ID: <1afaf6160807141622m140fb14dsb30c8312d1eb8af8@mail.gmail.com>

On Mon, Jul 14, 2008 at 6:18 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> "Benjamin Peterson" <musiccomposition at gmail.com> writes:
>
>> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
>> > Use new-style classes throughout
>> > --------------------------------
>> >
>> > The following classes will inherit explicitly from the built-in
>> > `object` type, to make all classes in the module part of the new-style
>> > type hierarchy.
>> >
>> > * ``TestResult``
>> > * ``TestCase``
>> > * ``TestSuite``
>> > * ``TestLoader``
>> > * ``_WritelnDecorator``
>> > * ``TextTestRunner``
>> > * ``TestProgram``
>>
>> They already do. __metaclass__ = type is found in unittest.py.
>
> Not in the copy I have. Is that in 3.x only, or in 2.x also?

Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import unittest
>>> isinstance(unittest.TestCase, object)
True


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From nirina at mail.blueline.mg  Tue Jul 15 10:10:30 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Tue, 15 Jul 2008 11:10:30 +0300 (EAT)
Subject: [Python-3000] adding gamma and error functions to math module
Message-ID: <20080715081030.36360F806@mail.blueline.mg>

gammas and errors functions are available from the C standard
library. it would be nice to have them in the math module.
or is there any reason not to include them?

diff -u1 /usr/local/src/Python-3.0b1/Modules/mathmodule.c mathmodule.c
<diff>
--- /usr/local/src/Python-3.0b1/Modules/mathmodule.c	2008-06-18 13:04:31.000000000 +0300
+++ mathmodule.c	2008-07-14 23:30:17.000000000 +0300
@@ -329,2 +329,7 @@
       "cosh(x)\n\nReturn the hyperbolic cosine of x.")
+FUNC1(erf, erf, 0,
+      "erf(x)\n\nReturn the error function of x.")
+FUNC1(erfc, erfc, 0,
+      "erfc(x)\n\nReturn the complementary error function of x.\n\
+      A domain error may occur if x is too large.")
 FUNC1(exp, exp, 1,
@@ -355,2 +360,6 @@
 
+FUNC1(lgamma, lgamma, 0,
+      "lgamma(x)\n\nReturn the natural logarithm of the absolute\n\
+      value of the gamma function of x.\n\
+      A domain error occurs if x is a negative integer or zero.")
 FUNC1(log1p, log1p, 1,
@@ -368,2 +377,6 @@
       "tanh(x)\n\nReturn the hyperbolic tangent of x.")
+FUNC1(tgamma, tgamma, 0,
+      "tgamma(x)\n\nReturn the gamma function of x.\n\
+      A domain error occurs if x is a negative integer or zero\n\
+      or if the magnitude of x is too large or too small.")
 
@@ -1075,2 +1088,4 @@
 	{"degrees",	math_degrees,	METH_O,		math_degrees_doc},
+        {"erf", math_erf,	METH_O,		math_erf_doc},
+        {"erfc",	math_erfc,	METH_O,		math_erfc_doc},
 	{"exp",		math_exp,	METH_O,		math_exp_doc},
@@ -1085,2 +1100,3 @@
 	{"ldexp",	math_ldexp,	METH_VARARGS,	math_ldexp_doc},
+        {"lgamma",	math_lgamma,	METH_O,		math_lgamma_doc},
 	{"log",		math_log,	METH_VARARGS,	math_log_doc},
@@ -1097,2 +1113,3 @@
 	{"tanh",	math_tanh,	METH_O,		math_tanh_doc},
+        {"tgamma",	math_tgamma,	METH_O,		math_tgamma_doc},
  	{"trunc",	math_trunc,	METH_O,		math_trunc_doc},

</diff>

nirinA

--


From dickinsm at gmail.com  Tue Jul 15 10:27:39 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 15 Jul 2008 09:27:39 +0100
Subject: [Python-3000] adding gamma and error functions to math module
In-Reply-To: <20080715081030.36360F806@mail.blueline.mg>
References: <20080715081030.36360F806@mail.blueline.mg>
Message-ID: <5c6f2a5d0807150127o1d3fac63pa80d456a58ab9422@mail.gmail.com>

On Tue, Jul 15, 2008 at 9:10 AM, nirinA raseliarison
<nirina at mail.blueline.mg> wrote:
> gammas and errors functions are available from the C standard
> library. it would be nice to have them in the math module.
> or is there any reason not to include them?

One reason is that they're probably not available on all platforms;
these functions
are part of the C99 standard, and not everyone has caught up with all the little
details of C99 yet.  In particular, I wouldn't be surprised to learn
that these functions
still weren't available on Windows.  We had this problem when adding the
inverse hyperbolic trig functions to Python 2.6.

I don't know whether it would be acceptable to expose these functions to Python
only on those platforms that have support for them in the C library.

Writing explicit code for these functions, for platforms whose libm doesn't
support them, would be a fairly major task.  Stealing code (in an appropriately
legal fashion) from somewhere else might work.

In any case, if you're interested in getting these in to 2.7/3.1 (it's too
late for 2.6/3.0) then I'd suggest opening a feature request at
bugs.python.org.  (And assign it to me, if you like.)

Mark

From python at rcn.com  Tue Jul 15 10:39:19 2008
From: python at rcn.com (Raymond Hettinger)
Date: Tue, 15 Jul 2008 01:39:19 -0700
Subject: [Python-3000] adding gamma and error functions to math module
References: <20080715081030.36360F806@mail.blueline.mg>
	<5c6f2a5d0807150127o1d3fac63pa80d456a58ab9422@mail.gmail.com>
Message-ID: <04277C8C444F4495B03155FFA4500892@RaymondLaptop1>


----- Original Message ----- 
From: "Mark Dickinson" <dickinsm at gmail.com>
To: "nirinA raseliarison" <nirina at mail.blueline.mg>; "python-3000" <python-3000 at python.org>
Sent: Tuesday, July 15, 2008 1:27 AM
Subject: Re: [Python-3000] adding gamma and error functions to math module


> On Tue, Jul 15, 2008 at 9:10 AM, nirinA raseliarison
> <nirina at mail.blueline.mg> wrote:
>> gammas and errors functions are available from the C standard
>> library. it would be nice to have them in the math module.
>> or is there any reason not to include them?
 . . .
> In any case, if you're interested in getting these in to 2.7/3.1 (it's too
> late for 2.6/3.0) then I'd suggest opening a feature request at
> bugs.python.org.  (And assign it to me, if you like.)

In the meantime, here's a little cheat:

>>> from test.test_random import gamma
>>> gamma(4)
5.9999999999999982
>>> gamma(5)
24.0
>>> gamma(6)
120.00000000000003
>>> gamma(6.1)
142.45194406567856


Raymond

From ben+python at benfinney.id.au  Tue Jul 15 01:18:57 2008
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 15 Jul 2008 09:18:57 +1000
Subject: [Python-3000] [Python-Dev] PEP: Consolidating names and classes
	in the `unittest` module
References: <87vdz8a983.fsf@benfinney.id.au>
	<1afaf6160807141519g42ea554dt2b437698b4382a68@mail.gmail.com>
Message-ID: <87abgk9hr2.fsf@benfinney.id.au>

"Benjamin Peterson" <musiccomposition at gmail.com> writes:

> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> > Use new-style classes throughout
> > --------------------------------
> >
> > The following classes will inherit explicitly from the built-in
> > `object` type, to make all classes in the module part of the new-style
> > type hierarchy.
> >
> > * ``TestResult``
> > * ``TestCase``
> > * ``TestSuite``
> > * ``TestLoader``
> > * ``_WritelnDecorator``
> > * ``TextTestRunner``
> > * ``TestProgram``
> 
> They already do. __metaclass__ = type is found in unittest.py.

Not in the copy I have. Is that in 3.x only, or in 2.x also?

-- 
 \       ?I love to go down to the schoolyard and watch all the little |
  `\   children jump up and down and run around yelling and screaming. |
_o__)             They don't know I'm only using blanks.? ?Emo Philips |
Ben Finney


From fuzzyman at voidspace.org.uk  Tue Jul 15 03:40:31 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 15 Jul 2008 02:40:31 +0100
Subject: [Python-3000] [Python-Dev] PEP: Consolidating names and classes
 in the	`unittest` module
In-Reply-To: <1afaf6160807141622m140fb14dsb30c8312d1eb8af8@mail.gmail.com>
References: <87vdz8a983.fsf@benfinney.id.au>	<1afaf6160807141519g42ea554dt2b437698b4382a68@mail.gmail.com>	<87abgk9hr2.fsf@benfinney.id.au>
	<1afaf6160807141622m140fb14dsb30c8312d1eb8af8@mail.gmail.com>
Message-ID: <487C000F.3050300@voidspace.org.uk>

Benjamin Peterson wrote:
> On Mon, Jul 14, 2008 at 6:18 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>   
>> "Benjamin Peterson" <musiccomposition at gmail.com> writes:
>>
>>     
>>> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
>>>       
>>>> Use new-style classes throughout
>>>> --------------------------------
>>>>
>>>> The following classes will inherit explicitly from the built-in
>>>> `object` type, to make all classes in the module part of the new-style
>>>> type hierarchy.
>>>>
>>>> * ``TestResult``
>>>> * ``TestCase``
>>>> * ``TestSuite``
>>>> * ``TestLoader``
>>>> * ``_WritelnDecorator``
>>>> * ``TextTestRunner``
>>>> * ``TestProgram``
>>>>         
>>> They already do. __metaclass__ = type is found in unittest.py.
>>>       
>> Not in the copy I have. Is that in 3.x only, or in 2.x also?
>>     
>
> Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
> [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>   
>>>> import unittest
>>>> isinstance(unittest.TestCase, object)
>>>>         
> True
>
>
>   
That proves nothing:

Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> class x: pass
...
 >>> isinstance(x, object)
True
 >>> isinstance(x, type)
False
 >>> type(x)
<type 'classobj'>

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/


From scott+python-dev at scottdial.com  Tue Jul 15 08:17:21 2008
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Tue, 15 Jul 2008 02:17:21 -0400
Subject: [Python-3000] [Python-Dev] PEP: Consolidating names and classes
 in the	`unittest` module
In-Reply-To: <487C000F.3050300@voidspace.org.uk>
References: <87vdz8a983.fsf@benfinney.id.au>	<1afaf6160807141519g42ea554dt2b437698b4382a68@mail.gmail.com>	<87abgk9hr2.fsf@benfinney.id.au>	<1afaf6160807141622m140fb14dsb30c8312d1eb8af8@mail.gmail.com>
	<487C000F.3050300@voidspace.org.uk>
Message-ID: <487C40F1.9000309@scottdial.com>

Michael Foord wrote:
> Benjamin Peterson wrote:
>> On Mon, Jul 14, 2008 at 6:18 PM, Ben Finney 
>> <ben+python at benfinney.id.au> wrote:
>>> "Benjamin Peterson" <musiccomposition at gmail.com> writes:
>>>> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney 
>>>> <ben+python at benfinney.id.au> wrote:
>>>>> Use new-style classes throughout
>>>>> --------------------------------
>>>>>
>>>>> The following classes will inherit explicitly from the built-in
>>>>> `object` type, to make all classes in the module part of the new-style
>>>>> type hierarchy.
>>>>>
[snip]
>>>>>         
>>>> They already do. __metaclass__ = type is found in unittest.py.
>>>>       
>>> Not in the copy I have. Is that in 3.x only, or in 2.x also?
>>>     
>>
>> Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
>> [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>  
>>>>> import unittest
>>>>> isinstance(unittest.TestCase, object)
>>>>>         
>> True
>>   
> That proves nothing:
> 
> Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
> [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> class x: pass
> ...
>  >>> isinstance(x, object)
> True
>  >>> isinstance(x, type)
> False
>  >>> type(x)
> <type 'classobj'>
> 

While your retort is accurate, I think it's unintentionally deceptive, 
because you didn't finish your thought.. Benjamin is actually still correct:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit 
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import unittest
 >>> isinstance(unittest.TestCase, type)
True
 >>> type(unittest.TestCase)
<type 'type'>

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

From barry at python.org  Tue Jul 15 14:32:37 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 15 Jul 2008 08:32:37 -0400
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
Message-ID: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>

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

A reminder: the second betas of Python 2.6 and 3.0 are schedule for  
tomorrow.  I will try to hang out on #python-dev today and will start  
looking at the trackers and buildbots.  Hopefully, we're on track to  
get the releases out!

If there is anything you need a decision on, please follow up to this  
thread.  I'm inundated with email so I can't watch every thread on the  
mailing lists.  Or ping me on #python-dev.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSHyY5XEjvBPtnXfVAQKvYgP+J4GYVDWOraKhErC4wRl0ylEdHcc9LypB
O7yxhBjb+tLu54IImxLkj/Nzff4uUQI6zsA6lg87A4b+sC0/0ltH4+vGkZaq8z7/
xSlP0b0UOaBpOEhTR8ZJK3DJBjSk97IR8Ty3MV1DuM0cczYltorCmQVpodA5ciXj
PRy/LAIalJg=
=DTQM
-----END PGP SIGNATURE-----

From dickinsm at gmail.com  Tue Jul 15 15:09:17 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 15 Jul 2008 14:09:17 +0100
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
Message-ID: <5c6f2a5d0807150609o136715f8gda5e599f1330f13c@mail.gmail.com>

On Tue, Jul 15, 2008 at 1:32 PM, Barry Warsaw <barry at python.org> wrote:
> If there is anything you need a decision on, please follow up to this
> thread.  I'm inundated with email so I can't watch every thread on the
> mailing lists.  Or ping me on #python-dev.

Can I request permission to check in the patch attached to issue 3008
(float <-> hex) conversion?  This is the revised version of the bin/oct/hex
for floats patch that Raymond had to withdraw shortly after the first beta.

Link to the issue:

http://bugs.python.org/issue3008

and the long recent thread on python-dev

http://mail.python.org/pipermail/python-dev/2008-June/080558.html

Mark

From ncoghlan at gmail.com  Tue Jul 15 15:29:34 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Jul 2008 23:29:34 +1000
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
Message-ID: <487CA63E.4000207@gmail.com>

Barry Warsaw wrote:
> A reminder: the second betas of Python 2.6 and 3.0 are schedule for 
> tomorrow.  I will try to hang out on #python-dev today and will start 
> looking at the trackers and buildbots.  Hopefully, we're on track to get 
> the releases out!
> 
> If there is anything you need a decision on, please follow up to this 
> thread.  I'm inundated with email so I can't watch every thread on the 
> mailing lists.  Or ping me on #python-dev.

I'll be checking in the fix for issue 2235 shortly (the problem with 
__hash__ not being inherited in 2.x). A pre-review from Guido would have 
been nice (since monkeying with typeobject.c is always a somewhat 
delicate operation), but it looks like he didn't get a chance to get 
back to it after Europython.

I'm also going to forward port the underlying implementation to Py3k (so 
that a non-existent hash is indicated by PyObject_HashNotImplemented in 
tp_hash at the C level as well as by __hash__ = None at the Python level).

Cheers,
Nick.

_______________________________________________
Python-3000 mailing list
Python-3000 at python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/ncoghlan%40gmail.com

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From daniel at stutzbachenterprises.com  Tue Jul 15 15:32:02 2008
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Tue, 15 Jul 2008 08:32:02 -0500
Subject: [Python-3000] adding gamma and error functions to math module
In-Reply-To: <5c6f2a5d0807150127o1d3fac63pa80d456a58ab9422@mail.gmail.com>
References: <20080715081030.36360F806@mail.blueline.mg>
	<5c6f2a5d0807150127o1d3fac63pa80d456a58ab9422@mail.gmail.com>
Message-ID: <eae285400807150632n2f825948x5f6eefeac01ef9bd@mail.gmail.com>

On Tue, Jul 15, 2008 at 3:27 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
> One reason is that they're probably not available on all platforms;
> these functions
> are part of the C99 standard, and not everyone has caught up with all the little
> details of C99 yet.  In particular, I wouldn't be surprised to learn
> that these functions
> still weren't available on Windows.  We had this problem when adding the
> inverse hyperbolic trig functions to Python 2.6.

Indeed, they aren't available on Windows (I just tested it via ctypes).

> Writing explicit code for these functions, for platforms whose libm doesn't
> support them, would be a fairly major task.  Stealing code (in an appropriately
> legal fashion) from somewhere else might work.

This would be great.  I need these functions pretty regularly (to
compute the CDF of normal and beta distributions), and it'd be
wonderful if I didn't have dive into C just to generate some values
for a plot.

I suggest using the versions from newlib's libm.  They contain
extensive comments explaining the math and have a generous license,
e.g.,:

http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/newlib/libm/math/s_erf.c?rev=1.1.1.1&cvsroot=src

-- 
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC

From jnoller at gmail.com  Tue Jul 15 15:36:24 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Tue, 15 Jul 2008 09:36:24 -0400
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
Message-ID: <4222a8490807150636w27d3186chd52d7266d0670b65@mail.gmail.com>

On Tue, Jul 15, 2008 at 8:32 AM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
> tomorrow.  I will try to hang out on #python-dev today and will start
> looking at the trackers and buildbots.  Hopefully, we're on track to get the
> releases out!
>
> If there is anything you need a decision on, please follow up to this
> thread.  I'm inundated with email so I can't watch every thread on the
> mailing lists.  Or ping me on #python-dev.
>
> - -Barry
>

One fix I would like for the upcoming beta is the patch to issue874900
- this seems to have resolved a good chunk of the test_multiprocessing
hangs we've been having problems with. I'm in the process of
double-checking the latest patch posted by Greg.

http://bugs.python.org/issue874900

From solipsis at pitrou.net  Tue Jul 15 15:42:34 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 15 Jul 2008 13:42:34 +0000 (UTC)
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
Message-ID: <loom.20080715T134107-337@post.gmane.org>


Hi,

> A reminder: the second betas of Python 2.6 and 3.0 are schedule for  
> tomorrow.  I will try to hang out on #python-dev today and will start  
> looking at the trackers and buildbots.  Hopefully, we're on track to  
> get the releases out!

In http://codereview.appspot.com/2448 (PEP 3134 exception reporting), Guido said:
? I think it's time to check this in, before beta 2 gets released! ?

Unfortunately I don't have commit privileges, so someone has to do it for me.

cheers

Antoine.



From musiccomposition at gmail.com  Tue Jul 15 15:47:14 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 15 Jul 2008 08:47:14 -0500
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <loom.20080715T134107-337@post.gmane.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<loom.20080715T134107-337@post.gmane.org>
Message-ID: <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>

On Tue, Jul 15, 2008 at 8:42 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hi,
>
>> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
>> tomorrow.  I will try to hang out on #python-dev today and will start
>> looking at the trackers and buildbots.  Hopefully, we're on track to
>> get the releases out!
>
> In http://codereview.appspot.com/2448 (PEP 3134 exception reporting), Guido said:
> ? I think it's time to check this in, before beta 2 gets released! ?
>
> Unfortunately I don't have commit privileges, so someone has to do it for me.

I can do that for you. OTOH, I think it's time we gave Antoine commit
access; we've gotten nothing but great things out of him so far. :)



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From ncoghlan at gmail.com  Tue Jul 15 17:59:17 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Jul 2008 01:59:17 +1000
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <487CA63E.4000207@gmail.com>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<487CA63E.4000207@gmail.com>
Message-ID: <487CC955.1000305@gmail.com>

Nick Coghlan wrote:
> Barry Warsaw wrote:
>> A reminder: the second betas of Python 2.6 and 3.0 are schedule for 
>> tomorrow.  I will try to hang out on #python-dev today and will start 
>> looking at the trackers and buildbots.  Hopefully, we're on track to 
>> get the releases out!
>>
>> If there is anything you need a decision on, please follow up to this 
>> thread.  I'm inundated with email so I can't watch every thread on the 
>> mailing lists.  Or ping me on #python-dev.
> 
> I'll be checking in the fix for issue 2235 shortly (the problem with 
> __hash__ not being inherited in 2.x). A pre-review from Guido would have 
> been nice (since monkeying with typeobject.c is always a somewhat 
> delicate operation), but it looks like he didn't get a chance to get 
> back to it after Europython.
> 
> I'm also going to forward port the underlying implementation to Py3k (so 
> that a non-existent hash is indicated by PyObject_HashNotImplemented in 
> tp_hash at the C level as well as by __hash__ = None at the Python level).

This is now done. There's some documentation updates still to do, as 
well as adding the Py3k warning back in to the 2.6 version, but I won't 
have time to do that for this release - I dropped the tracker item down 
to deferred blocker so it gets back on the list for beta 3.

Looking at the buildbots, getting the multiprocessing fixes in looks 
like it will be a major help in getting more of them to go green, and 
the import related lib2to3 tests also appear to need some attention.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From guido at python.org  Tue Jul 15 19:17:55 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Jul 2008 10:17:55 -0700
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <4877F696.1000405@canterbury.ac.nz>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>
	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>
	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>
	<loom.20080710T130828-461@post.gmane.org>
	<48769FAC.4030702@canterbury.ac.nz> <g56s1s$6g5$1@ger.gmane.org>
	<4877F696.1000405@canterbury.ac.nz>
Message-ID: <ca471dc20807151017r4e111cb6j46f89ddb1a7f8cd6@mail.gmail.com>

On Fri, Jul 11, 2008 at 5:11 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> From some experiments I just did using bare genexps and calling
> next() on them, I don't think anything is being silently caught
> in the genexp. What's happening is that the surrounding list()
> constructor is performing another level of iteration over the
> results of the genexp, and *that* is what's being stopped by
> the StopIteration.
>
> I don't see how this can be fixed, because there's no way for
> the list() constructor to know where the StopIteration is coming
> from.

Sounds like a good analysis to me. No bug here. Move along, nothing to see here!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Tue Jul 15 19:19:52 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Jul 2008 10:19:52 -0700
Subject: [Python-3000] Remove sunaudio?
In-Reply-To: <bbaeab100807121836u16881a2ft212b72231ab49891@mail.gmail.com>
References: <bbaeab100807121836u16881a2ft212b72231ab49891@mail.gmail.com>
Message-ID: <ca471dc20807151019v20e50981s22319b88bdd9bb48@mail.gmail.com>

Go right ahead.

On Sat, Jul 12, 2008 at 6:36 PM, Brett Cannon <brett at python.org> wrote:
> I just noticed that sunaudio was never broken out as a separate module
> to remove in PEP 3108. It is mentioned in the rationale of audiodev to
> remove if audiodev itself is taken out.
>
> I assume no one objects to sunaudio's removal, but I just wanted to
> double-check as it was not explicitly made its own list item in the
> PEP.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From tjreedy at udel.edu  Tue Jul 15 19:38:51 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 15 Jul 2008 13:38:51 -0400
Subject: [Python-3000] adding gamma and error functions to math module
In-Reply-To: <5c6f2a5d0807150127o1d3fac63pa80d456a58ab9422@mail.gmail.com>
References: <20080715081030.36360F806@mail.blueline.mg>
	<5c6f2a5d0807150127o1d3fac63pa80d456a58ab9422@mail.gmail.com>
Message-ID: <g5inbb$j2v$1@ger.gmane.org>



Mark Dickinson wrote:

> In any case, if you're interested in getting these in to 2.7/3.1 (it's too
> late for 2.6/3.0) then I'd suggest opening a feature request at
> bugs.python.org.  (And assign it to me, if you like.)

I'm interested also.  Done and done.
http://bugs.python.org/issue3366


From brett at python.org  Tue Jul 15 20:34:46 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 11:34:46 -0700
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<loom.20080715T134107-337@post.gmane.org>
	<1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>
Message-ID: <bbaeab100807151134l1ed88favcd2889571cfdd405@mail.gmail.com>

On Tue, Jul 15, 2008 at 6:47 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Tue, Jul 15, 2008 at 8:42 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> Hi,
>>
>>> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
>>> tomorrow.  I will try to hang out on #python-dev today and will start
>>> looking at the trackers and buildbots.  Hopefully, we're on track to
>>> get the releases out!
>>
>> In http://codereview.appspot.com/2448 (PEP 3134 exception reporting), Guido said:
>> ? I think it's time to check this in, before beta 2 gets released! ?
>>
>> Unfortunately I don't have commit privileges, so someone has to do it for me.
>
> I can do that for you. OTOH, I think it's time we gave Antoine commit
> access; we've gotten nothing but great things out of him so far. :)
>

Antoine just needs to ask himself and someone who knows how to add
commit privs can make the call (which I suspect will be in the
positive).

-Brett

From brett at python.org  Tue Jul 15 20:38:27 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 11:38:27 -0700
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
Message-ID: <bbaeab100807151138w1d61ed83k863016187708b25c@mail.gmail.com>

On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
> tomorrow.  I will try to hang out on #python-dev today and will start
> looking at the trackers and buildbots.  Hopefully, we're on track to get the
> releases out!
>
> If there is anything you need a decision on, please follow up to this
> thread.  I'm inundated with email so I can't watch every thread on the
> mailing lists.  Or ping me on #python-dev.
>

The new urllib package landed between the last beta and now, but
without fixers. Issue3316 has potential ones, but they have some
tweaks that need to be made before they are release quality. If the
beta goes out 2to3 will not be able to fix imports for urllib and
urllib2. Don't know if that is enough to hold up the release or just
something to put in the release notes that this will be resolved by
the next beta; made it a release blocker to catch your eye, Barry. =)

Oh, and fixers for test.test_support to test.support is not in either,
but this is probably such a small use case outside the core that I am
not sweating bullets for writing a new fixer just for this one case.

-Brett

From guido at python.org  Tue Jul 15 20:45:34 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Jul 2008 11:45:34 -0700
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <bbaeab100807151134l1ed88favcd2889571cfdd405@mail.gmail.com>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<loom.20080715T134107-337@post.gmane.org>
	<1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>
	<bbaeab100807151134l1ed88favcd2889571cfdd405@mail.gmail.com>
Message-ID: <ca471dc20807151145m694d7f45u3b00d6f59272f3ee@mail.gmail.com>

On Tue, Jul 15, 2008 at 11:34 AM, Brett Cannon <brett at python.org> wrote:
>> I can do that for you. OTOH, I think it's time we gave Antoine commit
>> access; we've gotten nothing but great things out of him so far. :)

> Antoine just needs to ask himself and someone who knows how to add
> commit privs can make the call (which I suspect will be in the
> positive).

I'm all in favor of commit privs for Antoine!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From tjreedy at udel.edu  Tue Jul 15 20:52:54 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 15 Jul 2008 14:52:54 -0400
Subject: [Python-3000] Is this a bug with list comprehensions or not?
In-Reply-To: <ca471dc20807151017r4e111cb6j46f89ddb1a7f8cd6@mail.gmail.com>
References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com>	<ca471dc20807090922y296ff3a5i9c892144fbae99bb@mail.gmail.com>	<C596C66C-A421-4CF3-A1B7-AE8690976C41@carlsensei.com>	<loom.20080710T130828-461@post.gmane.org>	<48769FAC.4030702@canterbury.ac.nz>
	<g56s1s$6g5$1@ger.gmane.org>	<4877F696.1000405@canterbury.ac.nz>
	<ca471dc20807151017r4e111cb6j46f89ddb1a7f8cd6@mail.gmail.com>
Message-ID: <g5irm7$37p$1@ger.gmane.org>



Guido van Rossum wrote:

>> I don't see how this can be fixed, because there's no way for
>> the list() constructor to know where the StopIteration is coming
>> from.
> 
> Sounds like a good analysis to me. No bug here. Move along, nothing to see here!

I decided a couple of days ago that the easiest 'fix' would be a minor 
doc tweak.  Aftef LibRef/Exceptions:
   "exception StopIteration
   Raised by builtin next() and an iterator?s __next__() method to signal
   that there are no further values."
add "Do not use this anywhere else."
or perhaps "Using this elsewhere may lead to undefined behavior."

I would include this with other suggestions for that section.

Then one wanting to be exact could write something like "Unless 
StopIteration is abused, list(genexp) == [genexp], and so on."

tjr




From solipsis at pitrou.net  Tue Jul 15 22:28:29 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 15 Jul 2008 20:28:29 +0000 (UTC)
Subject: [Python-3000] commit access request
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<loom.20080715T134107-337@post.gmane.org>
	<1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>
	<bbaeab100807151134l1ed88favcd2889571cfdd405@mail.gmail.com>
Message-ID: <loom.20080715T200625-20@post.gmane.org>


Hey,

My previous mail to the list apparently lost itself somewhere...

> > I can do that for you. OTOH, I think it's time we gave Antoine commit
> > access; we've gotten nothing but great things out of him so far. :)
> 
> Antoine just needs to ask himself and someone who knows how to add
> commit privs can make the call (which I suspect will be in the
> positive).

Well, while I'm still quite young in the python-dev community, I have
contributed a handful of patches, reviews and bug reports, and I'd definitely
like to get commit access so that I can stop bothering people (especially
Benjamin, who's often hanging out on #python-dev) when needing to sort out
reports and patches, or for the occasional trivial fix.

I swear I'll do all my possible to live up to the responsibilities that come
with those powers. Actually the prospect of breaking something by mistake makes
me a bit anxious, so please forgive me in advance.

Regards

Antoine.



From brett at python.org  Tue Jul 15 22:57:39 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 13:57:39 -0700
Subject: [Python-3000] commit access request
In-Reply-To: <loom.20080715T200625-20@post.gmane.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<loom.20080715T134107-337@post.gmane.org>
	<1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>
	<bbaeab100807151134l1ed88favcd2889571cfdd405@mail.gmail.com>
	<loom.20080715T200625-20@post.gmane.org>
Message-ID: <bbaeab100807151357p75e46a0fi4e05663368d74cb5@mail.gmail.com>

On Tue, Jul 15, 2008 at 1:28 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hey,
>
> My previous mail to the list apparently lost itself somewhere...
>
>> > I can do that for you. OTOH, I think it's time we gave Antoine commit
>> > access; we've gotten nothing but great things out of him so far. :)
>>
>> Antoine just needs to ask himself and someone who knows how to add
>> commit privs can make the call (which I suspect will be in the
>> positive).
>
> Well, while I'm still quite young in the python-dev community, I have
> contributed a handful of patches, reviews and bug reports, and I'd definitely
> like to get commit access so that I can stop bothering people (especially
> Benjamin, who's often hanging out on #python-dev) when needing to sort out
> reports and patches, or for the occasional trivial fix.
>
> I swear I'll do all my possible to live up to the responsibilities that come
> with those powers. Actually the prospect of breaking something by mistake makes
> me a bit anxious, so please forgive me in advance.
>

I can't give the privileges, Antoine, but I know that an SSH 2 public
key is going to be needed (see the dev FAQ at
http://www.python.org/dev/faq/ if you don't know how to generate one).
They will also need to know how you want your first.last name spelled
for your user account.

Just send that all in a separate email to python-dev and someone who
can add you will get to it at some point (probably soon).

-Brett

From barry at python.org  Wed Jul 16 01:42:17 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 15 Jul 2008 19:42:17 -0400
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <bbaeab100807151138w1d61ed83k863016187708b25c@mail.gmail.com>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<bbaeab100807151138w1d61ed83k863016187708b25c@mail.gmail.com>
Message-ID: <9CD62042-4AA1-421E-BB63-129DEC30175A@python.org>

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

I realized that the previous schedule really called for a release  
today 7/15 because I'm a bit busy tomorrow night.  In any event, let's  
try to stick to doing it on 7/16.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH012XEjvBPtnXfVAQLJiQQAiP+/S1KVuv9ZgzyS7XdQNW2USTcBGkCh
LIQs3Z+ueuZ9MORdwuDnuZmJWpxataYe26UiPKxt8BFJO81x1i7hy4/uvrO4aE+z
doksz9eJtclNWQNAcvgRX2bKM0OBO57egJrqxYFUgqlziELxOT/U2//josdl3jR1
ovOb/C0nWVU=
=LBea
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jul 16 01:45:42 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 15 Jul 2008 19:45:42 -0400
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <bbaeab100807151138w1d61ed83k863016187708b25c@mail.gmail.com>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<bbaeab100807151138w1d61ed83k863016187708b25c@mail.gmail.com>
Message-ID: <AD5D714F-3513-4BF5-A72C-2ADF6C62181E@python.org>

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

On Jul 15, 2008, at 2:38 PM, Brett Cannon wrote:

> On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw <barry at python.org>  
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
>> tomorrow.  I will try to hang out on #python-dev today and will start
>> looking at the trackers and buildbots.  Hopefully, we're on track  
>> to get the
>> releases out!
>>
>> If there is anything you need a decision on, please follow up to this
>> thread.  I'm inundated with email so I can't watch every thread on  
>> the
>> mailing lists.  Or ping me on #python-dev.
>>
>
> The new urllib package landed between the last beta and now, but
> without fixers. Issue3316 has potential ones, but they have some
> tweaks that need to be made before they are release quality. If the
> beta goes out 2to3 will not be able to fix imports for urllib and
> urllib2. Don't know if that is enough to hold up the release or just
> something to put in the release notes that this will be resolved by
> the next beta; made it a release blocker to catch your eye, Barry. =)

I knocked this down to a deferred blocker, so I won't let it hold up  
beta2, though I'd /really/ like to get this cleaned up and committed  
in time.  If I get enough deferred blockers though, I might hold  
things up after all.

> Oh, and fixers for test.test_support to test.support is not in either,
> but this is probably such a small use case outside the core that I am
> not sweating bullets for writing a new fixer just for this one case.

Ok.
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH02pnEjvBPtnXfVAQL1qgP/a2yf6fagOS7Hvbwd08ZhYkaB+GDTcFMy
mo/bJtvrdCRwPm+60q5mZYuMBIz/I7IBSQmSI09IOdEi0RPoXH6Los3LMrt+Aa6v
XgPu7nYcO1vNa/b+6vNvsBAEPfEuaMJsSRpHNJfAWsjF82BsiNEpJ0D5906CAhyW
MrjaPUb47bs=
=/qoQ
-----END PGP SIGNATURE-----

From barry at python.org  Wed Jul 16 01:48:45 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 15 Jul 2008 19:48:45 -0400
Subject: [Python-3000] commit access request
In-Reply-To: <bbaeab100807151357p75e46a0fi4e05663368d74cb5@mail.gmail.com>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<loom.20080715T134107-337@post.gmane.org>
	<1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>
	<bbaeab100807151134l1ed88favcd2889571cfdd405@mail.gmail.com>
	<loom.20080715T200625-20@post.gmane.org>
	<bbaeab100807151357p75e46a0fi4e05663368d74cb5@mail.gmail.com>
Message-ID: <617C4B5E-C026-4323-BC27-55FAAE1250CA@python.org>

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

On Jul 15, 2008, at 4:57 PM, Brett Cannon wrote:

> I can't give the privileges, Antoine, but I know that an SSH 2 public
> key is going to be needed (see the dev FAQ at
> http://www.python.org/dev/faq/ if you don't know how to generate one).
> They will also need to know how you want your first.last name spelled
> for your user account.
>
> Just send that all in a separate email to python-dev and someone who
> can add you will get to it at some point (probably soon).

Actually, the pydotorg admins can do this, and I've forwarded  
Antoine's key to them.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH03XXEjvBPtnXfVAQLeJwP+Kkb+2UhWRKwsUfaf9KpHVmDfbQ+Ixk6l
ZMh0RSorHqOsv2cJVCqGGUbS/GQKJP8h7gZCemPqGu46U9ERNbatX+2HsC9S9nSK
LCqdhALGDbMA1qgHINS8nxhlsxW8vMFPoVQCyki/R+EP3YvT71aGxfCjivVU/n27
q9BDjxIPPOI=
=byWZ
-----END PGP SIGNATURE-----

From brett at python.org  Wed Jul 16 02:05:26 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 15 Jul 2008 17:05:26 -0700
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <AD5D714F-3513-4BF5-A72C-2ADF6C62181E@python.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<bbaeab100807151138w1d61ed83k863016187708b25c@mail.gmail.com>
	<AD5D714F-3513-4BF5-A72C-2ADF6C62181E@python.org>
Message-ID: <bbaeab100807151705q56cade4cpc9b6417d8f70d34c@mail.gmail.com>

On Tue, Jul 15, 2008 at 4:45 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jul 15, 2008, at 2:38 PM, Brett Cannon wrote:
>
>> On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw <barry at python.org> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
>>> tomorrow.  I will try to hang out on #python-dev today and will start
>>> looking at the trackers and buildbots.  Hopefully, we're on track to get
>>> the
>>> releases out!
>>>
>>> If there is anything you need a decision on, please follow up to this
>>> thread.  I'm inundated with email so I can't watch every thread on the
>>> mailing lists.  Or ping me on #python-dev.
>>>
>>
>> The new urllib package landed between the last beta and now, but
>> without fixers. Issue3316 has potential ones, but they have some
>> tweaks that need to be made before they are release quality. If the
>> beta goes out 2to3 will not be able to fix imports for urllib and
>> urllib2. Don't know if that is enough to hold up the release or just
>> something to put in the release notes that this will be resolved by
>> the next beta; made it a release blocker to catch your eye, Barry. =)
>
> I knocked this down to a deferred blocker, so I won't let it hold up beta2,
> though I'd /really/ like to get this cleaned up and committed in time.  If I
> get enough deferred blockers though, I might hold things up after all.
>

Nick is actively working on it, so it might make it in b2.

-Brett

From barry at python.org  Wed Jul 16 02:22:09 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 15 Jul 2008 20:22:09 -0400
Subject: [Python-3000] Bug 3139
Message-ID: <585A47BF-246A-416D-B83C-E74933B0EB0E@python.org>

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

But 3139 appears important enough to hold up beta 2.

http://bugs.python.org/issue3139
bytearrays are not thread safe

Can we get this fixed by tomorrow?  Does anybody disagree that we  
should hold up the release for this one?  We don't have much time left  
to fix things like this.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH0/MXEjvBPtnXfVAQJoHwP8CFYbafuSTbnVdBBydZJ5k8Fb1L4YYVG/
0ee81N4AiQZ5uGQlk4ywAVBycPa+DMWE+cdrkYiGXkPaarhcOd55dfdvL1Ww6OgO
tor2fh2IxT0ee7gO/vgbyv4ybWsxuPH/9W5O+W2hZkHd60NkJCqpiHlMKGz6caOX
+rwbgqaQOU4=
=8lO1
-----END PGP SIGNATURE-----

From eric+python-dev at trueblade.com  Wed Jul 16 03:04:10 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Tue, 15 Jul 2008 21:04:10 -0400
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <483F06FF.9090007@trueblade.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>	<483EAF95.5050503@trueblade.com>	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>
	<483F06FF.9090007@trueblade.com>
Message-ID: <487D490A.9020209@trueblade.com>

Eric Smith wrote:
> Marcin ?Qrczak? Kowalczyk wrote:
>> 2008/5/29 Eric Smith <eric+python-dev at trueblade.com>:
>>
>>> I don't see it as a big problem.  You can now use any prefix you want,
>>> instead of the hard coded values that # supplied.
>>
>> Except that it works incorrectly for negative numbers.
> 
> Excellent point.  If only this had been brought up back when the PEP was 
> written :(
> 
> Any suggestions on how to improve the situation?  I guess we could add 
> '#' back in to the format specifier.  I can't really think of any other 
> way that doesn't involve converting the number to a string and then 
> operating on that, just to get the sign.
> 
> I'm reasonably sure I could implement that before the beta (next 
> Wednesday) if a decision is reached before this weekend.

So much for my estimating skills.  I was only off by 1 beta and 6 weeks. 
  I just checked in the code to close this issue 
(http://bugs.python.org/issue3038).  It's in both 2.6 and 3.0.

I've added test cases, but if anyone has any other uses for this, please 
look at it and let me know if you have any problems.

Eric.

From eric+python-dev at trueblade.com  Wed Jul 16 03:15:22 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Tue, 15 Jul 2008 21:15:22 -0400
Subject: [Python-3000] PEP 3101 str.format() equivalent of '%#o/x/X'?
In-Reply-To: <487D490A.9020209@trueblade.com>
References: <78b3a9580805290156x6790a6c4k5c9ae49e79fa21d4@mail.gmail.com>	<483EAF95.5050503@trueblade.com>	<3f4107910805291116w37af38e3qb2c5145539d7e23e@mail.gmail.com>	<483F06FF.9090007@trueblade.com>
	<487D490A.9020209@trueblade.com>
Message-ID: <487D4BAA.9070207@trueblade.com>

Eric Smith wrote:
> I just checked in the code to close this issue 
> (http://bugs.python.org/issue3038).  It's in both 2.6 and 3.0.

Make that http://bugs.python.org/issue3083.

From solipsis at pitrou.net  Tue Jul 15 17:38:13 2008
From: solipsis at pitrou.net (Antoine)
Date: Tue, 15 Jul 2008 17:38:13 +0200 (CEST)
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<loom.20080715T134107-337@post.gmane.org>
	<1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>
Message-ID: <731c984f6d36bf96dc25779eda414a20.squirrel@webmail.nerim.net>


> I can do that for you. OTOH, I think it's time we gave Antoine commit
> access; we've gotten nothing but great things out of him so far. :)

Part of the reason Benjamin says this is probably that I've been bugging
him quite a few times to commit some pending patches (he was the one
hanging out on #python-dev). Not lowering Benjamin's morale is a noble
justification in itself :-)

I must say I would be glad to be granted the power and responsibilities of
having developer access. It would allow me to be more efficient when
sorting out stuff on the bug tracker, and doing the occasional trivial
fix.

Regards

Antoine.



From ncoghlan at gmail.com  Wed Jul 16 07:09:27 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Jul 2008 15:09:27 +1000
Subject: [Python-3000] commit access request
In-Reply-To: <loom.20080715T200625-20@post.gmane.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>	<loom.20080715T134107-337@post.gmane.org>	<1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>	<bbaeab100807151134l1ed88favcd2889571cfdd405@mail.gmail.com>
	<loom.20080715T200625-20@post.gmane.org>
Message-ID: <487D8287.1030606@gmail.com>

Antoine Pitrou wrote:
> I swear I'll do all my possible to live up to the responsibilities that come
> with those powers. Actually the prospect of breaking something by mistake makes
> me a bit anxious, so please forgive me in advance.

The moment you check something in by mistake is the moment you will 
truly understand why atomic commits are such a wonderful thing :)

I recently spent an hour reverting a mistaken CVS checkin (meant to 
check in one file, checked in the whole working tree instead) that could 
have been reverted with a single command in SVN.

Cheers,
Nick.

P.S. I highly recommend bookmarking the dev FAQ Brett linked in another 
post. It contains several useful subversion tips and tricks.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From stefan_ml at behnel.de  Wed Jul 16 07:37:03 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 16 Jul 2008 07:37:03 +0200
Subject: [Python-3000] commit access request
In-Reply-To: <487D8287.1030606@gmail.com>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>	<loom.20080715T134107-337@post.gmane.org>	<1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>	<bbaeab100807151134l1ed88favcd2889571cfdd405@mail.gmail.com>	<loom.20080715T200625-20@post.gmane.org>
	<487D8287.1030606@gmail.com>
Message-ID: <g5k1dv$cd9$1@ger.gmane.org>

Nick Coghlan wrote:
> I recently spent an hour reverting a mistaken CVS checkin (meant to
> check in one file, checked in the whole working tree instead) that could
> have been reverted with a single command in SVN.

:) I know what that feels like ...

That's where Mercurial's "hg rollback" comes in very handy. And it's actually
a very nice feature that distributed VCSes split the commit and push
operations into two separate steps...

Stefan


From solipsis at pitrou.net  Wed Jul 16 10:41:29 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 16 Jul 2008 08:41:29 +0000 (UTC)
Subject: [Python-3000] Bug 3139
References: <585A47BF-246A-416D-B83C-E74933B0EB0E@python.org>
Message-ID: <loom.20080716T084013-248@post.gmane.org>


Hi,

Barry Warsaw <barry <at> python.org> writes:
> But 3139 appears important enough to hold up beta 2.
> 
> http://bugs.python.org/issue3139
> bytearrays are not thread safe
> 
> Can we get this fixed by tomorrow?  Does anybody disagree that we  
> should hold up the release for this one?  We don't have much time left  
> to fix things like this.
> 

I think it's definitely too short. Martin has outlined a clean solution to this
but it's a lot of changes. Let's wait for beta 3.

Regards

Antoine.



From barry at python.org  Wed Jul 16 14:32:27 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 16 Jul 2008 08:32:27 -0400
Subject: [Python-3000] Bug 3139
In-Reply-To: <loom.20080716T084013-248@post.gmane.org>
References: <585A47BF-246A-416D-B83C-E74933B0EB0E@python.org>
	<loom.20080716T084013-248@post.gmane.org>
Message-ID: <1AE3BF59-E31C-4E9F-AA98-0916953AE9AA@python.org>

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

On Jul 16, 2008, at 4:41 AM, Antoine Pitrou wrote:

> Barry Warsaw <barry <at> python.org> writes:
>> But 3139 appears important enough to hold up beta 2.
>>
>> http://bugs.python.org/issue3139
>> bytearrays are not thread safe
>>
>> Can we get this fixed by tomorrow?  Does anybody disagree that we
>> should hold up the release for this one?  We don't have much time  
>> left
>> to fix things like this.
>>
>
> I think it's definitely too short. Martin has outlined a clean  
> solution to this
> but it's a lot of changes. Let's wait for beta 3.

Okay, but it will definitely block beta 3.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH3qW3EjvBPtnXfVAQJKiQP/fOtwMtB160a1sXNDKv0gcSyCC3fOToKE
OaRrIraBHsTd1SEeKQHC6vle0EyC7slM+/ddTI2ENR6+eaeBreWDod4tQh8SmRkw
j5kQDYnXz1UikXAa4LkIXzrhBIuppSv80Pp+pogjgidYlAuZd2afXElfk7ndgpPL
Ft1xMti5yvo=
=Lti/
-----END PGP SIGNATURE-----

From g.brandl at gmx.net  Wed Jul 16 15:05:09 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 16 Jul 2008 15:05:09 +0200
Subject: [Python-3000] Unmerged changes
Message-ID: <g5krfk$2ke$1@ger.gmane.org>

I've merged most of the remaining changes to Py3k, with two exceptions:

* The bsddb upgrade (same reason as last time: #2887)
* The ssl changes (Bill, you said you had a separately maintained copy for 3k)

Georg


From barry at python.org  Wed Jul 16 15:18:19 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 16 Jul 2008 09:18:19 -0400
Subject: [Python-3000] Reminder: beta 2's schedule for tomorrow
In-Reply-To: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
Message-ID: <53E31F7D-875C-466C-B5F6-2D3D274847D4@python.org>

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

On Jul 15, 2008, at 8:32 AM, Barry Warsaw wrote:

> If there is anything you need a decision on, please follow up to  
> this thread.  I'm inundated with email so I can't watch every thread  
> on the mailing lists.  Or ping me on #python-dev.

I'm not currently optimistic that we can release today.

As I see it we have several problems serious enough to delay a  
release.  First, we have no green 2.6 or 3.0 buildbots

http://www.python.org/dev/buildbot/stable/

It looks like few of the buildbots for 2.6 are actually online, but  
still, the 3.0 buildbots are all failing.

We still have, and have had for a long time now, serious problems with  
the multiprocessing module:

http://bugs.python.org/issue?@columns=title,id,activity,versions,status&@sort=activity&@filter=priority,status&@pagesize=50&@startwith=0&priority=1&status=1&@dispname=Showstoppers

I noticed today that _multiprocessing.so has build problems on OS X  
10.5 and Ubuntu 8.04.  I opened a separate issue about that so as not  
to get lost in the other bug about test_multiprocessing hanging.  As  
evidenced by the thread for issue 3088, lots of people have put a lot  
of work into this module, but unfortunately we're still not there.   
These seem serious enough to me to hold up the release, especially  
since we have only one more beta left.

Speaking of which, we have a number of deferred blockers:

http://bugs.python.org/issue?@columns=title,id,activity,status&@sort=activity&@group=priority&@filter=priority,status&@pagesize=50&@startwith=0&priority=6&status=1&@dispname=Deferred%20Blockers

These will not block beta 2, but they /will/ block beta 3, so they  
really need some attention.

Please everyone, if you have only a little bit of time to work on  
Python, I hope you will attack the release critical and deferred  
blocker issues, and work on turning the buildbots green.  These are  
the top priorities in order to get 2.6 and 3.0 out on time.  And just  
as added incentive, our October 1st goal is being noted by downstream  
vendors.  I've been told that "Apple is willing to take the new Python  
if it is GM on schedule by Oct 1st, but may not if it is delayed"  
though you should not infer anything about Apple's schedule from this.

Still, we won't sacrifice quality in order to hit the October 1st  
goal.  After beta 2, I start getting mean. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH31HHEjvBPtnXfVAQIH+AQAtkRJo0uhvZ300jq0YSR6ezUU0tMHJwmd
pwLWwZWDqPyh3/ohKwrajdGm5hYS8gOnTo+k2XEEJjQJdLMTblzZ3ArsGfhXHqbV
GPeKK/6BYT6SOD75ubINq+jSsu6Pvjsadbk/cp/x53WwHL8kX40D0YQBhp3KQRrz
zgFmfVFPcys=
=3SDN
-----END PGP SIGNATURE-----

From musiccomposition at gmail.com  Wed Jul 16 15:44:48 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 16 Jul 2008 08:44:48 -0500
Subject: [Python-3000] commit access request
In-Reply-To: <g5k1dv$cd9$1@ger.gmane.org>
References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org>
	<loom.20080715T134107-337@post.gmane.org>
	<1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com>
	<bbaeab100807151134l1ed88favcd2889571cfdd405@mail.gmail.com>
	<loom.20080715T200625-20@post.gmane.org> <487D8287.1030606@gmail.com>
	<g5k1dv$cd9$1@ger.gmane.org>
Message-ID: <1afaf6160807160644w75db0be3p2911be6648920bb5@mail.gmail.com>

On Wed, Jul 16, 2008 at 12:37 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Nick Coghlan wrote:
>> I recently spent an hour reverting a mistaken CVS checkin (meant to
>> check in one file, checked in the whole working tree instead) that could
>> have been reverted with a single command in SVN.
>
> :) I know what that feels like ...
>
> That's where Mercurial's "hg rollback" comes in very handy. And it's actually
> a very nice feature that distributed VCSes split the commit and push
> operations into two separate steps...

Yeah for bzr uncommit!



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From nirina at mail.blueline.mg  Wed Jul 16 18:03:49 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Wed, 16 Jul 2008 19:03:49 +0300 (EAT)
Subject: [Python-3000] adding gamma and error functions to math module
Message-ID: <20080716160349.7D5B0F84B@mail.blueline.mg>

on Tue, 15 Jul 2008 01:39:19 -0700
Raymond Hettinger wrote:

> In the meantime, here's a little cheat:
>
> >>> from test.test_random import gamma
> >>> gamma(4)
> 5.9999999999999982
> >>> gamma(5)
> 24.0
> >>> gamma(6)
> 120.00000000000003
> >>> gamma(6.1)
> 142.45194406567856

there is a simple implementation in Python at:
http://en.wikipedia.org/wiki/Lanczos_approximation
with coefficients slightly different from those in
test_random.py, one gets:

>>> gamma(4)
(6.0000000000000071+0j)
>>> gamma(5)
(23.999999999999996+0j)
>>> gamma(6)
(120.00000000000021+0j)
>>> gamma(6.1)
(142.4519440656791+0j)
>>> 

with the gamma from gcc under linux,
which uses the MPFR library,
the result is not really satisfying:

>>> lgamma(4)
1.791759469228055
>>> tgamma(4)
6.0
>>> tgamma(5)
24.000000000000004
>>> tgamma(6)
119.99999999999997
>>> tgamma(6.1)
142.45194406567862

using the code from numerical recipes chap 6:

>>> lgamma(4)
1.7917594692280554
>>> math.exp(lgamma(4))
6.0000000000000027
>>> math.exp(lgamma(5))
23.999999999999993
>>> math.exp(lgamma(6))
119.99999999999987
>>> math.exp(lgamma(6.1))
142.45194406567873

and from the scipy package,
which uses the cephes math library:

>>> from scipy.special import *
>>> gamma(4)
6.0
>>> gamma(5)
24.0
>>> gamma(6)
120.0
>>> gamma(6.1)
142.45194406567867

i'll check if an appropriate choice of
of a set of coefficients or extending the
number of coefficients can lead to a more
accurate result.

nirinA

--


From nirina at mail.blueline.mg  Wed Jul 16 18:03:26 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Wed, 16 Jul 2008 19:03:26 +0300 (EAT)
Subject: [Python-3000] adding gamma and error functions to math module
Message-ID: <20080716160326.D8EA0F84B@mail.blueline.mg>

on Tue, 15 Jul 2008 09:27:39 +0100
Mark Dickinson wrote:

> Writing explicit code for these functions, for platforms
> whose libm doesn't support them, would be a fairly major task.
> Stealing code (in an appropriately legal fashion) from somewhere
> else might work.

> In any case, if you're interested in getting these in to 2.7/3.1
> (it's too late for 2.6/3.0) then I'd suggest opening a feature
> request at bugs.python.org.  (And assign it to me, if you like.)

my initial motivation is to make these functions accessible,
with just a few lines of additionnal code. that's so simple
with a linux box!

but now that a feature request is open - thanks Terry! -
it's interesting to have more accurate functions available.
so far, the most accurate code i found for the gamma
function is from the cephes library, used by the scipy package.

is there some other place to check?
do you know some nice code to see?
any link?

thanks,

nirinA

--


From python at rcn.com  Wed Jul 16 18:19:02 2008
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 16 Jul 2008 09:19:02 -0700
Subject: [Python-3000] adding gamma and error functions to math module
References: <20080716160349.7D5B0F84B@mail.blueline.mg>
Message-ID: <4B3EA20E085A4C3CA95B0A9CEADD1ECB@RaymondLaptop1>

From: "nirinA raseliarison" <nirina at mail.blueline.mg>
>> >>> from test.test_random import gamma
 . . .
> there is a simple implementation in Python at:
> http://en.wikipedia.org/wiki/Lanczos_approximation
> with coefficients slightly different from those in
> test_random.py, one gets:
 . . .
> with the gamma from gcc under linux,
> which uses the MPFR library,
> the result is not really satisfying:
> using the code from numerical recipes chap 6:
 . . .
> 
> and from the scipy package,
> which uses the cephes math library:
 ...
> i'll check if an appropriate choice of
> of a set of coefficients or extending the
> number of coefficients can lead to a more
> accurate result.

Discussions of "my approximation is better/faster/etc than yours" can be interminable.
Recommend you put together your favorite approximation in a recipe.
The one in test.random is suffices well for its purpose.


Raymond

From nirina at mail.blueline.mg  Wed Jul 16 18:04:09 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Wed, 16 Jul 2008 19:04:09 +0300 (EAT)
Subject: [Python-3000] adding gamma and error functions to math module
Message-ID: <20080716160409.82A7AF85D@mail.blueline.mg>

on Tue, 15 Jul 2008 08:32:02 -0500
Daniel Stutzbach wrote:

> I suggest using the versions from newlib's libm.  They contain
> extensive comments explaining the math and have a generous license,
> e.g.,:
>
> http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/newlib/libm/math/s_erf.c?rev=1.1.1.1&cvsroot=src

a personnal view here. i'm always perplex when there
are many magic numbers in some code. unless i know how
to compute these numbers.

however, as with the cephes library, no doubt that the
code will be much more robust, efficient and accurate.
but also much more difficult to implement, hundred lines
of code instead of a few lines.


nirinA

--


From dickinsm at gmail.com  Wed Jul 16 18:55:06 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Wed, 16 Jul 2008 17:55:06 +0100
Subject: [Python-3000] adding gamma and error functions to math module
In-Reply-To: <20080716160349.7D5B0F84B@mail.blueline.mg>
References: <20080716160349.7D5B0F84B@mail.blueline.mg>
Message-ID: <5c6f2a5d0807160955n26dc7398g9670353b736d5d6b@mail.gmail.com>

On Wed, Jul 16, 2008 at 5:03 PM, nirinA raseliarison
<nirina at mail.blueline.mg> wrote:
> with the gamma from gcc under linux,
> which uses the MPFR library,

Are you sure it uses MPFR?  I thought that for gcc 4.3, MPFR was used only for
compile-time constant expressions.  For a call to tgamma whose argument is
not known at compile time, the usual libm function should be used.

For example, on my machine, if I compile
and run the following code:

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

double f(double x) {
  return tgamma(x);
}

int main() {
  printf("%.16g\n", tgamma(12.0));
  printf("%.16g\n", f(12.0));
  exit(0);
}

I get the results:

39916800
39916800.00000003

Mark

From daniel at stutzbachenterprises.com  Wed Jul 16 19:08:17 2008
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Wed, 16 Jul 2008 12:08:17 -0500
Subject: [Python-3000] adding gamma and error functions to math module
In-Reply-To: <20080716160409.82A7AF85D@mail.blueline.mg>
References: <20080716160409.82A7AF85D@mail.blueline.mg>
Message-ID: <eae285400807161008m25349855rcfb425afff8e46c@mail.gmail.com>

On Wed, Jul 16, 2008 at 11:04 AM, nirinA raseliarison
<nirina at mail.blueline.mg> wrote:
> Daniel Stutzbach wrote:
>> http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/newlib/libm/math/s_erf.c?rev=1.1.1.1&cvsroot=src
>
> a personnal view here. i'm always perplex when there
> are many magic numbers in some code. unless i know how
> to compute these numbers.

The comments in the code *do* explain how to compute the numbers,
albeit tersely.

Most of the numbers are coefficients in a Taylor series expansion.

The code is a few hundred lines because numeric methods for these
functions that are accurate in the range [a,b] tend not to be accurate
outside the range [a,b].  Ergo, robust implementations include several
different methods so that they are accurate over the entire range of
the function.

-- 
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC

From dickinsm at gmail.com  Wed Jul 16 19:35:47 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Wed, 16 Jul 2008 18:35:47 +0100
Subject: [Python-3000] adding gamma and error functions to math module
In-Reply-To: <20080716160326.D8EA0F84B@mail.blueline.mg>
References: <20080716160326.D8EA0F84B@mail.blueline.mg>
Message-ID: <5c6f2a5d0807161035r1b4e50d5y51c97bc8d09992e9@mail.gmail.com>

On Wed, Jul 16, 2008 at 5:03 PM, nirinA raseliarison
<nirina at mail.blueline.mg> wrote:
> my initial motivation is to make these functions accessible,
> with just a few lines of additionnal code. that's so simple
> with a linux box!

As Daniel Stutzbach already hinted, the easiest way to just get at the
system gamma and error functions, in a platform-dependent manner,
is probably to use ctypes.  On OS X:

Macintosh-3:trunk dickinsm$ ./python.exe
Python 2.6b1+ (trunk:65004M, Jul 16 2008, 10:17:30)
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> tgamma = ctypes.CDLL('libm.dylib').tgamma
>>> tgamma.restype = ctypes.c_double
>>> tgamma.argtypes = [ctypes.c_double]
>>> tgamma(1.0)
1.0
>>> tgamma(6.1)
142.45194406567867

Is this enough for your immediate needs?

Mark

From janssen at parc.com  Wed Jul 16 19:49:40 2008
From: janssen at parc.com (Bill Janssen)
Date: Wed, 16 Jul 2008 10:49:40 PDT
Subject: [Python-3000] Unmerged changes
In-Reply-To: <g5krfk$2ke$1@ger.gmane.org> 
References: <g5krfk$2ke$1@ger.gmane.org>
Message-ID: <08Jul16.104941pdt."58698"@synergy1.parc.xerox.com>

> * The ssl changes (Bill, you said you had a separately maintained copy for 3k)

Yes, I think it's all up-to-date.

I'll unblock it after the beta2 release.

Bill

From martin at v.loewis.de  Wed Jul 16 20:58:34 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Jul 2008 20:58:34 +0200
Subject: [Python-3000] Bug 3139
In-Reply-To: <loom.20080716T084013-248@post.gmane.org>
References: <585A47BF-246A-416D-B83C-E74933B0EB0E@python.org>
	<loom.20080716T084013-248@post.gmane.org>
Message-ID: <487E44DA.2050308@v.loewis.de>

> I think it's definitely too short. Martin has outlined a clean solution to this
> but it's a lot of changes. Let's wait for beta 3.

FWIW, I started writing code today. I couldn't complete it, either (i.e.
it's for 2.6 only, has no docs, and only fixes a single function), but I
hope to submit a patch next week (if not, I'll provide a snapshot of my
patch).

From barry at python.org  Wed Jul 16 21:56:56 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 16 Jul 2008 15:56:56 -0400
Subject: [Python-3000] Bug 3139
In-Reply-To: <487E44DA.2050308@v.loewis.de>
References: <585A47BF-246A-416D-B83C-E74933B0EB0E@python.org>
	<loom.20080716T084013-248@post.gmane.org>
	<487E44DA.2050308@v.loewis.de>
Message-ID: <297DB67B-DC82-455D-A79E-3987795C8FDE@python.org>

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

On Jul 16, 2008, at 2:58 PM, Martin v. L?wis wrote:

>> I think it's definitely too short. Martin has outlined a clean  
>> solution to this
>> but it's a lot of changes. Let's wait for beta 3.
>
> FWIW, I started writing code today. I couldn't complete it, either  
> (i.e.
> it's for 2.6 only, has no docs, and only fixes a single function),  
> but I
> hope to submit a patch next week (if not, I'll provide a snapshot of  
> my
> patch).

Great Martin, thanks!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH5SiHEjvBPtnXfVAQLr5AP+Nir9iE/elroDpo5h2Kvtb2DNCTx7S7nS
CxR/1KHGD+emDz0vfMDYrGEDoFrjul6T79CSCSf7I+nViw/vHxPDCmPg6CBlLhGR
Z2dEs+bULL6L1u/eg/5vl3ibnOwwPrz/boOH/yk1J5S0slnDVGo9CMR62kpBgmhx
WLzhvbF1RjE=
=pVsS
-----END PGP SIGNATURE-----

From barry at python.org  Thu Jul 17 06:30:51 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Jul 2008 00:30:51 -0400
Subject: [Python-3000] No beta2 tonight
Message-ID: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>

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

We have green buildbots, yay!  Thanks everyone for that.

However, we still have three release blocker issues that I am not  
comfortable deferring.

3088 test_multiprocessing hangs intermittently on POSIX platforms
3375 _multiprocessing.so build problems
874900 threading module can deadlock after fork

My biggest concern is 3375 and 3088, the latter has a dependency on  
874900.

3375 is very strange since a subsequent 'make' completes just fine.   
This issue happens for me on both OS X 10.5 and Ubuntu 8.04 for py3k.

3088 does not appear to be happening now on OS X or Ubuntu, but the  
issue (and its dependent issue) are not closed, so I'm not sure  
exactly what's going on here.

So we'll give these releases another 24 hours.  Please, if you have  
time see what you can do about resolving these three blockers.  Chat  
with me on #python-dev if you think we should release anyway.  I will  
try to look into 3375, but I'd like to know if anybody else is seeing  
these build failures.

I'll note that I plan to hold the beta3 releases until all release  
blocker and deferred blockers are resolved.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH7K+3EjvBPtnXfVAQJPXgQAo+uHlgEEpOqlSYINJuXhTHNRWIQEByAu
RCJZw4jNABKR4Pyero9z2LR31bEWS0Osg8a9DdoeD7bvVmPYyIJCG9bfA3BUwpD8
LtZ1tx9ou/XVGkDD7vQLuTt3hJXSaUvovx4ieeA7OQMiI0Uf3klIny+s2mBFH9IA
COd48C7B/S4=
=tcGt
-----END PGP SIGNATURE-----

From jnoller at gmail.com  Thu Jul 17 15:16:37 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Thu, 17 Jul 2008 09:16:37 -0400
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
Message-ID: <4222a8490807170616x5ca600fdw3e6d0bced885c943@mail.gmail.com>

On Thu, Jul 17, 2008 at 12:30 AM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We have green buildbots, yay!  Thanks everyone for that.
>
> However, we still have three release blocker issues that I am not
> comfortable deferring.
>
> 3088 test_multiprocessing hangs intermittently on POSIX platforms
> 3375 _multiprocessing.so build problems
> 874900 threading module can deadlock after fork
>
> My biggest concern is 3375 and 3088, the latter has a dependency on 874900.
>
> 3375 is very strange since a subsequent 'make' completes just fine.  This
> issue happens for me on both OS X 10.5 and Ubuntu 8.04 for py3k.
>
> 3088 does not appear to be happening now on OS X or Ubuntu, but the issue
> (and its dependent issue) are not closed, so I'm not sure exactly what's
> going on here.
>
> So we'll give these releases another 24 hours.  Please, if you have time see
> what you can do about resolving these three blockers.  Chat with me on
> #python-dev if you think we should release anyway.  I will try to look into
> 3375, but I'd like to know if anybody else is seeing these build failures.
>
> I'll note that I plan to hold the beta3 releases until all release blocker
> and deferred blockers are resolved.
>
> - -Barry
>

Quick status update, since I'm the gating factor.

3088: I didn't want to close this until 874900's patch was submitted,
ported to py3k and I saw green build bots. By the time I went to sleep
last night, we were still seeing 2to3 test timeouts on the build bots.
I will port the patch to 3k today and lower the priority of 874900 and
close 3088 shortly.

3375: Guido (thanks guido) looked into this, and while I banged my
head on it a lot yesterday - guido's identified the issue, and now I
need to figure out a fix - help is welcome on this one.

I apologize for not getting these resolved last night

-jesse

From steve at holdenweb.com  Thu Jul 17 15:57:02 2008
From: steve at holdenweb.com (Steve Holden)
Date: Thu, 17 Jul 2008 09:57:02 -0400
Subject: [Python-3000] No beta2 tonight
In-Reply-To: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
Message-ID: <487F4FAE.3050600@holdenweb.com>

Barry Warsaw wrote:
[...]
> 
> I'll note that I plan to hold the beta3 releases until all release 
> blocker and deferred blockers are resolved.
> 
Ian Ozsvald of ShowMeDo.com noticed a blog post of mine about this beta, 
and responded as follows:

> Re. http://holdenweb.blogspot.com/2008/07/cpython-getting-serious-about-quality.html
> If someone on the dev side wanted to make a 5-10 minute 'cast on how to check out the python base, build it, test it, check stuff back in, we'd be honoured to host it.  Obviously the entire process deserves more attention but a short overview pointing out the key steps would be:
> 1) simple for the author to create
> 2) easy for possible contributors to watch and receive inspiration
> 3) powerful enough to attract another set of developers into the fold
> so that might be a useful, low-cost, quick win to help with the current effort?

I'd do this myself but a) I'm not the obvious candidate and b) I'm too 
busy to give it my attention now.

If someone wanted to tackle this, it might help getting people testing 
for the next beta, and also to recruit more testers in the long-term.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From guido at python.org  Thu Jul 17 16:07:09 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 17 Jul 2008 07:07:09 -0700
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <4222a8490807170616x5ca600fdw3e6d0bced885c943@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<4222a8490807170616x5ca600fdw3e6d0bced885c943@mail.gmail.com>
Message-ID: <ca471dc20807170707y2f40e5e3lf4af011e8219b096@mail.gmail.com>

On Thu, Jul 17, 2008 at 6:16 AM, Jesse Noller <jnoller at gmail.com> wrote:
> 3375: Guido (thanks guido) looked into this, and while I banged my
> head on it a lot yesterday - guido's identified the issue, and now I
> need to figure out a fix - help is welcome on this one.

You're welcome. I would have never found this if I hadn't had a
heightened awareness of the sys.path_importer_cache variable recently,
due to implementing a zipimport.py for Google App Engine. :-)

I can try looking for a fix later today (in a few hours). A very crude
fix would be to just remove all keys that have NullImporter values
from that variable just before attempting to import the module that
was just built. I'm hoping for something subtler though; I wonder if
there's an identifyable point where the lib directory got created.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From jnoller at gmail.com  Thu Jul 17 17:36:34 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Thu, 17 Jul 2008 11:36:34 -0400
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <ca471dc20807170707y2f40e5e3lf4af011e8219b096@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<4222a8490807170616x5ca600fdw3e6d0bced885c943@mail.gmail.com>
	<ca471dc20807170707y2f40e5e3lf4af011e8219b096@mail.gmail.com>
Message-ID: <4222a8490807170836o1875cef4u8b42d3e7edb1160b@mail.gmail.com>

On Thu, Jul 17, 2008 at 10:07 AM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Jul 17, 2008 at 6:16 AM, Jesse Noller <jnoller at gmail.com> wrote:
>> 3375: Guido (thanks guido) looked into this, and while I banged my
>> head on it a lot yesterday - guido's identified the issue, and now I
>> need to figure out a fix - help is welcome on this one.
>
> You're welcome. I would have never found this if I hadn't had a
> heightened awareness of the sys.path_importer_cache variable recently,
> due to implementing a zipimport.py for Google App Engine. :-)
>
> I can try looking for a fix later today (in a few hours). A very crude
> fix would be to just remove all keys that have NullImporter values
> from that variable just before attempting to import the module that
> was just built. I'm hoping for something subtler though; I wonder if
> there's an identifyable point where the lib directory got created.
>

An additional note for anyone else - this is only under py3k - trunk
is perfectly fine.

From musiccomposition at gmail.com  Thu Jul 17 17:41:37 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 17 Jul 2008 10:41:37 -0500
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
Message-ID: <1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>

On Wed, Jul 16, 2008 at 11:30 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We have green buildbots, yay!  Thanks everyone for that.

The Windows buildbots are not very happy, though. test_ssl and
test_bsddb and constantly failing on both the trunk and py3k. I don't
know much about either of these items (or Windows for that matter), so
any help would be greatly appreciated.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From guido at python.org  Thu Jul 17 18:27:58 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 17 Jul 2008 09:27:58 -0700
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <4222a8490807170836o1875cef4u8b42d3e7edb1160b@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<4222a8490807170616x5ca600fdw3e6d0bced885c943@mail.gmail.com>
	<ca471dc20807170707y2f40e5e3lf4af011e8219b096@mail.gmail.com>
	<4222a8490807170836o1875cef4u8b42d3e7edb1160b@mail.gmail.com>
Message-ID: <ca471dc20807170927g1b7c810r1cad09bf1e1a93dd@mail.gmail.com>

On Thu, Jul 17, 2008 at 8:36 AM, Jesse Noller <jnoller at gmail.com> wrote:
> On Thu, Jul 17, 2008 at 10:07 AM, Guido van Rossum <guido at python.org> wrote:
>> On Thu, Jul 17, 2008 at 6:16 AM, Jesse Noller <jnoller at gmail.com> wrote:
>>> 3375: Guido (thanks guido) looked into this, and while I banged my
>>> head on it a lot yesterday - guido's identified the issue, and now I
>>> need to figure out a fix - help is welcome on this one.
>>
>> You're welcome. I would have never found this if I hadn't had a
>> heightened awareness of the sys.path_importer_cache variable recently,
>> due to implementing a zipimport.py for Google App Engine. :-)
>>
>> I can try looking for a fix later today (in a few hours). A very crude
>> fix would be to just remove all keys that have NullImporter values
>> from that variable just before attempting to import the module that
>> was just built. I'm hoping for something subtler though; I wonder if
>> there's an identifyable point where the lib directory got created.

I submitted a fix along these lines -- other things I tried did not
work out. The issue is fixed.

> An additional note for anyone else - this is only under py3k - trunk
> is perfectly fine.

Right. I'm thinking that something changed in the massaging of the
default search path, but I can't be bothered to investigate further. I
do know that right after startup there are more non-trivial entries in
sys.path_importer_cache in 3.0 than there are in 2.6.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From janssen at parc.com  Thu Jul 17 18:57:21 2008
From: janssen at parc.com (Bill Janssen)
Date: Thu, 17 Jul 2008 09:57:21 PDT
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com> 
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
Message-ID: <08Jul17.095729pdt."58698"@synergy1.parc.xerox.com>

> test_ssl ... constantly failing on both the trunk and py3k.

I'll take a closer look at this.  It's the new test added in lately.
Seems to be working on non-Windows platforms, so I'm guessing it's
some Windows oddity, which I'm not very good at diagnosing.  Worst
comes to worst, we can take out that test.

Bill

From janssen at parc.com  Thu Jul 17 19:41:32 2008
From: janssen at parc.com (Bill Janssen)
Date: Thu, 17 Jul 2008 10:41:32 PDT
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <08Jul17.095729pdt."58698"@synergy1.parc.xerox.com> 
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<08Jul17.095729pdt."58698"@synergy1.parc.xerox.com>
Message-ID: <08Jul17.104140pdt."58698"@synergy1.parc.xerox.com>

> > test_ssl ... constantly failing on both the trunk and py3k.
> 
> I'll take a closer look at this.  It's the new test added in lately.
> Seems to be working on non-Windows platforms, so I'm guessing it's
> some Windows oddity, which I'm not very good at diagnosing.  Worst
> comes to worst, we can take out that test.

It looks like the handshake code in _ssl.c is returning this Windows
error (I'm looking at the trunk):

ERROR: testWrongCert (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_ssl.py", line 807, in testWrongCert
    "wrongcert.pem"))
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_ssl.py", line 597, in badCertTest
    s.connect((HOST, server.port))
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\ssl.py", line 272, in connect
    self.do_handshake()
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\ssl.py", line 256, in do_handshake
    self._sslobj.do_handshake()
error: [Errno 10054] An existing connection was forcibly closed by the remote host

Error 10054 is WSAECONNRESET, according to Google.

Arguably, it's an error in this scrap of _ssl.c:

	} else if (ret == -1) {
	  /* underlying BIO reported an I/O error */
          return obj->Socket->errorhandler();
        }

I should be checking for EOF error returns like this one from Socket,
and returning an PY_SSL_ERROR_EOF exception.  Is there a list somewhere
of what EOF errors are signalled by Socket?

Bill

From jnoller at gmail.com  Thu Jul 17 19:45:44 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Thu, 17 Jul 2008 13:45:44 -0400
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <4222a8490807170616x5ca600fdw3e6d0bced885c943@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<4222a8490807170616x5ca600fdw3e6d0bced885c943@mail.gmail.com>
Message-ID: <4222a8490807171045y17b7252sfc99e1fe67e4f1d6@mail.gmail.com>

On Thu, Jul 17, 2008 at 9:16 AM, Jesse Noller <jnoller at gmail.com> wrote:
> On Thu, Jul 17, 2008 at 12:30 AM, Barry Warsaw <barry at python.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> We have green buildbots, yay!  Thanks everyone for that.
>>
>> However, we still have three release blocker issues that I am not
>> comfortable deferring.
>>
>> 3088 test_multiprocessing hangs intermittently on POSIX platforms
>> 3375 _multiprocessing.so build problems
>> 874900 threading module can deadlock after fork
>>
>> My biggest concern is 3375 and 3088, the latter has a dependency on 874900.
>>
>> 3375 is very strange since a subsequent 'make' completes just fine.  This
>> issue happens for me on both OS X 10.5 and Ubuntu 8.04 for py3k.
>>
>> 3088 does not appear to be happening now on OS X or Ubuntu, but the issue
>> (and its dependent issue) are not closed, so I'm not sure exactly what's
>> going on here.
>>
>> So we'll give these releases another 24 hours.  Please, if you have time see
>> what you can do about resolving these three blockers.  Chat with me on
>> #python-dev if you think we should release anyway.  I will try to look into
>> 3375, but I'd like to know if anybody else is seeing these build failures.
>>
>> I'll note that I plan to hold the beta3 releases until all release blocker
>> and deferred blockers are resolved.
>>
>> - -Barry
>>
>
> Quick status update, since I'm the gating factor.
>
> 3088: I didn't want to close this until 874900's patch was submitted,
> ported to py3k and I saw green build bots. By the time I went to sleep
> last night, we were still seeing 2to3 test timeouts on the build bots.
> I will port the patch to 3k today and lower the priority of 874900 and
> close 3088 shortly.
>
> 3375: Guido (thanks guido) looked into this, and while I banged my
> head on it a lot yesterday - guido's identified the issue, and now I
> need to figure out a fix - help is welcome on this one.
>
> I apologize for not getting these resolved last night
>
> -jesse
>

Just to close the loop - 3088 is closed now, and 874900 is on py3k,
therefore lowered from a release blocker for now (it needs to remain
open to finish resolving a few issues)

Guido fixed 3375 (thanks again)

-jesse

From janssen at parc.com  Thu Jul 17 20:18:34 2008
From: janssen at parc.com (Bill Janssen)
Date: Thu, 17 Jul 2008 11:18:34 PDT
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com> 
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
Message-ID: <08Jul17.111840pdt."58698"@synergy1.parc.xerox.com>

> The Windows buildbots are not very happy, though. test_ssl ...
> constantly failing on both the trunk and py3k.

I've checked in patches for test_ssl on both branches.  Let's see how
the Windows buildbots do.

Bill

From solipsis at pitrou.net  Thu Jul 17 23:14:06 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 17 Jul 2008 21:14:06 +0000 (UTC)
Subject: [Python-3000] Review desired for 2523: binary buffered reading is
	quadratic
Message-ID: <loom.20080717T210937-524@post.gmane.org>


Hi,

it would be nice if someone could take a look at the patch for issue 2523. Right
now it takes py3k 30 seconds at 100% CPU to read a 10MB binary file.

Thanks

Antoine.



From tjreedy at udel.edu  Fri Jul 18 00:38:00 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 Jul 2008 18:38:00 -0400
Subject: [Python-3000] Undocumented new bytecodes (issue 3400)
Message-ID: <g5ohk7$a9r$1@ger.gmane.org>

http://bugs.python.org/issue3400

dis / Python Bytecode Instructions doc is missing entries for
UNPACK_EX
STORE_LOCALS
LOAD_BUILD_CLASS
MAKE_BYTES
which appear in dis.opname (3.0 version).

Based on examples, I suggested that the UNPACK_SEQUENCE entry be followed by

UNPACK_EX(bytepair)
Used for starred assignment.  Similar to UNPACK_SEQUENCE except 1) the
lo and hi bytes of the argument are the number of unstarred targets
before and after the starred target and 2) the values between the first
lo and last hi are collected into a list for the starred target.

Could a bytecode expert confirm the above and confirm the validity* of 
and suggest entries for the other three?

*(I am puzzled by MAKE_BYTES especially since there is otherwise only 
MAKE_FUNCTION and _CLOSURE but BUILD_MAP, _SET, _LIST, _TUPLE, _SLICE, 
and _CLASS and neither for _STRING)

Terry Jan Reedy


From martin at v.loewis.de  Fri Jul 18 01:27:08 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 18 Jul 2008 01:27:08 +0200
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
Message-ID: <487FD54C.2040308@v.loewis.de>

> The Windows buildbots are not very happy, though. test_ssl and
> test_bsddb and constantly failing on both the trunk and py3k. I don't
> know much about either of these items (or Windows for that matter), so
> any help would be greatly appreciated.

bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
3k. I somewhat doubt that this gets resolved before the release, so
bsddb users might need to skip 3.0.

Regards,
Martin

From musiccomposition at gmail.com  Fri Jul 18 02:06:37 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 17 Jul 2008 19:06:37 -0500
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <487FD54C.2040308@v.loewis.de>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
Message-ID: <1afaf6160807171706p8c2b226wc7bd8d0a072840fa@mail.gmail.com>

On Thu, Jul 17, 2008 at 6:27 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> The Windows buildbots are not very happy, though. test_ssl and
>> test_bsddb and constantly failing on both the trunk and py3k. I don't
>> know much about either of these items (or Windows for that matter), so
>> any help would be greatly appreciated.
>
> bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
> 3k. I somewhat doubt that this gets resolved before the release, so
> bsddb users might need to skip 3.0.

Ok. ssl has stopped failing now (Thanks Bill). test_wsgiref is failing
on the trunk, but as it is an externally maintained module, there
isn't much I can do about it. (see issue #3401). Overall, though, I
think we've done what we can here, so these shouldn't hold up the
release.

>
> Regards,
> Martin
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From barry at python.org  Fri Jul 18 04:13:33 2008
From: barry at python.org (barry at python.org)
Date: Thu, 17 Jul 2008 22:13:33 -0400
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <487FD54C.2040308@v.loewis.de>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
Message-ID: <20080717221333.1d61bfe1@mission.wooz.org>

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

On Jul 18, 2008, at 01:27 AM, Martin v. L?wis wrote:

>> The Windows buildbots are not very happy, though. test_ssl and
>> test_bsddb and constantly failing on both the trunk and py3k. I don't
>> know much about either of these items (or Windows for that matter), so
>> any help would be greatly appreciated.
>
>bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
>3k. I somewhat doubt that this gets resolved before the release, so
>bsddb users might need to skip 3.0.

We have no showstoppers and several green buildbots, so I'm going to make the
releases tonight.  Please, NO CHECKINS until I say so, or ping me on
#python-dev.

As for bsddb, we'll make a determination after beta3.  If it's terminally
busted for Python 3.0, so be it.

Thanks everyone for working so hard at getting beta2 ready.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIf/xT2YZpQepbvXERAtmoAKCyUkejAFxFG10Bsn/CJjZfGy0B9QCeMO0z
momJmXRLCdmxs84j2hXGrTY=
=Y3wS
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jul 18 04:16:38 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Jul 2008 22:16:38 -0400
Subject: [Python-3000] No beta2 tonight
In-Reply-To: <487F4FAE.3050600@holdenweb.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<487F4FAE.3050600@holdenweb.com>
Message-ID: <20080717221638.226ae4ee@mission.wooz.org>

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

On Jul 17, 2008, at 09:57 AM, Steve Holden wrote:

>Barry Warsaw wrote:
>[...]
>> 
>> I'll note that I plan to hold the beta3 releases until all release 
>> blocker and deferred blockers are resolved.
>> 
>Ian Ozsvald of ShowMeDo.com noticed a blog post of mine about this beta, 
>and responded as follows:
>
>> Re. http://holdenweb.blogspot.com/2008/07/cpython-getting-serious-about-quality.html
>> If someone on the dev side wanted to make a 5-10 minute 'cast on how to check out the python base, build it, test it, check stuff back in, we'd be honoured to host it.  Obviously the entire process deserves more attention but a short overview pointing out the key steps would be:
>> 1) simple for the author to create
>> 2) easy for possible contributors to watch and receive inspiration
>> 3) powerful enough to attract another set of developers into the fold
>> so that might be a useful, low-cost, quick win to help with the current effort?
>
>I'd do this myself but a) I'm not the obvious candidate and b) I'm too 
>busy to give it my attention now.
>
>If someone wanted to tackle this, it might help getting people testing 
>for the next beta, and also to recruit more testers in the long-term.

It's a great idea, but unfortunately I also don't have time to do this right
now.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIf/0G2YZpQepbvXERAtNzAJ9Os117wAD8KCkhkt6x+jhKuJ4snwCfbjXS
VtkFGzUUTzg+ersqU3+TObg=
=jdUf
-----END PGP SIGNATURE-----

From fdrake at acm.org  Fri Jul 18 04:30:38 2008
From: fdrake at acm.org (Fred Drake)
Date: Thu, 17 Jul 2008 22:30:38 -0400
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <487FD54C.2040308@v.loewis.de>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
Message-ID: <0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>

On Jul 17, 2008, at 7:27 PM, Martin v. L?wis wrote:
> bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
> 3k. I somewhat doubt that this gets resolved before the release, so
> bsddb users might need to skip 3.0.


In fact, bsddb as packages in core Python has rarely been in good shape.

Has anyone actually considered that bsddb might do better if  
maintained strictly as an external package?  That would make it easier  
for the any maintainers to release updates, and removes a source of  
frustration for users who either don't need it or would rather wait  
for a happier version.

I think this is worth considering.  I vaguely recall that the bsddb  
module was maintained before it was incorporated into the core Python  
release.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From guido at python.org  Fri Jul 18 04:37:32 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 17 Jul 2008 19:37:32 -0700
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
Message-ID: <ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>

On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake <fdrake at acm.org> wrote:
> On Jul 17, 2008, at 7:27 PM, Martin v. L?wis wrote:
>>
>> bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
>> 3k. I somewhat doubt that this gets resolved before the release, so
>> bsddb users might need to skip 3.0.
>
>
> In fact, bsddb as packages in core Python has rarely been in good shape.
>
> Has anyone actually considered that bsddb might do better if maintained
> strictly as an external package?  That would make it easier for the any
> maintainers to release updates, and removes a source of frustration for
> users who either don't need it or would rather wait for a happier version.
>
> I think this is worth considering.  I vaguely recall that the bsddb module
> was maintained before it was incorporated into the core Python release.

+1. In my recollection maintaining bsddb has been nothing but trouble
right from the start when we were all sitting together at "Zope Corp
North" in a rented office in McLean... We can remove it from 3.0. We
can't really remove it from 2.6, but we can certainly start
end-of-lifing it in 2.6.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From barry at python.org  Fri Jul 18 04:51:06 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Jul 2008 22:51:06 -0400
Subject: [Python-3000] NO CHECKINS - BETA 2 COMING
Message-ID: <8914AB44-1B5D-45B9-9EB9-DDC728B1B032@python.org>

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

Please, no checkins on the 3.0 or 2.6 branches until further notice.   
We're a go with the releases tonight.  Email is not the quickest way  
to get my attention.  For that, use irc on freenode, #python-dev.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSIAFGnEjvBPtnXfVAQIBmwP/VzIYu58DzSND0CNM0NKfsWVS9yTnBVi8
EijaxenUv0rRVloCawJbK8cMOyI0JmEa4GE5bMrCf+o9niRgFeJxrYEaw1jN4fWW
dsXH8Fuw/nHpoUnFDbu5ePaBdvcOSuWKTS/iGq2i9DzfYXdx+FaXqZ/mhx43bY3o
eCF7I+y/fPg=
=iTgT
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jul 18 04:52:40 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Jul 2008 22:52:40 -0400
Subject: [Python-3000] [Python-Dev]   No beta2 tonight
In-Reply-To: <ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
Message-ID: <EA2CA734-E0D1-49AB-8E14-1AE30082F971@python.org>

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

On Jul 17, 2008, at 10:37 PM, Guido van Rossum wrote:

> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake <fdrake at acm.org> wrote:
>> On Jul 17, 2008, at 7:27 PM, Martin v. L?wis wrote:
>>>
>>> bsddb is in a very bad shape, as the 2.6 code hasn't been merged  
>>> into
>>> 3k. I somewhat doubt that this gets resolved before the release, so
>>> bsddb users might need to skip 3.0.
>>
>>
>> In fact, bsddb as packages in core Python has rarely been in good  
>> shape.
>>
>> Has anyone actually considered that bsddb might do better if  
>> maintained
>> strictly as an external package?  That would make it easier for the  
>> any
>> maintainers to release updates, and removes a source of frustration  
>> for
>> users who either don't need it or would rather wait for a happier  
>> version.
>>
>> I think this is worth considering.  I vaguely recall that the bsddb  
>> module
>> was maintained before it was incorporated into the core Python  
>> release.
>
> +1. In my recollection maintaining bsddb has been nothing but trouble
> right from the start when we were all sitting together at "Zope Corp
> North" in a rented office in McLean... We can remove it from 3.0. We
> can't really remove it from 2.6, but we can certainly start
> end-of-lifing it in 2.6.

+1, but please, after I make tonight's releases. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSIAFenEjvBPtnXfVAQKEewP+OWCBAH437X4+EptdcuIFFYrCCVXqbrV4
F2dZMyv/RU0jYgd6YTLspklEIzuEcH1sxYsnh2q4aWNfFlfL50LPf1/TKurZpO2C
9CrjEZpTcK0k5z5FCxAOLdVFLQDC4w7FGYop3uR27g5u9KCLdQvTrPs/mZllv263
/g2YdwhZFEE=
=NAOe
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jul 18 05:42:31 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Jul 2008 23:42:31 -0400
Subject: [Python-3000] RELEASED Python 2.6b2 and 3.0b2
Message-ID: <E9E66405-B49F-479C-A9E4-47F48FBF1AA5@python.org>

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

On behalf of the Python development team and the Python community, I  
am happy to announce the second beta releases of Python 2.6 and Python  
3.0.

Please note that these are beta releases, and as such are not suitable  
for production environments.  We continue to strive for a high degree  
of quality, and these releases are intended to freeze the feature set  
for Python 2.6 and 3.0.

 From now until the planned final releases in October 2008, we will be  
fixing known problems and stabilizing these new Python versions.  You  
can help by downloading and testing them, providing feedback and  
hopefully helping to fix bugs.  You can also use these releases to  
determine how changes in 2.6 and 3.0 might impact you.

ONLY ONE MORE BETA RELEASE IS PLANNED, so now is a great time to  
download the releases and try them with your code.  If you find things  
broken or incorrect, please submit bug reports at

     http://bugs.python.org

For more information and downloadable distributions, see the Python  
2.6 website:

     http://www.python.org/download/releases/2.6/

and the Python 3.0 web site:

     http://www.python.org/download/releases/3.0/

See PEP 361 for release schedule details:

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

Enjoy,
- -Barry

Barry Warsaw
barry at python.org
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSIARKHEjvBPtnXfVAQL7AQQAjPSbfKz2Oh/au/hPzS4x2IR5/R6FVe+g
o9UYrONNRKJ14UHpbZRzvIvw/4G3PdpzzGxjYFIhVGEesEGJnMzT3YdkMHt4NW9d
HOZxL3hseGbTdpUJPCsIkNG+4hX7iuY3NSV81Z75LGAL4tqbooGqwwUslXMT5f8s
lRrZUcBRKZ0=
=ju6s
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jul 18 05:50:24 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Jul 2008 23:50:24 -0400
Subject: [Python-3000] SVN IS OPEN
Message-ID: <B34131B7-30CE-44B9-9B45-7BB71F9562E2@python.org>

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

The releases have been made, so both the 3.0 branch and the trunk  
(2.6) are now open for commits.  Remember, there's only one more  
planned beta, and we /really/ want to try to hit the October 1st  
deadline.  Let's do everything we can to stabilize these releases,  
address the blockers, and turn those buildbots green.

Thanks everyone.
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSIATAHEjvBPtnXfVAQIWLAP+OVUXh3H5j8WN4cm3fHcLkgd+E4FuWWwb
zKr7JPYUHhgvwpYB5iZjQuJe/62qKXh70wNWyDcxLi9/TEbx8NvhQ+nMbHAJkfE2
1/HkP9bbgiwE/JYJsN0a0DK/MSpwvxfxxakQrQV9H8SiL5aDqlVCFdzLu31SkOhx
iQ+iTCqwIdY=
=UOPo
-----END PGP SIGNATURE-----

From guido at python.org  Fri Jul 18 06:05:35 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 17 Jul 2008 21:05:35 -0700
Subject: [Python-3000] [Python-Dev] SVN IS OPEN
In-Reply-To: <B34131B7-30CE-44B9-9B45-7BB71F9562E2@python.org>
References: <B34131B7-30CE-44B9-9B45-7BB71F9562E2@python.org>
Message-ID: <ca471dc20807172105u50b686aya2c7be22679b9690@mail.gmail.com>

On Thu, Jul 17, 2008 at 8:50 PM, Barry Warsaw <barry at python.org> wrote:
> The releases have been made, so both the 3.0 branch and the trunk (2.6) are
> now open for commits.  Remember, there's only one more planned beta, and we
> /really/ want to try to hit the October 1st deadline.  Let's do everything
> we can to stabilize these releases, address the blockers, and turn those
> buildbots green.

Thanks Barry! Indeed, I want everyone to focus on stabilization and
release blockers (and the occasional speed-up). Be extra careful with
what you submit between now and October, ask for a code review unless
you're really sure. Also, remember, NO NEW FEATURES!

> Thanks everyone.
> - -Barry

And thanks Barry for doing the release!!!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From brett at python.org  Fri Jul 18 07:43:15 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 17 Jul 2008 22:43:15 -0700
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
Message-ID: <bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>

On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake <fdrake at acm.org> wrote:
>> On Jul 17, 2008, at 7:27 PM, Martin v. L?wis wrote:
>>>
>>> bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
>>> 3k. I somewhat doubt that this gets resolved before the release, so
>>> bsddb users might need to skip 3.0.
>>
>>
>> In fact, bsddb as packages in core Python has rarely been in good shape.
>>
>> Has anyone actually considered that bsddb might do better if maintained
>> strictly as an external package?  That would make it easier for the any
>> maintainers to release updates, and removes a source of frustration for
>> users who either don't need it or would rather wait for a happier version.
>>
>> I think this is worth considering.  I vaguely recall that the bsddb module
>> was maintained before it was incorporated into the core Python release.
>
> +1. In my recollection maintaining bsddb has been nothing but trouble
> right from the start when we were all sitting together at "Zope Corp
> North" in a rented office in McLean... We can remove it from 3.0. We
> can't really remove it from 2.6, but we can certainly start
> end-of-lifing it in 2.6.
>

Unless I hear otherwise, I will add it to PEP 3108.

-Brett

From guido at python.org  Fri Jul 18 16:21:45 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 18 Jul 2008 07:21:45 -0700
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
Message-ID: <ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>

On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon <brett at python.org> wrote:
> On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum <guido at python.org> wrote:
>> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake <fdrake at acm.org> wrote:
>>> On Jul 17, 2008, at 7:27 PM, Martin v. L?wis wrote:
>>>>
>>>> bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
>>>> 3k. I somewhat doubt that this gets resolved before the release, so
>>>> bsddb users might need to skip 3.0.
>>>
>>>
>>> In fact, bsddb as packages in core Python has rarely been in good shape.
>>>
>>> Has anyone actually considered that bsddb might do better if maintained
>>> strictly as an external package?  That would make it easier for the any
>>> maintainers to release updates, and removes a source of frustration for
>>> users who either don't need it or would rather wait for a happier version.
>>>
>>> I think this is worth considering.  I vaguely recall that the bsddb module
>>> was maintained before it was incorporated into the core Python release.
>>
>> +1. In my recollection maintaining bsddb has been nothing but trouble
>> right from the start when we were all sitting together at "Zope Corp
>> North" in a rented office in McLean... We can remove it from 3.0. We
>> can't really remove it from 2.6, but we can certainly start
>> end-of-lifing it in 2.6.

> Unless I hear otherwise, I will add it to PEP 3108.

Please do!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From josiah.carlson at gmail.com  Fri Jul 18 16:57:01 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Fri, 18 Jul 2008 07:57:01 -0700
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
Message-ID: <e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>

On Fri, Jul 18, 2008 at 7:21 AM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon <brett at python.org> wrote:
>> On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum <guido at python.org> wrote:
>>> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake <fdrake at acm.org> wrote:
>>>> On Jul 17, 2008, at 7:27 PM, Martin v. L?wis wrote:
>>>>>
>>>>> bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
>>>>> 3k. I somewhat doubt that this gets resolved before the release, so
>>>>> bsddb users might need to skip 3.0.
>>>>
>>>>
>>>> In fact, bsddb as packages in core Python has rarely been in good shape.
>>>>
>>>> Has anyone actually considered that bsddb might do better if maintained
>>>> strictly as an external package?  That would make it easier for the any
>>>> maintainers to release updates, and removes a source of frustration for
>>>> users who either don't need it or would rather wait for a happier version.
>>>>
>>>> I think this is worth considering.  I vaguely recall that the bsddb module
>>>> was maintained before it was incorporated into the core Python release.
>>>
>>> +1. In my recollection maintaining bsddb has been nothing but trouble
>>> right from the start when we were all sitting together at "Zope Corp
>>> North" in a rented office in McLean... We can remove it from 3.0. We
>>> can't really remove it from 2.6, but we can certainly start
>>> end-of-lifing it in 2.6.
>
>> Unless I hear otherwise, I will add it to PEP 3108.
>
> Please do!

Invariably, when someone goes and removes a module, someone else is
going to complain, "but I used feature X, not having feature X will
break my code."  We, as maintainers can then say, "if you cared,
maintain it."  But I'm not sure that is the greatest thing to tell
people.  I suspect that we may have to include some sort of
"work-alike" for 2.7 and if not 3.0, 3.1 .  If I were to vote for a
work-alike, it would be based on sqlite.  For one of the most common
use-cases (bsddb.btree), simple sqlite code can be written to do the
right thing.  Recno is a little more tricky, but can also be done.
The bsddb hash may not be possible, because sqlite doesn't support
hashed indices :/.

Just an idea.

 - Josiah

From guido at python.org  Fri Jul 18 17:11:06 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 18 Jul 2008 08:11:06 -0700
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>
Message-ID: <ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>

On Fri, Jul 18, 2008 at 7:57 AM, Josiah Carlson
<josiah.carlson at gmail.com> wrote:
> Invariably, when someone goes and removes a module, someone else is
> going to complain, "but I used feature X, not having feature X will
> break my code."  We, as maintainers can then say, "if you cared,
> maintain it."  But I'm not sure that is the greatest thing to tell
> people.  I suspect that we may have to include some sort of
> "work-alike" for 2.7 and if not 3.0, 3.1 .  If I were to vote for a
> work-alike, it would be based on sqlite.  For one of the most common
> use-cases (bsddb.btree), simple sqlite code can be written to do the
> right thing.  Recno is a little more tricky, but can also be done.
> The bsddb hash may not be possible, because sqlite doesn't support
> hashed indices :/.

In my mind, BSDDB is pretty much the most heavy-weight extension we're
maintaining. I think it's an illusion that a sqlite-based look-alike
is going to fool anyone. The correct solution is to take support for
bsddb to a separate project where those who care about it can maintain
it together. That also makes it a lot easier to track the versions of
Berkeley DB as they come out.

Of course, you're free to try writing the work-alike you're proposing. :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From josiah.carlson at gmail.com  Fri Jul 18 19:45:06 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Fri, 18 Jul 2008 10:45:06 -0700
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>
	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>
Message-ID: <e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>

On Fri, Jul 18, 2008 at 8:11 AM, Guido van Rossum <guido at python.org> wrote:
> On Fri, Jul 18, 2008 at 7:57 AM, Josiah Carlson
> <josiah.carlson at gmail.com> wrote:
>> Invariably, when someone goes and removes a module, someone else is
>> going to complain, "but I used feature X, not having feature X will
>> break my code."  We, as maintainers can then say, "if you cared,
>> maintain it."  But I'm not sure that is the greatest thing to tell
>> people.  I suspect that we may have to include some sort of
>> "work-alike" for 2.7 and if not 3.0, 3.1 .  If I were to vote for a
>> work-alike, it would be based on sqlite.  For one of the most common
>> use-cases (bsddb.btree), simple sqlite code can be written to do the
>> right thing.  Recno is a little more tricky, but can also be done.
>> The bsddb hash may not be possible, because sqlite doesn't support
>> hashed indices :/.
>
> In my mind, BSDDB is pretty much the most heavy-weight extension we're
> maintaining. I think it's an illusion that a sqlite-based look-alike
> is going to fool anyone. The correct solution is to take support for
> bsddb to a separate project where those who care about it can maintain
> it together. That also makes it a lot easier to track the versions of
> Berkeley DB as they come out.
>
> Of course, you're free to try writing the work-alike you're proposing. :-)

It's entirely possible that I know very little about what was being
made available via the bsddb module, but to match the API of what is
included in the documentation (plus the dictionary interface that it
supports) shouldn't be terribly difficult.

Now, if there were *other* things that were undocumented, well,
there's not much I can do about those. ;)

 - Josiah

From fdrake at acm.org  Fri Jul 18 20:03:27 2008
From: fdrake at acm.org (Fred Drake)
Date: Fri, 18 Jul 2008 14:03:27 -0400
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>
	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>
	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>
Message-ID: <F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>

On Jul 18, 2008, at 1:45 PM, Josiah Carlson wrote:
> It's entirely possible that I know very little about what was being
> made available via the bsddb module, but to match the API of what is
> included in the documentation (plus the dictionary interface that it
> supports) shouldn't be terribly difficult.


It's also entirely possible that the API isn't interesting if you  
don't support existing databases, for many applications.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>


From brett at python.org  Fri Jul 18 20:04:17 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 18 Jul 2008 11:04:17 -0700
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
Message-ID: <bbaeab100807181104ra7e7cdcl98183746e0016daa@mail.gmail.com>

On Fri, Jul 18, 2008 at 7:21 AM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon <brett at python.org> wrote:
>> On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum <guido at python.org> wrote:
>>> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake <fdrake at acm.org> wrote:
>>>> On Jul 17, 2008, at 7:27 PM, Martin v. L?wis wrote:
>>>>>
>>>>> bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
>>>>> 3k. I somewhat doubt that this gets resolved before the release, so
>>>>> bsddb users might need to skip 3.0.
>>>>
>>>>
>>>> In fact, bsddb as packages in core Python has rarely been in good shape.
>>>>
>>>> Has anyone actually considered that bsddb might do better if maintained
>>>> strictly as an external package?  That would make it easier for the any
>>>> maintainers to release updates, and removes a source of frustration for
>>>> users who either don't need it or would rather wait for a happier version.
>>>>
>>>> I think this is worth considering.  I vaguely recall that the bsddb module
>>>> was maintained before it was incorporated into the core Python release.
>>>
>>> +1. In my recollection maintaining bsddb has been nothing but trouble
>>> right from the start when we were all sitting together at "Zope Corp
>>> North" in a rented office in McLean... We can remove it from 3.0. We
>>> can't really remove it from 2.6, but we can certainly start
>>> end-of-lifing it in 2.6.
>
>> Unless I hear otherwise, I will add it to PEP 3108.
>
> Please do!
>

Done.

-Brett

From ncoghlan at gmail.com  Fri Jul 18 20:16:57 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Jul 2008 04:16:57 +1000
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>	<487FD54C.2040308@v.loewis.de>	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>
	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
Message-ID: <4880DE19.7050704@gmail.com>

Fred Drake wrote:
> On Jul 18, 2008, at 1:45 PM, Josiah Carlson wrote:
>> It's entirely possible that I know very little about what was being
>> made available via the bsddb module, but to match the API of what is
>> included in the documentation (plus the dictionary interface that it
>> supports) shouldn't be terribly difficult.
> 
> 
> It's also entirely possible that the API isn't interesting if you don't 
> support existing databases, for many applications.

And downloading pybsddb and installing really shouldn't be all that 
difficult :)

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From josiah.carlson at gmail.com  Fri Jul 18 21:15:42 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Fri, 18 Jul 2008 12:15:42 -0700
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>
	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>
	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>
	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
Message-ID: <e6511dbf0807181215r4774dae9i3c10f128be83c93c@mail.gmail.com>

On Fri, Jul 18, 2008 at 11:03 AM, Fred Drake <fdrake at acm.org> wrote:
> On Jul 18, 2008, at 1:45 PM, Josiah Carlson wrote:
>>
>> It's entirely possible that I know very little about what was being
>> made available via the bsddb module, but to match the API of what is
>> included in the documentation (plus the dictionary interface that it
>> supports) shouldn't be terribly difficult.
>
>
> It's also entirely possible that the API isn't interesting if you don't
> support existing databases, for many applications.

I see where the confusion was.  I'm not suggesting that someone write
a new bsddb module, I'm suggesting that we can provide something
called, perhaps, on_disk_dictionary, which offers the behavior of
bsddb, without using bsddb anywhere, or supporting bsddb files.

 - Josiah

From stephen at xemacs.org  Fri Jul 18 21:06:01 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 19 Jul 2008 04:06:01 +0900
Subject: [Python-3000] [Python-Dev]    No beta2 tonight
In-Reply-To: <4880DE19.7050704@gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>
	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>
	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>
	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
	<4880DE19.7050704@gmail.com>
Message-ID: <87ljzzovvq.fsf@uwakimon.sk.tsukuba.ac.jp>

Nick Coghlan writes:

 > And downloading pybsddb and installing really shouldn't be all that 
 > difficult :)

It shouldn't be, but lots of "enterprise"[1] environments will require
qualifying the "new" package according to corporate standards.

I won't argue that this is a sufficient reason to keep a package with
bsddb's history in stdlib, but let's not joke about the difficulties.


Footnotes: 
[1]  Which apparently means that the company can be enterprising, but
the people who do the work mustn't be!


From jcea at jcea.es  Sat Jul 19 03:41:32 2008
From: jcea at jcea.es (Jesus Cea)
Date: Sat, 19 Jul 2008 03:41:32 +0200
Subject: [Python-3000] [Python-Dev] No beta2 tonight
In-Reply-To: <487FD54C.2040308@v.loewis.de>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
Message-ID: <4881464C.3000908@jcea.es>

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

Martin v. L?wis wrote:
| bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
| 3k. I somewhat doubt that this gets resolved before the release, so
| bsddb users might need to skip 3.0.

Working on the 3.0 port just now. 03:40 in the morning, in Spain.

bsddb will be ready for python 3.0.

(writting this while compiling new 2.6 and 3.0 beta2 :-) )

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIFGTJlgi5GaxT1NAQKTBAP/f2AiHwEmMCSE6xhYVKj/0Rkh3A9/7XWG
f8CrJ8Dn//QoG7+FZ63mF1BoT9aJ3RGUIrkIePe7+XJUpa8Fq264sQMoz94Estkc
KyzSN69j+O9fTBGdI3PByFuCkfrrcl3+i0sEg0WQylOzzTpEfwKcRT5hGG2qb8c1
RZKV8BxQVXA=
=4fO2
-----END PGP SIGNATURE-----

From jcea at jcea.es  Sat Jul 19 03:36:27 2008
From: jcea at jcea.es (Jesus Cea)
Date: Sat, 19 Jul 2008 03:36:27 +0200
Subject: [Python-3000] [Python-Dev]  No beta2 tonight
In-Reply-To: <bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>	<487FD54C.2040308@v.loewis.de>	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
Message-ID: <4881451B.9010304@jcea.es>

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

Brett Cannon wrote:
| On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum <guido at python.org>
wrote:
|> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake <fdrake at acm.org> wrote:
|>> On Jul 17, 2008, at 7:27 PM, Martin v. L?wis wrote:
|>>> bsddb is in a very bad shape, as the 2.6 code hasn't been merged into
|>>> 3k. I somewhat doubt that this gets resolved before the release, so
|>>> bsddb users might need to skip 3.0.
|>>
|>> In fact, bsddb as packages in core Python has rarely been in good shape.
|>>
|>> Has anyone actually considered that bsddb might do better if maintained
|>> strictly as an external package?  That would make it easier for the any
|>> maintainers to release updates, and removes a source of frustration for
|>> users who either don't need it or would rather wait for a happier
version.
|>>
|>> I think this is worth considering.  I vaguely recall that the bsddb
module
|>> was maintained before it was incorporated into the core Python release.
|> +1. In my recollection maintaining bsddb has been nothing but trouble
|> right from the start when we were all sitting together at "Zope Corp
|> North" in a rented office in McLean... We can remove it from 3.0. We
|> can't really remove it from 2.6, but we can certainly start
|> end-of-lifing it in 2.6.
|>
|
| Unless I hear otherwise, I will add it to PEP 3108.

03:31 AM in the morning in Spain. Just working in porting bsddb to
python3000. I have a lot of issues compiling the C code and with the
2to3 automated conversion, but I'm pretty sure can get it ready for
october release.

I'm still loooking for a *GOOD* python2->python3 conversion guide for C
language modules.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIFFFJlgi5GaxT1NAQLHlQP/cXmobkxlEs5gL9MRVNOAhcCtmATJqkQd
lpAkzExa+75cQSoP28iIa+GhxRuJJCAz9NxAw22VIkwab/93R1eFYVjdC9jqYprK
gwZsZDHKs12RlRRHFk0562ZDMgtdFB4Ne9iJXsFOKNz6ZvOhMFHfoj/blZyyocsq
zdS6SoxTtXM=
=aIrU
-----END PGP SIGNATURE-----

From mhammond at skippinet.com.au  Sat Jul 19 04:33:29 2008
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 19 Jul 2008 12:33:29 +1000
Subject: [Python-3000] Extension modules moving to py3k (was: No beta2
	tonight)
In-Reply-To: <4881451B.9010304@jcea.es>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>	<487FD54C.2040308@v.loewis.de>	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<4881451B.9010304@jcea.es>
Message-ID: <04f601c8e947$d4d27010$7e775030$@com.au>

Jesus wrote:

> I'm still loooking for a *GOOD* python2->python3 conversion guide for C
> language modules.

I was chatting with Raymond about that recently, and we agreed that this
will be a major challenge for extension authors moving forward.  Strategies
for dealing with your .py code are becoming clearer, but extension code will
be a problem, particularly for projects that can't abandon the 2.x series.
It seems very unlikely a strategy used for py code (eg, maintain in 2.6 and
use a conversion tool for 3.x) will work for C code - but some strategy will
be necessary as extensions become the bottle neck in preventing projects
moving to 3.x (your project only needs to use a single key extension that
doesn't exist on py3k, and your project is stuck)

It seems that it would be a huge help to extension authors if porting tricks
and hacks could be encapsulated in code that everyone can use.  In most
cases some cool tricks in header files might be all that is necessary, but
other cases may require special purpose helper functions designed purely to
aid people trying to keep code working in both environments. 

Roger Upole, one of the main pywin32 contributors, recently started an
attempt at porting pywin32 to py3k, and fell over at some fairly early
hurdles (eg, working out how to move C code that creates and returns buffer
objects to memory views), and I suspect each project will have a number of
unique challenges to overcome - so if we can share the *common* pain and let
them focus on their unique pain, 'dual-porting' efforts would stand a much
greater chance of success.
 
I'd love to help on this (even if the only reason is selfish - I believe
pywin32 will *need* it while 2.x remains important.)  Who would get involved
in such an effort?  How and where can we kick this off?

Cheers,

Mark


From jcea at jcea.es  Sat Jul 19 06:47:14 2008
From: jcea at jcea.es (Jesus Cea)
Date: Sat, 19 Jul 2008 06:47:14 +0200
Subject: [Python-3000] Help replacing Py_FindMethod
Message-ID: <488171D2.5000709@jcea.es>

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

Good night everybody!.

Working on the Python3.0 support for bsddb I see that "Py_FindMethod"
was just removed in Python last beta.

Most uses of "Py_FindMethod" can be resolved as (as far as I know):

1. Delete the getattr routine.
2. Put a "0" in the getattr slot in the type object.
3. Use the "methods" slot. [*]

This is not documented anywhere, so I needed to "diff" modules between
2.6 and 3.0 trees :-(

But I have some code I don't know how to "upgrade". Can you possibly
help me?

The full sourcecode:

"""
static PyObject*
DBEnv_getattr(DBEnvObject* self, char *name)
{
~    if (!strcmp(name, "db_home")) {
~      const char *home = NULL;
~      CHECK_ENV_NOT_CLOSED(self);
#if (DBVER >= 42)
~      self->db_env->get_home(self->db_env, &home);
#else
~      home=self->db_env->db_home;
#endif
~      if (home == NULL) {
~          RETURN_NONE();
~      }
~      return PyBytes_FromString(home);
~    }

~    return Py_FindMethod(DBEnv_methods, (PyObject* )self, name);
}
"""

What can I do?.

Moreover, is this "Py_FindMethod" removal strategy valid for old Python
releases?. I need to support Python 2.3 and up.

[*] Using this change, the code doesn't work :-(. Compiling under
Python2.6 I get a lot of errors: "AttributeError: 'DB' object has no
attribute 'XXX'."

Example of "diff" I'm doing:

1. Delete the "DBSequence_getattr" routine.
2. Change the DBSequence_Type as:

"""
@@ -6800,7 +6785,7 @@
~     /* methods */
~     (destructor)DBSequence_dealloc, /*tp_dealloc*/
~     0,          /*tp_print*/
- -    (getattrfunc)DBSequence_getattr,/*tp_getattr*/
+    0,          /*tp_getattr*/
~     0,          /*tp_setattr*/
~     0,          /*tp_compare*/
~     0,          /*tp_repr*/
@@ -6823,6 +6808,10 @@
~     0,                 /* tp_clear */
~     0,                 /* tp_richcompare */
~     offsetof(DBSequenceObject, in_weakreflist),/*tp_weaklistoffset*/
+    0,          /*tp_iter*/
+    0,          /*tp_iternext*/
+    DBSequence_methods, /*tp_methods*/
+    0,          /*tp_members*/
~ };
~ #endif
"""

What am I doing wrong?.

Thanks in advance.

PS: Four hours of hard working and bsddb "almost" compiles under
Python3.0b2!.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIFxyplgi5GaxT1NAQKBgAP+MWBeOOzNypzLNyG7UX7ZHZ4bMSn8t/Oh
fnR8UeRQoSCBuhvqfi6Vl6o06cc/v9bnsZ25Shhy73bn+KRm+HE6x6HXnFFO8e6W
XPLgi2l7xd/wIp6IA8M9r0NSpwn8nE4qJz44lhzRFPV54DsxwhbEkmCRyzpeJppb
DGu75Yw5cww=
=nte2
-----END PGP SIGNATURE-----

From jcea at jcea.es  Sat Jul 19 07:39:28 2008
From: jcea at jcea.es (Jesus Cea)
Date: Sat, 19 Jul 2008 07:39:28 +0200
Subject: [Python-3000] Int and Long unification (was Re: Help replacing
	Py_FindMethod)
In-Reply-To: <488171D2.5000709@jcea.es>
References: <488171D2.5000709@jcea.es>
Message-ID: <48817E10.9080208@jcea.es>

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

Jesus Cea wrote:
| Good night everybody!.
|
| Working on the Python3.0 support for bsddb I see that "Py_FindMethod"
| was just removed in Python last beta.

Nevermind. I just reviewed the recent changes in the SVN and I can see
your patches for bsddb. Changes "ported" to my tree :-).

Now I see another issue: I just changed "PyInt_*" in my code to
"PyLong_*" (since PyInt_* functions don't exist in Python 3.0). But
since an integer fails "PyLong_Check()" in Python 2.*, how can I check
for integers portably between Python 2.[3-6] and Python 3.0?. I would
like to avoid conditional compilation, if possible.

I'm thinking about defining macros "NUMBER_*" to be defined as "PyInt_*"
in Python 2.* and "PyLong_*" in Python 3.0, but I guess must exist a
better approach. Ideas?.

Thanks for your time and attention.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIF+CZlgi5GaxT1NAQLAxQP/ahlDSx2MsHMvcTnVbhBom4ulT0XdIIKu
kGNPi1il0orF6udom3Y3eGxbdVqwetvGRMrkn56US7wWFUIkNllFbdvk+ILc9neP
HudrLl2QNt+TIaEU/e0KztfJEU4ilaxZ20T0VVFaJsUALEZ1ovxMWKkwzo/CVHfN
EZ5ljqBQ0hY=
=8TJz
-----END PGP SIGNATURE-----

From jcea at jcea.es  Sat Jul 19 10:00:12 2008
From: jcea at jcea.es (Jesus Cea)
Date: Sat, 19 Jul 2008 10:00:12 +0200
Subject: [Python-3000] bsddb ownership, buffer protocol and 3.0
Message-ID: <48819F0C.6010508@jcea.es>

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

I'm actively working porting current bsddb code to python 3.0. The work
is going fine. Current code compiles in both Python 2.[3-6] and 3.0. I
have some issues with module initialization:

"""
[jcea at tesalia bsddb3]$ python3.0
Python 3.0b2 (r30b2:65080, Jul 19 2008, 03:39:09)
[GCC 4.2.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
|>> import _pybsddb
Traceback (most recent call last):
~  File "<string>", line 1, in <module>
ImportError: __build_class__ not found
Fatal Python error: can't initialize module _bsddb
Abort (core dumped)
"""

Help welcomed :).


I was going to commit current (in flux) bsddb code, hoping you were able
to help me with this error, but I see a lot of work there. The 3.0 bsddb
branch has evolved at its own, without porting a huge number of patches
available in bsddb code in 2.6. The new code has grown buffer protocol,
for example, but it is based in an old codebase.

My intention as maintainer of pybsddb is to keep an unified sourcecode
for Python 2.x y 3.x branches. The C sourcecode should be a single file
(with some ugly conditional compilations, I know), and Python code would
be maintained as 2.x and ported to 3.x automagically via 2to3. At least
for the time being.

Current bsddb code in 3.0 branch has new features like buffers, but it
is based in an old bsddb codebase.

What can we do?.

I've picked some selected patches from 3.0 code fork, bit I rather
prefer to delay the buffer protocol until having a functional library
for 3.0.

Anybody is able to compile current bsddb in 3.0 svn?. May I overwrite
current version with my own one, updated with your patches (except the
buffer code; I rather prefer to delay that)?.

This lib is huge and fairly complex for a binding. The testsuite has
more than 300 testcases, and growing. Keeping an unified codebase (for
python 2.x and 3.0) seems to be the only way to garantee quality and
avoid divergence. I'm asking for module ownership, to be able to meet
3.0 deadline with an stable and complete product. For example, current
3.0 code has no replication or distributed transactions support, while
2.6 has.

So I'm asking your permission to:

1. Take your (valuable) current patches in 3.0.

2. Replace current code with my own one + your patches. The Buffer
protocol will be out at this time. It will be evaluated when the binding
is ready for 3.0. Time constrains and my aim to keep an unified codebase
precludes its inclusion, *for now*. This will change in the future, of
course.

3. The canonical sourcecode would be the 2.6 version. The C code in 3.0
should be identical. The Python code in 3.0 would be a direct
translation via 2to3. So, patches should go to 2.6. I will keep 2.6 and
3.0 in sync.

I acknowledge that some people would like to remove bsddb from the
standard lib, arguing it is a maintenance nightmare. I consider, then,
that the right thing to do would be to (fully) delegate this code to me,
a guy motivated, with deep knowledge on this technology and that uses
this code everyday. You will be relieved of maintain it, while keeping
this extremely powerful tool in the stdlib.

Any linux distro includes Berkeley DB. With this lib in Python, everyone
has a powerful ACID+replication+distributed transaction system scalable
to petabytes without any extra download&install. That fact is very
valuable. Do not drop this advantage!.

Thanks for your confidence.


PS: I need help with the "ImportError: __build_class__ not found" thing.
You can look at the code at svn://svn.argo.es/jcea/pybsddb/trunk/Modules
, revision 523. This code compiles under Python 2.[3-6] and 3.0. Under
2.6 it pases all the 303 tests. On 3.0 it compiles, but fails to import,
with the given error. Any idea?.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIGfAplgi5GaxT1NAQLwfgP9EPFmX54XbZaC7h6qfPldNZ84YpbMA7MR
lD/CnzRaep5yfHnk1N3JRGbO14lCajYbyvjWQ3LdH5upocNplxUbn5Uog4inQpty
U8oVMMcWh1KzQvLAqk4nWuD9veGMKlGR9i4mOlN65Jfv4H0+gJmx+Y0xAI8E01b9
oUSQppoaKYM=
=oFI5
-----END PGP SIGNATURE-----

From ncoghlan at gmail.com  Sat Jul 19 12:22:06 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Jul 2008 20:22:06 +1000
Subject: [Python-3000] Removing bsddb module from py3k (was Re: [Python-Dev]
 No beta2 tonight)
In-Reply-To: <e6511dbf0807181215r4774dae9i3c10f128be83c93c@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<487FD54C.2040308@v.loewis.de>	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
	<e6511dbf0807181215r4774dae9i3c10f128be83c93c@mail.gmail.com>
Message-ID: <4881C04E.5060208@gmail.com>

Josiah Carlson wrote:
> On Fri, Jul 18, 2008 at 11:03 AM, Fred Drake <fdrake at acm.org> wrote:
>> On Jul 18, 2008, at 1:45 PM, Josiah Carlson wrote:
>>> It's entirely possible that I know very little about what was being
>>> made available via the bsddb module, but to match the API of what is
>>> included in the documentation (plus the dictionary interface that it
>>> supports) shouldn't be terribly difficult.
>>
>> It's also entirely possible that the API isn't interesting if you don't
>> support existing databases, for many applications.
> 
> I see where the confusion was.  I'm not suggesting that someone write
> a new bsddb module, I'm suggesting that we can provide something
> called, perhaps, on_disk_dictionary, which offers the behavior of
> bsddb, without using bsddb anywhere, or supporting bsddb files.

No, I knew what you were suggesting, I just don't see the point in doing 
it. If an app depends on bsddb specifically, they can either stick with 
the 2.x series, or they can move to 3.0 and download the externally 
maintained pybsddb (modulo any additional licensing checks required by a 
company's contracts department) or they can switch to a simpler 
file-based database format like sqlite3.

I'm not clear on what problem you are attempting to solve with the idea 
of a module with the bsddb API but without an actual bsddb backend.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From barry at python.org  Sat Jul 19 14:12:31 2008
From: barry at python.org (Barry Warsaw)
Date: Sat, 19 Jul 2008 08:12:31 -0400
Subject: [Python-3000] bsddb ownership, buffer protocol and 3.0
In-Reply-To: <48819F0C.6010508@jcea.es>
References: <48819F0C.6010508@jcea.es>
Message-ID: <60EB721C-B8C7-4914-B089-3572A88B0C5F@python.org>

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

On Jul 19, 2008, at 4:00 AM, Jesus Cea wrote:

> I acknowledge that some people would like to remove bsddb from the
> standard lib, arguing it is a maintenance nightmare. I consider, then,
> that the right thing to do would be to (fully) delegate this code to  
> me,
> a guy motivated, with deep knowledge on this technology and that uses
> this code everyday. You will be relieved of maintain it, while keeping
> this extremely powerful tool in the stdlib.

I'm all for keeping it in the stdlib if it has an active maintainer.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSIHaMHEjvBPtnXfVAQJmCAP9EplzjISrrGa//xetCXl2vh2BJ8L+06F/
zVihQ9o/3i8Vh6hX/htiQHGYEuUkfNYCVxukp4zoYxCVaVJlCYPgm5oLbn2QPku8
/FWPzGSjg7mb+KB1cewdgn/n4E4EkZLHOCEp/UtTwwAPYu/UfSKY061dBUcUnDuy
jceVwOfW07U=
=dPXM
-----END PGP SIGNATURE-----

From lars at ibp.de  Sat Jul 19 14:09:33 2008
From: lars at ibp.de (Lars Immisch)
Date: Sat, 19 Jul 2008 14:09:33 +0200
Subject: [Python-3000] Extension modules moving to py3k
In-Reply-To: <04f601c8e947$d4d27010$7e775030$@com.au>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>	<487FD54C.2040308@v.loewis.de>	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>	<4881451B.9010304@jcea.es>
	<04f601c8e947$d4d27010$7e775030$@com.au>
Message-ID: <4881D97D.10603@ibp.de>

Hi,

>> I'm still loooking for a *GOOD* python2->python3 conversion guide for C
>> language modules.

Me too, but I haven't even found not so good ones yet.

<snip>

> I'd love to help on this (even if the only reason is selfish - I believe
> pywin32 will *need* it while 2.x remains important.)  Who would get involved
> in such an effort?  How and where can we kick this off?

A wiki page would be a good start. Maybe 
http://wiki.python.org/moin/Py3kExtensionModules?

- Lars

From ggpolo at gmail.com  Sat Jul 19 15:33:09 2008
From: ggpolo at gmail.com (Guilherme Polo)
Date: Sat, 19 Jul 2008 10:33:09 -0300
Subject: [Python-3000] Extension modules moving to py3k
In-Reply-To: <4881D97D.10603@ibp.de>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<4881451B.9010304@jcea.es> <04f601c8e947$d4d27010$7e775030$@com.au>
	<4881D97D.10603@ibp.de>
Message-ID: <ac2200130807190633h9a8d9cco6ef345f93357112@mail.gmail.com>

On Sat, Jul 19, 2008 at 9:09 AM, Lars Immisch <lars at ibp.de> wrote:
> Hi,
>
>>> I'm still loooking for a *GOOD* python2->python3 conversion guide for C
>>> language modules.
>
> Me too, but I haven't even found not so good ones yet.

Have you looked at the Modules/xx*.c files ? It is not a conversion
guide but it will help you if you happen to like reading code.

>
> <snip>
>
>> I'd love to help on this (even if the only reason is selfish - I believe
>> pywin32 will *need* it while 2.x remains important.)  Who would get
>> involved
>> in such an effort?  How and where can we kick this off?
>
> A wiki page would be a good start. Maybe
> http://wiki.python.org/moin/Py3kExtensionModules?
>
> - Lars
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/ggpolo%40gmail.com
>



-- 
-- Guilherme H. Polo Goncalves

From musiccomposition at gmail.com  Sat Jul 19 15:39:24 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 19 Jul 2008 08:39:24 -0500
Subject: [Python-3000] Int and Long unification (was Re: Help replacing
	Py_FindMethod)
In-Reply-To: <48817E10.9080208@jcea.es>
References: <488171D2.5000709@jcea.es> <48817E10.9080208@jcea.es>
Message-ID: <1afaf6160807190639x49dc2f98v33ee954446ab9e8b@mail.gmail.com>

On Sat, Jul 19, 2008 at 12:39 AM, Jesus Cea <jcea at jcea.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jesus Cea wrote:
> | Good night everybody!.
> |
> | Working on the Python3.0 support for bsddb I see that "Py_FindMethod"
> | was just removed in Python last beta.
>
> Nevermind. I just reviewed the recent changes in the SVN and I can see
> your patches for bsddb. Changes "ported" to my tree :-).
>
> Now I see another issue: I just changed "PyInt_*" in my code to
> "PyLong_*" (since PyInt_* functions don't exist in Python 3.0). But
> since an integer fails "PyLong_Check()" in Python 2.*, how can I check
> for integers portably between Python 2.[3-6] and Python 3.0?. I would
> like to avoid conditional compilation, if possible.

I think PyNumber_Check should do the trick.
>
> I'm thinking about defining macros "NUMBER_*" to be defined as "PyInt_*"
> in Python 2.* and "PyLong_*" in Python 3.0, but I guess must exist a
> better approach. Ideas?.
>
> Thanks for your time and attention.
>
> - --
> 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.8 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBSIF+CZlgi5GaxT1NAQLAxQP/ahlDSx2MsHMvcTnVbhBom4ulT0XdIIKu
> kGNPi1il0orF6udom3Y3eGxbdVqwetvGRMrkn56US7wWFUIkNllFbdvk+ILc9neP
> HudrLl2QNt+TIaEU/e0KztfJEU4ilaxZ20T0VVFaJsUALEZ1ovxMWKkwzo/CVHfN
> EZ5ljqBQ0hY=
> =8TJz
> -----END PGP SIGNATURE-----
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From martin at v.loewis.de  Sat Jul 19 15:51:21 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Jul 2008 15:51:21 +0200
Subject: [Python-3000] Int and Long unification (was Re: Help replacing
 Py_FindMethod)
In-Reply-To: <1afaf6160807190639x49dc2f98v33ee954446ab9e8b@mail.gmail.com>
References: <488171D2.5000709@jcea.es> <48817E10.9080208@jcea.es>
	<1afaf6160807190639x49dc2f98v33ee954446ab9e8b@mail.gmail.com>
Message-ID: <4881F159.6060503@v.loewis.de>

> Now I see another issue: I just changed "PyInt_*" in my code to
> "PyLong_*" (since PyInt_* functions don't exist in Python 3.0). But
> since an integer fails "PyLong_Check()" in Python 2.*, how can I check
> for integers portably between Python 2.[3-6] and Python 3.0?. I would
> like to avoid conditional compilation, if possible.
> 
>> I think PyNumber_Check should do the trick.

PyNumber_Check also succeeds for floats, right? so it shouldn't be
use when checking for integers is desired.

Regards,
Martin

From musiccomposition at gmail.com  Sat Jul 19 15:53:35 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 19 Jul 2008 08:53:35 -0500
Subject: [Python-3000] Int and Long unification (was Re: Help replacing
	Py_FindMethod)
In-Reply-To: <4881F159.6060503@v.loewis.de>
References: <488171D2.5000709@jcea.es> <48817E10.9080208@jcea.es>
	<1afaf6160807190639x49dc2f98v33ee954446ab9e8b@mail.gmail.com>
	<4881F159.6060503@v.loewis.de>
Message-ID: <1afaf6160807190653i2b2e6597x2bcd104ea9743b93@mail.gmail.com>

On Sat, Jul 19, 2008 at 8:51 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Now I see another issue: I just changed "PyInt_*" in my code to
>> "PyLong_*" (since PyInt_* functions don't exist in Python 3.0). But
>> since an integer fails "PyLong_Check()" in Python 2.*, how can I check
>> for integers portably between Python 2.[3-6] and Python 3.0?. I would
>> like to avoid conditional compilation, if possible.
>>
>>> I think PyNumber_Check should do the trick.
>
> PyNumber_Check also succeeds for floats, right? so it shouldn't be
> use when checking for integers is desired.

I believe he wants PyIndex_Check then.

>
> Regards,
> Martin
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From martin at v.loewis.de  Sat Jul 19 15:56:00 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Jul 2008 15:56:00 +0200
Subject: [Python-3000] Int and Long unification (was Re: Help replacing
 Py_FindMethod)
In-Reply-To: <48817E10.9080208@jcea.es>
References: <488171D2.5000709@jcea.es> <48817E10.9080208@jcea.es>
Message-ID: <4881F270.7080904@v.loewis.de>

> (since PyInt_* functions don't exist in Python 3.0).

Some PyInt_ functions exist in intobject.h, which you need to include
explicitly.

> But
> since an integer fails "PyLong_Check()" in Python 2.*, how can I check
> for integers portably between Python 2.[3-6] and Python 3.0?. I would
> like to avoid conditional compilation, if possible.

Depends on what you want to test. If anything that has nb_int available
is sufficient, check for presence of nb_int. If you only want to test
for int-or-long, use intobject.h, and write

if (PyInt_Check(o) || PyLong_Check(o))

If you don't want to use intobject.h, write

#ifndef PyInt_Check
#define PyInt_Check(x) PyLong_Check(x)
#endif

at the top, then use the same if block.

HTH,
Martin

From josiah.carlson at gmail.com  Sat Jul 19 18:27:15 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Sat, 19 Jul 2008 09:27:15 -0700
Subject: [Python-3000] Removing bsddb module from py3k (was Re:
	[Python-Dev] No beta2 tonight)
In-Reply-To: <4881C04E.5060208@gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>
	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>
	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>
	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
	<e6511dbf0807181215r4774dae9i3c10f128be83c93c@mail.gmail.com>
	<4881C04E.5060208@gmail.com>
Message-ID: <e6511dbf0807190927o2415eb02rd0ae21b7f0b88375@mail.gmail.com>

On Sat, Jul 19, 2008 at 3:22 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Josiah Carlson wrote:
>>
>> On Fri, Jul 18, 2008 at 11:03 AM, Fred Drake <fdrake at acm.org> wrote:
>>>
>>> On Jul 18, 2008, at 1:45 PM, Josiah Carlson wrote:
>>>>
>>>> It's entirely possible that I know very little about what was being
>>>> made available via the bsddb module, but to match the API of what is
>>>> included in the documentation (plus the dictionary interface that it
>>>> supports) shouldn't be terribly difficult.
>>>
>>> It's also entirely possible that the API isn't interesting if you don't
>>> support existing databases, for many applications.
>>
>> I see where the confusion was.  I'm not suggesting that someone write
>> a new bsddb module, I'm suggesting that we can provide something
>> called, perhaps, on_disk_dictionary, which offers the behavior of
>> bsddb, without using bsddb anywhere, or supporting bsddb files.
>
> No, I knew what you were suggesting, I just don't see the point in doing it.
> If an app depends on bsddb specifically, they can either stick with the 2.x
> series, or they can move to 3.0 and download the externally maintained
> pybsddb (modulo any additional licensing checks required by a company's
> contracts department) or they can switch to a simpler file-based database
> format like sqlite3.
>
> I'm not clear on what problem you are attempting to solve with the idea of a
> module with the bsddb API but without an actual bsddb backend.

On-disk key -> value dictionary.  In every use of bsddb that I've seen
(or done myself), that's been the extent of it's use.  That's what I
*was* offering.  But it seems that everyone has had experience with
bsddb on a far deeper level (beyond dictionary + cursor access), and
would find (like you) absolutely no use in an on-disk dictionary with
a sqlite backend (which hasn't had the same maintenance issues as
bsddb), which is why I withdrew the offer.

 - Josiah

From greg at krypto.org  Sat Jul 19 19:57:23 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sat, 19 Jul 2008 10:57:23 -0700
Subject: [Python-3000] bsddb ownership, buffer protocol and 3.0
In-Reply-To: <48819F0C.6010508@jcea.es>
References: <48819F0C.6010508@jcea.es>
Message-ID: <52dc1c820807191057l524294fcm1442973a94b7fa39@mail.gmail.com>

On Sat, Jul 19, 2008 at 1:00 AM, Jesus Cea <jcea at jcea.es> wrote:

>
> Anybody is able to compile current bsddb in 3.0 svn?. May I overwrite
> current version with my own one, updated with your patches (except the
> buffer code; I rather prefer to delay that)?.
>

Yes, feel free to replace it with your updated code.  py3k bsddb has largely
been neglected so far.


>
> This lib is huge and fairly complex for a binding. The testsuite has
> more than 300 testcases, and growing. Keeping an unified codebase (for
> python 2.x and 3.0) seems to be the only way to garantee quality and
> avoid divergence. I'm asking for module ownership, to be able to meet
> 3.0 deadline with an stable and complete product. For example, current
> 3.0 code has no replication or distributed transactions support, while
> 2.6 has.
>
> So I'm asking your permission to:
>
> 1. Take your (valuable) current patches in 3.0.
>
> 2. Replace current code with my own one + your patches. The Buffer
> protocol will be out at this time. It will be evaluated when the binding
> is ready for 3.0. Time constrains and my aim to keep an unified codebase
> precludes its inclusion, *for now*. This will change in the future, of
> course.
>
> 3. The canonical sourcecode would be the 2.6 version. The C code in 3.0
> should be identical. The Python code in 3.0 would be a direct
> translation via 2to3. So, patches should go to 2.6. I will keep 2.6 and
> 3.0 in sync.


I agree with all of the above.  the existing py3k branch bsddb code should
be tossed out and replaced by your unified 2.6+3.0 code base.  Thanks for
examining it to extract whatever potentially useful changes are already in
it.

The py3k bsddb module buffer protocol work was done in large part by me last
year as an attempt at using the buffer protocol (some changes to the buffer
protocol resulted).  I think its okay if the bsddb module isn't using it
even in the 3.0 release, it can happen for 3.1.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080719/836292e9/attachment.htm>

From brett at python.org  Sat Jul 19 20:53:16 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 19 Jul 2008 11:53:16 -0700
Subject: [Python-3000] bsddb ownership, buffer protocol and 3.0
In-Reply-To: <48819F0C.6010508@jcea.es>
References: <48819F0C.6010508@jcea.es>
Message-ID: <bbaeab100807191153n6ac95fd1jdc3ef46559e819a0@mail.gmail.com>

On Sat, Jul 19, 2008 at 1:00 AM, Jesus Cea <jcea at jcea.es> wrote:
[SNIP]
> I acknowledge that some people would like to remove bsddb from the
> standard lib, arguing it is a maintenance nightmare. I consider, then,
> that the right thing to do would be to (fully) delegate this code to me,
> a guy motivated, with deep knowledge on this technology and that uses
> this code everyday. You will be relieved of maintain it, while keeping
> this extremely powerful tool in the stdlib.
>

The code has already been delegated to whomever wants it since no
other core developer maintains the code. And that is my worry; the
bsddb code base is owned by either no one or a single person since no
one else wants to deal with it (and I tried; I helped with the initial
transition to 3.0). For as long as I have been a core developer, if
you asked me what module or package caused the greatest amount of
grief for the core developers, I would have always answered bsddb.

I appreciate you want to maintain the code, Jesus, but that still
makes you the single point of failure for the code. If you decide you
don't want to deal with it, or are on vacation when the code breaks
just before a release, it is quite possible we are screwed. The Python
code base is not owned or maintained by a single individual, and yet
bsddb has been handled by a single person for as long as I can
remember.

Short of new code from _multiprocessing, everything else has been
ported to 3.0 throughout the development process without nearly as
much issue.

> Any linux distro includes Berkeley DB. With this lib in Python, everyone
> has a powerful ACID+replication+distributed transaction system scalable
> to petabytes without any extra download&install. That fact is very
> valuable. Do not drop this advantage!.
>

Assuming you even want to use Berkeley DB. And not all of us are on
Linux.  This is one of those situations where an argument tends to
break out over what types of things should be included in the stdlib.
I think bsddb is heavier than what we should include. But that's my
opinion.

> Thanks for your confidence.
>
>
> PS: I need help with the "ImportError: __build_class__ not found" thing.
> You can look at the code at svn://svn.argo.es/jcea/pybsddb/trunk/Modules
> , revision 523. This code compiles under Python 2.[3-6] and 3.0. Under
> 2.6 it pases all the 303 tests. On 3.0 it compiles, but fails to import,
> with the given error. Any idea?.
>

Well, _build_class__ is a built-in, so something is not running under
a proper environment.

-Brett

From python at rcn.com  Sat Jul 19 21:08:49 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sat, 19 Jul 2008 12:08:49 -0700
Subject: [Python-3000] bsddb ownership, buffer protocol and 3.0
References: <48819F0C.6010508@jcea.es>
	<bbaeab100807191153n6ac95fd1jdc3ef46559e819a0@mail.gmail.com>
Message-ID: <467ABF79AE854A27B9862327301B1838@RaymondLaptop1>

From: "Brett Cannon" <brett at python.org>
> I appreciate you want to maintain the code, Jesus, but that still
> makes you the single point of failure for the code. If you decide you
> don't want to deal with it, or are on vacation when the code breaks
> just before a release, it is quite possible we are screwed.

FWIW, I think its fine to have a single dedicated maintainer.
We've had that for a number of contributed modules and
it mostly works out fine (though it's always better to have
more than one).

I applaud Jesus's volunteer effort.


Raymond


From jcea at jcea.es  Sun Jul 20 03:44:10 2008
From: jcea at jcea.es (Jesus Cea)
Date: Sun, 20 Jul 2008 03:44:10 +0200
Subject: [Python-3000] [Python-Dev] Removing bsddb module from py3k (was
 Re:	 No beta2 tonight)
In-Reply-To: <e6511dbf0807190927o2415eb02rd0ae21b7f0b88375@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>	<e6511dbf0807181215r4774dae9i3c10f128be83c93c@mail.gmail.com>	<4881C04E.5060208@gmail.com>
	<e6511dbf0807190927o2415eb02rd0ae21b7f0b88375@mail.gmail.com>
Message-ID: <4882986A.3060509@jcea.es>

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

Josiah Carlson wrote:
| On-disk key -> value dictionary.  In every use of bsddb that I've seen
| (or done myself), that's been the extent of it's use.  That's what I
| *was* offering.  But it seems that everyone has had experience with
| bsddb on a far deeper level (beyond dictionary + cursor access), and
| would find (like you) absolutely no use in an on-disk dictionary with
| a sqlite backend (which hasn't had the same maintenance issues as
| bsddb), which is why I withdrew the offer.

For such a simple application, you can use the already in stdlib "gdbm"
module. Just remember it is not transactional, so beware diskfulls,
application crashes, etc.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIKXKJlgi5GaxT1NAQLmSQP+PEDrOy5AM6IRhIDFriyks0nTpA5a3vYi
bgrVRNJYQXTkV43AFD0bUkDFT1VBsROSlSO0jEsSfHXG2FG51TJa7Hp1LCX62ryV
H6NtztvqlA5OpTxEcWGPdha0XRueRwjYe/a+cVFXjAo+fXirlIac2W6ZhNJiAehg
VP9lxrffQSM=
=KV8P
-----END PGP SIGNATURE-----

From g.brandl at gmx.net  Sun Jul 20 16:44:29 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 20 Jul 2008 16:44:29 +0200
Subject: [Python-3000] Is this really a SyntaxError?
Message-ID: <g5vj0t$nmn$1@ger.gmane.org>

Someone just wrote to the docs mailing list and reported that the itertools
documentation for Py3k contains this recipe:

def grouper(n, iterable, fillvalue=None):
     args = [iter(iterable)] * n
     return zip_longest(*args, fillvalue=fillvalue)

It is currently a syntax error in 3k. There's also a test for it in
test_keywordonlyarg.py, however, I can currently see no reason why
it should be disallowed.

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.


From josiah.carlson at gmail.com  Sun Jul 20 19:24:56 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Sun, 20 Jul 2008 10:24:56 -0700
Subject: [Python-3000] [Python-Dev] Removing bsddb module from py3k (was
	Re: No beta2 tonight)
In-Reply-To: <4882986A.3060509@jcea.es>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>
	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>
	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>
	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
	<e6511dbf0807181215r4774dae9i3c10f128be83c93c@mail.gmail.com>
	<4881C04E.5060208@gmail.com>
	<e6511dbf0807190927o2415eb02rd0ae21b7f0b88375@mail.gmail.com>
	<4882986A.3060509@jcea.es>
Message-ID: <e6511dbf0807201024x5f50b46fha0a76ad859dc9e82@mail.gmail.com>

On Sat, Jul 19, 2008 at 6:44 PM, Jesus Cea <jcea at jcea.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Josiah Carlson wrote:
> | On-disk key -> value dictionary.  In every use of bsddb that I've seen
> | (or done myself), that's been the extent of it's use.  That's what I
> | *was* offering.  But it seems that everyone has had experience with
> | bsddb on a far deeper level (beyond dictionary + cursor access), and
> | would find (like you) absolutely no use in an on-disk dictionary with
> | a sqlite backend (which hasn't had the same maintenance issues as
> | bsddb), which is why I withdrew the offer.
>
> For such a simple application, you can use the already in stdlib "gdbm"
> module. Just remember it is not transactional, so beware diskfulls,
> application crashes, etc.

But sqlite is transactional, can offer cursors, getrange, etc., etc.

I'm still curious as to what deep features people are using in bsddb.
Anyone have any pointers to open source software?

 - Josiah

From charleshixsn at earthlink.net  Sun Jul 20 20:00:12 2008
From: charleshixsn at earthlink.net (Charles Hixson)
Date: Sun, 20 Jul 2008 11:00:12 -0700
Subject: [Python-3000] [Python-Dev] Removing bsddb module from py3k (was
	Re: No beta2 tonight)
In-Reply-To: <e6511dbf0807201024x5f50b46fha0a76ad859dc9e82@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<4882986A.3060509@jcea.es>
	<e6511dbf0807201024x5f50b46fha0a76ad859dc9e82@mail.gmail.com>
Message-ID: <200807201100.12925.charleshixsn@earthlink.net>

On Sunday 20 July 2008 10:24:56 am Josiah Carlson wrote:
> On Sat, Jul 19, 2008 at 6:44 PM, Jesus Cea <jcea at jcea.es> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Josiah Carlson wrote:
> > | On-disk key -> value dictionary.  In every use of bsddb that I've seen
> > | (or done myself), that's been the extent of it's use.  That's what I
> > | *was* offering.  But it seems that everyone has had experience with
> > | bsddb on a far deeper level (beyond dictionary + cursor access), and
> > | would find (like you) absolutely no use in an on-disk dictionary with
> > | a sqlite backend (which hasn't had the same maintenance issues as
> > | bsddb), which is why I withdrew the offer.
> >
> > For such a simple application, you can use the already in stdlib "gdbm"
> > module. Just remember it is not transactional, so beware diskfulls,
> > application crashes, etc.
>
> But sqlite is transactional, can offer cursors, getrange, etc., etc.
>
> I'm still curious as to what deep features people are using in bsddb.
> Anyone have any pointers to open source software?
>
>  - Josiah
> _
FWIW, when I use bsddb it's because all I want is a B+Tree.  I often 
explicitly DON'T want to use SQL.  The "deep feature" is simplicity.  The 
only feature I want it to have that it doesn't is the ability to use integers 
as keys.  I can handle that, but the extra layer of processing bothers me.

From andrewm at object-craft.com.au  Mon Jul 21 02:13:02 2008
From: andrewm at object-craft.com.au (Andrew McNamara)
Date: Mon, 21 Jul 2008 10:13:02 +1000
Subject: [Python-3000] [Python-Dev] Removing bsddb module from py3k (was
	Re: No beta2 tonight)
In-Reply-To: <e6511dbf0807201024x5f50b46fha0a76ad859dc9e82@mail.gmail.com> 
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>
	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>
	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>
	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>
	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
	<e6511dbf0807181215r4774dae9i3c10f128be83c93c@mail.gmail.com>
	<4881C04E.5060208@gmail.com>
	<e6511dbf0807190927o2415eb02rd0ae21b7f0b88375@mail.gmail.com>
	<4882986A.3060509@jcea.es>
	<e6511dbf0807201024x5f50b46fha0a76ad859dc9e82@mail.gmail.com>
Message-ID: <20080721001302.EAED5600808@longblack.object-craft.com.au>

>But sqlite is transactional, can offer cursors, getrange, etc., etc.
>
>I'm still curious as to what deep features people are using in bsddb.

It's not using "deep features", unless you define their on-disk layout
as deep, but it does get used for things such as interactions with other
systems - for example, using it to maintain Radius user databases for a
(proprietary/commercial) Radius auth daemon. But dropping it from the
core won't stop this.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

From g.brandl at gmx.net  Mon Jul 21 11:05:26 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 21 Jul 2008 11:05:26 +0200
Subject: [Python-3000] PEPs
Message-ID: <g61jh9$hag$1@ger.gmane.org>

There are some "accepted" PEPs that are, AFAIK, fully implemented.
There shouldn't be much work left to bring them to "final" state:

*  358 -- bytes object
*  370 -- per-user site-packages directory
*  371 -- multiprocessing
* 3101 -- adv. string formatting
* 3106 -- dict.keys() etc.
* 3116 -- new IO
* 3119 -- ABCs
* 3121 -- extension module initialization
* 3134 -- exception chaining
* 3137 -- bytes/buffer
* 3141 -- number hierarchy

PEP 364 is open, but maybe should be rejected.
PEP 3135 must be rewritten, then finalized.

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.


From jcea at jcea.es  Mon Jul 21 11:26:43 2008
From: jcea at jcea.es (Jesus Cea)
Date: Mon, 21 Jul 2008 11:26:43 +0200
Subject: [Python-3000] [Python-Dev] Removing bsddb module from py3k (was
 Re: No beta2 tonight)
In-Reply-To: <e6511dbf0807201024x5f50b46fha0a76ad859dc9e82@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<ca471dc20807180721u5bd34bflac00cd319bdf90c0@mail.gmail.com>	<e6511dbf0807180757p2a36ff38xae7445378f13b0ef@mail.gmail.com>	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>	<e6511dbf0807181215r4774dae9i3c10f128be83c93c@mail.gmail.com>	<4881C04E.5060208@gmail.com>	<e6511dbf0807190927o2415eb02rd0ae21b7f0b88375@mail.gmail.com>	<4882986A.3060509@jcea.es>
	<e6511dbf0807201024x5f50b46fha0a76ad859dc9e82@mail.gmail.com>
Message-ID: <48845653.5000100@jcea.es>

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

Josiah Carlson wrote:
| I'm still curious as to what deep features people are using in bsddb.
| Anyone have any pointers to open source software?

I'm using replication and distributed transactions. Database encryption
and page integrity checks. Abusing the master election BDB
infrastructure for some evil but fun purposes. Managing databases in the
200 terabyte range. Locking & logging infrastructure to implement
application logic integrated with database operation. MVCC everywhere.

Nothing I can show you without killing you after, though.

Independently of current bsddb usage profile, current 2.6 code support
for distributed transactions and replication enables new application
uses that sqlite can't match.

Since I'm taking full responsability over bsddb both in 2.6 and 3.0, I
don't really see what the issue is. Past mistakes and maintenance
nightmares WILL NOT be repeated.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIRWSplgi5GaxT1NAQL2CgQAnbv7hrxb4I5KzdZ1T05A/pGzzuX4NATm
SN5TBeKsesl1LlEwI1+5xaBv9uxuJFfnPYMFLlW7NZdGumIdNCo7QXMhPmEdvuNx
2BxcmlS2Zuag8piAbmgq31Ov2RnnskOCf5ZxmuK4smk5Y0H2L+hUGG96Rk8dz9BU
s+AVkiaorKY=
=szyU
-----END PGP SIGNATURE-----

From jcea at jcea.es  Mon Jul 21 11:54:45 2008
From: jcea at jcea.es (Jesus Cea)
Date: Mon, 21 Jul 2008 11:54:45 +0200
Subject: [Python-3000] Extension modules moving to py3k
In-Reply-To: <ac2200130807190633h9a8d9cco6ef345f93357112@mail.gmail.com>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>	<487FD54C.2040308@v.loewis.de>	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>	<4881451B.9010304@jcea.es>
	<04f601c8e947$d4d27010$7e775030$@com.au>	<4881D97D.10603@ibp.de>
	<ac2200130807190633h9a8d9cco6ef345f93357112@mail.gmail.com>
Message-ID: <48845CE5.1070200@jcea.es>

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

Guilherme Polo wrote:
| On Sat, Jul 19, 2008 at 9:09 AM, Lars Immisch <lars at ibp.de> wrote:
|> Hi,
|>
|>>> I'm still loooking for a *GOOD* python2->python3 conversion guide for C
|>>> language modules.
|> Me too, but I haven't even found not so good ones yet.
|
| Have you looked at the Modules/xx*.c files ? It is not a conversion
| guide but it will help you if you happen to like reading code.

Yes. "Diffing" 2.6/3.0 Modules is my lifeline and my blood these days.
Still, I rather prefer written documentation, use cases, examples and such.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIRc5Jlgi5GaxT1NAQKX/QQAkpIa6OdF/G2P3MfEAmutos63pxTAlo+o
qfmZN5RqtqR/1/ivk2VGLF5SqUCMST2hcxPLuSenLL45mp7SG1k/PyIDIXZm2wuE
p1JNTouyrjwHXsjt88rdn9WJdnkK5Ftxzz1HYuw1ha/aI4ITwBEV+p3ZRR0W7X9o
v1SmLQv5Rgw=
=yjlb
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Mon Jul 21 12:10:59 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 21 Jul 2008 10:10:59 +0000 (UTC)
Subject: [Python-3000] PEPs
References: <g61jh9$hag$1@ger.gmane.org>
Message-ID: <loom.20080721T095650-455@post.gmane.org>


Hi,

Georg Brandl <g.brandl <at> gmx.net> writes:
> * 3134 -- exception chaining

There are few things to correct/clean up:

(1) The "C API" paragraph contains incorrect information:
  - the sentence "The PyErr_Set* calls for setting exceptions will not set the
'__context__' attribute on exceptions" is wrong. The __context__ attribute is
actually set in PyErr_SetObject.
  - the sentence "PyErr_NormalizeException will always set the 'traceback'
attribute to its 'tb' argument and the '__context__' and '__cause__' attributes
to None" is wrong. The __context__ and __cause__ attributes are set to NULL in
BaseException_new
  - there are no functions PyErr_SetContext/PyErr_SetCause, but
PyException_SetContext/PyException_SetCause.

(2) "Open Issue: yield" has been fixed with the lexical exception handlers patch
(see test case:
http://hg.pitrou.net/public/py3k/py3k/file/184db4b87529/Lib/test/test_raise.py#l100
)

(3) "Open Issue: Garbage Collection" has been resolved as part of PEP 3110 (see
"semantic changes" in the latter)

(4) "Open Issue: Limiting Exception Types" has been solved since exception types
must all derive from BaseException

Regards

Antoine.



From jcea at jcea.es  Mon Jul 21 12:20:29 2008
From: jcea at jcea.es (Jesus Cea)
Date: Mon, 21 Jul 2008 12:20:29 +0200
Subject: [Python-3000] Extension modules moving to py3k
In-Reply-To: <04f601c8e947$d4d27010$7e775030$@com.au>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>	<487FD54C.2040308@v.loewis.de>	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>	<4881451B.9010304@jcea.es>
	<04f601c8e947$d4d27010$7e775030$@com.au>
Message-ID: <488462ED.2030407@jcea.es>

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

Mark Hammond wrote:
|In most
| cases some cool tricks in header files might be all that is necessary, but
| other cases may require special purpose helper functions designed
purely to
| aid people trying to keep code working in both environments.

+1

| and I suspect each project will have a number of
| unique challenges to overcome - so if we can share the *common* pain
and let
| them focus on their unique pain, 'dual-porting' efforts would stand a much
| greater chance of success.

+1

| Who would get involved in such an effort?
| How and where can we kick this off?

I would contribute, because I *NEED* this information myself.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIRi6plgi5GaxT1NAQLxzAQAoTmdT5hkFwJ44O8xD0tOy1RETyt4Ox44
T+iIr7SXwMXUYh277hRUlnenGYvLdDTUDfiwAimGmT4Rn16/SJy8qNsDkjSmal1x
+KjCn08pjmUj2UtTUJHlUYE6IN6mVHLRRTfeiykDjwkMmbkg4/CegqQ7CkZVJgFo
QKXJzSJycPQ=
=B2rf
-----END PGP SIGNATURE-----

From nirina at mail.blueline.mg  Mon Jul 21 15:16:08 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Mon, 21 Jul 2008 16:16:08 +0300 (EAT)
Subject: [Python-3000] adding gamma and error functions to math module
Message-ID: <20080721131608.37588F8BA@mail.blueline.mg>

Terry Reedy
> I'm interested also.  Done and done.
> http://bugs.python.org/issue3366
patch is submitted. it is tested only on linux-2.6.26
with gcc-4.3.1.

Raymond Hettinger
> Discussions of "my approximation is better/faster/etc than yours"
> can be interminable.
> Recommend you put together your favorite approximation in a recipe.
> The one in test.random is suffices well for its purpose.
agreed.

Mark Dickinson
> Are you sure it uses MPFR?
no!
> I thought that for gcc 4.3,MPFR was used only for compile-time
> constant expressions. For a call to tgamma whose argument is
> not known at compile time, the usual libm function should be used.
i understood gcc now uses MPFR, but i missed the "only for compile-time
constant expressions."
thank you for the correction.

Daniel Stutzbach
> The code is a few hundred lines because numeric methods for these
> functions that are accurate in the range [a,b] tend not to be accurate
> outside the range [a,b].  Ergo, robust implementations include several
> different methods so that they are accurate over the entire range of
> the function.
i love codes when they look like mathematical formulae. but most of the
time, these codes are poorly accurate, and i prefer robustness. so now,
i'm not so lazy to read hundred lines of codes.

Mark Dickinson
> As Daniel Stutzbach already hinted, the easiest way to just
> get at the system gamma and error functions, in a platform-dependent
> manner, is probably to use ctypes.
> ...
> Is this enough for your immediate needs?
the other platform i use, and will still use, is a window98!
in this case, the gamma function defined in test_random.py is sufficient.

thanks for your input, guys

nirinA

--


From daniel at stutzbachenterprises.com  Mon Jul 21 15:46:03 2008
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Mon, 21 Jul 2008 08:46:03 -0500
Subject: [Python-3000] adding gamma and error functions to math module
In-Reply-To: <20080721131608.37588F8BA@mail.blueline.mg>
References: <20080721131608.37588F8BA@mail.blueline.mg>
Message-ID: <eae285400807210646t55e6553ma6ace7d290a3915@mail.gmail.com>

On Mon, Jul 21, 2008 at 8:16 AM, nirinA raseliarison
<nirina at mail.blueline.mg> wrote:
> Terry Reedy
>> I'm interested also.  Done and done.
>> http://bugs.python.org/issue3366
> patch is submitted. it is tested only on linux-2.6.26
> with gcc-4.3.1.

Thanks for doing this.  In the patch, wouldn't it be good to have a
comment with a pointer to where you got the code from?  That way, in
the unlikely event someone finds a mathematical bug, we can a) check
the upstream code to see if they've fixed it already, or b) send a
patch upstream if they haven't.

Also, the patch doesn't include the extensive comments in the original
code that explain the mathematics.  Including a URL in the patch would
at least allow someone to find those comments.

Thanks again,

-- 
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC

From lars at gustaebel.de  Mon Jul 21 16:32:09 2008
From: lars at gustaebel.de (Lars =?iso-8859-1?Q?Gust=E4bel?=)
Date: Mon, 21 Jul 2008 16:32:09 +0200
Subject: [Python-3000] Remove TarFileCompat from tarfile.py
Message-ID: <20080721143209.GA10793@axis.g33x.de>

Hi!

I just had a look at issue 3039 that reports a bug in tarfile.py's
TarFileCompat class and I came to the conclusion that I really would like to
remove the TarFileCompat class from Python 3.0.

Some details: The ZipFile and TarFile classes both have very different
interfaces. The original intention behind TarFileCompat was to have a second
TarFile class with a ZipFile-like interface, so that both could be used in the
same context.

In retrospect, the addition of TarFileCompat has never been a good idea. There
are few use cases and I think only a few people actually know that it exists.
The class is small and has little functionality which can be accomplished
easily without it. It has to be synchronized with ZipFile whenever that
changes. It has no unittests, so that the TarFile.writestr() method has been
broken for over two years without anyone noticing. Recently, TarFile's
extract() and extractall() methods were added to ZipFile's interface.

I know that this is a minor issue, but I don't want to remove TarFileCompat
without having asked for opinions before (if there are any).

Thanks.

-- 
Lars Gust?bel
lars at gustaebel.de

War does not determine who is right - only who is left.
(Bertrand Russell)

From jcea at jcea.es  Mon Jul 21 17:00:27 2008
From: jcea at jcea.es (Jesus Cea)
Date: Mon, 21 Jul 2008 17:00:27 +0200
Subject: [Python-3000] Strange code in bsddb that doesn't work in Python 3.0
Message-ID: <4884A48B.2070904@jcea.es>

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

Trying to find why I can't import bsddb in python3.0, I have found that
this code fails:

"""
~    /* Some magic to make DBNotFoundError and DBKeyEmptyError derive
~     * from both DBError and KeyError, since the API only supports
~     * using one base class. */
~    PyDict_SetItemString(d, "KeyError", PyExc_KeyError);
~    PyRun_String("class DBNotFoundError(DBError, KeyError): pass\n"
~                 "class DBKeyEmptyError(DBError, KeyError): pass",
~                 Py_file_input, d, d);
~    DBNotFoundError = PyDict_GetItemString(d, "DBNotFoundError");
~    DBKeyEmptyError = PyDict_GetItemString(d, "DBKeyEmptyError");
~    PyDict_DelItemString(d, "KeyError");
"""

"Some magic" comment is a bit scary :-), although the code seems fairly
obvious.

This code works in Python 2.x, but fails in 3.0.

The line that fails is "PyRun_String()". The error is: "ImportError:
__build_class__ not found".

:-?

Ideas welcomed!

The code should work in python2.[3-6] and python3.0. Conditional
compilation can be used.

PS: Googling around, I see that Python 2.5 allows a tuple being used as
base for exception creation.  Is this available in Python3.0?. Searching
for "PyErr_NewException" in 3.0 documentation online shows no results.

Ok, the index show the function. It should work.

I'm still interested in knowing WHY the original code fails.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSISkhplgi5GaxT1NAQIyMQP/R2GmrLsMT+AKaM2toJtJQqrWDF8EzmAa
gqaW+vvi8fivYGXWm4IzHOzNCSW48N/5rMHQQREkHliRQxVypukYU48VSr4lRfAC
3m8EnS/dVgyP2GN19mm50xa+gWK9OpAopN6GLwDXlG2pxiHCMLmfI+PusQdGsIsU
kHhkWRUkwwo=
=ofiW
-----END PGP SIGNATURE-----

From amauryfa at gmail.com  Mon Jul 21 18:26:11 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Mon, 21 Jul 2008 18:26:11 +0200
Subject: [Python-3000] Extension modules moving to py3k (was: No beta2
	tonight)
In-Reply-To: <04f601c8e947$d4d27010$7e775030$@com.au>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com>
	<487FD54C.2040308@v.loewis.de>
	<0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org>
	<ca471dc20807171937x21a4ba4bv6063b5ff91baed01@mail.gmail.com>
	<bbaeab100807172243s2b5bd743pb6a1817489599443@mail.gmail.com>
	<4881451B.9010304@jcea.es> <04f601c8e947$d4d27010$7e775030$@com.au>
Message-ID: <e27efe130807210926u2df29149ie532413d61788b3e@mail.gmail.com>

Mark Hammond wrote:
...
>
> It seems that it would be a huge help to extension authors if porting tricks
> and hacks could be encapsulated in code that everyone can use.  In most
> cases some cool tricks in header files might be all that is necessary, but
> other cases may require special purpose helper functions designed purely to
> aid people trying to keep code working in both environments.
>
> Roger Upole, one of the main pywin32 contributors, recently started an
> attempt at porting pywin32 to py3k, and fell over at some fairly early
> hurdles (eg, working out how to move C code that creates and returns buffer
> objects to memory views), and I suspect each project will have a number of
> unique challenges to overcome - so if we can share the *common* pain and let
> them focus on their unique pain, 'dual-porting' efforts would stand a much
> greater chance of success.
>
> I'd love to help on this (even if the only reason is selfish - I believe
> pywin32 will *need* it while 2.x remains important.)  Who would get involved
> in such an effort?  How and where can we kick this off?

I suggest to start with a wiki page to collect items in random order,
then consolidate topics in the documentation, Doc/howto/2to3.rst for example.

-- 
Amaury Forgeot d'Arc

From g.brandl at gmx.net  Mon Jul 21 20:26:54 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 21 Jul 2008 20:26:54 +0200
Subject: [Python-3000] MemoryError oddities
Message-ID: <g62ke1$45m$1@ger.gmane.org>

In a debug-build 3k, do this (32-bit machine):

Python 3.0b2+ (py3k:65171M, Jul 21 2008, 20:08:20)
[GCC 4.2.4 (Gentoo 4.2.4 p1.0)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> "a"*1000000000
instinstTraceback (most recent call last):
   File "<stdin>", line 1, in <module>
MemoryError
[41296 refs]
 >>> "a"*1000000000
inst[1]    21400 segmentation fault  ./python

Here, something fishy is probably going on in the unicode free list.
Compare with 2.6:

Python 2.6b2+ (trunk:65131:65163M, Jul 21 2008, 19:58:07)
[GCC 4.2.4 (Gentoo 4.2.4 p1.0)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> u"a"*1000000000
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
MemoryError
[34330 refs]
 >>> u"a"*1000000000
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
MemoryError
[34332 refs]

Still, the refcount seems to leak.

Also:

 >>> b"a"*sys.maxsize
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
MemoryError
[41297 refs]
 >>> b"a"*sys.maxsize
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 1, in <module>
MemoryError
[41317 refs]
 >>> b"a"*sys.maxsize
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 1, in <module>
MemoryError
[41337 refs]

This probably has to do with the fact that this MemoryError is a prebuilt
instance.

Finally:

 >>> "a"*sys.maxsize
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
OverflowError: repeated string is too long
[41379 refs]

Nothing wrong here, but the exception is a different one.

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.


From amauryfa at gmail.com  Tue Jul 22 00:39:54 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 22 Jul 2008 00:39:54 +0200
Subject: [Python-3000] Strange code in bsddb that doesn't work in Python
	3.0
In-Reply-To: <4884A48B.2070904@jcea.es>
References: <4884A48B.2070904@jcea.es>
Message-ID: <e27efe130807211539l22bb35e6v6dd29726d853e71a@mail.gmail.com>

2008/7/21 Jesus Cea <jcea at jcea.es>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Trying to find why I can't import bsddb in python3.0, I have found that
> this code fails:
>
> """
> ~    /* Some magic to make DBNotFoundError and DBKeyEmptyError derive
> ~     * from both DBError and KeyError, since the API only supports
> ~     * using one base class. */
> ~    PyDict_SetItemString(d, "KeyError", PyExc_KeyError);
> ~    PyRun_String("class DBNotFoundError(DBError, KeyError): pass\n"
> ~                 "class DBKeyEmptyError(DBError, KeyError): pass",
> ~                 Py_file_input, d, d);
> ~    DBNotFoundError = PyDict_GetItemString(d, "DBNotFoundError");
> ~    DBKeyEmptyError = PyDict_GetItemString(d, "DBKeyEmptyError");
> ~    PyDict_DelItemString(d, "KeyError");
> """
>
> "Some magic" comment is a bit scary :-), although the code seems fairly
> obvious.
>
> This code works in Python 2.x, but fails in 3.0.
>
> The line that fails is "PyRun_String()". The error is: "ImportError:
> __build_class__ not found".
>
> :-?
>
> Ideas welcomed!
>
> The code should work in python2.[3-6] and python3.0. Conditional
> compilation can be used.
>
> PS: Googling around, I see that Python 2.5 allows a tuple being used as
> base for exception creation.  Is this available in Python3.0?. Searching
> for "PyErr_NewException" in 3.0 documentation online shows no results.
>
> Ok, the index show the function. It should work.
>
> I'm still interested in knowing WHY the original code fails.

I suppose you just copied the _bsddb.c file from trunk, right? Here is
the problem.
The current version of _bsddb.c in the py3k branch contains the lines:
    {
	    PyObject *builtin_mod = PyImport_ImportModule("builtins");
	    PyDict_SetItemString(d, "__builtins__", builtin_mod);
    }
And indeed __build_class__ is in the __builtins__ module, and seems to
be needed by any "class" statement
(to implement new metaclass semantics I guess)
PyErr_NewException is better in any case.

But didn't you try svnmerge? there are other py3k changes you may want to keep.

-- 
Amaury Forgeot d'Arc

From amauryfa at gmail.com  Tue Jul 22 00:48:59 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 22 Jul 2008 00:48:59 +0200
Subject: [Python-3000] Help replacing Py_FindMethod
In-Reply-To: <488171D2.5000709@jcea.es>
References: <488171D2.5000709@jcea.es>
Message-ID: <e27efe130807211548k7aff821ejb4453fea0e48e601@mail.gmail.com>

Jesus Cea wrote:
> Good night everybody!.
>
> Working on the Python3.0 support for bsddb I see that "Py_FindMethod"
> was just removed in Python last beta.
>
> Most uses of "Py_FindMethod" can be resolved as (as far as I know):
>
> 1. Delete the getattr routine.
> 2. Put a "0" in the getattr slot in the type object.
> 3. Use the "methods" slot. [*]
>
> This is not documented anywhere, so I needed to "diff" modules between
> 2.6 and 3.0 trees :-(
>
> But I have some code I don't know how to "upgrade". Can you possibly
> help me?
>
> The full sourcecode:
>
> """
> static PyObject*
> DBEnv_getattr(DBEnvObject* self, char *name)
> {
> ~    if (!strcmp(name, "db_home")) {
> ~      const char *home = NULL;
> ~      CHECK_ENV_NOT_CLOSED(self);
> #if (DBVER >= 42)
> ~      self->db_env->get_home(self->db_env, &home);
> #else
> ~      home=self->db_env->db_home;
> #endif
> ~      if (home == NULL) {
> ~          RETURN_NONE();
> ~      }
> ~      return PyBytes_FromString(home);
> ~    }
>
> ~    return Py_FindMethod(DBEnv_methods, (PyObject* )self, name);
> }
> """
>
> What can I do?.
>
> Moreover, is this "Py_FindMethod" removal strategy valid for old Python
> releases?. I need to support Python 2.3 and up.
>
> [*] Using this change, the code doesn't work :-(. Compiling under
> Python2.6 I get a lot of errors: "AttributeError: 'DB' object has no
> attribute 'XXX'."
>
> Example of "diff" I'm doing:
>
> 1. Delete the "DBSequence_getattr" routine.
> 2. Change the DBSequence_Type as:
>
> """
> @@ -6800,7 +6785,7 @@
> ~     /* methods */
> ~     (destructor)DBSequence_dealloc, /*tp_dealloc*/
> ~     0,          /*tp_print*/
> - -    (getattrfunc)DBSequence_getattr,/*tp_getattr*/
> +    0,          /*tp_getattr*/
> ~     0,          /*tp_setattr*/
> ~     0,          /*tp_compare*/
> ~     0,          /*tp_repr*/
> @@ -6823,6 +6808,10 @@
> ~     0,                 /* tp_clear */
> ~     0,                 /* tp_richcompare */
> ~     offsetof(DBSequenceObject, in_weakreflist),/*tp_weaklistoffset*/
> +    0,          /*tp_iter*/
> +    0,          /*tp_iternext*/
> +    DBSequence_methods, /*tp_methods*/
> +    0,          /*tp_members*/
> ~ };
> ~ #endif
> """
>
> What am I doing wrong?.
>
> Thanks in advance.
>
> PS: Four hours of hard working and bsddb "almost" compiles under
> Python3.0b2!.

The best is to look at the change that suppressed Py_FindMethod (and I
am guilty):
http://svn.python.org/view?rev=64672&view=rev
I even modified (an older version of?) the _bsddb module! You could
start with it...

I think you were close, you just have to be careful to call
PyType_Ready in the module init function,
to create the descriptors for each tp_methods and tp_members entries.

-- 
Amaury Forgeot d'Arc

From divinekid at gmail.com  Wed Jul 23 19:21:40 2008
From: divinekid at gmail.com (Haoyu Bai)
Date: Thu, 24 Jul 2008 01:21:40 +0800
Subject: [Python-3000] Wiki page for C extension modules migration
Message-ID: <1d7983e80807231021g2eb59406la55ce4b9088fbbe4@mail.gmail.com>

Hello,

I have created a wiki page Py3kExtensionModules by summerizing my
experience of working on SWIG's Python 3.0 support. You can see it
here:
http://wiki.python.org/moin/Py3kExtensionModules

The list would be incomplete, so feel free to contribute to it!

Thanks!

-- 
Haoyu Bai

From josiah.carlson at gmail.com  Thu Jul 24 19:26:39 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Thu, 24 Jul 2008 10:26:39 -0700
Subject: [Python-3000] [Python-Dev] Removing bsddb module from py3k (was
	Re: No beta2 tonight)
In-Reply-To: <48845653.5000100@jcea.es>
References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org>
	<ca471dc20807180811v2478f5ds140810ca486c2bb0@mail.gmail.com>
	<e6511dbf0807181045x5e7f8b63n8bf90e8c47f8c4f8@mail.gmail.com>
	<F9D592EE-FB50-412A-9553-B071823E1EEF@acm.org>
	<e6511dbf0807181215r4774dae9i3c10f128be83c93c@mail.gmail.com>
	<4881C04E.5060208@gmail.com>
	<e6511dbf0807190927o2415eb02rd0ae21b7f0b88375@mail.gmail.com>
	<4882986A.3060509@jcea.es>
	<e6511dbf0807201024x5f50b46fha0a76ad859dc9e82@mail.gmail.com>
	<48845653.5000100@jcea.es>
Message-ID: <e6511dbf0807241026qc2aa105o11a3b6ca8bdd5a5a@mail.gmail.com>

On Mon, Jul 21, 2008 at 2:26 AM, Jesus Cea <jcea at jcea.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Josiah Carlson wrote:
> | I'm still curious as to what deep features people are using in bsddb.
> | Anyone have any pointers to open source software?
>
> I'm using replication and distributed transactions. Database encryption
> and page integrity checks. Abusing the master election BDB
> infrastructure for some evil but fun purposes. Managing databases in the
> 200 terabyte range. Locking & logging infrastructure to implement
> application logic integrated with database operation. MVCC everywhere.
>
> Nothing I can show you without killing you after, though.

That's the kind of answer I was looking for :).  Though I don't know
if you are the "typical user"; I don't have enough data (the few
others that sent messages here and privately weren't using it to your
extent).

Some of those features are possible to add without huge amounts of
work (an afternoon or two), but indeed, some of those are not possible
without substantial investment and testing.


> Independently of current bsddb usage profile, current 2.6 code support
> for distributed transactions and replication enables new application
> uses that sqlite can't match.
>
> Since I'm taking full responsability over bsddb both in 2.6 and 3.0, I
> don't really see what the issue is. Past mistakes and maintenance
> nightmares WILL NOT be repeated.

Your taking over of maintenance is part of the reason why I withdrew
my offer ;) .

 - Josiah

From dalcinl at gmail.com  Thu Jul 24 21:03:01 2008
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Thu, 24 Jul 2008 16:03:01 -0300
Subject: [Python-3000] distutils: usage of the 'map()' builtin breaks the
	parsing of MANIFEST.in
Message-ID: <e7ba66e40807241203x5b1408c3o68e05368fd8d5368@mail.gmail.com>

In module 'distutils.filelist', class 'FileList', method
'_parse_template_line()', the 'map()' builtin is being used. Now
'map()' returns an iterator, and this iterator is exhausted in other
methods (for the purpose of 'debug_print()' stuff) before the data is
actually used.

I'm currently monkey-patching like this, but a patch for 'distutils'
perhaps should be implemented in terms of list comprehensions,
removing the usage of 'map()' builtin.


from distutils import filelist

_FileList = filelist.FileList

class FileList(_FileList):

    def _parse_template_line(self, line):
        (action, patterns, dir, dir_pattern) = \
                 _FileList._parse_template_line(self, line)
        if patterns is not None:
            patterns = list(patterns)
        return (action, patterns, dir, dir_pattern)

filelist.FileList = FileList


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From nirina at mail.blueline.mg  Fri Jul 25 02:34:25 2008
From: nirina at mail.blueline.mg (nirinA raseliarison)
Date: Fri, 25 Jul 2008 03:34:25 +0300 (EAT)
Subject: [Python-3000] adding gamma and error functions to math module
Message-ID: <20080725003425.4AB57F899@mail.blueline.mg>

on Mon, 21 Jul 2008 08:46:03 -0500
"Daniel Stutzbach" wrote:

> Also, the patch doesn't include the extensive comments in the original
> code that explain the mathematics.  Including a URL in the patch would
> at least allow someone to find those comments.

i rearranged the patches so that they are in their right place.
the links for the original codes and the comments for the
mathematics are also added.

nirinA

--


From fumanchu at aminus.org  Fri Jul 25 06:24:30 2008
From: fumanchu at aminus.org (Robert Brewer)
Date: Thu, 24 Jul 2008 21:24:30 -0700
Subject: [Python-3000] lib2to3 refactor.py has a lot of 2.6-isms
Message-ID: <F1962646D3B64642B7C9A06068EE1E640419C0C4@ex10.hostedexchange.local>

The README at
http://svn.python.org/view/sandbox/trunk/2to3/README?rev=65003&view=auto
says: "2to3 must be run (at the moment) with Python 2.x!" However, it
doesn't even import under 2.5.2 because of print() statements,
'Exception as err', .relative imports, etc.

Is this an attempt to make people upgrade to 2.6 before converting to 3?
Or is the desire to eventually run under 3.0? If neither, would y'all
welcome a version that ran under 2.5? I'd be happy to try my hand at
that.


Robert Brewer
fumanchu at aminus.org


From python at rcn.com  Fri Jul 25 06:34:48 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 24 Jul 2008 21:34:48 -0700
Subject: [Python-3000] lib2to3 refactor.py has a lot of 2.6-isms
References: <F1962646D3B64642B7C9A06068EE1E640419C0C4@ex10.hostedexchange.local>
Message-ID: <40671021E4774D03B1F1C5464C5DB3B2@RaymondLaptop1>

The intended upgrade path is through 2.6.
If you go straight from 2.5, you don't get
to go through a step with the -3 warnings
and optional text/bytes annotations.

IMO, it would be a mistake to create a 2.5 to 3.0 converter.

Raymond

----- Original Message ----- 
From: "Robert Brewer" <fumanchu at aminus.org>
To: "Python 3000" <python-3000 at python.org>
Sent: Thursday, July 24, 2008 9:24 PM
Subject: [Python-3000] lib2to3 refactor.py has a lot of 2.6-isms


> The README at
> http://svn.python.org/view/sandbox/trunk/2to3/README?rev=65003&view=auto
> says: "2to3 must be run (at the moment) with Python 2.x!" However, it
> doesn't even import under 2.5.2 because of print() statements,
> 'Exception as err', .relative imports, etc.
> 
> Is this an attempt to make people upgrade to 2.6 before converting to 3?
> Or is the desire to eventually run under 3.0? If neither, would y'all
> welcome a version that ran under 2.5? I'd be happy to try my hand at
> that.
> 
> 
> Robert Brewer
> fumanchu at aminus.org
> 
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/python%40rcn.com

From fumanchu at aminus.org  Fri Jul 25 06:39:34 2008
From: fumanchu at aminus.org (Robert Brewer)
Date: Thu, 24 Jul 2008 21:39:34 -0700
Subject: [Python-3000] lib2to3 refactor.py has a lot of 2.6-isms
In-Reply-To: <40671021E4774D03B1F1C5464C5DB3B2@RaymondLaptop1>
References: <F1962646D3B64642B7C9A06068EE1E640419C0C4@ex10.hostedexchange.local>
	<40671021E4774D03B1F1C5464C5DB3B2@RaymondLaptop1>
Message-ID: <F1962646D3B64642B7C9A06068EE1E640419C0CB@ex10.hostedexchange.local>

Raymond Hettinger wrote:
> The intended upgrade path is through 2.6.
> If you go straight from 2.5, you don't get
> to go through a step with the -3 warnings
> and optional text/bytes annotations.
> 
> IMO, it would be a mistake to create a 2.5 to 3.0 converter.
> 
> ----- Original Message -----
> From: "Robert Brewer" <fumanchu at aminus.org>
> To: "Python 3000" <python-3000 at python.org>
> Sent: Thursday, July 24, 2008 9:24 PM
> Subject: [Python-3000] lib2to3 refactor.py has a lot of 2.6-isms
> 
> 
> > The README at
> >
>
http://svn.python.org/view/sandbox/trunk/2to3/README?rev=65003&view=aut
> o
> > says: "2to3 must be run (at the moment) with Python 2.x!" However,
it
> > doesn't even import under 2.5.2 because of print() statements,
> > 'Exception as err', .relative imports, etc.
> >
> > Is this an attempt to make people upgrade to 2.6 before converting
to
> 3?
> > Or is the desire to eventually run under 3.0? If neither, would
y'all
> > welcome a version that ran under 2.5? I'd be happy to try my hand at
> > that.

That's fine by me. But every combination of refactor.py with 2.6 and 3.0
is also failing. Which combination is the preferred one so I can try to
fix it?

C:\Python25\Lib\site-packages>c:\python30\python
c:\python30\Lib\lib2to3\refactor.py --help
Traceback (most recent call last):
  File "c:\python30\Lib\lib2to3\refactor.py", line 25, in <module>
    from .pgen2 import driver
ValueError: Attempted relative import in non-package

C:\Python25\Lib\site-packages>c:\python26\python
c:\python30\Lib\lib2to3\refactor.py --help
  File "c:\python30\Lib\lib2to3\refactor.py", line 67
    print("At least one file or directory argument required.",
file=sys.stderr)
                                                                   ^
SyntaxError: invalid syntax

C:\Python25\Lib\site-packages>c:\python26\python
c:\python26\Lib\lib2to3\refactor.py --help
Traceback (most recent call last):
  File "c:\python26\Lib\lib2to3\refactor.py", line 25, in <module>
    from .pgen2 import driver
ValueError: Attempted relative import in non-package

C:\Python25\Lib\site-packages>c:\python30\python
c:\python26\Lib\lib2to3\refactor.py --help
  File "c:\python26\Lib\lib2to3\refactor.py", line 61
    print "Available transformations for the -f/--fix option:"
                                                             ^
SyntaxError: invalid syntax


Robert Brewer
fumanchu at aminus.org




From collinw at gmail.com  Fri Jul 25 06:58:28 2008
From: collinw at gmail.com (Collin Winter)
Date: Thu, 24 Jul 2008 21:58:28 -0700
Subject: [Python-3000] lib2to3 refactor.py has a lot of 2.6-isms
In-Reply-To: <F1962646D3B64642B7C9A06068EE1E640419C0CB@ex10.hostedexchange.local>
References: <F1962646D3B64642B7C9A06068EE1E640419C0C4@ex10.hostedexchange.local>
	<40671021E4774D03B1F1C5464C5DB3B2@RaymondLaptop1>
	<F1962646D3B64642B7C9A06068EE1E640419C0CB@ex10.hostedexchange.local>
Message-ID: <43aa6ff70807242158o3717cb00y8e9e473abfabc314@mail.gmail.com>

On Thu, Jul 24, 2008 at 9:39 PM, Robert Brewer <fumanchu at aminus.org> wrote:
> Raymond Hettinger wrote:
>> The intended upgrade path is through 2.6.
>> If you go straight from 2.5, you don't get
>> to go through a step with the -3 warnings
>> and optional text/bytes annotations.
>>
>> IMO, it would be a mistake to create a 2.5 to 3.0 converter.
>>
>> ----- Original Message -----
>> From: "Robert Brewer" <fumanchu at aminus.org>
>> To: "Python 3000" <python-3000 at python.org>
>> Sent: Thursday, July 24, 2008 9:24 PM
>> Subject: [Python-3000] lib2to3 refactor.py has a lot of 2.6-isms
>>
>>
>> > The README at
>> >
>>
> http://svn.python.org/view/sandbox/trunk/2to3/README?rev=65003&view=aut
>> o
>> > says: "2to3 must be run (at the moment) with Python 2.x!" However,
> it
>> > doesn't even import under 2.5.2 because of print() statements,
>> > 'Exception as err', .relative imports, etc.
>> >
>> > Is this an attempt to make people upgrade to 2.6 before converting
> to
>> 3?
>> > Or is the desire to eventually run under 3.0? If neither, would
> y'all
>> > welcome a version that ran under 2.5? I'd be happy to try my hand at
>> > that.
>
> That's fine by me. But every combination of refactor.py with 2.6 and 3.0
> is also failing. Which combination is the preferred one so I can try to
> fix it?
>
> C:\Python25\Lib\site-packages>c:\python30\python
> c:\python30\Lib\lib2to3\refactor.py --help
> Traceback (most recent call last):
>  File "c:\python30\Lib\lib2to3\refactor.py", line 25, in <module>
>    from .pgen2 import driver
> ValueError: Attempted relative import in non-package
>
> C:\Python25\Lib\site-packages>c:\python26\python
> c:\python30\Lib\lib2to3\refactor.py --help
>  File "c:\python30\Lib\lib2to3\refactor.py", line 67
>    print("At least one file or directory argument required.",
> file=sys.stderr)
>                                                                   ^
> SyntaxError: invalid syntax
>
> C:\Python25\Lib\site-packages>c:\python26\python
> c:\python26\Lib\lib2to3\refactor.py --help
> Traceback (most recent call last):
>  File "c:\python26\Lib\lib2to3\refactor.py", line 25, in <module>
>    from .pgen2 import driver
> ValueError: Attempted relative import in non-package
>
> C:\Python25\Lib\site-packages>c:\python30\python
> c:\python26\Lib\lib2to3\refactor.py --help
>  File "c:\python26\Lib\lib2to3\refactor.py", line 61
>    print "Available transformations for the -f/--fix option:"
>                                                             ^
> SyntaxError: invalid syntax

Ah, this is a docs problem: the entry point is ./2to3, not
lib2to3/refactor.py. I've just committed r65224 to fix the README.

$ py26 2to3 --helpUsage: refactor.py [options] file|dir ...

Options:
  -h, --help            show this help message and exit
  -d, --doctests_only   Fix up doctests only
  -f FIX, --fix=FIX     Each FIX specifies a transformation; default all
  -l, --list-fixes      List available transformations (fixes/fix_*.py)
  -p, --print-function  Modify the grammar so that print() is a function
  -v, --verbose         More verbose logging
  -w, --write           Write back modified files
$

In the olden days, 2to3 used to run on 2.4, 2.5 and 2.6, but at some
point (PyCon 2008, I believe) the decision was taken to intentionally
drop support for 2.4 and 2.5.

Collin

From musiccomposition at gmail.com  Fri Jul 25 14:51:56 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 25 Jul 2008 07:51:56 -0500
Subject: [Python-3000] lib2to3 refactor.py has a lot of 2.6-isms
In-Reply-To: <43aa6ff70807242158o3717cb00y8e9e473abfabc314@mail.gmail.com>
References: <F1962646D3B64642B7C9A06068EE1E640419C0C4@ex10.hostedexchange.local>
	<40671021E4774D03B1F1C5464C5DB3B2@RaymondLaptop1>
	<F1962646D3B64642B7C9A06068EE1E640419C0CB@ex10.hostedexchange.local>
	<43aa6ff70807242158o3717cb00y8e9e473abfabc314@mail.gmail.com>
Message-ID: <1afaf6160807250551uca40d37p6412b9d665c0c608@mail.gmail.com>

On Thu, Jul 24, 2008 at 11:58 PM, Collin Winter <collinw at gmail.com> wrote:
>
> In the olden days, 2to3 used to run on 2.4, 2.5 and 2.6, but at some
> point (PyCon 2008, I believe) the decision was taken to intentionally
> drop support for 2.4 and 2.5.

Does that mean I can go ahead and apply the patch for issue 3131?
>
> Collin
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From amauryfa at gmail.com  Sat Jul 26 22:11:55 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Sat, 26 Jul 2008 22:11:55 +0200
Subject: [Python-3000] distutils: usage of the 'map()' builtin breaks
	the parsing of MANIFEST.in
In-Reply-To: <e7ba66e40807241203x5b1408c3o68e05368fd8d5368@mail.gmail.com>
References: <e7ba66e40807241203x5b1408c3o68e05368fd8d5368@mail.gmail.com>
Message-ID: <e27efe130807261311l7b3f9025kad8d85a8fee5663b@mail.gmail.com>

Lisandro Dalcin wrote:
> In module 'distutils.filelist', class 'FileList', method
> '_parse_template_line()', the 'map()' builtin is being used. Now
> 'map()' returns an iterator, and this iterator is exhausted in other
> methods (for the purpose of 'debug_print()' stuff) before the data is
> actually used.
>
> I'm currently monkey-patching like this, but a patch for 'distutils'
> perhaps should be implemented in terms of list comprehensions,
> removing the usage of 'map()' builtin.

It's now corrected in svn.
Thanks for the report, but next time, please use the bug tracker.

-- 
Amaury Forgeot d'Arc

From solipsis at pitrou.net  Mon Jul 28 18:51:30 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Jul 2008 16:51:30 +0000 (UTC)
Subject: [Python-3000] Review needed: regular expressions and unicode
Message-ID: <loom.20080728T164236-192@post.gmane.org>


Hi,

I've posted my final patch to adapt the re module to the py3k standards of
bytes/unicode separation.

Here is a short summary of the changes:
- mixing bytes and str patterns, search and replacement strings raises a
TypeError
- re.UNICODE and (?u) become almost no-ops: they are the default for unicode
strings, and forbidden for bytes strings
- re.ASCII and (?a) are introduced: for unicode strings, they specify to do
old-style ASCII matching (for example, \d will only match [0-9] rather than all
ranges of unicode decimal digits); for bytes strings, they are the only
available behaviour
- mixing re.UNICODE and re.ASCII is forbidden
- the stdlib is adapted so that (hopefully) all places which rely on ASCII
matching of unicode patterns don't break

>From the above description you might infer that we should deprecate re.UNICODE
and (?u). It's a possible decision but I think we should leave that to a later
patch. The status of re.LOCALE is another issue again.

The issue is at http://bugs.python.org/issue2834
and the patch can be reviewed at http://codereview.appspot.com/2439

Thanks

Antoine.



From solipsis at pitrou.net  Mon Jul 28 20:45:10 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Jul 2008 18:45:10 +0000 (UTC)
Subject: [Python-3000] Signature of RawIOBase.read() ?
Message-ID: <loom.20080728T184308-29@post.gmane.org>


Hi,

There is an uncertainty in the signature for RawIOBase.read().
PEP 3116 says:
    read(n: int) -> bytes

but current io.py says:
    def read(self, n: int = -1) -> bytes:

Is omitting the `n` parameter always supported by RawIOBase implementations?
(meaning: read up to the end)

Regards

Antoine.



From guido at python.org  Mon Jul 28 21:15:52 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 28 Jul 2008 12:15:52 -0700
Subject: [Python-3000] Signature of RawIOBase.read() ?
In-Reply-To: <loom.20080728T184308-29@post.gmane.org>
References: <loom.20080728T184308-29@post.gmane.org>
Message-ID: <ca471dc20807281215o450b19c2kc7283689f945da96@mail.gmail.com>

On Mon, Jul 28, 2008 at 11:45 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> There is an uncertainty in the signature for RawIOBase.read().
> PEP 3116 says:
>    read(n: int) -> bytes
>
> but current io.py says:
>    def read(self, n: int = -1) -> bytes:
>
> Is omitting the `n` parameter always supported by RawIOBase implementations?
> (meaning: read up to the end)

In this (and many other) cases I consider io.py to be more correct; I
haven't kept the PEP up to date. Note that None and any negative value
should be treated the same way. Zero OTOH should mean "read nothing".

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From jcea at jcea.es  Tue Jul 29 15:53:51 2008
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 29 Jul 2008 15:53:51 +0200
Subject: [Python-3000] Strange code in bsddb that doesn't work in Python
 3.0
In-Reply-To: <e27efe130807211539l22bb35e6v6dd29726d853e71a@mail.gmail.com>
References: <4884A48B.2070904@jcea.es>
	<e27efe130807211539l22bb35e6v6dd29726d853e71a@mail.gmail.com>
Message-ID: <488F20EF.80900@jcea.es>

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

Amaury Forgeot d'Arc wrote:
| I suppose you just copied the _bsddb.c file from trunk, right? Here is
| the problem.
| The current version of _bsddb.c in the py3k branch contains the lines:
|     {
| 	    PyObject *builtin_mod = PyImport_ImportModule("builtins");
| 	    PyDict_SetItemString(d, "__builtins__", builtin_mod);
|     }
| And indeed __build_class__ is in the __builtins__ module, and seems to
| be needed by any "class" statement
| (to implement new metaclass semantics I guess)
| PyErr_NewException is better in any case.

Your are right.

| But didn't you try svnmerge? there are other py3k changes you may want
to keep.

The source has diverged so much, no hope for an automated merge.

In any case, 3.0 compatibility is on the works.

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSI8g75lgi5GaxT1NAQJsYAP5Ad65VOIlDbSAv/XFPzbmy8HK9N45mSx3
BVg73MgilBj7KvY5Z4uMuTsZiLq6e8jqEN4nr6Tov3jfLd7vpASPSQxkP+nwFDO0
Hv8wz2EXPJ16Lb+lPKuCNU03oBW8rXBud/A0osGV+h0DZbfuz+Zi3gyA2KEUR3ot
zs6NtXngM5Y=
=LuVu
-----END PGP SIGNATURE-----

From jcea at jcea.es  Tue Jul 29 15:55:34 2008
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 29 Jul 2008 15:55:34 +0200
Subject: [Python-3000] Help replacing Py_FindMethod
In-Reply-To: <e27efe130807211548k7aff821ejb4453fea0e48e601@mail.gmail.com>
References: <488171D2.5000709@jcea.es>
	<e27efe130807211548k7aff821ejb4453fea0e48e601@mail.gmail.com>
Message-ID: <488F2156.7010803@jcea.es>

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

Amaury Forgeot d'Arc wrote:
| I think you were close, you just have to be careful to call
| PyType_Ready in the module init function,
| to create the descriptors for each tp_methods and tp_members entries.

Already done :). Thanks for answering.

My doubt now is how do write a *clever* "getattr" routine without
"Py_FindMethod".

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSI8hVplgi5GaxT1NAQIHzwP+Kociw4Tg+eUCj/jQh+G2ILJY7hzdDqz7
9Bv24LAUGiwm7X7UvS7sD1ILhu4F6EDs1q7qY6jtJDjSc5+TwoAOoGNt3vTdv3Rk
KgNeLzBzuwzA2uhX5YYyjGu1InkOzJw9ZLo8joY+mnujkI9Ps9txSOymLNtffp4U
WzQ3BuYvDbo=
=orpJ
-----END PGP SIGNATURE-----

From jcea at jcea.es  Tue Jul 29 16:32:30 2008
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 29 Jul 2008 16:32:30 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
Message-ID: <488F29FE.6090800@jcea.es>

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

Working on the 3.0 version of bsddb, I have the following issue.

Until 3.0, keys and values were strings. For bsddb, they are opaque, and
stored unchanged.

In 3.0 the string type is replaced by unicode. A new "byte" type is
added. So, code like "db.put('key','value')" needs to be changed to
"db.put(bytes('key', 'utf-8'), bytes('value', 'utf-8'))", or something
similar.

This is ugly and generates incompatible code with previous python releases.

I was wondering what to do. The obvious path would be to put a proxy
object between application code and bsddb, doing the byte<->unicode
translation on the fly. This could be problematic when dealing with
legacy data, since it couldn't be a valid encoded bytestring. Data
misspresentation would be dangerous and can go undetected for a long
time, slowly corrupting the database data.

Moreover, the data is application specific, so automatic conversion can
introduce incompatibilities and bugs.

Another approach would be to add a new bsddb method to specify the
default encoding to use to convert unicode->bytes, and to do the
conversion internally when getting unicode data as a parameter. The
issue here is that "u'hi' != b'hi'", so the translation must be done
both when storing and when retrieving data.

These problems are caused because now string!=bytes. In fact the
approach in 3.0 is the right one, and any try to hide this difference
with proxy objects or automatic conversion is going to bite us, someday.

So, I'm thinking seriously in accepting *ONLY* "bytes" in the bsddb API
(when working under Python 3.0), and do the proxy thing *ONLY* in the
testsuite, to be able to reuse it.

What do you think?.

PS: Since most of the time keys/values are 7bit, a direct "ascii"
encoding would be fine... until we are required to store a 8 bit value.

PPS: In dbm (gdbm) I'm seeing automatic unicode->byte conversion, but NO
byte->unicode. See the problem when storing non ASCII data:

"""
Python 3.0b2 (r30b2:65080, Jul 19 2008, 03:39:09)
[GCC 4.2.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
|>> import dbm
|>> a=dbm.open("z","c")
|>> a
<_gdbm.gdbm object at 0x82fb560>
|>> a["a"]="b"
|>> a["b"]="c"
|>> a.sync()
|>> a.close()
|>> a=dbm.open("z","w")
|>> a.keys()
[b'b', b'a']
|>> a["c"]=chr(210)
|>> a["c"]
b'\xc3\x92'
|>> a["c"]==chr(210)
False
"""

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSI8p+Jlgi5GaxT1NAQKTggP/R+swZ429fecTyNahJj6dw9nJfMgg7YcE
NbkueWM4zhUhhKa03sCT9ACiFHaXhmPyF2Q75wrGeI+WZxtafbYj+sjhjyCXpikn
cptAnWxXMEchqshwGafXoUi9eyVLMxihvulDf9rXJIqWLR8oRqoRaiJJPWf39ZCk
VhF+L1uKWiw=
=A3en
-----END PGP SIGNATURE-----

From amauryfa at gmail.com  Tue Jul 29 16:32:47 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 16:32:47 +0200
Subject: [Python-3000] Help replacing Py_FindMethod
In-Reply-To: <488F2156.7010803@jcea.es>
References: <488171D2.5000709@jcea.es>
	<e27efe130807211548k7aff821ejb4453fea0e48e601@mail.gmail.com>
	<488F2156.7010803@jcea.es>
Message-ID: <e27efe130807290732y4737753dk1ab28da5da6a0e1f@mail.gmail.com>

Jesus Cea wrote:
> Amaury Forgeot d'Arc wrote:
> | I think you were close, you just have to be careful to call
> | PyType_Ready in the module init function,
> | to create the descriptors for each tp_methods and tp_members entries.
>
> Already done :). Thanks for answering.
>
> My doubt now is how do write a *clever* "getattr" routine without
> "Py_FindMethod".

Well, I'd write a "tp_getattro" member function,
which would do its "clever" things before it falls back to
PyObject_GenericGetAttr to get the usual behaviour.

Or did you mean something more "clever"?

-- 
Amaury Forgeot d'Arc

From jcea at jcea.es  Tue Jul 29 16:42:08 2008
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 29 Jul 2008 16:42:08 +0200
Subject: [Python-3000] Help replacing Py_FindMethod
In-Reply-To: <e27efe130807290732y4737753dk1ab28da5da6a0e1f@mail.gmail.com>
References: <488171D2.5000709@jcea.es>	<e27efe130807211548k7aff821ejb4453fea0e48e601@mail.gmail.com>	<488F2156.7010803@jcea.es>
	<e27efe130807290732y4737753dk1ab28da5da6a0e1f@mail.gmail.com>
Message-ID: <488F2C40.1060006@jcea.es>

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

Amaury Forgeot d'Arc wrote:
|> My doubt now is how do write a *clever* "getattr" routine without
|> "Py_FindMethod".
|
| Well, I'd write a "tp_getattro" member function,
| which would do its "clever" things before it falls back to
| PyObject_GenericGetAttr to get the usual behaviour.

Now I'm confused about difference between "tp_getattro" and
"tp_getattr", and when to use them.

I guess that "tp_methods" and "tp_members" are faster, but only usable
when the data is "static" and available, while "tp_getattr" and friends
are used when you need to execute some code in the lookup. But I read
somewhere that "tp_getattr" was deprecated :-? ...

- --
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.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSI8sQJlgi5GaxT1NAQKmegP/XMCw9xprI2GGYvFrsO40Gck0AOk/bSl1
TiDYGuBqocY8aE/HQcU5AENbCUM0z2XxBwPjUbzCqDS3s+Y/AoCi0CMpCRqKkz4g
EYTLZqfQmOMWe41oXU57h+7JH+6knXXV/D12Mufhg/NzSWvUQuxXpIMLkvvbigV1
trtark4zmzU=
=2kph
-----END PGP SIGNATURE-----

From amauryfa at gmail.com  Tue Jul 29 17:19:32 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 17:19:32 +0200
Subject: [Python-3000] Help replacing Py_FindMethod
In-Reply-To: <488F2C40.1060006@jcea.es>
References: <488171D2.5000709@jcea.es>
	<e27efe130807211548k7aff821ejb4453fea0e48e601@mail.gmail.com>
	<488F2156.7010803@jcea.es>
	<e27efe130807290732y4737753dk1ab28da5da6a0e1f@mail.gmail.com>
	<488F2C40.1060006@jcea.es>
Message-ID: <e27efe130807290819i382d5c15yefe7826284c0c6bd@mail.gmail.com>

Jesus Cea wrote:
> Amaury Forgeot d'Arc wrote:
> |> My doubt now is how do write a *clever* "getattr" routine without
> |> "Py_FindMethod".
> |
> | Well, I'd write a "tp_getattro" member function,
> | which would do its "clever" things before it falls back to
> | PyObject_GenericGetAttr to get the usual behaviour.
>
> Now I'm confused about difference between "tp_getattro" and
> "tp_getattr", and when to use them.

They are identical, except that tp_getattr takes a char*, when
tp_getattro wants a PyObject*.
(see the code in Object/object.c::PyObject_GetAttr())

> I guess that "tp_methods" and "tp_members" are faster, but only usable
> when the data is "static" and available, while "tp_getattr" and friends
> are used when you need to execute some code in the lookup.

Yes. Fortunately, it's not often the case.

> But I read
> somewhere that "tp_getattr" was deprecated :-? ...

Deprecated in favor of tp_getattro I presume.

-- 
Amaury Forgeot d'Arc

From amauryfa at gmail.com  Tue Jul 29 18:13:02 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 29 Jul 2008 18:13:02 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <488F29FE.6090800@jcea.es>
References: <488F29FE.6090800@jcea.es>
Message-ID: <e27efe130807290913w6eb6e681qcd747860e748b757@mail.gmail.com>

Jesus Cea wrote:
>
> Working on the 3.0 version of bsddb, I have the following issue.
>
> Until 3.0, keys and values were strings. For bsddb, they are opaque, and
> stored unchanged.
>
> In 3.0 the string type is replaced by unicode. A new "byte" type is
> added. So, code like "db.put('key','value')" needs to be changed to
> "db.put(bytes('key', 'utf-8'), bytes('value', 'utf-8'))", or something
> similar.
>
> This is ugly and generates incompatible code with previous python releases.
>
> I was wondering what to do. The obvious path would be to put a proxy
> object between application code and bsddb, doing the byte<->unicode
> translation on the fly. This could be problematic when dealing with
> legacy data, since it couldn't be a valid encoded bytestring. Data
> misspresentation would be dangerous and can go undetected for a long
> time, slowly corrupting the database data.
>
> Moreover, the data is application specific, so automatic conversion can
> introduce incompatibilities and bugs.
>
> Another approach would be to add a new bsddb method to specify the
> default encoding to use to convert unicode->bytes, and to do the
> conversion internally when getting unicode data as a parameter. The
> issue here is that "u'hi' != b'hi'", so the translation must be done
> both when storing and when retrieving data.
>
> These problems are caused because now string!=bytes. In fact the
> approach in 3.0 is the right one, and any try to hide this difference
> with proxy objects or automatic conversion is going to bite us, someday.
>
> So, I'm thinking seriously in accepting *ONLY* "bytes" in the bsddb API
> (when working under Python 3.0), and do the proxy thing *ONLY* in the
> testsuite, to be able to reuse it.
>
> What do you think?.
>
> PS: Since most of the time keys/values are 7bit, a direct "ascii"
> encoding would be fine... until we are required to store a 8 bit value.

I propose to do something similar to the io.open() function:
add two parameters, 'encoding' and 'errors', that default to "ascii"
and "strict".
Then do the conversions, and raise exceptions on every failure...

-- 
Amaury Forgeot d'Arc

From solipsis at pitrou.net  Tue Jul 29 18:55:40 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 29 Jul 2008 16:55:40 +0000 (UTC)
Subject: [Python-3000] Bytes and unicode conversion in C extensions
References: <488F29FE.6090800@jcea.es>
Message-ID: <loom.20080729T164527-251@post.gmane.org>


Hi,

> In 3.0 the string type is replaced by unicode. A new "byte" type is
> added. So, code like "db.put('key','value')" needs to be changed to
> "db.put(bytes('key', 'utf-8'), bytes('value', 'utf-8'))", or something
> similar.

Why not "db.put(b'key', b'value')"?

> This is ugly and generates incompatible code with previous python releases.

3.0 *is* meant to break compatibility with previous versions. Of course, it
would be better if databases created with 2.x could be opened using 3.0 without
any complications.

As for "ugly", this is avoided using the b"..." literal syntax.

> In fact the
> approach in 3.0 is the right one, and any try to hide this difference
> with proxy objects or automatic conversion is going to bite us, someday.

+1.
Or as Amaury suggests, you could add an option, when connecting to a bsddb
database, to open it in binary or text mode. But it seems to me that the bsddb
storage is inherently binary, if it doesn't care about encodings.

> So, I'm thinking seriously in accepting *ONLY* "bytes" in the bsddb API
> (when working under Python 3.0), and do the proxy thing *ONLY* in the
> testsuite, to be able to reuse it.

You needn't do any proxy thing in the testsuite. Just use b"..." literals, they
also work in 2.6.

> PPS: In dbm (gdbm) I'm seeing automatic unicode->byte conversion, but NO
> byte->unicode. See the problem when storing non ASCII data:

You should file a bug if there isn't already one.

cheers and good luck with this,

Antoine.



From jeremy.kloth at gmail.com  Tue Jul 29 19:02:07 2008
From: jeremy.kloth at gmail.com (Jeremy Kloth)
Date: Tue, 29 Jul 2008 11:02:07 -0600
Subject: [Python-3000] Help replacing Py_FindMethod
In-Reply-To: <488F2C40.1060006@jcea.es>
References: <488171D2.5000709@jcea.es>
	<e27efe130807290732y4737753dk1ab28da5da6a0e1f@mail.gmail.com>
	<488F2C40.1060006@jcea.es>
Message-ID: <200807291102.07719.jeremy.kloth@gmail.com>

On Tue July 29 2008 8:42:08 am Jesus Cea wrote:
> Amaury Forgeot d'Arc wrote:
> |> My doubt now is how do write a *clever* "getattr" routine without
> |> "Py_FindMethod".
> |
> | Well, I'd write a "tp_getattro" member function,
> | which would do its "clever" things before it falls back to
> | PyObject_GenericGetAttr to get the usual behaviour.
>
> Now I'm confused about difference between "tp_getattro" and
> "tp_getattr", and when to use them.
>
> I guess that "tp_methods" and "tp_members" are faster, but only usable
> when the data is "static" and available, while "tp_getattr" and friends
> are used when you need to execute some code in the lookup. But I read
> somewhere that "tp_getattr" was deprecated :-? ...

There is also the "tp_getset" slot (right after the "tp_members" slot) which 
is exactly for "computed" attribute access. See:
http://docs.python.org/dev/extending/newtypes.html#providing-finer-control-over-data-attributes
for further information.

-- 
Jeremy Kloth
http://4suite.org/

From martin at v.loewis.de  Tue Jul 29 21:12:33 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 29 Jul 2008 21:12:33 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <488F29FE.6090800@jcea.es>
References: <488F29FE.6090800@jcea.es>
Message-ID: <488F6BA1.1020806@v.loewis.de>

> So, I'm thinking seriously in accepting *ONLY* "bytes" in the bsddb API
> (when working under Python 3.0), and do the proxy thing *ONLY* in the
> testsuite, to be able to reuse it.
> 
> What do you think?.

I think you should write the test suite in terms of bytes.

Regards,
Martin

From g.brandl at gmx.net  Tue Jul 29 21:48:42 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 29 Jul 2008 21:48:42 +0200
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <g5vj0t$nmn$1@ger.gmane.org>
References: <g5vj0t$nmn$1@ger.gmane.org>
Message-ID: <g6ns02$tqi$1@ger.gmane.org>

Georg Brandl schrieb:
> Someone just wrote to the docs mailing list and reported that the itertools
> documentation for Py3k contains this recipe:
> 
> def grouper(n, iterable, fillvalue=None):
>      args = [iter(iterable)] * n
>      return zip_longest(*args, fillvalue=fillvalue)
> 
> It is currently a syntax error in 3k. There's also a test for it in
> test_keywordonlyarg.py, however, I can currently see no reason why
> it should be disallowed.

No opinions at all?

Georg


From steven.bethard at gmail.com  Tue Jul 29 22:02:10 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Tue, 29 Jul 2008 14:02:10 -0600
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <g6ns02$tqi$1@ger.gmane.org>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
Message-ID: <d11dcfba0807291302l27a3741em2c3a73e3082b9873@mail.gmail.com>

On Tue, Jul 29, 2008 at 1:48 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> Georg Brandl schrieb:
>>
>> Someone just wrote to the docs mailing list and reported that the
>> itertools
>> documentation for Py3k contains this recipe:
>>
>> def grouper(n, iterable, fillvalue=None):
>>     args = [iter(iterable)] * n
>>     return zip_longest(*args, fillvalue=fillvalue)
>>
>> It is currently a syntax error in 3k. There's also a test for it in
>> test_keywordonlyarg.py, however, I can currently see no reason why
>> it should be disallowed.
>
> No opinions at all?

FWIW, I'd be happy to see this allowed. I know I've wished I could do
this once or twice before.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From mike.klaas at gmail.com  Tue Jul 29 22:29:19 2008
From: mike.klaas at gmail.com (Mike Klaas)
Date: Tue, 29 Jul 2008 13:29:19 -0700
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <488F29FE.6090800@jcea.es>
References: <488F29FE.6090800@jcea.es>
Message-ID: <A39B71EC-1816-4C70-B2A5-BECF3882B051@gmail.com>


On 29-Jul-08, at 7:32 AM, Jesus Cea wrote:
>
> Working on the 3.0 version of bsddb, I have the following issue.
>
> Until 3.0, keys and values were strings. For bsddb, they are opaque,  
> and
> stored unchanged.
>
> In 3.0 the string type is replaced by unicode. A new "byte" type is
> added. So, code like "db.put('key','value')" needs to be changed to
> "db.put(bytes('key', 'utf-8'), bytes('value', 'utf-8'))", or something
> similar.


You may find this thread to be relevant:

http://mail.python.org/pipermail/python-3000/2007-August/009197.html

-Mike

From charleshixsn at earthlink.net  Wed Jul 30 00:13:22 2008
From: charleshixsn at earthlink.net (Charles Hixson)
Date: Tue, 29 Jul 2008 15:13:22 -0700
Subject: [Python-3000] __hash__ : Problem with either documentation or
	understanding
Message-ID: <200807291513.22374.charleshixsn@earthlink.net>

.../Python-3.0b2/Python-3.0b2/Doc/build/html/reference/datamodel.html#object.__hash__

"""If a class defines mutable objects and implements a __cmp__() or __eq__() 
method, it should not implement __hash__(), since the dictionary 
implementation requires that a key?s hash value is immutable (if the object?s 
hash value changes, it will be in the wrong hash bucket).
"""

What I had been planning to do was implement a hash code created by hashing a 
unique integer, say the sequential order in which the instance of the class 
was created.  This would be unique and unchanging number, so the explanation 
of why __hash__ should not be created seems wrong.  Or *could* it be created?  
In which case that statement that it shouldn't be created is wrong.

(Or, of course, I'm misunderstanding things.)

From cvrebert at gmail.com  Wed Jul 30 00:31:38 2008
From: cvrebert at gmail.com (Chris Rebert)
Date: Tue, 29 Jul 2008 15:31:38 -0700
Subject: [Python-3000] __hash__ : Problem with either documentation or
	understanding
In-Reply-To: <200807291513.22374.charleshixsn@earthlink.net>
References: <200807291513.22374.charleshixsn@earthlink.net>
Message-ID: <47c890dc0807291531v6990c468m8bf46c56ad648879@mail.gmail.com>

Your question isn't really Python-3000-specific, and belongs more on
the comp.lang.python list.

That said, whether it's right for your object really depends on how
you're defining equality for it. Are you defining equality as merely
identity (i.e. are they pointers to the same spot in memory) or does
it depend on the values of their instance variables?
If the former, then your approach is fine, and in fact Python's
default __hash__ does something similar by default using id(), so you
don't even need to implement your own __hash__; just use the default
one from class object.
If the latter, than you shouldn't implement __hash__ because, as the
docs you quote say, Bad Things (tm) will happen if someone puts your
object into a dict and then mutates it.
So really it comes down to answering the question: "Can mutating an
instance of my class affect its equality with other instances?"
I can't answer it for you since you didn't include enough information
about your exact circumstances, but you should be able to answer it
for yourself.

Hope that helps to elucidate it for you. And remember to post to the
correct mailinglist n the future.

- Chris

-- 
Follow the path of the Iguana...
Rebertia: http://rebertia.com
Blog: http://blog.rebertia.com


On Tue, Jul 29, 2008 at 3:13 PM, Charles Hixson
<charleshixsn at earthlink.net> wrote:
> .../Python-3.0b2/Python-3.0b2/Doc/build/html/reference/datamodel.html#object.__hash__
>
> """If a class defines mutable objects and implements a __cmp__() or __eq__()
> method, it should not implement __hash__(), since the dictionary
> implementation requires that a key's hash value is immutable (if the object's
> hash value changes, it will be in the wrong hash bucket).
> """
>
> What I had been planning to do was implement a hash code created by hashing a
> unique integer, say the sequential order in which the instance of the class
> was created.  This would be unique and unchanging number, so the explanation
> of why __hash__ should not be created seems wrong.  Or *could* it be created?
> In which case that statement that it shouldn't be created is wrong.
>
> (Or, of course, I'm misunderstanding things.)
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/cvrebert%40gmail.com
>

From guido at python.org  Wed Jul 30 00:36:11 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 29 Jul 2008 15:36:11 -0700
Subject: [Python-3000] Remove TarFileCompat from tarfile.py
In-Reply-To: <20080721143209.GA10793@axis.g33x.de>
References: <20080721143209.GA10793@axis.g33x.de>
Message-ID: <ca471dc20807291536o2d586f98w17cc8481c50be416@mail.gmail.com>

Sounds good to me. Less cruft is the tagline for Py3k!

On Mon, Jul 21, 2008 at 7:32 AM, Lars Gust?bel <lars at gustaebel.de> wrote:
> Hi!
>
> I just had a look at issue 3039 that reports a bug in tarfile.py's
> TarFileCompat class and I came to the conclusion that I really would like to
> remove the TarFileCompat class from Python 3.0.
>
> Some details: The ZipFile and TarFile classes both have very different
> interfaces. The original intention behind TarFileCompat was to have a second
> TarFile class with a ZipFile-like interface, so that both could be used in the
> same context.
>
> In retrospect, the addition of TarFileCompat has never been a good idea. There
> are few use cases and I think only a few people actually know that it exists.
> The class is small and has little functionality which can be accomplished
> easily without it. It has to be synchronized with ZipFile whenever that
> changes. It has no unittests, so that the TarFile.writestr() method has been
> broken for over two years without anyone noticing. Recently, TarFile's
> extract() and extractall() methods were added to ZipFile's interface.
>
> I know that this is a minor issue, but I don't want to remove TarFileCompat
> without having asked for opinions before (if there are any).
>
> Thanks.
>
> --
> Lars Gust?bel
> lars at gustaebel.de
>
> War does not determine who is right - only who is left.
> (Bertrand Russell)
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From ncoghlan at gmail.com  Wed Jul 30 00:51:09 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 30 Jul 2008 08:51:09 +1000
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <g6ns02$tqi$1@ger.gmane.org>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
Message-ID: <488F9EDD.1010009@gmail.com>

Georg Brandl wrote:
> Georg Brandl schrieb:
>> Someone just wrote to the docs mailing list and reported that the 
>> itertools
>> documentation for Py3k contains this recipe:
>>
>> def grouper(n, iterable, fillvalue=None):
>>      args = [iter(iterable)] * n
>>      return zip_longest(*args, fillvalue=fillvalue)
>>
>> It is currently a syntax error in 3k. There's also a test for it in
>> test_keywordonlyarg.py, however, I can currently see no reason why
>> it should be disallowed.
> 
> No opinions at all?

I think I was busy first time it went by :)

With keyword-only parameters allowed now, I think it makes sense to be 
able to supply the keywords arguments after the variable length argument 
as well.

Cheers,
Nick.

From ncoghlan at gmail.com  Wed Jul 30 00:55:13 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 30 Jul 2008 08:55:13 +1000
Subject: [Python-3000] __hash__ : Problem with either documentation or
 understanding
In-Reply-To: <200807291513.22374.charleshixsn@earthlink.net>
References: <200807291513.22374.charleshixsn@earthlink.net>
Message-ID: <488F9FD1.2070503@gmail.com>

Charles Hixson wrote:
> .../Python-3.0b2/Python-3.0b2/Doc/build/html/reference/datamodel.html#object.__hash__
> 
> """If a class defines mutable objects and implements a __cmp__() or __eq__() 
> method, it should not implement __hash__(), since the dictionary 
> implementation requires that a key?s hash value is immutable (if the object?s 
> hash value changes, it will be in the wrong hash bucket).
> """
> 
> What I had been planning to do was implement a hash code created by hashing a 
> unique integer, say the sequential order in which the instance of the class 
> was created.  This would be unique and unchanging number, so the explanation 
> of why __hash__ should not be created seems wrong.  Or *could* it be created?  
> In which case that statement that it shouldn't be created is wrong.
> 
> (Or, of course, I'm misunderstanding things.)

 From earlier in the paragraph you quoted:

"""The only required property is that objects which compare equal have 
the same hash value;"""

Objects which compare equal must also end up in the same hash bucket in 
order for dictionaries to work correctly.

Cheers,
Nick.

P.S. Chris is right that this question is technically off-topic.

From guido at python.org  Wed Jul 30 01:18:41 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 29 Jul 2008 16:18:41 -0700
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <488F9EDD.1010009@gmail.com>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
	<488F9EDD.1010009@gmail.com>
Message-ID: <ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>

On Tue, Jul 29, 2008 at 3:51 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Georg Brandl wrote:
>>
>> Georg Brandl schrieb:
>>>
>>> Someone just wrote to the docs mailing list and reported that the
>>> itertools
>>> documentation for Py3k contains this recipe:
>>>
>>> def grouper(n, iterable, fillvalue=None):
>>>     args = [iter(iterable)] * n
>>>     return zip_longest(*args, fillvalue=fillvalue)
>>>
>>> It is currently a syntax error in 3k. There's also a test for it in
>>> test_keywordonlyarg.py, however, I can currently see no reason why
>>> it should be disallowed.
>>
>> No opinions at all?
>
> I think I was busy first time it went by :)
>
> With keyword-only parameters allowed now, I think it makes sense to be able
> to supply the keywords arguments after the variable length argument as well.

Agreed. I doubt that this will be a simple enough change to allow it
in 3.0 though.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Wed Jul 30 02:05:13 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 29 Jul 2008 17:05:13 -0700
Subject: [Python-3000] MemoryError oddities
In-Reply-To: <g62ke1$45m$1@ger.gmane.org>
References: <g62ke1$45m$1@ger.gmane.org>
Message-ID: <ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>

Did anyone come up with a fix for these?

It's true that OverflowError and MemoryError are returned pretty
randomly when we detect that an allocation is not going to fit. I
think MemoryError is better though, so perhaps those uses of
OverflowError should be fixed. I doubt that there are any apps (except
unit tests for this specific feature) that depend on such specific
errors.

On Mon, Jul 21, 2008 at 11:26 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> In a debug-build 3k, do this (32-bit machine):
>
> Python 3.0b2+ (py3k:65171M, Jul 21 2008, 20:08:20)
> [GCC 4.2.4 (Gentoo 4.2.4 p1.0)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> "a"*1000000000
> instinstTraceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> MemoryError
> [41296 refs]
>>>> "a"*1000000000
> inst[1]    21400 segmentation fault  ./python
>
> Here, something fishy is probably going on in the unicode free list.
> Compare with 2.6:
>
> Python 2.6b2+ (trunk:65131:65163M, Jul 21 2008, 19:58:07)
> [GCC 4.2.4 (Gentoo 4.2.4 p1.0)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> u"a"*1000000000
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> MemoryError
> [34330 refs]
>>>> u"a"*1000000000
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> MemoryError
> [34332 refs]
>
> Still, the refcount seems to leak.
>
> Also:
>
>>>> b"a"*sys.maxsize
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> MemoryError
> [41297 refs]
>>>> b"a"*sys.maxsize
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "<stdin>", line 1, in <module>
> MemoryError
> [41317 refs]
>>>> b"a"*sys.maxsize
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "<stdin>", line 1, in <module>
>  File "<stdin>", line 1, in <module>
> MemoryError
> [41337 refs]
>
> This probably has to do with the fact that this MemoryError is a prebuilt
> instance.
>
> Finally:
>
>>>> "a"*sys.maxsize
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> OverflowError: repeated string is too long
> [41379 refs]
>
> Nothing wrong here, but the exception is a different one.
>
> 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-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg.ewing at canterbury.ac.nz  Wed Jul 30 03:09:07 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 30 Jul 2008 13:09:07 +1200
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <488F9EDD.1010009@gmail.com>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
	<488F9EDD.1010009@gmail.com>
Message-ID: <488FBF33.7000405@canterbury.ac.nz>

Nick Coghlan wrote:

> With keyword-only parameters allowed now, I think it makes sense to be 
> able to supply the keywords arguments after the variable length argument 
> as well.

I'm confused -- I thought that keyword-only arguments were
supposed to let you do exactly that. Or is that only in the
def and not the call?

In any case, it seems a natural thing to do in the call.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Wed Jul 30 03:11:20 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 30 Jul 2008 13:11:20 +1200
Subject: [Python-3000] __hash__ : Problem with either documentation or
 understanding
In-Reply-To: <488F9FD1.2070503@gmail.com>
References: <200807291513.22374.charleshixsn@earthlink.net>
	<488F9FD1.2070503@gmail.com>
Message-ID: <488FBFB8.4040409@canterbury.ac.nz>

Nick Coghlan wrote:

> Objects which compare equal must also end up in the same hash bucket in 
> order for dictionaries to work correctly.

And, if its equality with another object can change during
its lifetime, it will never work properly in a dictionary.
So in that case you should leave __hash__ unimplemented so
that you can't accidentally use one as a dict key.

-- 
Greg

From python at rcn.com  Wed Jul 30 03:19:11 2008
From: python at rcn.com (Raymond Hettinger)
Date: Tue, 29 Jul 2008 18:19:11 -0700
Subject: [Python-3000] Is this really a SyntaxError?
References: <g5vj0t$nmn$1@ger.gmane.org>
	<g6ns02$tqi$1@ger.gmane.org><488F9EDD.1010009@gmail.com>
	<ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>
Message-ID: <EA5C25E043FC4308925C30526F024ABA@RaymondLaptop1>

>> With keyword-only parameters allowed now, I think it makes sense to be able
>> to supply the keywords arguments after the variable length argument as well.
> 
> Agreed. I doubt that this will be a simple enough change to allow it
> in 3.0 though.

Sure would be nice if it could go in. IMO, the functionality is an essential companion to keyword-only parameters. 

Looking at the Py2.6 version of the same itertools recipe, the workaround is somewhat unattractive:

    def grouper(n, iterable, fillvalue=None):
        "grouper(3, 'abcdefg', 'x') --> abc def gxx"
        args = [iter(iterable)] * n
        kwds = dict(fillvalue=fillvalue)
        return izip_longest(*args, **kwds)


Raymond

From musiccomposition at gmail.com  Wed Jul 30 03:48:46 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 29 Jul 2008 20:48:46 -0500
Subject: [Python-3000] MemoryError oddities
In-Reply-To: <ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>
References: <g62ke1$45m$1@ger.gmane.org>
	<ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>
Message-ID: <1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com>

On Tue, Jul 29, 2008 at 7:05 PM, Guido van Rossum <guido at python.org> wrote:
> Did anyone come up with a fix for these?
>
> It's true that OverflowError and MemoryError are returned pretty
> randomly when we detect that an allocation is not going to fit. I
> think MemoryError is better though, so perhaps those uses of
> OverflowError should be fixed. I doubt that there are any apps (except
> unit tests for this specific feature) that depend on such specific
> errors.

+1 OverflowErrors should probably by reserved for numeric overflows.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From andrewm at object-craft.com.au  Wed Jul 30 04:24:01 2008
From: andrewm at object-craft.com.au (Andrew McNamara)
Date: Wed, 30 Jul 2008 12:24:01 +1000
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <488F29FE.6090800@jcea.es> 
References: <488F29FE.6090800@jcea.es>
Message-ID: <20080730022402.01A4B5CCC95@longblack.object-craft.com.au>

>Another approach would be to add a new bsddb method to specify the
>default encoding to use to convert unicode->bytes, and to do the
>conversion internally when getting unicode data as a parameter. The
>issue here is that "u'hi' != b'hi'", so the translation must be done
>both when storing and when retrieving data.

What about a new keyword argument to the constructor, "encoding". If
specified, *only* accept unicode (and do the conversion internally). If
not specified, only accept bytes. That way, people dealing with "strings"
can set-and-forget, people doing hairy stuff can use bytes, and mistakes
instantly result in an exception.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

From guido at python.org  Wed Jul 30 05:57:39 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 29 Jul 2008 20:57:39 -0700
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <EA5C25E043FC4308925C30526F024ABA@RaymondLaptop1>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
	<488F9EDD.1010009@gmail.com>
	<ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>
	<EA5C25E043FC4308925C30526F024ABA@RaymondLaptop1>
Message-ID: <ca471dc20807292057r2ae1c1bal67260f4b01b5b438@mail.gmail.com>

On Tue, Jul 29, 2008 at 6:19 PM, Raymond Hettinger <python at rcn.com> wrote:
>>> With keyword-only parameters allowed now, I think it makes sense to be able
>>> to supply the keywords arguments after the variable length argument as
>>> well.
>>
>> Agreed. I doubt that this will be a simple enough change to allow it
>> in 3.0 though.
>
> Sure would be nice if it could go in. IMO, the functionality is an essential
> companion to keyword-only parameters.
> Looking at the Py2.6 version of the same itertools recipe, the workaround is
> somewhat unattractive:
>
>   def grouper(n, iterable, fillvalue=None):
>       "grouper(3, 'abcdefg', 'x') --> abc def gxx"
>       args = [iter(iterable)] * n
>       kwds = dict(fillvalue=fillvalue)
>       return izip_longest(*args, **kwds)

If you reverse the two parts it will work:

  izip_longest(fillvalue=fillvalue, *args)

This works in 2.6 and 3.0. It would be nice to allow the other order
too, I know it's tripped me up... But the syntax would become really
tricky. So let's strive to fix this for 3.1 rather than introduce
instability in such a subtle area of the code this late in the game.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From martin at v.loewis.de  Wed Jul 30 07:03:00 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 30 Jul 2008 07:03:00 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <20080730022402.01A4B5CCC95@longblack.object-craft.com.au>
References: <488F29FE.6090800@jcea.es>
	<20080730022402.01A4B5CCC95@longblack.object-craft.com.au>
Message-ID: <488FF604.507@v.loewis.de>

> What about a new keyword argument to the constructor, "encoding". If
> specified, *only* accept unicode (and do the conversion internally).

Would that apply to keys, values, or both?

Regards,
Martin

From martin at v.loewis.de  Wed Jul 30 07:07:18 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 30 Jul 2008 07:07:18 +0200
Subject: [Python-3000] MemoryError oddities
In-Reply-To: <1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com>
References: <g62ke1$45m$1@ger.gmane.org>	<ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>
	<1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com>
Message-ID: <488FF706.2040602@v.loewis.de>

> +1 OverflowErrors should probably by reserved for numeric overflows.

In a sense, passing sys.maxsize as a string size *is* a numeric
overflow - the size can't be represented in the available variable.

Regards,
Martin

From andrewm at object-craft.com.au  Wed Jul 30 07:17:26 2008
From: andrewm at object-craft.com.au (Andrew McNamara)
Date: Wed, 30 Jul 2008 15:17:26 +1000
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <488FF604.507@v.loewis.de> 
References: <488F29FE.6090800@jcea.es>
	<20080730022402.01A4B5CCC95@longblack.object-craft.com.au>
	<488FF604.507@v.loewis.de>
Message-ID: <20080730051726.BA11E5CCC96@longblack.object-craft.com.au>

>> What about a new keyword argument to the constructor, "encoding". If
>> specified, *only* accept unicode (and do the conversion internally).
>
>Would that apply to keys, values, or both?

I admit that I deliberately glossed over that. 8-)

One option is to say "both", just to keep it simple: if you're doing
something funky, use the "bytes" mode and do your own encoding.

Another option would be have "key_encoding" and "value_encoding" as well,
and let them default to "encoding". I'm not so keen on this.

I think the important point is to throw an exception if the module gets
input of the wrong type, rather than trying to coerce the input. Which
implies it needs to know what mode it's in.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

From python at rcn.com  Wed Jul 30 08:06:45 2008
From: python at rcn.com (Raymond Hettinger)
Date: Tue, 29 Jul 2008 23:06:45 -0700
Subject: [Python-3000] Is this really a SyntaxError?
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
	<488F9EDD.1010009@gmail.com>
	<ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>
	<EA5C25E043FC4308925C30526F024ABA@RaymondLaptop1>
	<ca471dc20807292057r2ae1c1bal67260f4b01b5b438@mail.gmail.com>
Message-ID: <5A7EFD086690494DAEBE835A19FA4C68@RaymondLaptop1>

>>   def grouper(n, iterable, fillvalue=None):
>>       "grouper(3, 'abcdefg', 'x') --> abc def gxx"
>>       args = [iter(iterable)] * n
>>       kwds = dict(fillvalue=fillvalue)
>>       return izip_longest(*args, **kwds)

[GvR]
> If you reverse the two parts it will work:
> 
>  izip_longest(fillvalue=fillvalue, *args)

Wow, I'm astonished that that works.  How weird.

Am I the only one who didn't know you could
put keyword arguments before star-args?

It's especially odd given that keyword arguments
are prohibited from preceding positional arguments, so
you can't just take the star-args version and
substitute the unpacked values:

IDLE 2.6b2      
>>> from itertools import izip_longest
>>> args = 'abcdef', 'AB'
>>> list(izip_longest(fillvalue='x', *args))
[('a', 'A'), ('b', 'B'), ('c', 'x'), ('d', 'x'), ('e', 'x'), ('f', 'x')]
>>> list(izip_longest(fillvalue='x', 'abcdef', 'AB'))
SyntaxError: non-keyword arg after keyword arg


Raymond

From amauryfa at gmail.com  Wed Jul 30 11:34:41 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Wed, 30 Jul 2008 11:34:41 +0200
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
	<488F9EDD.1010009@gmail.com>
	<ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>
Message-ID: <e27efe130807300234s4d31f1fcv3f3cac874c188c27@mail.gmail.com>

Guido van Rossum wrote:
> On Tue, Jul 29, 2008 at 3:51 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Georg Brandl wrote:
>>>
>>> Georg Brandl schrieb:
>>>>
>>>> Someone just wrote to the docs mailing list and reported that the
>>>> itertools
>>>> documentation for Py3k contains this recipe:
>>>>
>>>> def grouper(n, iterable, fillvalue=None):
>>>>     args = [iter(iterable)] * n
>>>>     return zip_longest(*args, fillvalue=fillvalue)
>>>>
>>>> It is currently a syntax error in 3k. There's also a test for it in
>>>> test_keywordonlyarg.py, however, I can currently see no reason why
>>>> it should be disallowed.
>>>
>>> No opinions at all?
>>
>> I think I was busy first time it went by :)
>>
>> With keyword-only parameters allowed now, I think it makes sense to be able
>> to supply the keywords arguments after the variable length argument as well.
>
> Agreed. I doubt that this will be a simple enough change to allow it
> in 3.0 though.

I hope this patch is simple enough for you:

Index: Grammar/Grammar
===================================================================
--- Grammar/Grammar     (revision 65298)
+++ Grammar/Grammar     (working copy)
@@ -113,7 +113,9 @@

 classdef: 'class' NAME ['(' [arglist] ')'] ':' suite

-arglist: (argument ',')* (argument [',']| '*' test [',' '**' test] | '**' test)
+arglist: (argument ',')* (argument [',']
+                         |'*' test (',' NAME '=' test)* [',' '**' test]
+                         |'**' test)
 argument: test [comp_for] | test '=' test  # Really [keyword '='] test

 comp_iter: comp_for | comp_if


(and call pgen to rebuild the graminit.c)

Positional arguments after the *args are explicitly disallowed:
        f(1, *[2, 3], 4, z=5)
The syntax could make sense, but this would require more changes in
the compiler,
to properly order the parameters.

-- 
Amaury Forgeot d'Arc

From mal at egenix.com  Wed Jul 30 15:55:39 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 30 Jul 2008 15:55:39 +0200
Subject: [Python-3000] Bytes and unicode conversion in C extensions
In-Reply-To: <20080730051726.BA11E5CCC96@longblack.object-craft.com.au>
References: <488F29FE.6090800@jcea.es>	<20080730022402.01A4B5CCC95@longblack.object-craft.com.au>	<488FF604.507@v.loewis.de>
	<20080730051726.BA11E5CCC96@longblack.object-craft.com.au>
Message-ID: <489072DB.7050201@egenix.com>

On 2008-07-30 07:17, Andrew McNamara wrote:
>>> What about a new keyword argument to the constructor, "encoding". If
>>> specified, *only* accept unicode (and do the conversion internally).
>> Would that apply to keys, values, or both?
> 
> I admit that I deliberately glossed over that. 8-)
> 
> One option is to say "both", just to keep it simple: if you're doing
> something funky, use the "bytes" mode and do your own encoding.
> 
> Another option would be have "key_encoding" and "value_encoding" as well,
> and let them default to "encoding". I'm not so keen on this.
> 
> I think the important point is to throw an exception if the module gets
> input of the wrong type, rather than trying to coerce the input. Which
> implies it needs to know what mode it's in.

Since bsddb is about storing arbitrary data, I think just accepting
bytes for both keys and values is more intuitive.

The question of encoding is application and database specific, so
not something you'd want to put into a low-level interface.

BTW: If you make the database object subclassable, an application
could easily implement whatever strategy is needed on top of the
bytes-only interface.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 30 2008)
 >>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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

From 4vinoth at gmail.com  Wed Jul 30 16:37:29 2008
From: 4vinoth at gmail.com (vin vin)
Date: Wed, 30 Jul 2008 20:07:29 +0530
Subject: [Python-3000] Any Built in Session Handling?
Message-ID: <6176a14d0807300737t4b550afbh30209d36c53be557@mail.gmail.com>

HI there?

Do you planned to provide any built in session handling for web applications
in python 3000?

we should cover the basic web things to provide the Great Web Language
right?

Because as a normal web developer she would search for the basic things
first if not provided, she may disappointed :) she may not even know about
the other great web applications in Python that provides the basics.

What you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080730/1ac4f995/attachment.htm>

From musiccomposition at gmail.com  Wed Jul 30 16:41:34 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 30 Jul 2008 09:41:34 -0500
Subject: [Python-3000] Any Built in Session Handling?
In-Reply-To: <6176a14d0807300737t4b550afbh30209d36c53be557@mail.gmail.com>
References: <6176a14d0807300737t4b550afbh30209d36c53be557@mail.gmail.com>
Message-ID: <1afaf6160807300741u33a49184t4cae5736ab8d8392@mail.gmail.com>

On Wed, Jul 30, 2008 at 9:37 AM, vin vin <4vinoth at gmail.com> wrote:
> HI there?
>
> Do you planned to provide any built in session handling for web applications
> in python 3000?

No. Almost all of the standard Python web frameworks provide session management.

>
> we should cover the basic web things to provide the Great Web Language
> right?
>
> Because as a normal web developer she would search for the basic things
> first if not provided, she may disappointed :) she may not even know about
> the other great web applications in Python that provides the basics.

A good web framework will give you session management in addition to
many other web development tools.

>
> What you think?
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From guido at python.org  Wed Jul 30 18:36:40 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 30 Jul 2008 09:36:40 -0700
Subject: [Python-3000] MemoryError oddities
In-Reply-To: <488FF706.2040602@v.loewis.de>
References: <g62ke1$45m$1@ger.gmane.org>
	<ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>
	<1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com>
	<488FF706.2040602@v.loewis.de>
Message-ID: <ca471dc20807300936s1c64e3cah54c4756416ff9da5@mail.gmail.com>

On Tue, Jul 29, 2008 at 10:07 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> +1 OverflowErrors should probably by reserved for numeric overflows.
>
> In a sense, passing sys.maxsize as a string size *is* a numeric
> overflow - the size can't be represented in the available variable.

I'm sure this is the source of the confusion. The problem is that if
you specify a small enough value that you *don't* get into
unrepresentable sizes, but still very large, you do get a MemoryError.
For continuity it would be better to treat both the same, i.e. use
MemoryError consistently.

FWIW, are there any legitimate occurrences of OverflowError in Py3k
now that ints have unlimited range?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From musiccomposition at gmail.com  Wed Jul 30 18:42:32 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 30 Jul 2008 11:42:32 -0500
Subject: [Python-3000] MemoryError oddities
In-Reply-To: <ca471dc20807300936s1c64e3cah54c4756416ff9da5@mail.gmail.com>
References: <g62ke1$45m$1@ger.gmane.org>
	<ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>
	<1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com>
	<488FF706.2040602@v.loewis.de>
	<ca471dc20807300936s1c64e3cah54c4756416ff9da5@mail.gmail.com>
Message-ID: <1afaf6160807300942i22bdb61br2c1daba21894fe4d@mail.gmail.com>

On Wed, Jul 30, 2008 at 11:36 AM, Guido van Rossum <guido at python.org> wrote:
>
> FWIW, are there any legitimate occurrences of OverflowError in Py3k
> now that ints have unlimited range?

I believe not being able to convert an int to Py_ssize_t with
PyNumber_AsSsize_t is a valid use.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From guido at python.org  Wed Jul 30 21:33:26 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 30 Jul 2008 12:33:26 -0700
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <5A7EFD086690494DAEBE835A19FA4C68@RaymondLaptop1>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
	<488F9EDD.1010009@gmail.com>
	<ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>
	<EA5C25E043FC4308925C30526F024ABA@RaymondLaptop1>
	<ca471dc20807292057r2ae1c1bal67260f4b01b5b438@mail.gmail.com>
	<5A7EFD086690494DAEBE835A19FA4C68@RaymondLaptop1>
Message-ID: <ca471dc20807301233l625ad5b6mf35329e93b798cfa@mail.gmail.com>

On Tue, Jul 29, 2008 at 11:06 PM, Raymond Hettinger <python at rcn.com> wrote:
>>>  def grouper(n, iterable, fillvalue=None):
>>>      "grouper(3, 'abcdefg', 'x') --> abc def gxx"
>>>      args = [iter(iterable)] * n
>>>      kwds = dict(fillvalue=fillvalue)
>>>      return izip_longest(*args, **kwds)
>
> [GvR]
>>
>> If you reverse the two parts it will work:
>>
>>  izip_longest(fillvalue=fillvalue, *args)
>
> Wow, I'm astonished that that works.  How weird.

Long ago this was this simplest solution.

> Am I the only one who didn't know you could
> put keyword arguments before star-args?

As I alluded, I forget this on a regular basis myself.

It's not "could" though. It's "must". :-)

> It's especially odd given that keyword arguments
> are prohibited from preceding positional arguments, so
> you can't just take the star-args version and
> substitute the unpacked values:
>
> IDLE 2.6b2
>>>>
>>>> from itertools import izip_longest
>>>> args = 'abcdef', 'AB'
>>>> list(izip_longest(fillvalue='x', *args))
>
> [('a', 'A'), ('b', 'B'), ('c', 'x'), ('d', 'x'), ('e', 'x'), ('f', 'x')]
>>>>
>>>> list(izip_longest(fillvalue='x', 'abcdef', 'AB'))
>
> SyntaxError: non-keyword arg after keyword arg

Yeah, that's why we all keep forgetting it.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Wed Jul 30 21:35:07 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 30 Jul 2008 12:35:07 -0700
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <e27efe130807300234s4d31f1fcv3f3cac874c188c27@mail.gmail.com>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
	<488F9EDD.1010009@gmail.com>
	<ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>
	<e27efe130807300234s4d31f1fcv3f3cac874c188c27@mail.gmail.com>
Message-ID: <ca471dc20807301235s7bff8a83r6b5747f4daabcbdf@mail.gmail.com>

On Wed, Jul 30, 2008 at 2:34 AM, Amaury Forgeot d'Arc
<amauryfa at gmail.com> wrote:

> I hope this patch is simple enough for you:
>
> Index: Grammar/Grammar
> ===================================================================
> --- Grammar/Grammar     (revision 65298)
> +++ Grammar/Grammar     (working copy)
> @@ -113,7 +113,9 @@
>
>  classdef: 'class' NAME ['(' [arglist] ')'] ':' suite
>
> -arglist: (argument ',')* (argument [',']| '*' test [',' '**' test] | '**' test)
> +arglist: (argument ',')* (argument [',']
> +                         |'*' test (',' NAME '=' test)* [',' '**' test]
> +                         |'**' test)
>  argument: test [comp_for] | test '=' test  # Really [keyword '='] test
>
>  comp_iter: comp_for | comp_if
>
>
> (and call pgen to rebuild the graminit.c)
>
> Positional arguments after the *args are explicitly disallowed:
>        f(1, *[2, 3], 4, z=5)
> The syntax could make sense, but this would require more changes in
> the compiler,
> to properly order the parameters.

Are you saying that after the above Grammar change, the code generator
already does the right thing for Raymond's code? Then I say go for it
-- but please do add new unit tests.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From amauryfa at gmail.com  Thu Jul 31 03:17:44 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 31 Jul 2008 03:17:44 +0200
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <ca471dc20807301235s7bff8a83r6b5747f4daabcbdf@mail.gmail.com>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
	<488F9EDD.1010009@gmail.com>
	<ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>
	<e27efe130807300234s4d31f1fcv3f3cac874c188c27@mail.gmail.com>
	<ca471dc20807301235s7bff8a83r6b5747f4daabcbdf@mail.gmail.com>
Message-ID: <e27efe130807301817s47619b17k47e980f472f740d@mail.gmail.com>

2008/7/30 Guido van Rossum <guido at python.org>:
> On Wed, Jul 30, 2008 at 2:34 AM, Amaury Forgeot d'Arc
> <amauryfa at gmail.com> wrote:
>
>> I hope this patch is simple enough for you:
>>
>> Index: Grammar/Grammar
>> ===================================================================
>> --- Grammar/Grammar     (revision 65298)
>> +++ Grammar/Grammar     (working copy)
>> @@ -113,7 +113,9 @@
>>
>>  classdef: 'class' NAME ['(' [arglist] ')'] ':' suite
>>
>> -arglist: (argument ',')* (argument [',']| '*' test [',' '**' test] | '**' test)
>> +arglist: (argument ',')* (argument [',']
>> +                         |'*' test (',' NAME '=' test)* [',' '**' test]
>> +                         |'**' test)
>>  argument: test [comp_for] | test '=' test  # Really [keyword '='] test
>>
>>  comp_iter: comp_for | comp_if
>>
>>
>> (and call pgen to rebuild the graminit.c)
>>
>> Positional arguments after the *args are explicitly disallowed:
>>        f(1, *[2, 3], 4, z=5)
>> The syntax could make sense, but this would require more changes in
>> the compiler,
>> to properly order the parameters.
>
> Are you saying that after the above Grammar change, the code generator
> already does the right thing for Raymond's code?

Yes! the ast builder simply collects items from the parenthesized sequence,
and does not care about the ordering - except for an explicit
"non-keyword arg after keyword arg".

> Then I say go for it
> -- but please do add new unit tests.

Of course -- I was just requesting approval.
I am working on a documentation patch as well, and filed
http://bugs.python.org/issue3473

-- 
Amaury Forgeot d'Arc

From guido at python.org  Thu Jul 31 06:03:21 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 30 Jul 2008 21:03:21 -0700
Subject: [Python-3000] Is this really a SyntaxError?
In-Reply-To: <e27efe130807301817s47619b17k47e980f472f740d@mail.gmail.com>
References: <g5vj0t$nmn$1@ger.gmane.org> <g6ns02$tqi$1@ger.gmane.org>
	<488F9EDD.1010009@gmail.com>
	<ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com>
	<e27efe130807300234s4d31f1fcv3f3cac874c188c27@mail.gmail.com>
	<ca471dc20807301235s7bff8a83r6b5747f4daabcbdf@mail.gmail.com>
	<e27efe130807301817s47619b17k47e980f472f740d@mail.gmail.com>
Message-ID: <ca471dc20807302103o37b94fcbtcf441efb5995322e@mail.gmail.com>

Cool.

I hope others can review, and you should ask Barry if this is okay for beta3.

On Wed, Jul 30, 2008 at 6:17 PM, Amaury Forgeot d'Arc
<amauryfa at gmail.com> wrote:
> 2008/7/30 Guido van Rossum <guido at python.org>:
>> On Wed, Jul 30, 2008 at 2:34 AM, Amaury Forgeot d'Arc
>> <amauryfa at gmail.com> wrote:
>>
>>> I hope this patch is simple enough for you:
>>>
>>> Index: Grammar/Grammar
>>> ===================================================================
>>> --- Grammar/Grammar     (revision 65298)
>>> +++ Grammar/Grammar     (working copy)
>>> @@ -113,7 +113,9 @@
>>>
>>>  classdef: 'class' NAME ['(' [arglist] ')'] ':' suite
>>>
>>> -arglist: (argument ',')* (argument [',']| '*' test [',' '**' test] | '**' test)
>>> +arglist: (argument ',')* (argument [',']
>>> +                         |'*' test (',' NAME '=' test)* [',' '**' test]
>>> +                         |'**' test)
>>>  argument: test [comp_for] | test '=' test  # Really [keyword '='] test
>>>
>>>  comp_iter: comp_for | comp_if
>>>
>>>
>>> (and call pgen to rebuild the graminit.c)
>>>
>>> Positional arguments after the *args are explicitly disallowed:
>>>        f(1, *[2, 3], 4, z=5)
>>> The syntax could make sense, but this would require more changes in
>>> the compiler,
>>> to properly order the parameters.
>>
>> Are you saying that after the above Grammar change, the code generator
>> already does the right thing for Raymond's code?
>
> Yes! the ast builder simply collects items from the parenthesized sequence,
> and does not care about the ordering - except for an explicit
> "non-keyword arg after keyword arg".
>
>> Then I say go for it
>> -- but please do add new unit tests.
>
> Of course -- I was just requesting approval.
> I am working on a documentation patch as well, and filed
> http://bugs.python.org/issue3473
>
> --
> Amaury Forgeot d'Arc
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From python at rcn.com  Thu Jul 31 07:51:58 2008
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 30 Jul 2008 22:51:58 -0700
Subject: [Python-3000] Is this really a SyntaxError?
References: <g5vj0t$nmn$1@ger.gmane.org>
	<g6ns02$tqi$1@ger.gmane.org><488F9EDD.1010009@gmail.com><ca471dc20807291618k4eefed40qcf4f3854490b09d8@mail.gmail.com><e27efe130807300234s4d31f1fcv3f3cac874c188c27@mail.gmail.com><ca471dc20807301235s7bff8a83r6b5747f4daabcbdf@mail.gmail.com><e27efe130807301817s47619b17k47e980f472f740d@mail.gmail.com>
	<ca471dc20807302103o37b94fcbtcf441efb5995322e@mail.gmail.com>
Message-ID: <38058BB4B31141FF8E661CDDDF9A002E@RaymondLaptop1>

Yea!  I'm very happy about this.


----- Original Message ----- 
From: "Guido van Rossum" <guido at python.org>
To: "Amaury Forgeot d'Arc" <amauryfa at gmail.com>
Cc: <python-3000 at python.org>
Sent: Wednesday, July 30, 2008 9:03 PM
Subject: Re: [Python-3000] Is this really a SyntaxError?


> Cool.
> 
> I hope others can review, and you should ask Barry if this is okay for beta3.
> 
> On Wed, Jul 30, 2008 at 6:17 PM, Amaury Forgeot d'Arc
> <amauryfa at gmail.com> wrote:
>> 2008/7/30 Guido van Rossum <guido at python.org>:
>>> On Wed, Jul 30, 2008 at 2:34 AM, Amaury Forgeot d'Arc
>>> <amauryfa at gmail.com> wrote:
>>>
>>>> I hope this patch is simple enough for you:
>>>>
>>>> Index: Grammar/Grammar
>>>> ===================================================================
>>>> --- Grammar/Grammar     (revision 65298)
>>>> +++ Grammar/Grammar     (working copy)
>>>> @@ -113,7 +113,9 @@
>>>>
>>>>  classdef: 'class' NAME ['(' [arglist] ')'] ':' suite
>>>>
>>>> -arglist: (argument ',')* (argument [',']| '*' test [',' '**' test] | '**' test)
>>>> +arglist: (argument ',')* (argument [',']
>>>> +                         |'*' test (',' NAME '=' test)* [',' '**' test]
>>>> +                         |'**' test)
>>>>  argument: test [comp_for] | test '=' test  # Really [keyword '='] test
>>>>
>>>>  comp_iter: comp_for | comp_if
>>>>
>>>>
>>>> (and call pgen to rebuild the graminit.c)
>>>>
>>>> Positional arguments after the *args are explicitly disallowed:
>>>>        f(1, *[2, 3], 4, z=5)
>>>> The syntax could make sense, but this would require more changes in
>>>> the compiler,
>>>> to properly order the parameters.
>>>
>>> Are you saying that after the above Grammar change, the code generator
>>> already does the right thing for Raymond's code?
>>
>> Yes! the ast builder simply collects items from the parenthesized sequence,
>> and does not care about the ordering - except for an explicit
>> "non-keyword arg after keyword arg".
>>
>>> Then I say go for it
>>> -- but please do add new unit tests.
>>
>> Of course -- I was just requesting approval.
>> I am working on a documentation patch as well, and filed
>> http://bugs.python.org/issue3473
>>
>> --
>> Amaury Forgeot d'Arc
>>
> 
> 
> 
> -- 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/python%40rcn.com

From solipsis at pitrou.net  Thu Jul 31 10:26:27 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 31 Jul 2008 08:26:27 +0000 (UTC)
Subject: [Python-3000] MemoryError oddities
References: <g62ke1$45m$1@ger.gmane.org>
	<ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>
	<1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com>
	<488FF706.2040602@v.loewis.de>
	<ca471dc20807300936s1c64e3cah54c4756416ff9da5@mail.gmail.com>
Message-ID: <loom.20080731T082135-816@post.gmane.org>

Guido van Rossum <guido <at> python.org> writes:
> 
> FWIW, are there any legitimate occurrences of OverflowError in Py3k
> now that ints have unlimited range?

Legitimate:

>>> n = 2 ** 16384
>>> float(n)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C double

Perhaps a bit less legitimate but still :)

>>> r = range(n)
>>> len(r)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C ssize_t

Speaking of which, http://bugs.python.org/issue2690 (? Precompute range length
?, which has the - positive, IMHO - side effect that range objects of length
greater than sys.maxsize cannot be created at all) is still awaiting a
resolution.

Regards

Antoine.



From ncoghlan at gmail.com  Thu Jul 31 16:26:47 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 01 Aug 2008 00:26:47 +1000
Subject: [Python-3000] __hash__ : Problem with either documentation or
 understanding
In-Reply-To: <488FBFB8.4040409@canterbury.ac.nz>
References: <200807291513.22374.charleshixsn@earthlink.net>	<488F9FD1.2070503@gmail.com>
	<488FBFB8.4040409@canterbury.ac.nz>
Message-ID: <4891CBA7.2050101@gmail.com>

Greg Ewing wrote:
> Nick Coghlan wrote:
> 
>> Objects which compare equal must also end up in the same hash bucket 
>> in order for dictionaries to work correctly.
> 
> And, if its equality with another object can change during
> its lifetime, it will never work properly in a dictionary.
> So in that case you should leave __hash__ unimplemented so
> that you can't accidentally use one as a dict key.

As of 2.6b2 (and 3.0b2) you can actually set "__hash__ = None" to 
explicitly block the inheritance of the method in a new-style class and 
have Python correctly consider the type unhashable even though it has a 
__hash__ attribute.

Making object.__hash__ inherited by default again in 2.6 while still 
preserving useful behaviour for the collections.Hashable ABC turned out 
to be a fairly interesting exercise...

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Thu Jul 31 16:32:32 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 01 Aug 2008 00:32:32 +1000
Subject: [Python-3000] MemoryError oddities
In-Reply-To: <loom.20080731T082135-816@post.gmane.org>
References: <g62ke1$45m$1@ger.gmane.org>	<ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>	<1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com>	<488FF706.2040602@v.loewis.de>	<ca471dc20807300936s1c64e3cah54c4756416ff9da5@mail.gmail.com>
	<loom.20080731T082135-816@post.gmane.org>
Message-ID: <4891CD00.8070206@gmail.com>

Antoine Pitrou wrote:
> Perhaps a bit less legitimate but still :)
> 
>>>> r = range(n)
>>>> len(r)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> OverflowError: Python int too large to convert to C ssize_t
> 
> Speaking of which, http://bugs.python.org/issue2690 (? Precompute range length
> ?, which has the - positive, IMHO - side effect that range objects of length
> greater than sys.maxsize cannot be created at all) is still awaiting a
> resolution.

I think what your patch does is the correct fix for the current 3.0 
behaviour - it would probably be a good thing to get in before beta 3.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From nnorwitz at gmail.com  Thu Jul 31 19:32:08 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 31 Jul 2008 10:32:08 -0700
Subject: [Python-3000] MemoryError oddities
In-Reply-To: <ca471dc20807300936s1c64e3cah54c4756416ff9da5@mail.gmail.com>
References: <g62ke1$45m$1@ger.gmane.org>
	<ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>
	<1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com>
	<488FF706.2040602@v.loewis.de>
	<ca471dc20807300936s1c64e3cah54c4756416ff9da5@mail.gmail.com>
Message-ID: <ee2a432c0807311032o45843e48g8c7db50a79b214ab@mail.gmail.com>

On Wed, Jul 30, 2008 at 9:36 AM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Jul 29, 2008 at 10:07 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> +1 OverflowErrors should probably by reserved for numeric overflows.
>>
>> In a sense, passing sys.maxsize as a string size *is* a numeric
>> overflow - the size can't be represented in the available variable.
>
> I'm sure this is the source of the confusion. The problem is that if
> you specify a small enough value that you *don't* get into
> unrepresentable sizes, but still very large, you do get a MemoryError.
> For continuity it would be better to treat both the same, i.e. use
> MemoryError consistently.

I just checked in a bunch of security patches that do not follow this
convention.  I wanted to avoid changing the patches we exchanged on
the security list.  The errors should be changed and made consistent.
The patches were checked in to 2.4, 2.5, and trunk.  Can someone make
sure to forward port to 3k?

Thanks,
n

From guido at python.org  Thu Jul 31 19:34:12 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 31 Jul 2008 10:34:12 -0700
Subject: [Python-3000] MemoryError oddities
In-Reply-To: <ee2a432c0807311032o45843e48g8c7db50a79b214ab@mail.gmail.com>
References: <g62ke1$45m$1@ger.gmane.org>
	<ca471dc20807291705u69a55af4j1adbcc3316ef571f@mail.gmail.com>
	<1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com>
	<488FF706.2040602@v.loewis.de>
	<ca471dc20807300936s1c64e3cah54c4756416ff9da5@mail.gmail.com>
	<ee2a432c0807311032o45843e48g8c7db50a79b214ab@mail.gmail.com>
Message-ID: <ca471dc20807311034n6a63a135t1a12be1ba3c83d29@mail.gmail.com>

On Thu, Jul 31, 2008 at 10:32 AM, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On Wed, Jul 30, 2008 at 9:36 AM, Guido van Rossum <guido at python.org> wrote:
>> On Tue, Jul 29, 2008 at 10:07 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>>> +1 OverflowErrors should probably by reserved for numeric overflows.
>>>
>>> In a sense, passing sys.maxsize as a string size *is* a numeric
>>> overflow - the size can't be represented in the available variable.
>>
>> I'm sure this is the source of the confusion. The problem is that if
>> you specify a small enough value that you *don't* get into
>> unrepresentable sizes, but still very large, you do get a MemoryError.
>> For continuity it would be better to treat both the same, i.e. use
>> MemoryError consistently.
>
> I just checked in a bunch of security patches that do not follow this
> convention.  I wanted to avoid changing the patches we exchanged on
> the security list.  The errors should be changed and made consistent.
> The patches were checked in to 2.4, 2.5, and trunk.  Can someone make
> sure to forward port to 3k?

Let's first forward port these to 3k. In 2.6, I think we should leave
the exceptions as they were. In 3.0 I think it's okay to change such
OverflowErrors into MemoryErrors.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From jimjjewett at gmail.com  Thu Jul 31 19:44:49 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Thu, 31 Jul 2008 13:44:49 -0400
Subject: [Python-3000] __hash__ : Problem with either documentation or
	understanding
In-Reply-To: <47c890dc0807291531v6990c468m8bf46c56ad648879@mail.gmail.com>
References: <200807291513.22374.charleshixsn@earthlink.net>
	<47c890dc0807291531v6990c468m8bf46c56ad648879@mail.gmail.com>
Message-ID: <fb6fbf560807311044k6c336582p25324b377d8c6656@mail.gmail.com>

On 7/29/08, Chris Rebert <cvrebert at gmail.com> wrote:
>  If the latter, than you shouldn't implement __hash__ because, as the
>  docs you quote say, Bad Things (tm) will happen if someone puts your
>  object into a dict and then mutates it.

Not quite.

>  So really it comes down to answering the question: "Can mutating an
>  instance of my class affect its equality with other instances?"

Sort of.

The only time hash ever gets used is when your object is the key of a
dict (or set, or similar).  If changes can affect equality, then it
*usually* isn't suitable for use as a key, and there is no point to
making a hash.

But if the mutability is limited, it might still be OK.

Things that are equal must hash equal, but things that are unequal can
hash however they want.  (hashing unequal is useful for efficiency,
but not required.)

For example, if your objects used two attributes for equality, but
only one of them was immutable, it would be OK to use (only) the
immutable attribute for the hash; things that were even potentially
equal would hash together, which is the only strict requirement.
(Debugging would be a pain though, because whether keys were
equivalent could change between the time the dict checked and the time
you were investigating.)

-jJ

From coolman.guron at gmail.com  Thu Jul 31 17:18:33 2008
From: coolman.guron at gmail.com (binaryjesus)
Date: Thu, 31 Jul 2008 08:18:33 -0700 (PDT)
Subject: [Python-3000] is it easier to multithread ?
Message-ID: <e7f3ad37-e1de-4723-8cda-4704dd3f3108@l33g2000pri.googlegroups.com>

Is these any improvement in multi-threaded performance in the py3k
scheduler over py2?
>From what i know py2 runs only 1 (one) pythn thread at a time (refer 1
below).  Another thing that i would like to see being included in
python is auto-mutex like the java implementation. That would make my
life much easier !!

Binaryjesus-

refer1 : http://softwareramblings.com/2008/07/multi-thread-scaling-issues-with-python-and-ruby.html