Re: [Python-Dev] 3.2b2 fails test suite on (my) Windows XP

2011-01-06 Thread Antoine Pitrou 
On Wed, 5 Jan 2011 17:56:53 -0600
Brian Curtin  wrote:
> 
> http://bugs.python.org/issue9116 covers this issue.
> 
> The reason it doesn't fail on any of the build slaves is because they modify
> a registry value for Windows Error Reporting to not display the pop-up
> window, or at least mine does. I think I got the idea from one of the other
> Windows build slave maintainers.

How about simply using the -n flag to regrtest?

Regards

Antoine.


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

Re: [Python-Dev] Checking input range in time.asctime and time.ctime

2011-01-06 Thread Victor Stinner 
Le mercredi 05 janvier 2011 à 23:48 -0500, Alexander Belopolsky a
écrit :
> I would be happy with just
> 
>if accept2dyear:
>if 69 <= y <= 99:
>y += 1900
>elif 0 <= y <= 68:
>y += 2000
># call system function with tm_year = y - 1900

Perfect. That's what I expect from a "2 digits" option: it should not
touch 3 (100..999) or 4 digits digits (>= 1000).

Remember that the "2 digit option" is a hack to workaround the y2k bug.
It is maybe time to try to remove the workaround: disable accept2dyear
by default and remove PYTHONY2K env var.

> but I thought that would be too radical.

Why ?

Victor

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

Re: [Python-Dev] Checking input range in time.asctime and time.ctime

2011-01-06 Thread Victor Stinner 
Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
>  If calling specific system functions such as strftime with tm_year <
> 0 is deemed unsafe, we can move the check to where the system function
> is called.

What do you mean by "unsafe"? Does it crash? On my Linux box,
strftime("%Y") is able to format integers in [-2^31-1900; 2^31-1-1900]
(full range of the int type).

Can't we add a test in the configure script to check for "broken"
strftime() implementation?

Victor

___
Python-Dev mailing list
Python-Dev@python.org
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: Strip out all generic svn instructions from the FAQ. It's not only

2011-01-06 Thread Michael Foord 

On 05/01/2011 18:37, Brett Cannon wrote:

To those that want to keep those steps in the dev FAQ, go ahead but I
recuse myself from maintaining it. Having had so many instances of
people asking "how do I do this?" and me almost always able to go
"read the dev FAQ" has basically made me feel like it is not worth the
effort if people are not going to bother to check it and just simply
ask how to do things.


I think you have it backwards. The benefit of having a FAQ is not that 
people read it first (they will almost never do that) but that you have 
a single place to send them when they ask the questions. It sounds like 
it's working! :-)


All the best,

Michael Foord


The copy of the dev FAQ on the website has not been touched, so me
cutting this stuff out so I know what has and has not been covered has
no permanent impact. Plus having the devguide on hg.python.org and not
the website means anyone with commit rights can modify the devguide,
including adding/maintaining a dev FAQ on common VCS/SSH/whatever
tools.

On Wed, Jan 5, 2011 at 01:08, Terry Reedy  wrote:

On 1/5/2011 1:18 AM, Eli Bendersky wrote:

On Wed, Jan 5, 2011 at 04:13, Nick Coghlan
As a complete neophyte at actually using a source code system, I found the
stripped-down step-by-step instructions useful even though I am using
TortoiseSVN. Even the TortoiseSVN help doc is a bit overwhelming because it
includes so much that I do not need to read. It would be a bit like a
beginning programmer trying to learn Python from the Langauge Reference
without having the Tutorial to read. (And even as an experienced C
programmer, I started with the latter.)

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/brett%40python.org


___
Python-Dev mailing list
Python-Dev@python.org
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Checking input range in time.asctime and time.ctime

2011-01-06 Thread R. David Murray 
On Thu, 06 Jan 2011 12:55:24 +0100, Victor Stinner 
 wrote:
>Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
>>  If calling specific system functions such as strftime with tm_year <
>> 0 is deemed unsafe, we can move the check to where the system function
>> is called.
>
>What do you mean by "unsafe"? Does it crash? On my Linux box,
>strftime("%Y") is able to format integers in [-2^31-1900; 2^31-1-1900]
>(full range of the int type).

I believe that we have had several cases where Windows "crashed" when
out-of-range values were passed to the CRT that other platforms
accepted.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Checking input range in time.asctime and time.ctime

2011-01-06 Thread Victor Stinner 
Le jeudi 06 janvier 2011 à 10:47 -0500, R. David Murray a écrit :
> On Thu, 06 Jan 2011 12:55:24 +0100, Victor Stinner 
>  wrote:
> >Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
> >>  If calling specific system functions such as strftime with tm_year <
> >> 0 is deemed unsafe, we can move the check to where the system function
> >> is called.
> >
> >What do you mean by "unsafe"? Does it crash? On my Linux box,
> >strftime("%Y") is able to format integers in [-2^31-1900; 2^31-1-1900]
> >(full range of the int type).
> 
> I believe that we have had several cases where Windows "crashed" when
> out-of-range values were passed to the CRT that other platforms
> accepted.

If there are only issues on Windows, we can add a #ifdef _MSC_VER and
raise a ValueError("Stupid OS, install Linux or recompile with Cygwin")
for year < 1900.

Does Cygwin and MinGW have the same issues?

Victor

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

Re: [Python-Dev] Checking input range in time.asctime and time.ctime

2011-01-06 Thread Eric Smith 

On 01/06/2011 11:08 AM, Victor Stinner wrote:

Le jeudi 06 janvier 2011 à 10:47 -0500, R. David Murray a écrit :

On Thu, 06 Jan 2011 12:55:24 +0100, Victor 
Stinner  wrote:

Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :

  If calling specific system functions such as strftime with tm_year<
0 is deemed unsafe, we can move the check to where the system function
is called.


What do you mean by "unsafe"? Does it crash? On my Linux box,
strftime("%Y") is able to format integers in [-2^31-1900; 2^31-1-1900]
(full range of the int type).


I believe that we have had several cases where Windows "crashed" when
out-of-range values were passed to the CRT that other platforms
accepted.


If there are only issues on Windows, we can add a #ifdef _MSC_VER and
raise a ValueError("Stupid OS, install Linux or recompile with Cygwin")
for year<  1900.


Is strftime really so complex that we shouldn't just write our own? I'd 
be willing to do it. Over the years the platform strftime has caused any 
number of problems. The last time I looked at it we already have to do 
some work pre-parsing the format string and passing it off to platform 
strftime, so it's not like it's not already a maintenance hassle.


I understand strptime is probably more complex and there's some value to 
having strptime/strftime coming from the same library. But I'd be 
willing to look at it, too.


Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Implementing strftime Was: Checking input range in time.asctime and time.ctime

2011-01-06 Thread Alexander Belopolsky 
On Thu, Jan 6, 2011 at 11:30 AM, Eric Smith  wrote:
..
> Is strftime really so complex that we shouldn't just write our own? I'd be
> willing to do it. Over the years the platform strftime has caused any number
> of problems. The last time I looked at it we already have to do some work
> pre-parsing the format string and passing it off to platform strftime, so
> it's not like it's not already a maintenance hassle.
>

This is the subject of issue 3173:

http://bugs.python.org/issue3173

As far as I can tell, the main problem with implementing strftime is
that it has to be locale aware and locale API is as inconsistent/buggy
across platforms as strftime itself.


> I understand strptime is probably more complex and there's some value to
> having strptime/strftime coming from the same library. But I'd be willing to
> look at it, too.

strptime is already implemented (in pure python) by stdlib, but it
piggybacks on strftime for locale information.  See Lib/_strptime.py.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Checking input range in time.asctime and time.ctime

2011-01-06 Thread Alexander Belopolsky 
On Thu, Jan 6, 2011 at 6:47 AM, Victor Stinner
 wrote:
