Re: [Python-Dev] PEP 3333: wsgi_string() function

2011-01-10 Thread Ian Bicking 
On Sun, Jan 9, 2011 at 1:47 AM, Stephen J. Turnbull wrote:

> Robert Brewer writes:
>
>  > 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.
>
> You have one.  It's called "ISO 2022: Information processing -- ISO
> 7-bit and 8-bit coded character sets -- Code extension techniques".
> The popularity of that standard speaks for itself.
>

The kind of object PJE was referring to is more like Ruby's strings, which
do not embed the encoding inside the bytes themselves but have the encoding
as a kind of annotation on the bytes, and do lazy transcoding when combining
strings of different encodings.  The goal with respect to WSGI is that you
could annotate bytes with an encoding but also change or fix that encoding
if other out-of-band information implied that you got the encoding wrong
(e.g., some data is submitted with the encoding of the page the browser was
on, and so nothing inside the request itself will indicate the encoding of
the data).  Latin1 is kind of the poor man's version of this -- it's a good
guess at an encoding, that at worst requires transcoding that can be done in
a predictable way.  (Personally I think Latin1 gets us 99% of the way there,
and so bytes-of-a-known-encoding are not really that important to the WSGI
case.)

  Ian
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3333: wsgi_string() function

2011-01-10 Thread Michael Foord 

On 10/01/2011 17:24, Ian Bicking wrote:
On Sun, Jan 9, 2011 at 1:47 AM, Stephen J. Turnbull 
mailto:[email protected]>> wrote:


Robert Brewer writes:

> 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.

You have one.  It's called "ISO 2022: Information processing -- ISO
7-bit and 8-bit coded character sets -- Code extension techniques".
The popularity of that standard speaks for itself.


The kind of object PJE was referring to is more like Ruby's strings, 
which do not embed the encoding inside the bytes themselves but have 
the encoding as a kind of annotation on the bytes, and do lazy 
transcoding when combining strings of different encodings.  The goal 
with respect to WSGI is that you could annotate bytes with an encoding 
but also change or fix that encoding if other out-of-band information 
implied that you got the encoding wrong (e.g., some data is submitted 
with the encoding of the page the browser was on, and so nothing 
inside the request itself will indicate the encoding of the data).  
Latin1 is kind of the poor man's version of this -- it's a good guess 
at an encoding, that at worst requires transcoding that can be done in 
a predictable way.  (Personally I think Latin1 gets us 99% of the way 
there, and so bytes-of-a-known-encoding are not really that important 
to the WSGI case.)




I think the language moratorium was not the only objection to the 
inclusion of a third string type in Python (the "screwed string" - safe 
to treat neither as bytes nor as text). I recall objections in principle 
too from core developers during the EuroPython language summit.


Michael


  Ian


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3333: wsgi_string() function

2011-01-10 Thread Nick Coghlan 
On Tue, Jan 11, 2011 at 3:24 AM, Ian Bicking  wrote:
>
> The kind of object PJE was referring to is more like Ruby's strings, which
> do not embed the encoding inside the bytes themselves but have the encoding
> as a kind of annotation on the bytes, and do lazy transcoding when combining
> strings of different encodings.  The goal with respect to WSGI is that you
> could annotate bytes with an encoding but also change or fix that encoding
> if other out-of-band information implied that you got the encoding wrong
> (e.g., some data is submitted with the encoding of the page the browser was
> on, and so nothing inside the request itself will indicate the encoding of
> the data).  Latin1 is kind of the poor man's version of this -- it's a good
> guess at an encoding, that at worst requires transcoding that can be done in
> a predictable way.  (Personally I think Latin1 gets us 99% of the way there,
> and so bytes-of-a-known-encoding are not really that important to the WSGI
> case.)

Having done the upgrade to urllib to support direct manipulation of
byte sequences, I don't think such a type would help as much people
hoped anyway. Converting to Unicode, manipulating as text and
converting back really *is* the right way to do text manipulation
(however, providing bytes-in-bytes-out APIs that do the conversions
for you can also be quite convenient).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] "unit test needed"

2011-01-10 Thread Antoine Pitrou 

Hello,

I would like to advocate again for the removal of the "unit test
needed" stage on the tracker, which regularly confuses our triagers
into thinking it's an actual requirement or expectation from
contributors and bug reporters.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

