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> <48405420.8010800@trueblade.com> <486927B0.60300@trueblade.com> Message-ID: 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 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 >> 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 >>>> wrote: >>>>> >>>>> wesley chun wrote: >>>>>> >>>>>> On 5/29/08, Eric Smith 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: 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> <48405420.8010800@trueblade.com> <486927B0.60300@trueblade.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 > 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 >>> 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 >>>>> wrote: >>>>>> wesley chun wrote: >>>>>>> On 5/29/08, Eric Smith 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> <48405420.8010800@trueblade.com> <486927B0.60300@trueblade.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 >> 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 >>>> 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 >>>>>> wrote: >>>>>>> wesley chun wrote: >>>>>>>> On 5/29/08, Eric Smith 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: 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: References: Message-ID: On Tue, Jul 1, 2008 at 5:37 AM, Amaury Forgeot d'Arc 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: 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: 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 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: 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: References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org> Message-ID: <4222a8490807011328v4df3eb9fl7de44be415b334ff@mail.gmail.com> On Tue, Jul 1, 2008 at 4:23 PM, Georg Brandl 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: References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org> Message-ID: -----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> Message-ID: 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: References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org> Message-ID: <1afaf6160807011345n650a645fq661908f75a1f6a03@mail.gmail.com> On Tue, Jul 1, 2008 at 3:40 PM, Barry Warsaw 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> Message-ID: <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> From: "Barry Warsaw" > 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> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> Message-ID: On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger wrote: > From: "Barry Warsaw" > >> 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: 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: References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> 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 > wrote: > From: "Barry Warsaw" > > 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> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org> Message-ID: On Tue, Jul 1, 2008 at 3:55 PM, Barry Warsaw wrote: > On Jul 1, 2008, at 4:54 PM, Guido van Rossum wrote: >> On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger wrote: >> From: "Barry Warsaw" >> >> 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: References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org> 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 wrote: >> On Jul 1, 2008, at 4:54 PM, Guido van Rossum wrote: >>> On Tue, Jul 1, 2008 at 1:51 PM, Raymond Hettinger >>> wrote: >>> From: "Barry Warsaw" >>> >>> 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> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org> Message-ID: On Tue, Jul 1, 2008 at 3:55 PM, Barry Warsaw 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 wrote: >> From: "Barry Warsaw" >> >> 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: References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org> Message-ID: <1afaf6160807011628m43738e85x3f03064a6df307ef@mail.gmail.com> On Tue, Jul 1, 2008 at 6:27 PM, Brett Cannon 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: 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: 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: References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org> 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 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 >>> wrote: >>> From: "Barry Warsaw" >>> >>> 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> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org> <79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org> Message-ID: On Tue, Jul 1, 2008 at 6:44 PM, Barry Warsaw 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 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 >>>> wrote: >>>> From: "Barry Warsaw" >>>> >>>> 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> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org> <79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org> Message-ID: <1afaf6160807011942r738aae8u6c84aab03d463d76@mail.gmail.com> On Tue, Jul 1, 2008 at 8:44 PM, Barry Warsaw 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> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org> <79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org> <1afaf6160807011942r738aae8u6c84aab03d463d76@mail.gmail.com> Message-ID: -----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 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: References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org> Message-ID: -----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 > To: Eric Smith > 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> > <48405420.8010800 at trueblade.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 > 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: References: Message-ID: <20080702193609.3381614C6FB@irishsea.home.craig-wood.com> Paul Langevin 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 -- 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: <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: <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" : > 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: <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: <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" : > >> 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: On Wed, Jul 2, 2008 at 1:17 PM, Benjamin Peterson 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: On Wed, Jul 2, 2008 at 1:17 PM, Benjamin Peterson 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: References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com> Message-ID: On Wed, Jul 2, 2008 at 1:57 PM, Josiah Carlson wrote: > On Wed, Jul 2, 2008 at 1:17 PM, Benjamin Peterson > 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: References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com> Message-ID: <1afaf6160807021600u302abbddife6e3518a8321015@mail.gmail.com> On Wed, Jul 2, 2008 at 5:50 PM, Josiah Carlson 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 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 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: References: <2865D095-DA45-4875-AE40-8A5F8C81C299@python.org> <9B1D90667C03488BB57E09808F4C9B64@RaymondLaptop1> <8A43F3E7-BEE8-4656-833D-867328D16D52@python.org> <79F76ED3-D21C-4D1D-B6B0-ECEBDFCEDDE3@python.org> <1afaf6160807011942r738aae8u6c84aab03d463d76@mail.gmail.com> Message-ID: <52dc1c820807051200v9bb3673g967aa6d596520f6a@mail.gmail.com> On Tue, Jul 1, 2008 at 8:29 PM, Barry Warsaw wrote: > On Jul 1, 2008, at 10:42 PM, Benjamin Peterson wrote: > >> On Tue, Jul 1, 2008 at 8:44 PM, Barry Warsaw 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.comas a friend in your existing google calendar to see the release schedule calendar alongside your own. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: <43aa6ff70807052007g6ea3a182uf0e337cc70f31773@mail.gmail.com> On Tue, Jul 1, 2008 at 10:06 AM, Guido van Rossum wrote: > On Tue, Jul 1, 2008 at 5:37 AM, Amaury Forgeot d'Arc 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: References: <1afaf6160807021317n6ad28c3bq47a32dc85a63ab1a@mail.gmail.com> Message-ID: On Wed, Jul 2, 2008 at 3:50 PM, Josiah Carlson wrote: > On Wed, Jul 2, 2008 at 1:57 PM, Josiah Carlson wrote: >> On Wed, Jul 2, 2008 at 1:17 PM, Benjamin Peterson >> 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 "", line 1, in File "", line 1, in File "", 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 "", line 1, in > File "", line 1, in > File "", 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: It's suspect, please file a bug. Thanks for noticing! On Wed, Jul 9, 2008 at 7:49 AM, 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 "", line 1, in > File "", line 1, in > File "", 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> Message-ID: 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 "", line 2, in File "", 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: References: 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 wrote: > > On Tue, Jul 1, 2008 at 5:37 AM, Amaury Forgeot d'Arc 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> Message-ID: Carl Johnson 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> Message-ID: On Thu, Jul 10, 2008 at 6:28 AM, Antoine Pitrou wrote: > Carl Johnson 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> Message-ID: Antoine Pitrou wrote: > Carl Johnson 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> 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> Message-ID: From: "Guido van Rossum" > 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> Message-ID: On Thu, Jul 10, 2008 at 2:26 PM, Raymond Hettinger 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> <48769FAC.4030702@canterbury.ac.nz> Message-ID: 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> Message-ID: <775965700EF44A1F967430F94451B273@RaymondLaptop1> From: "Guido van Rossum" > 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> <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> <775965700EF44A1F967430F94451B273@RaymondLaptop1> <487732E6.6000408@gmail.com> Message-ID: <430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1> From: "Nick Coghlan" > 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> <775965700EF44A1F967430F94451B273@RaymondLaptop1> <487732E6.6000408@gmail.com> <430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1> Message-ID: <48775918.8070105@gmail.com> Raymond Hettinger wrote: > From: "Nick Coghlan" >> 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> <775965700EF44A1F967430F94451B273@RaymondLaptop1> Message-ID: On Fri, Jul 11, 2008 at 12:00 AM, Raymond Hettinger wrote: > From: "Guido van Rossum" >> >> 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 [] should be implemented as completely equivalent to list(). 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> <48769FAC.4030702@canterbury.ac.nz> Message-ID: On Thu, Jul 10, 2008 at 11:45 PM, Stefan Behnel 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> <48769FAC.4030702@canterbury.ac.nz> 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> <775965700EF44A1F967430F94451B273@RaymondLaptop1> <487732E6.6000408@gmail.com> <430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1> Message-ID: <4877FE17.4090502@gmail.com> Raymond Hettinger wrote: > From: "Nick Coghlan" >> 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 ( at 0xb7c41260, file "", 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> <48769FAC.4030702@canterbury.ac.nz> <4877F696.1000405@canterbury.ac.nz> Message-ID: On Fri, Jul 11, 2008 at 6:11 PM, Greg Ewing 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> <48769FAC.4030702@canterbury.ac.nz> 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> <48769FAC.4030702@canterbury.ac.nz> <48780499.2060800@canterbury.ac.nz> Message-ID: On Fri, Jul 11, 2008 at 7:10 PM, 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? > > 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> <48769FAC.4030702@canterbury.ac.nz> <4877F696.1000405@canterbury.ac.nz> Message-ID: Adam Olsen wrote: > On Fri, Jul 11, 2008 at 6:11 PM, Greg Ewing 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: 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() # 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> <48769FAC.4030702@canterbury.ac.nz> <48780499.2060800@canterbury.ac.nz> Message-ID: 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> <775965700EF44A1F967430F94451B273@RaymondLaptop1> <487732E6.6000408@gmail.com> <430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1> Message-ID: 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> <775965700EF44A1F967430F94451B273@RaymondLaptop1> <487732E6.6000408@gmail.com> <430824B9D65C4090AC3780CBE24EE3AD@RaymondLaptop1> 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: 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 "", line 1, in File "", line 1, in File "", 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> <4877FFF3.5090900@gmail.com> 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: 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> <487943D6.1060203@canterbury.ac.nz> Message-ID: Greg Ewing 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> <4877FFF3.5090900@gmail.com> <487943D6.1060203@canterbury.ac.nz> 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: 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 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 wrote: > "Benjamin Peterson" writes: > >> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney 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 --- /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}, 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 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" To: "nirinA raseliarison" ; "python-3000" 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 > 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" writes: > On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney 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 wrote: > >> "Benjamin Peterson" writes: >> >> >>> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney 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) -- 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 >> wrote: >>> "Benjamin Peterson" writes: >>>> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney >>>> 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) > > 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) -- 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 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: On Tue, Jul 15, 2008 at 3:27 AM, Mark Dickinson 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 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: 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: References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org> Message-ID: <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com> On Tue, Jul 15, 2008 at 8:42 AM, Antoine Pitrou 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> <48769FAC.4030702@canterbury.ac.nz> <4877F696.1000405@canterbury.ac.nz> Message-ID: On Fri, Jul 11, 2008 at 5:11 PM, Greg Ewing 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: References: Message-ID: Go right ahead. On Sat, Jul 12, 2008 at 6:36 PM, Brett Cannon 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: 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> <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com> Message-ID: On Tue, Jul 15, 2008 at 6:47 AM, Benjamin Peterson wrote: > On Tue, Jul 15, 2008 at 8:42 AM, Antoine Pitrou 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: On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw 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: References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org> <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com> Message-ID: On Tue, Jul 15, 2008 at 11:34 AM, Brett Cannon 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: References: <8624BB4A-D629-4B28-A34C-AC50EA8CDAD5@carlsensei.com> <48769FAC.4030702@canterbury.ac.nz> <4877F696.1000405@canterbury.ac.nz> Message-ID: 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> <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com> Message-ID: 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: References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org> <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com> Message-ID: On Tue, Jul 15, 2008 at 1:28 PM, Antoine Pitrou 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: References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org> 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: References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org> Message-ID: -----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 > 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: References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org> <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@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: References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org> Message-ID: On Tue, Jul 15, 2008 at 4:45 PM, Barry Warsaw 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 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 : >> >>> 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> <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: References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org> <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com> 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> <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com> <487D8287.1030606@gmail.com> Message-ID: 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: Hi, Barry Warsaw 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: References: <585A47BF-246A-416D-B83C-E74933B0EB0E@python.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 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: 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: References: <294E40E5-06DF-43B8-8895-96AB2C319038@python.org> <1afaf6160807150647n3fa5d6c2lbaf0db42bad76fd@mail.gmail.com> <487D8287.1030606@gmail.com> Message-ID: <1afaf6160807160644w75db0be3p2911be6648920bb5@mail.gmail.com> On Wed, Jul 16, 2008 at 12:37 AM, Stefan Behnel 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" >> >>> 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 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 #include #include 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: On Wed, Jul 16, 2008 at 11:04 AM, nirinA raseliarison 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 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: References: 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: References: <585A47BF-246A-416D-B83C-E74933B0EB0E@python.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> <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 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: On Thu, Jul 17, 2008 at 6:16 AM, Jesse Noller 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: References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org> <4222a8490807170616x5ca600fdw3e6d0bced885c943@mail.gmail.com> Message-ID: <4222a8490807170836o1875cef4u8b42d3e7edb1160b@mail.gmail.com> On Thu, Jul 17, 2008 at 10:07 AM, Guido van Rossum wrote: > On Thu, Jul 17, 2008 at 6:16 AM, Jesse Noller 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 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> <4222a8490807170836o1875cef4u8b42d3e7edb1160b@mail.gmail.com> Message-ID: On Thu, Jul 17, 2008 at 8:36 AM, Jesse Noller wrote: > On Thu, Jul 17, 2008 at 10:07 AM, Guido van Rossum wrote: >> On Thu, Jul 17, 2008 at 6:16 AM, Jesse Noller 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 wrote: > On Thu, Jul 17, 2008 at 12:30 AM, Barry Warsaw 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: 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: 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" 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 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: On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake 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: 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: -----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 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: -----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: -----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: References: Message-ID: On Thu, Jul 17, 2008 at 8:50 PM, Barry Warsaw 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: 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: On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum wrote: > On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake 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: 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: On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon wrote: > On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum wrote: >> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake 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: 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: On Fri, Jul 18, 2008 at 7:21 AM, Guido van Rossum wrote: > On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon wrote: >> On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum wrote: >>> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake 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: 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: On Fri, Jul 18, 2008 at 7:57 AM, Josiah Carlson 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: 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: On Fri, Jul 18, 2008 at 8:11 AM, Guido van Rossum wrote: > On Fri, Jul 18, 2008 at 7:57 AM, Josiah Carlson > 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: 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: 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 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: 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: On Fri, Jul 18, 2008 at 7:21 AM, Guido van Rossum wrote: > On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon wrote: >> On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum wrote: >>> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake 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: 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: <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: References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org> <487FD54C.2040308@v.loewis.de> <0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org> Message-ID: On Fri, Jul 18, 2008 at 11:03 AM, 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. 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> <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: 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: <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 wrote: |> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake 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> <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 "", line 1, in 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: References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org> <487FD54C.2040308@v.loewis.de> <0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org> Message-ID: <4881C04E.5060208@gmail.com> Josiah Carlson wrote: > On Fri, Jul 18, 2008 at 11:03 AM, 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. > > 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> <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. > 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> <4881451B.9010304@jcea.es> <04f601c8e947$d4d27010$7e775030$@com.au> <4881D97D.10603@ibp.de> Message-ID: On Sat, Jul 19, 2008 at 9:09 AM, Lars Immisch 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. > > > >> 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 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" 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> <4881C04E.5060208@gmail.com> Message-ID: On Sat, Jul 19, 2008 at 3:22 AM, Nick Coghlan wrote: > Josiah Carlson wrote: >> >> On Fri, Jul 18, 2008 at 11:03 AM, 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. >> >> 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 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: 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: On Sat, Jul 19, 2008 at 1:00 AM, Jesus Cea 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> Message-ID: <467ABF79AE854A27B9862327301B1838@RaymondLaptop1> From: "Brett Cannon" > 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: References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org> <4881C04E.5060208@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: 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> <4881C04E.5060208@gmail.com> <4882986A.3060509@jcea.es> Message-ID: On Sat, Jul 19, 2008 at 6:44 PM, Jesus Cea 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: References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org> <4882986A.3060509@jcea.es> 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 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: References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org> <4881C04E.5060208@gmail.com> <4882986A.3060509@jcea.es> 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: 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: References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org> <4881C04E.5060208@gmail.com> <4882986A.3060509@jcea.es> 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: References: <1DB64EE3-AEC5-4745-B3F3-BB7321B3E5D4@python.org> <1afaf6160807170841x7cf14947x1276878b4fd50cd4@mail.gmail.com> <487FD54C.2040308@v.loewis.de> <0A94A999-9CF4-4864-BF26-829BB2798ED5@acm.org> <4881451B.9010304@jcea.es> <04f601c8e947$d4d27010$7e775030$@com.au> <4881D97D.10603@ibp.de> 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 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: Message-ID: Hi, Georg Brandl 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> <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: On Mon, Jul 21, 2008 at 8:16 AM, nirinA raseliarison 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> <4881451B.9010304@jcea.es> <04f601c8e947$d4d27010$7e775030$@com.au> Message-ID: 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: 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 "", line 1, in 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 "", line 1, in MemoryError [34330 refs] >>> u"a"*1000000000 Traceback (most recent call last): File "", line 1, in MemoryError [34332 refs] Still, the refcount seems to leak. Also: >>> b"a"*sys.maxsize Traceback (most recent call last): File "", line 1, in MemoryError [41297 refs] >>> b"a"*sys.maxsize Traceback (most recent call last): File "", line 1, in File "", line 1, in MemoryError [41317 refs] >>> b"a"*sys.maxsize Traceback (most recent call last): File "", line 1, in File "", line 1, in File "", line 1, in 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 "", line 1, in 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: 2008/7/21 Jesus Cea : > -----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: 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> <4881C04E.5060208@gmail.com> <4882986A.3060509@jcea.es> <48845653.5000100@jcea.es> Message-ID: On Mon, Jul 21, 2008 at 2:26 AM, Jesus Cea 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: 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: 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: 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" To: "Python 3000" 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: <40671021E4774D03B1F1C5464C5DB3B2@RaymondLaptop1> Message-ID: 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" > To: "Python 3000" > 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 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 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: References: <40671021E4774D03B1F1C5464C5DB3B2@RaymondLaptop1> Message-ID: <43aa6ff70807242158o3717cb00y8e9e473abfabc314@mail.gmail.com> On Thu, Jul 24, 2008 at 9:39 PM, Robert Brewer 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" >> To: "Python 3000" >> 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 > 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 > 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: <40671021E4774D03B1F1C5464C5DB3B2@RaymondLaptop1> <43aa6ff70807242158o3717cb00y8e9e473abfabc314@mail.gmail.com> Message-ID: <1afaf6160807250551uca40d37p6412b9d665c0c608@mail.gmail.com> On Thu, Jul 24, 2008 at 11:58 PM, Collin Winter 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: References: Message-ID: 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: 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: 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: References: Message-ID: On Mon, Jul 28, 2008 at 11:45 AM, Antoine Pitrou 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: References: <4884A48B.2070904@jcea.es> 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: References: <488171D2.5000709@jcea.es> 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> <488F2156.7010803@jcea.es> Message-ID: 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: References: <488171D2.5000709@jcea.es> <488F2156.7010803@jcea.es> 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> <488F2156.7010803@jcea.es> <488F2C40.1060006@jcea.es> Message-ID: 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: 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: 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> <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: References: Message-ID: 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: References: Message-ID: On Tue, Jul 29, 2008 at 1:48 PM, 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? 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: 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 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: Sounds good to me. Less cruft is the tagline for Py3k! On Mon, Jul 21, 2008 at 7:32 AM, Lars Gust?bel 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: References: 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: <488F9EDD.1010009@gmail.com> Message-ID: On Tue, Jul 29, 2008 at 3:51 PM, Nick Coghlan 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: References: Message-ID: 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 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 "", line 1, in > 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 "", line 1, in > MemoryError > [34330 refs] >>>> u"a"*1000000000 > Traceback (most recent call last): > File "", line 1, in > MemoryError > [34332 refs] > > Still, the refcount seems to leak. > > Also: > >>>> b"a"*sys.maxsize > Traceback (most recent call last): > File "", line 1, in > MemoryError > [41297 refs] >>>> b"a"*sys.maxsize > Traceback (most recent call last): > File "", line 1, in > File "", line 1, in > MemoryError > [41317 refs] >>>> b"a"*sys.maxsize > Traceback (most recent call last): > File "", line 1, in > File "", line 1, in > File "", line 1, in > 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 "", line 1, in > 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: <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: <488F9EDD.1010009@gmail.com> Message-ID: >> 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: References: Message-ID: <1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com> On Tue, Jul 29, 2008 at 7:05 PM, Guido van Rossum 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: References: <488F9EDD.1010009@gmail.com> Message-ID: On Tue, Jul 29, 2008 at 6:19 PM, Raymond Hettinger 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: <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: <488F9EDD.1010009@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: References: <488F9EDD.1010009@gmail.com> Message-ID: Guido van Rossum wrote: > On Tue, Jul 29, 2008 at 3:51 PM, Nick Coghlan 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: 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: <1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com> <488FF706.2040602@v.loewis.de> Message-ID: On Tue, Jul 29, 2008 at 10:07 PM, "Martin v. L?wis" 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: References: <1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com> <488FF706.2040602@v.loewis.de> Message-ID: <1afaf6160807300942i22bdb61br2c1daba21894fe4d@mail.gmail.com> On Wed, Jul 30, 2008 at 11:36 AM, Guido van Rossum 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: <488F9EDD.1010009@gmail.com> <5A7EFD086690494DAEBE835A19FA4C68@RaymondLaptop1> Message-ID: On Tue, Jul 29, 2008 at 11:06 PM, Raymond Hettinger 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: References: <488F9EDD.1010009@gmail.com> Message-ID: On Wed, Jul 30, 2008 at 2:34 AM, Amaury Forgeot d'Arc 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: References: <488F9EDD.1010009@gmail.com> Message-ID: 2008/7/30 Guido van Rossum : > On Wed, Jul 30, 2008 at 2:34 AM, Amaury Forgeot d'Arc > 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: References: <488F9EDD.1010009@gmail.com> Message-ID: 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 wrote: > 2008/7/30 Guido van Rossum : >> On Wed, Jul 30, 2008 at 2:34 AM, Amaury Forgeot d'Arc >> 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: <488F9EDD.1010009@gmail.com> Message-ID: <38058BB4B31141FF8E661CDDDF9A002E@RaymondLaptop1> Yea! I'm very happy about this. ----- Original Message ----- From: "Guido van Rossum" To: "Amaury Forgeot d'Arc" Cc: 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 > wrote: >> 2008/7/30 Guido van Rossum : >>> On Wed, Jul 30, 2008 at 2:34 AM, Amaury Forgeot d'Arc >>> 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: <1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com> <488FF706.2040602@v.loewis.de> Message-ID: Guido van Rossum 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 "", line 1, in 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 "", line 1, in 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: References: <1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com> <488FF706.2040602@v.loewis.de> 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 "", line 1, in > 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: References: <1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com> <488FF706.2040602@v.loewis.de> Message-ID: On Wed, Jul 30, 2008 at 9:36 AM, Guido van Rossum wrote: > On Tue, Jul 29, 2008 at 10:07 PM, "Martin v. L?wis" 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: References: <1afaf6160807291848k3798d701xad57e8771a95c6e9@mail.gmail.com> <488FF706.2040602@v.loewis.de> Message-ID: On Thu, Jul 31, 2008 at 10:32 AM, Neal Norwitz wrote: > On Wed, Jul 30, 2008 at 9:36 AM, Guido van Rossum wrote: >> On Tue, Jul 29, 2008 at 10:07 PM, "Martin v. L?wis" 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: On 7/29/08, Chris Rebert 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: 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