> Le mercredi 05 janvier 2011 à 23:48 -0500, Alexander Belopolsky a
> écrit :
>> I would be happy with just
>>
>>    if accept2dyear:
>>        if 69 <= y <= 99:
>>            y += 1900
>>        elif 0 <= y <= 68:
>>            y += 2000
>>    # call system function with tm_year = y - 1900
..
>> but I thought that would be too radical.
>
> Why ?

ISTM that time.asctime() called with a 3-digit year, particularly a
low 3-digit, one is much more likely to be a manifestation of a
lingering Y2K bug than a real intent to print an ancient date.  I do
remember that many devices were showing Jan 1, 100 back in early 2000.

The same logic does not apply to programs that run with PYTHONY2K set
because presumably users who bothered to set PYTHONY2K know that their
program does not use 2-digit years.

That's why, I think for 3.2 we should do the following:

1.  Keep PYTHONY2K logic and accept2dyear = 1 default.
2. With default accept2dyear = 1:
 - for 0 <= year < 100 issue a deprecation warning and supply
century according to POSIX rules
 - for 100 <= year < 1000 raise ValueError
 - for year >= 1000 leave year unchanged
3. With  accept2dyear = 0 leave year unchanged regardless of value.

For 3.3, remove PYTHONY2K and accept2dyear and leave year unchanged
regardless of value.

Can we agree that this is reasonable for time.asctime()?  In
time/datetime.strftime we can impose stricter limits if necessary to
work around platform bugs.
___
Python-Dev mailing list
Python-Dev@python.org
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-06 Thread Ned Deily 
In article ,
 brett.cannon  wrote:
[...]
> summary:
>   Point out that OS X users need to change examples to use python.exe instead 
>   of python.
>  Once Python is done building you will then have a working build of Python
>  that can be run in-place; ``./python`` on most machines, ``./python.exe``
> -on OS X.
> +on OS X (all examples throughout this documentation say ``./python`` but
> +implies you choose the proper name based on your OS).

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.

-- 
 Ned Deily,
 n...@acm.org

___
Python-Dev mailing list
Python-Dev@python.org
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-06 Thread And Clover 
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. PEP  requires it.

> os.environ is supposed to be correctly decoded and contain valid
unicode characters.

It is not possible to ‘correctly’ decode to unicode for os.environ
because that decoding happens long before the web application (the
only party that knows what encoding should be in use) gets a look in.

Maybe the web application is using UTF-8, maybe it's using cp1252,
but if we let the server/gateway decide and do that decoding
before the application can do anything about it, we will get the wrong
encoding in *many* cases and the result will be permanent, unrecoverable
mangling of non-ASCII characters in submitted headers.

> If WSGI uses another encoding than the locale encoding (which is a bad
idea),

It's an absolutely necessary idea. The locale encoding is nothing to do
with the web application's encoding. Windows applications need to be
able to use UTF-8 (which is never the ANSI code page), and web
applications in general need to be deployable to any server without
having to worry about the server's locale.

The locale-dependent status quo is that non-ASCII characters in URL
paths and other HTTP headers don't work for Python apps.

The recoding dances present in wsgiref's CGIHandler for 3.2 are
distasteful but completely necessary to normalise differences in
encodings used by various servers and platforms to generate their CGI
environment.

>  it should use os.environb and decodes keys and values using its
> own encoding.

Well yes, but:

(a) os.environb doesn't exist in previous Python 3.1, making it
impossible to implement WSGI before 3.2;
(b) a byte environment on Windows would have to be encoded
from the Unicode environment, with a server-specific encoding,
and then what encoding are you going to choose for the variables
that contain non-HTTP-sourced native Unicode strings (such as,
very commonly, Windows pathnames)?