2011-01-10 Thread Antoine Pitrou 
On Sun, 9 Jan 2011 15:18:12 -0800
Brett Cannon  wrote:
> 
> OK, so the sentence is poorly phrased, but in the list of tasks it is
> labeled explicitly as intermediate when one is comfortable with the
> process, not a newbie. Does that alleviate the worry you both have?

It does seem to alleviate it :) Sorry for not noticing!
However, could the following be removed from the list:

“Is there a proper unit test that can reproduce the bug?”

We don't need or require unit tests to reproduce bugs; and besides,
some things simply are very difficult to write an unit test for. A
reporter need not be an experienced Python developer able (or willing)
to write an elaborate unit test reproducing, for example, a timing
issue involving Unix signals and the IO stack ;)

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Éric Araujo 
> I would like to advocate again for the removal of the "unit test
> needed" stage on the tracker, which regularly confuses our triagers
> into thinking it's an actual requirement or expectation from
> contributors and bug reporters.

Speaking as a bug triager:
+1 to rename it “test needed”
+1 to remove it

Regards

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Georg Brandl 
Am 10.01.2011 19:21, schrieb Éric Araujo:
>> I would like to advocate again for the removal of the "unit test
>> needed" stage on the tracker, which regularly confuses our triagers
>> into thinking it's an actual requirement or expectation from
>> contributors and bug reporters.
> 
> Speaking as a bug triager:
> +1 to rename it “test needed”
> +1 to remove it

First rename, then remove?

Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Éric Araujo 
>> +1 to rename it “test needed”
>> +1 to remove it

I meant either one would be an improvement.

Regards

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Point out that OS X users need to change examples to use python.exe instead of

2011-01-10 Thread Łukasz Langa 
Wiadomość napisana przez Ned Deily w dniu 2011-01-08, o godz. 22:13:

> In article 
> ,
> Brett Cannon  wrote:
> 
>> On Thu, Jan 6, 2011 at 13:04, Ned Deily  wrote:
>>> In article ,
>>> 
>>> That's true on OS X if you are using a case-insensitive file system.
>>> But wIth the newer, case-sensitive HFS+, for example, you get ./python.
>> 
>> Are you thinking of UFS, because I am running HFS+ and I still get
>> python.exe since it's case-preserving.
> 
> No, not UFS.  Since at least 10.4, OS X has supported the creation of at 
> least four variants of HFS+ via Disk Utility.app or disktutil(8).

I'm using the case-sensitive variant of HFS+ since 10.4. It works, I like it 
and you get ./python with it.

-- 
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

2011-01-10 Thread Brett Cannon 
On Mon, Jan 10, 2011 at 10:24, Antoine Pitrou  wrote:

> On Sun, 9 Jan 2011 15:18:12 -0800
> Brett Cannon  wrote:
> >
> > OK, so the sentence is poorly phrased, but in the list of tasks it is
> > labeled explicitly as intermediate when one is comfortable with the
> > process, not a newbie. Does that alleviate the worry you both have?
>
> It does seem to alleviate it :) Sorry for not noticing!
> However, could the following be removed from the list:
>
> “Is there a proper unit test that can reproduce the bug?”
>
> We don't need or require unit tests to reproduce bugs; and besides,
> some things simply are very difficult to write an unit test for. A
> reporter need not be an experienced Python developer able (or willing)
> to write an elaborate unit test reproducing, for example, a timing
> issue involving Unix signals and the IO stack ;)
>
>
Fair enough. I will remove it.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Eli Bendersky 
> I would like to advocate again for the removal of the "unit test
> needed" stage on the tracker, which regularly confuses our triagers
> into thinking it's an actual requirement or expectation from
> contributors and bug reporters.
>
>
Perhaps a different wording would be preferred to removal. Suppose a
reviewer accepts a patch but asks for a test before committing it. If it's
hidden in the issue discussion, only those involved in the issue are aware
of the situation. If it's in the issue state, then other potential
contributors may notice it and provide tests. IMHO tests are simpler and
less "scary" for newbies making their first steps in CPython.

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

2011-01-10 Thread Michael Foord 

On 10/01/2011 19:05, Brett Cannon wrote:



On Mon, Jan 10, 2011 at 10:24, Antoine Pitrou > wrote:


