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
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
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
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
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 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, 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 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
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
> 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
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
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 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
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
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
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
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 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.
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
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
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
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
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
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 | [email protected] | Brisbane, Australia
___
Python-Dev mailing
> 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,
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
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(),
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
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
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
É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 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
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
-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
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
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
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.
>> >
>
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
> 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
> 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
40 matches
Mail list logo