The bytes-or-bytes-in-Unicode argument is something that has been
bounced around Web-SIG for literally *years*; this is what we ended up
with. Although I personally like bytes, frankly, a re-run of this
argument *again* whilst WSGI remains in perpetual stalemate does not
appeal. WSGI and wsgiref in Python 3.0-3.1 simply does not work. This
has long been an embarrassing situation for what is supposed to be a
leading
web language. Let us not perpetuate this sorry story to 3.2 as well.

-- 
And Clover
mailto:a...@doxdesk.com http://www.doxdesk.com
skype:uknrbobince gtalk:chat?jid=bobi...@gmail.com


___
Python-Dev mailing list
Python-Dev@python.org
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-06 Thread Raymond Hettinger 
Can you please take a look at
http://docs.python.org/dev/whatsnew/3.2.html#pep--python-web-server-gateway-interface-v1-0-1
to see if it accurately recaps the resolution of the WSGI text/bytes issues.
I would appreciate any feedback, as it is likely that the whatsnew
document will be most people's first chance to hear the outcome
of the multi-year discussion.

Thanks,


Raymond


On Jan 6, 2011, at 3:50 PM, And Clover wrote:

> 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. PEP  requires it.
> 
>> os.environ is supposed to be correctly decoded and contain valid
> unicode characters.
> 
> It is not possible to ‘correctly’ decode to unicode for os.environ
> because that decoding happens long before the web application (the
> only party that knows what encoding should be in use) gets a look in.
> 
> Maybe the web application is using UTF-8, maybe it's using cp1252,
> but if we let the server/gateway decide and do that decoding
> before the application can do anything about it, we will get the wrong
> encoding in *many* cases and the result will be permanent, unrecoverable
> mangling of non-ASCII characters in submitted headers.
> 
>> If WSGI uses another encoding than the locale encoding (which is a bad
> idea),
> 
> It's an absolutely necessary idea. The locale encoding is nothing to do
> with the web application's encoding. Windows applications need to be
> able to use UTF-8 (which is never the ANSI code page), and web
> applications in general need to be deployable to any server without
> having to worry about the server's locale.
> 
> The locale-dependent status quo is that non-ASCII characters in URL
> paths and other HTTP headers don't work for Python apps.
> 
> The recoding dances present in wsgiref's CGIHandler for 3.2 are
> distasteful but completely necessary to normalise differences in
> encodings used by various servers and platforms to generate their CGI
> environment.
> 
>> it should use os.environb and decodes keys and values using its
>> own encoding.
> 
> Well yes, but:
> 
> (a) os.environb doesn't exist in previous Python 3.1, making it
> impossible to implement WSGI before 3.2;
> (b) a byte environment on Windows would have to be encoded
> from the Unicode environment, with a server-specific encoding,
> and then what encoding are you going to choose for the variables
> that contain non-HTTP-sourced native Unicode strings (such as,
> very commonly, Windows pathnames)?
> 
> The bytes-or-bytes-in-Unicode argument is something that has been
> bounced around Web-SIG for literally *years*; this is what we ended up
> with. Although I personally like bytes, frankly, a re-run of this
> argument *again* whilst WSGI remains in perpetual stalemate does not
> appeal. WSGI and wsgiref in Python 3.0-3.1 simply does not work. This
> has long been an embarrassing situation for what is supposed to be a
> leading
> web language. Let us not perpetuate this sorry story to 3.2 as well.
> 
> -- 
> And Clover
> mailto:a...@doxdesk.com http://www.doxdesk.com
> skype:uknrbobince gtalk:chat?jid=bobi...@gmail.com
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/raymond.hettinger%40gmail.com

___
Python-Dev mailing list
Python-Dev@python.org
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-06 Thread Glenn Linderman 

On 1/6/2011 3:50 PM, And Clover wrote:

ISO-8859-1 is the encoding specified by the HTTP RFC


Please could I have the reference to that specification?  I only recall 
ASCII and UTF-8 in my readings of various things HTTP and HTML, for 
headers, and form data.  Naturally data pages can have any encoding they 
please, as there are headers and  tags to describe their encodings.


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