On Sun, 9 Jan 2011 15:18:12 -0800
Brett Cannon mailto:[email protected]>> wrote:
>
> OK, so the sentence is poorly phrased, but in the list of tasks
it is
> labeled explicitly as intermediate when one is comfortable with the
> process, not a newbie. Does that alleviate the worry you both have?

It does seem to alleviate it :) Sorry for not noticing!
However, could the following be removed from the list:

“Is there a proper unit test that can reproduce the bug?”

We don't need or require unit tests to reproduce bugs; and besides,
some things simply are very difficult to write an unit test for. A
reporter need not be an experienced Python developer able (or willing)
to write an elaborate unit test reproducing, for example, a timing
issue involving Unix signals and the IO stack ;)


Fair enough. I will remove it.


Well, *often* a test that exposes the issue can be written - and if so 
it is a useful exercise (surely).


Michael



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Éric Araujo 
Le 10/01/2011 20:11, Eli Bendersky a écrit :
> Perhaps a different wording would be preferred to removal. Suppose a
> reviewer accepts a patch but asks for a test before committing it.

Well, we usually forewarn that a patch should include tests and docs, so
I think “patch needed” or “patch review” is good enough.

Regards

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Antoine Pitrou 
On Mon, 10 Jan 2011 21:11:23 +0200
Eli Bendersky  wrote:
> > I would like to advocate again for the removal of the "unit test
> > needed" stage on the tracker, which regularly confuses our triagers
> > into thinking it's an actual requirement or expectation from
> > contributors and bug reporters.
> >
> >
> Perhaps a different wording would be preferred to removal. Suppose a
> reviewer accepts a patch but asks for a test before committing it. If it's
> hidden in the issue discussion, only those involved in the issue are aware
> of the situation. If it's in the issue state, then other potential
> contributors may notice it and provide tests. IMHO tests are simpler and
> less "scary" for newbies making their first steps in CPython.

Then we would need a whole array of checkboxes for things missing in a
patch:
- missing unit test
- missing documentation changes
- other things?

I don't think it's useful. As for "tests are simpler", it really depends
on the issue :) I've worked on many issues where writing the test took
much more time than actually fixing the bug (one-line fix vs. careful
test setup to exercise the fix).

(also, as a matter of principle, I think it's better that the same
person who wrote the bugfix is asked to write the tests)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

2011-01-10 Thread Antoine Pitrou 
Le lundi 10 janvier 2011 à 19:26 +, Michael Foord a écrit :
> > 
> > 
> > Fair enough. I will remove it. 
> > 
> 
> Well, *often* a test that exposes the issue can be written - and if so
> it is a useful exercise (surely).

Yes, well, that's a matter of "useful exercise for the contributor" vs.
"required to advance on the issue". AFAICT the "stage" field aims at
conveying the latter piece of information (the current wording says
"unit test *needed*").

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

2011-01-10 Thread Michael Foord 

On 10/01/2011 19:31, Antoine Pitrou wrote:

Le lundi 10 janvier 2011 à 19:26 +, Michael Foord a écrit :


Fair enough. I will remove it.


Well, *often* a test that exposes the issue can be written - and if so
it is a useful exercise (surely).

Yes, well, that's a matter of "useful exercise for the contributor" vs.
"required to advance on the issue". AFAICT the "stage" field aims at
conveying the latter piece of information (the current wording says
"unit test *needed*").


Aren't we discussing the dev guide? Discussion about tracker field is 
that away <-.


Michael


Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

2011-01-10 Thread Antoine Pitrou 
Le lundi 10 janvier 2011 à 19:37 +, Michael Foord a écrit :
> On 10/01/2011 19:31, Antoine Pitrou wrote:
> > Le lundi 10 janvier 2011 à 19:26 +, Michael Foord a écrit :
> >>>
> >>> Fair enough. I will remove it.
> >>>
> >> Well, *often* a test that exposes the issue can be written - and if so
> >> it is a useful exercise (surely).
> > Yes, well, that's a matter of "useful exercise for the contributor" vs.
> > "required to advance on the issue". AFAICT the "stage" field aims at
> > conveying the latter piece of information (the current wording says
> > "unit test *needed*").
> 
> Aren't we discussing the dev guide? Discussion about tracker field is 
> that away <-.

Oh, well. I think we're discussing the directions that a contributor
willing to help triage could give so to advance an issue. I hope I'm not
mistaken.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Alexander Belopolsky 
On Mon, Jan 10, 2011 at 1:49 PM, Éric Araujo  wrote:
>>> +1 to rename it “test needed”
>>> +1 to remove it
>
> I meant either one would be an improvement.

