> Well, one of the tradeoffs here is that Informational track allows
> something to grow into a solid standard without also having to pass the
> same level of up-front scrutiny and commitment that a Standards track
> item does. I rather doubt that either the DBAPI *or* WSGI would've
> passed that
> Because it's not clear to most of us on this thread what the failure
> modes and recovery strategies are? I know it's clear as mud to me how
> to debug these kinds of issues.
As a starting point, look at the postcommitlog. It should contain the
commands that got executed, and the error messages
On 9/27/2010 11:27 PM, Benjamin Peterson wrote:
> 2010/9/27 Meador Inge :
>> which, as seen in the trace, is because the 'detect_encoding' function in
>> 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string
>> to tokenize 'first' (a 'str' object). It seems to me that strings
At 05:41 PM 9/27/2010 -0700, Guido van Rossum wrote:
On Mon, Sep 27, 2010 at 4:29 PM, P.J. Eby wrote:
> At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote:
>>
>> On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby wrote:
>> > At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote:
>> >>
>> >> All fixed.
>> >
>
2010/9/27 Meador Inge :
> which, as seen in the trace, is because the 'detect_encoding' function in
> 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string
> to tokenize 'first' (a 'str' object). It seems to me that strings should
> still be able to be tokenized, but maybe I a
Hi All,
I was going through some of the open issues related to 'tokenize' and ran
across 'issue2180'. The reproduction case for this issue is along the lines
of:
>>> tokenize.tokenize(io.StringIO("if 1:\n \\\n #hey\n print 1").readline)
but, with 'py3k' I get:
>>> tokenize.tokenize(io.Str
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://bugs.python.org/issue9675
Long history sort: Python 2.7 backported Capsule support and
(incorrectly, in my opinion) marked CObject as deprecated.
All C modules in the stdlib were updated to Capsule (with a CObject
compatibility layer), except
On 9/26/2010 9:38 PM, P.J. Eby wrote:
Currently, the PEP preface is littered with unnecessary links,
because the PEP pre-processor turns *every* mere textual mention of a
PEP into a link to it.
Perhaps the preprocessor should only do this for the first
occurrence of each linkable phrase i
On Mon, Sep 27, 2010 at 5:09 PM, Nick Coghlan wrote:
> I saw the code for PEP 3148 go by on python-checkins the other day. Is
> there anything left to be done on that front, or can the PEP be marked
> Final?
>
> Cheers,
> Nick.
Argh, yes :)
___
Python-D
Éric Araujo writes:
> Le 25/09/2010 10:20, anatoly techtonik a écrit :
> > Python ML are:
> > 1. require dedicated admin to update, who is not a member of the group
> > 2. don't have search
> > 3. don't have optional thread subscription
> > That's already enough to seek better platform for c
On Mon, Sep 27, 2010 at 4:29 PM, P.J. Eby wrote:
> At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote:
>>
>> On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby wrote:
>> > At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote:
>> >>
>> >> All fixed.
>> >
>> > Nope. I mean, sure, I checked in fixed PEP sources
On Mon, Sep 27, 2010 at 3:41 PM, Antoine Pitrou wrote:
> While trying to solve #3873 (poor performance of pickle on file
> objects, due to the overhead of calling read() with very small values),
> it occurred to me that the prefetching facilities offered by
> BufferedIOBase are not flexible and ef
At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote:
On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby wrote:
> At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote:
>>
>> All fixed.
>
> Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but
> python.org still doesn't show PEP , or th
Hello,
While trying to solve #3873 (poor performance of pickle on file
objects, due to the overhead of calling read() with very small values),
it occurred to me that the prefetching facilities offered by
BufferedIOBase are not flexible and efficient enough.
Indeed, if you use seek() and read(),
On Mon, Sep 27, 2010 at 2:21 PM, "Martin v. Löwis" wrote:
>> Someone with web server access may want to double check the
>> modification dates of the .txt files relative to the generated .html
>> files for other PEPs though.
>
> make will deal with that just fine. If a PEP was modified, svn up wil
> Someone with web server access may want to double check the
> modification dates of the .txt files relative to the generated .html
> files for other PEPs though.
make will deal with that just fine. If a PEP was modified, svn up will
update the time stamp on the file. When then the rebuild fails,
I saw the code for PEP 3148 go by on python-checkins the other day. Is
there anything left to be done on that front, or can the PEP be marked
Final?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing
On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby wrote:
> At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote:
>>
>> All fixed.
>
> Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but
> python.org still doesn't show PEP , or the updated version of PEP 333.
Seems Brett has fixed it
On Tue, Sep 28, 2010 at 6:33 AM, P.J. Eby wrote:
> At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote:
>>
>> All fixed.
>
> Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but
> python.org still doesn't show PEP , or the updated version of PEP 333.
I tweaked the post dates
Am 27.09.2010 22:17, schrieb P.J. Eby:
> At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote:
>> All fixed.
>
> Nope.
Indeed. The immediate problem was that genpepindex tried to read
pep-, and didn't like it.
I worked around that in r85041, so that genpepindex now skips over
pep-.txt. Howeve
Am 27.09.2010 22:33, schrieb P.J. Eby:
> At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote:
>>All fixed.
>
> Nope. I mean, sure, I checked in fixed PEP sources several hours
> ago, but python.org still doesn't show PEP , or the updated
> version of PEP 333.
It does now, for me, so I assume s
I spoke too soon. The Makefile stopped complaining before I committed,
but turned out that was a lie. Fixed PEP 0 again, verifying there were
no errors after a `make clean`, touching pep-.txt, or from just
deleting pep-.txt.
On Mon, Sep 27, 2010 at 13:33, P.J. Eby wrote:
> At 12:36 PM 9/2
On Sep 27, 2010, at 10:36 PM, Éric Araujo wrote:
>> Because Yet Another Mailing List doesn't solve the problem.
>> If you need one - go Google Groups like packaging folks did.
>> Python ML are:
>> 1. require dedicated admin to update, who is not a member of the
>> group 2. don't have search
>> 3.
Hello
Le 25/09/2010 10:20, anatoly techtonik a écrit :
> On Fri, Sep 24, 2010 at 1:27 AM, Nick Coghlan wrote:
>> That's a good point actually... why *isn't* there a pydotorg-wiki-sig?
>> (Aside from the obvious point of nobody ever asking for one).
>
> Because Yet Another Mailing List doesn't so
On Mon, Sep 27, 2010 at 10:31 PM, A.M. Kuchling wrote:
> On Sun, Sep 26, 2010 at 03:53:58PM +0200, Georg Brandl wrote:
>> * redirect from wiki.python.org to wiki.python.org/moin
>
> I've added a element to the top page of
> wiki.python.org, so browsers will now jump to the /moin/ page
> immediate
At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote:
All fixed.
Nope. I mean, sure, I checked in fixed PEP sources several hours
ago, but python.org still doesn't show PEP , or the updated
version of PEP 333.
___
Python-Dev mailing list
Python-De
All fixed.
On Mon, Sep 27, 2010 at 11:22, "Martin v. Löwis" wrote:
>> The PEP still hasn't showed up on Python.org, though, so I'm wondering
>> if maybe I broke something else somewhere.
>
> See http://www.python.org/status/postcommitlog.txt
>
> Error processing PEP None (./pep-.txt), excludi
On 24/09/2010 12:06, Vinay Sajip wrote:
http://plumberjack.blogspot.com/2010/09/improved-queuehandler-queuelistener.html
Cool, how can I use it in Python 2.6? :-)
1. Copy the top part (imports, QueueHandler and QueueListener classes) from the
Gist linked to in the article - http://gist.gith
On 27/09/2010 18:22, Terry Reedy wrote:
On 9/26/2010 9:38 PM, P.J. Eby wrote:
At 11:15 AM 9/27/2010 +1000, Ben Finney wrote:
You misunderstand me; I wasn't asking how to *add* a link, but how to
turn OFF the automatic conversion of the phrase "PEP 333" that happens
without any special markup
On 9/27/2010 2:22 PM, "Martin v. Löwis" wrote:
The PEP still hasn't showed up on Python.org, though, so I'm wondering
if maybe I broke something else somewhere.
See http://www.python.org/status/postcommitlog.txt
Nasty link. That log begins back in 2008 and is so huge that it was
still loadin
> The PEP still hasn't showed up on Python.org, though, so I'm wondering
> if maybe I broke something else somewhere.
See http://www.python.org/status/postcommitlog.txt
Error processing PEP None (./pep-.txt), excluding: (./pep-.txt):
"did not deal with u'Replaces' before having to handle
At 01:22 PM 9/27/2010 -0400, Terry Reedy wrote:
On 9/26/2010 9:38 PM, P.J. Eby wrote:
At 11:15 AM 9/27/2010 +1000, Ben Finney wrote:
You misunderstand me; I wasn't asking how to *add* a link, but how to
turn OFF the automatic conversion of the phrase "PEP 333" that happens
without any special
On 9/26/2010 9:38 PM, P.J. Eby wrote:
At 11:15 AM 9/27/2010 +1000, Ben Finney wrote:
You misunderstand me; I wasn't asking how to *add* a link, but how to
turn OFF the automatic conversion of the phrase "PEP 333" that happens
without any special markup.
Currently, the PEP preface is li
On Mon, 27 Sep 2010 12:25:17 -0400
Alexander Belopolsky wrote:
> On Mon, Sep 27, 2010 at 11:28 AM, Barry Warsaw wrote:
> ..
> > If so, then I say in hg, nuke the tags we don't care about and sanitize the
> > release tags to something that obvious and can't collide (e.g. r311 is 3.1.1
> > or 3.11
On Mon, Sep 27, 2010 at 11:28 AM, Barry Warsaw wrote:
..
> If so, then I say in hg, nuke the tags we don't care about and sanitize the
> release tags to something that obvious and can't collide (e.g. r311 is 3.1.1
> or 3.11? - yes despite Guido's Rule of Version Numbering). I'd personally be
> fi
On Mon, Sep 27, 2010 at 17:28, Barry Warsaw wrote:
> I do think we should keep a mapping from new to old though. If that's not
> possible within the hg repository, can we at least generate a text file or
> some such and commit that?
I'm planning an extension so that at least the web interface wi
On Sep 27, 2010, at 04:52 PM, Georg Brandl wrote:
>I'd remove as many tags as makes sense, only keeping the release tags.
>Most others were made to quickly go back to a version before some
>change happened; however nobody would want to go back there anymore
>now. Just like my *-before-rstdocs tags
Am 27.09.2010 07:32, schrieb kristjan.jonsson:
> Author: kristjan.jonsson
> Date: Mon Sep 27 07:32:54 2010
> New Revision: 85028
>
> Log:
> issue 9910
> Add a Py_SetPath api to override magic path computations when starting up
> python.
>
> Modified:
>python/branches/py3k/Doc/c-api/init.rst
Am 26.09.2010 12:55, schrieb Dirkjan Ochtman:
> Hi all,
>
> I've recently been working on the conversion more (since my thesis got
> finished). I finally wrote the script that splits the release branches
> from the feature branches, so that we can include the former in the
> main repository and ke
On Sun, Sep 26, 2010 at 03:53:58PM +0200, Georg Brandl wrote:
> * redirect from wiki.python.org to wiki.python.org/moin
I've added a element to the top page of
wiki.python.org, so browsers will now jump to the /moin/ page
immediately. This won't help crawlers that don't parse the HTML, but
that
40 matches
Mail list logo