Re: [Python-Dev] 3.2b2 fails test suite on (my) Windows XP

2011-01-06 Thread Dj Gilcrease 
On Thu, Jan 6, 2011 at 1:00 AM, Terry Reedy  wrote:
> On 1/5/2011 8:59 PM, Nick Coghlan wrote:
> Run 3: -x test_capi test_concurrent_futures
> Instead of the normal output I expected, I got some of the craziest stuff I
> have ever seen. Things like
> "
>    assert main_name not in sys.modules, main_name
> AssertionError: __main__
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 369, in
> main
>    prepare(preparation_data)
>  File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 477,
> "
> were printed 100s of times intermixed with the normal sequential test
> startup lines. They stopped after text_sax started and output became normal
> through the end of the report.

The 100's or 1000's of processes popping up is cause by a test that
uses multi-processing and failing to have the if __name__ ==
'__main__' check around where it creates the processes
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Checking input range in time.asctime and time.ctime

2011-01-06 Thread Stephen J. Turnbull 
R. David Murray writes:

 > I believe that we have had several cases where Windows "crashed" when
 > out-of-range values were passed to the CRT that other platforms
 > accepted.

XEmacs had crashes due to strftime on Windows native with VC++.  Never
went so far as to BSOD, but a couple of users lost recently input
data. :-(  IIRC Cygwin was OK (their libc uses a different code base).
Dunno mingw, almost all of our users either want the full Cygwin
environment or they don't care about GCC, but since mingw uses MSFT
runtime, it's probably vulnerable too.


___
Python-Dev mailing list
Python-Dev@python.org
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-06 Thread James Y Knight 

On Jan 6, 2011, at 8:16 PM, Glenn Linderman wrote:

> On 1/6/2011 3:50 PM, And Clover wrote:
>> 
>> ISO-8859-1 is the encoding specified by the HTTP RFC
> 
> Please could I have the reference to that specification?  I only recall ASCII 
> and UTF-8 in my readings of various things HTTP and HTML, for headers, and 
> form data.  Naturally data pages can have any encoding they please, as there 
> are headers and  tags to describe their encodings.


Did you try google? http://www.google.com/search?http+rfc

James
___
Python-Dev mailing list
Python-Dev@python.org
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-06 Thread Stephen J. Turnbull 
Glenn Linderman writes:
 > On 1/6/2011 3:50 PM, And Clover wrote:
 > > ISO-8859-1 is the encoding specified by the HTTP RFC
 > 
 > Please could I have the reference to that specification?

RFC 2616 (probably obsolete by now, but IRC ISO 8859/1 is already
there IIRC), and I don't think UTF-8 is the default for anything until
you get to XHTML (and maybe HTML5).

___
Python-Dev mailing list
Python-Dev@python.org
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: Strip out all generic svn instructions from the FAQ. It's not only

2011-01-06 Thread Nick Coghlan 
On Thu, Jan 6, 2011 at 10:24 PM, Michael Foord
 wrote:
> I think you have it backwards. The benefit of having a FAQ is not that
> people read it first (they will almost never do that) but that you have a
> single place to send them when they ask the questions. It sounds like it's
> working! :-)

I believe it's also the case that *any given person* usually only
needs to be sent to the dev FAQ once :)

Still, Brett's right that any of us will be able to add the source
control cheat sheet once he has finished with the basic structure of
the dev guide.

Cheers,
Nick.

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

Re: [Python-Dev] 3.2b2 fails test suite on (my) Windows XP

2011-01-06 Thread Nick Coghlan 
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 message.
> Close command prompt window with [x] buttom (crtl-whatever had no effect).
>
> Run 2: normal (as before)
> Process reported capi test failure (supposedly fatal) but continued.
> Process just stopped ('hung') at concurrent futures. Close as before.
>
> Run 3: -x test_capi test_concurrent_futures
> Instead of the normal output I expected, I got some of the craziest stuff I
> have ever seen. Things like