+1 to remove it

Let's remove it first, an then decide if another stage is necessary.
The problems with "unit test needed" is that

1. It is not clear whether unit tests should be written before or
after a patch and thus once a bug is acknowledged as valid, what an
appropriate stage should be.

2. For a bug that needs confirmation as being reproducible, it
suggests that familiarity with unit test framework in necessary to
move the issue forward.  In fact, in many cases a short stand-alone
script is more helpful than a Lib/test patch.

I think "patch needed" is a good enough first stage.  For bugs it
should be set when there is a rough consensus that the behavior is a
bug and for RFEs, it should be set when a decision to include cannot
be made without an implementation.

While there is no agreement on whether the bug is valid or whether an
RFE makes any sense, the stage can stay undefined.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Michael Foord 

On 10/01/2011 19:48, Alexander Belopolsky wrote:

On Mon, Jan 10, 2011 at 1:49 PM, Éric Araujo  wrote:

+1 to rename it “test needed”
+1 to remove it

I meant either one would be an improvement.

+1 to remove it

Let's remove it first, an then decide if another stage is necessary.
The problems with "unit test needed" is that

1. It is not clear whether unit tests should be written before or
after a patch and thus once a bug is acknowledged as valid, what an
appropriate stage should be.

2. For a bug that needs confirmation as being reproducible, it
suggests that familiarity with unit test framework in necessary to
move the issue forward.  In fact, in many cases a short stand-alone
script is more helpful than a Lib/test patch.

I think "patch needed" is a good enough first stage.  For bugs it
should be set when there is a rough consensus that the behavior is a
bug and for RFEs, it should be set when a decision to include cannot
be made without an implementation.


Agree. "Patch needed" applies if the patch is incomplete, and if it 
lacks tests then it is incomplete.


Michael


While there is no agreement on whether the bug is valid or whether an
RFE makes any sense, the stage can stay undefined.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread skip 

Antoine> Then we would need a whole array of checkboxes for things
Antoine> missing in a patch:
Antoine> - missing unit test
Antoine> - missing documentation changes
Antoine> - other things?

How about replacing all the possibilities with

patch incomplete

then elaborate in the issue itself how that is the case.

Antoine> I don't think it's useful. As for "tests are simpler", it
Antoine> really depends on the issue :) I've worked on many issues where
Antoine> writing the test took much more time than actually fixing the
Antoine> bug (one-line fix vs. careful test setup to exercise the fix).

I would rather write event-driven code than the test cases for it. ;-)

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] devguide: TODO about explaining how to fill in every field in an issue for a triager.

2011-01-10 Thread Alexander Belopolsky 
On Mon, Jan 10, 2011 at 3:15 PM, brett.cannon
 wrote:
..
> +.. todo::
> +    Figure out where to put instructions for triagers on filling out issue
> +    fields properly

Some field titles are clickable and linked to field choices
descriptions.  Maybe these could be replaced with links to proper
devguide sections.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Point out that OS X users need to change examples to use python.exe instead of

2011-01-10 Thread Glyph Lefkowitz 

On Jan 10, 2011, at 1:37 PM, Łukasz Langa wrote:

> I'm using the case-sensitive variant of HFS+ since 10.4. It works, I like it 
> and you get ./python with it.

I realize that this isn't a popularity contest for this feature, but I feel 
like I should pipe up here and mention that it breaks some applications - for 
example, you can't really install World of Warcraft on a case-insensitive 
filesystem.  Not the filesystem's fault really, but it is a good argument for 
why users shouldn't choose it.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Point out that OS X users need to change examples to use python.exe instead of

2011-01-10 Thread Ned Deily 
In article ,
 Glyph Lefkowitz  wrote:

> On Jan 10, 2011, at 1:37 PM, ®©ukasz Langa wrote:
> > I'm using the case-sensitive variant of HFS+ since 10.4. It works, I like 
> > it and you get ./python with it.
> I realize that this isn't a popularity contest for this feature, but I feel 
> like I should pipe up here and mention that it breaks some applications - for 
> example, you can't really install World of Warcraft on a case-insensitive 
> filesystem.  Not the filesystem's fault really, but it is a good argument for 
> why users shouldn't choose it.

