On 1/6/2011 11:54 PM, Nick Coghlan wrote:
On Thu, Jan 6, 2011 at 4:00 PM, Terry Reedy wrote:
Does it behave itself if you add "-x test_capi" to the command line?
No, it gets worse. Really.
Let me summarize a long post.
Run 1: normal (as above)
Process stops at capi test with Windows error me
On Tue, 2011-01-04 at 03:44 +0100, Victor Stinner wrote:
> What is this horrible encoding "bytes-as-unicode"?
It is a unicode string decoded from bytes using ISO-8859-1. ISO-8859-1
is the encoding specified by the HTTP RFC, as well as having the happy
property of preserving every input byte.
> os
Le jeudi 06 janvier 2011 à 23:50 +, And Clover a écrit :
> On Tue, 2011-01-04 at 03:44 +0100, Victor Stinner wrote:
> > What is this horrible encoding "bytes-as-unicode"?
>
> It is a unicode string decoded from bytes using ISO-8859-1. ISO-8859-1
> is the encoding specified by the HTTP RFC, as
Victor Stinner writes:
> It doesn't work and so something has to be changed.
What specific bug have you observed?
Everybody hates this hack, or at the very least is somewhat
embarrassed by it, but the working group clearly believes that it
works and something like it is necessary. They've stud
On Fri, Jan 7, 2011 at 9:51 PM, Victor Stinner
wrote:
> On POSIX, the current code looks like that:
>
> a) the OS pass a bytes environ to the program
> b) Python decodes environ from the locale encoding
> c) wsgi.read_environ() encodes environ to the locale encoding to get
> back the original b
On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote:
> I don't understand why you are attached to this horrible hack
> (bytes-in-unicode). It introduces more work and more confusing than
> using raw bytes unchanged.
>
> It doesn't work and so something has to be changed.
It's gross but it does work.
I think I've said all I can say in this thread; I'm sure you will come
up with a satisfactory solution.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
Le vendredi 07 janvier 2011 à 16:39 +0100, phillip.eby a écrit :
> Author: phillip.eby
> Date: Fri Jan 7 16:39:27 2011
> New Revision: 87815
>
> Log:
> More bytes I/O fixes
>
>
> Modified:
>peps/trunk/pep-.txt
>
> Modified: peps/trunk/pep-.txt
>
On Fri, 7 Jan 2011 16:45:26 +0100 (CET)
phillip.eby wrote:
> Author: phillip.eby
> Date: Fri Jan 7 16:45:26 2011
> New Revision: 87816
>
> Log:
> Fix re-raise syntax for Python 3
>
>
> Modified:
>peps/trunk/pep-.txt
>
> Modified: peps/trunk/pep-.txt
>
At 09:43 AM 1/7/2011 -0500, James Y Knight wrote:
On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote:
> I don't understand why you are attached to this horrible hack
> (bytes-in-unicode). It introduces more work and more confusing than
> using raw bytes unchanged.
>
> It doesn't work and so somethi
ACTIVITY SUMMARY (2010-12-31 - 2011-01-07)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2501 (-24)
closed 20138 (+80)
total 22639 (+56)
Open issues wit
There are many API changes and proposals that were forgotten and
didn't get into Python 3, although they should be, because it was the
only chance to change things with backwards compatibility break. For
example http://bugs.python.org/issue1559549
This happened, because of poor bug management, whe
On Fri, Jan 7, 2011 at 11:20, anatoly techtonik wrote:
> There are many API changes and proposals that were forgotten and
> didn't get into Python 3, although they should be, because it was the
> only chance to change things with backwards compatibility break. For
> example http://bugs.python.org
On 07/01/2011 17:07, Python tracker wrote:
ACTIVITY SUMMARY (2010-12-31 - 2011-01-07)
Python tracker athttp://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2501 (-24)
closed 2013
On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin wrote:
>>
>> There are many API changes and proposals that were forgotten and
>> didn't get into Python 3, although they should be, because it was the
>> only chance to change things with backwards compatibility break. For
>> example http://bugs.python.
On Fri, Jan 7, 2011 at 7:55 PM, Michael Foord wrote:
> On 07/01/2011 17:07, Python tracker wrote:
>>
>> ACTIVITY SUMMARY (2010-12-31 - 2011-01-07)
>> Python tracker athttp://bugs.python.org/
>>
>> To view or respond to any of the issues listed below, click on the issue.
>> Do NOT respond to this m
On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote:
> On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin
> wrote:
> >>
> >> There are many API changes and proposals that were forgotten and
> >> didn't get into Python 3, although they should be, because it was the
> >> only chance to change things w
On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote:
..
> Don't you think that if people could review issues and "star" them
> then such minor issues could be scheduled for release not only by
> "severity" status as decided be release manager and several core
> developers, but also by communit
On 2011-01-07, at 7:14 PM, anatoly techtonik wrote:
> Don't you think that if people could review issues and "star" them
> then such minor issues could be scheduled for release not only by
> "severity" status as decided be release manager and several core
> developers, but also by community vote?
P.J. Eby wrote:
> At 09:43 AM 1/7/2011 -0500, James Y Knight wrote:
> >On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote:
> > > I don't understand why you are attached to this horrible hack
> > > (bytes-in-unicode). It introduces more work and more confusing
than
> > > using raw bytes unchanged.
> >
On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote:
> On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin
> wrote:
> >>
> >> This mostly because of limitation of our tracker and desire of people
> >> to extend it to get damn "stars", module split, sorting, digging and
> >> tagging options.
> >
> > I
On Fri, Jan 7, 2011 at 1:17 PM, anatoly techtonik wrote:
..
>>> Issues counts and deltas:
>>> open 2501 (-24)
>>> closed 20138 (+80)
>>> total 22639 (+56)
..
> Less users -> less issues. It's always easy to speedup the process by
> leaving the most irritating ones. ;)
You should read th
On Fri, 7 Jan 2011 13:36:26 -0500
Alexander Belopolsky wrote:
> On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote:
> ..
> > Don't you think that if people could review issues and "star" them
> > then such minor issues could be scheduled for release not only by
> > "severity" status as deci
On Fri, 7 Jan 2011 12:39:34 -0600
Brian Curtin wrote:
> >
> > I haven't started using Python 3 yet, but I already know some annoying
> > API issues that are not fixed there. Unfortunately, I don't remember
> > them to give you a list. That's why I asked for a flag.
>
> If you haven't used it yet,
> Module split:
> try to get all issues for 'os' module
> try to subscribe to all commits for 'CGIHTTPServer'
+1
I've been thinking about such a thing as well and I think it would be useful.
Every now and then I go to the bug tracker to see whether the modules
I usually maintain (mainly ftplib,
On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
wrote:
> -1 on the "star system" for the tracker
The tracker on Google Code uses stars. We use this tracker to track
external App Engine issues. It works very well to measure how
widespread a particular issue or need is (even if we don't alway
Am 07.01.2011 19:39, schrieb Brian Curtin:
> Tagging:
> as a tracker user, try to add tag 'easy' to some easy issue
>
>
> You probably need escalated privileges for this. If you can't change it, you
> can
> always request on the issue that a field be changed.
He *could* also behave re
On 07/01/2011 19:11, Guido van Rossum wrote:
On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
wrote:
-1 on the "star system" for the tracker
The tracker on Google Code uses stars. We use this tracker to track
external App Engine issues. It works very well to measure how
widespread a part
On Fri, 7 Jan 2011 11:11:47 -0800
Guido van Rossum wrote:
> On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
> wrote:
> > -1 on the "star system" for the tracker
>
> The tracker on Google Code uses stars. We use this tracker to track
> external App Engine issues. It works very well to meas
On Fri, Jan 7, 2011 at 11:15 AM, Michael Foord
wrote:
> On 07/01/2011 19:11, Guido van Rossum wrote:
>>
>> On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
>> wrote:
>>>
>>> -1 on the "star system" for the tracker
>>
>> The tracker on Google Code uses stars. We use this tracker to track
>>
On Fri, Jan 7, 2011 at 11:18 AM, Antoine Pitrou wrote:
> I'd also mention that many bugzilla installs have a "voting" facility
> where people can vote for a limited number of issues of their choice (I
> think the number of votes also depends on the user's number of
> contributions, although I'm no
On 07/01/2011 18:44, Antoine Pitrou wrote:
On Fri, 7 Jan 2011 13:36:26 -0500
Alexander Belopolsky wrote:
On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote:
..
Don't you think that if people could review issues and "star" them
then such minor issues could be scheduled for release not on
On 07/01/2011 19:22, Guido van Rossum wrote:
On Fri, Jan 7, 2011 at 11:15 AM, Michael Foord
wrote:
On 07/01/2011 19:11, Guido van Rossum wrote:
On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky
wrote:
-1 on the "star system" for the tracker
The tracker on Google Code uses stars. We
On 7 January 2011 18:36, Robert Brewer wrote:
> Still looking forward to the day when that moratorium is lifted. Anyone
> have any idea when that will be?
See PEP 3003 (http://www.python.org/dev/peps/pep-3003/) - Python 3.3
is expected to be post-moratorium.
Paul.
___
On Fri, Jan 7, 2011 at 12:04 PM, P.J. Eby wrote:
> At 09:43 AM 1/7/2011 -0500, James Y Knight wrote:
>>
>> On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote:
>> > I don't understand why you are attached to this horrible hack
>> > (bytes-in-unicode). It introduces more work and more confusing than
>
P.J. Eby wrote:
> Right. Also, it should be mentioned that none of this would be
> necessary if we could've gotten a "bytes of a known encoding" type.
Indeed! Or even "string using a known encoding"...
> If you look back to the last big Python-Dev discussion on
> bytes/unicode and stdlib API
Paul Moore wrote:
> Robert Brewer wrote:
> > P.J. Eby wrote:
> > > Also, it should be mentioned that none of this would be
> > > necessary if we could've gotten a "bytes of a known encoding"
> > > type.
> >
> > Still looking forward to the day when that moratorium is lifted.
> > Anyone have any id
On Fri, 7 Jan 2011 22:54:18 +0100 (CET)
raymond.hettinger wrote:
> Author: raymond.hettinger
> Date: Fri Jan 7 22:54:18 2011
> New Revision: 87838
>
> Log:
> Revert r87821 which moved the source link to the wrong section (from the
> module intro covering the module to a section on thread impor
On Sat, Jan 8, 2011 at 6:16 AM, Robert Brewer wrote:
> Python 3.1 was released June 27th, 2009. We're coming up faster on the
> two-year period than we seem to be on a revised WSGI spec. Maybe we
> should shoot for a "bytes of a known encoding" type first.
There were a few minor* practical issues
39 matches
Mail list logo