Does it all go back to normal if you use "python -m test.regrtest"
instead? Antoine discovered that multiprocessing on Windows gets
thoroughly confused if __file__ in the main module ends with
"__main__.py" (see http://bugs.python.org/issue10845)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
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-06 Thread Glenn Linderman 

On 1/6/2011 7:37 PM, Stephen J. Turnbull wrote:

Glenn Linderman writes:
  >  On 1/6/2011 3:50 PM, And Clover wrote:
  >  >  ISO-8859-1 is the encoding specified by the HTTP RFC
  >
  >  Please could I have the reference to that specification?

RFC 2616 (probably obsolete by now, but IRC ISO 8859/1 is already
there IIRC), and I don't think UTF-8 is the default for anything until
you get to XHTML (and maybe HTML5).


Thanks.

Looking back, it is 2068 and 1945 also, I just had a mental blind spot, 
thinking I understood the header formats from email-land, where they are 
more required to be ASCII, as mentioned in my reply to James.


UTF-8 is the default for FORM DATA when using multipart/form-data 
encoding, using the POST method.  Otherwise, it FORM DATA is limited to 
ASCII.  Per  http://www.w3.org/TR/html401/interact/forms.html#h-17.13.1 
which is HTML 4.01 (and maybe earlier, but I didn't go back further).


Nice to quote chapter and verse (or link) when declaring that something 
is in a standard.


___
Python-Dev mailing list
Python-Dev@python.org
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-06 Thread P.J. Eby 

At 04:00 PM 1/6/2011 -0800, Raymond Hettinger wrote:

Can you please take a look at
http://docs.python.org/dev/whatsnew/3.2.html#pep--python-web-server-gateway-interface-v1-0-1
to see if it accurately recaps the resolution of the WSGI text/bytes issues.
I would appreciate any feedback, as it is likely that the whatsnew
document will be most people's first chance to hear the outcome
of the multi-year discussion.


Hi Raymond -- nice work there.  A few minor suggestions:

1. Native strings are used as the keys and values of the environ 
dictionary, not just as headers for start_response.


2. The read_environ() method is strictly for use with CGI-to-WSGI 
gateways, or for bridging other CGI-like protocols (e.g. FastCGI) to 
WSGI.  It is ONLY for server implementers, in other words, and the 
typical app developer is doing something terribly wrong if they are 
even bothering to read its documentation.  ;-)


3. The primary relevance of the "native string" type to an app 
developer is that when porting code from Python 2 to 3, they must 
still decode environment variable values, even though they are 
"already" Unicode.  If their code was previously dealing only in 
Python 2 'str' objects, then nothing really changes.  If they were 
previously decoding from environ str's to unicode, then they must 
replace their prior .decode('whatever') with 
.encode('latin1').decode('whatever').  That's basically it for 
porting from Python 2.


IOW, this design choice allows most HTTP header manipulating code 
(whether input or output) to be ported to Python 3 with a very 
mechanical change pattern.  Most such code is working with ASCII 
anyway, since normally both input and output headers are, and there 
are few headers that an application would be likely to convert to 
actual unicode anyway.


On output via send_response(), if an application is currently 
encoding an output header  -- why they would be, I have no idea, but 
if they are -- they need to add a re-encode to latin1.  (i.e., 
.encode('whatever').decode('latin1'))


IOW, a short 2-to-3 porting guide for WSGI:

* If you just used strings for headers before, that part of your code 
doesn't change.  (And if it was broken before, it's still broken in 
exactly the same way.  No new breakage is introduced. ;-) )


* If you encoded any output headers or decoded any input headers, you 
must take into account the extra latin1 step.  This is expected to be 
rare, since it's usually only SCRIPT_NAME and PATH_INFO that anybody 
would ever care about on input, and almost never anything on output.


* Values yielded by an application or sent via a write() call MUST be 
byte strings; The environ and start_response() MUST be native 
strings.  No mixing and matching.


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