It's true that there is a bit of risk (and breaking WoW would be a big 
one for aficionados).  Over the past few years, I have run into a few 
traditional Mac apps that did break when installed in a case-sensitive 
HFS.  In all but one case, the app developers were happy to have the bug 
report and fix the app.  I thought I noticed that Apple was starting to 
ship new machines formatted as case-insensitive but I may be imagining 
that.  OTOH, there have been Unixy packages that break on 
case-insensitive systems, also arguably a bug.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3333: wsgi_string() function

2011-01-10 Thread Stephen J. Turnbull 
Ian Bicking writes:
 > On Sun, Jan 9, 2011 at 1:47 AM, Stephen J. Turnbull 
 > wrote:
 > 
 > > Robert Brewer writes:
 > >
 > >  > 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.
 > >
 > > You have one.  It's called "ISO 2022: Information processing -- ISO
 > > 7-bit and 8-bit coded character sets -- Code extension techniques".
 > > The popularity of that standard speaks for itself.
 > >
 > 
 > The kind of object PJE was referring to is more like Ruby's strings,

Notice that Ruby was written by a Japanese, the same culture that
brought us Mule, TRON, X Compound Text, and ISO-2022 in the first
place.  Matsumoto himself probably isn't infected with the "Unicode is
going to be the death of all Japanese culture" bug, but that's the
attitude that is behind ISO 2022.

 > which do not embed the encoding inside the bytes themselves but have the 
 > encoding
 > as a kind of annotation on the bytes,

My pointis that ISO-2022 is basically just a serialization of that.

And it sucks; nobody uses it, except in Japanese and Korean email.
Maybe Mandarin (but Taiwan and Hong Kong use Big5 or EUC, not an
escape-extended representation).

 > and do lazy transcoding when combining strings of different
 > encodings.

Which buys WSGI nothing, AIUI, since the people who want this claim
that translating to Unicode either correctly or as "big bytes" (ie,
zero-extension) is inefficient.  They're shoveling bits; much of the
time, by the time the out-of-band information catches up, it's going
to be too late.

 > The goal with respect to WSGI is that you could annotate bytes with
 > an encoding but also change or fix that encoding if other
 > out-of-band information implied that you got the encoding wrong
 > (e.g., some data is submitted with the encoding of the page the
 > browser was on, and so nothing inside the request itself will
 > indicate the encoding of the data).

A noble goal, but nobody's gonna bell that cat.  This is all just
wishful thinking.  2 decades of experience with Emacs/Mule and similar
efforts show that if you provide this facility, people will use it,
and that use will include a lot of abuse (ie, throwing the garbage
into somebody else's backyard, rather than disposing of it yourself)
-- in the end, the garbage gets piled high enough that it's not worth
the effort to try to make it work.

 > Latin1 is kind of the poor man's version of this -- it's a good
 > guess at an encoding, that at worst requires transcoding that can
 > be done in a predictable way.  (Personally I think Latin1 gets us
 > 99% of the way there, and so bytes-of-a-known-encoding are not
 > really that important to the WSGI case.)

In particular, it gets PJE 100% of the way there, since he proposes
always targeting ISO 8859/1, anyway.

And if it's not useful to WSGI, who is it useful to?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Nick Coghlan 
On Tue, Jan 11, 2011 at 6:37 AM,   wrote:
> How about replacing all the possibilities with
>
>    patch incomplete
>
> then elaborate in the issue itself how that is the case.

+1

This is much clearer than lumping incomplete patches in with
nonexistent ones. A process that goes "needs patch->patch
review->(patch incomplete)->commit review->committed/rejected" (with
the possibility of multiple iterations between patch review and patch
incomplete) would give a pretty clear idea of where any given issue
stands.

The "unit test needed" stage is actually more a "confirmation needed"
stage - i.e. can the reported bug actually be reproduced by anyone
other than the original reporter.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "unit test needed"

2011-01-10 Thread Eli Bendersky 
On Mon, Jan 10, 2011 at 22:37,  wrote:

>
>Antoine> Then we would need a whole array of checkboxes for things
>Antoine> missing in a patch:
>Antoine> - missing unit test
>Antoine> - missing documentation changes
>Antoine> - other things?
>
> How about replacing all the possibilities with
>
>patch incomplete
>
> then elaborate in the issue itself how that is the case.
>
>
+1
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com