Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

PJ Eby
At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
>Is that the last thing or do I need to go spend some time and write my
>own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
>lying around and just do some final validation checks with a parallel
>implementation as a sanity check to make sure we got everything? This
>might be a good idea anyway.

It would.  In the meantime, though, I've checked in the two-line
change to add .buffer in.  ;-)

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

James Y Knight
On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote:
> At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
>> Is that the last thing or do I need to go spend some time and write my
>> own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
>> lying around and just do some final validation checks with a parallel
>> implementation as a sanity check to make sure we got everything? This
>> might be a good idea anyway.
>
> It would.  In the meantime, though, I've checked in the two-line change to add .buffer in.  ;-)

So does that mean PEP 3333 can be accepted now?

James
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Guido van Rossum
On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight <[hidden email]> wrote:

> On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote:
>> At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
>>> Is that the last thing or do I need to go spend some time and write my
>>> own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
>>> lying around and just do some final validation checks with a parallel
>>> implementation as a sanity check to make sure we got everything? This
>>> might be a good idea anyway.
>>
>> It would.  In the meantime, though, I've checked in the two-line change to add .buffer in.  ;-)
>
> So does that mean PEP 3333 can be accepted now?

TBH I've totally lost track. Hopefully PJE and Graham can tell you...

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Graham Dumpleton-2
Stupid question first. When running 2to3 on the example CGI code, why
would it throw back the following. Is this indicative of anything else
that needs to be changed to satisfy some Python 3 thing. The list()
bit seems redundant, but I don't know what the other stuff is about.

--- xx.py (original)
+++ xx.py (refactored)
@@ -9,7 +9,7 @@
     return u.encode(enc, esc).decode('iso-8859-1')

 def run_with_cgi(application):
-    environ = {k: wsgi_string(v) for k,v in os.environ.items()}
+    environ = {k: wsgi_string(v) for k,v in list(os.environ.items())}
     environ['wsgi.input']        = sys.stdin
     environ['wsgi.errors']       = sys.stderr
     environ['wsgi.version']      = (1, 0)
@@ -45,7 +45,7 @@
             try:
                 if headers_sent:
                     # Re-raise original exception if headers sent
-                    raise exc_info[0], exc_info[1], exc_info[2]
+                    raise exc_info[0](exc_info[1]).with_traceback(exc_info[2])
             finally:
                 exc_info = None     # avoid dangling circular ref
         elif headers_set:




On 7 January 2011 16:58, Guido van Rossum <[hidden email]> wrote:

> On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight <[hidden email]> wrote:
>> On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote:
>>> At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
>>>> Is that the last thing or do I need to go spend some time and write my
>>>> own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
>>>> lying around and just do some final validation checks with a parallel
>>>> implementation as a sanity check to make sure we got everything? This
>>>> might be a good idea anyway.
>>>
>>> It would.  In the meantime, though, I've checked in the two-line change to add .buffer in.  ;-)
>>
>> So does that mean PEP 3333 can be accepted now?
>
> TBH I've totally lost track. Hopefully PJE and Graham can tell you...
>
> --
> --Guido van Rossum (python.org/~guido)
>
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Graham Dumpleton-2
The version at:

http://svn.python.org/projects/peps/trunk/pep-3333.txt

still shows:

        elif not headers_sent:
             # Before the first output, send the stored headers
             status, response_headers = headers_sent[:] = headers_set
             sys.stdout.write('Status: %s\r\n' % status)
             for header in response_headers:
                 sys.stdout.write('%s: %s\r\n' % header)
             sys.stdout.write('\r\n')

so not using buffer there and also not converting strings written for
headers to bytes.

Graham

On 7 January 2011 17:00, Graham Dumpleton <[hidden email]> wrote:

> Stupid question first. When running 2to3 on the example CGI code, why
> would it throw back the following. Is this indicative of anything else
> that needs to be changed to satisfy some Python 3 thing. The list()
> bit seems redundant, but I don't know what the other stuff is about.
>
> --- xx.py (original)
> +++ xx.py (refactored)
> @@ -9,7 +9,7 @@
>     return u.encode(enc, esc).decode('iso-8859-1')
>
>  def run_with_cgi(application):
> -    environ = {k: wsgi_string(v) for k,v in os.environ.items()}
> +    environ = {k: wsgi_string(v) for k,v in list(os.environ.items())}
>     environ['wsgi.input']        = sys.stdin
>     environ['wsgi.errors']       = sys.stderr
>     environ['wsgi.version']      = (1, 0)
> @@ -45,7 +45,7 @@
>             try:
>                 if headers_sent:
>                     # Re-raise original exception if headers sent
> -                    raise exc_info[0], exc_info[1], exc_info[2]
> +                    raise exc_info[0](exc_info[1]).with_traceback(exc_info[2])
>             finally:
>                 exc_info = None     # avoid dangling circular ref
>         elif headers_set:
>
>
>
>
> On 7 January 2011 16:58, Guido van Rossum <[hidden email]> wrote:
>> On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight <[hidden email]> wrote:
>>> On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote:
>>>> At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
>>>>> Is that the last thing or do I need to go spend some time and write my
>>>>> own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
>>>>> lying around and just do some final validation checks with a parallel
>>>>> implementation as a sanity check to make sure we got everything? This
>>>>> might be a good idea anyway.
>>>>
>>>> It would.  In the meantime, though, I've checked in the two-line change to add .buffer in.  ;-)
>>>
>>> So does that mean PEP 3333 can be accepted now?
>>
>> TBH I've totally lost track. Hopefully PJE and Graham can tell you...
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Alice Bevan–McGregor
In reply to this post by Graham Dumpleton-2
On 2011-01-06 22:00:17 -0800, Graham Dumpleton said:
> -    environ = {k: wsgi_string(v) for k,v in os.environ.items()}
> +    environ = {k: wsgi_string(v) for k,v in list(os.environ.items())}

2to3 takes the conservative route of assuming your application treats
dict.items() as a list in all cases; this is not nessicarily true (of
course), but it is safe, and interestingly, backwards compatible.

> -                    raise exc_info[0], exc_info[1], exc_info[2]
> +                    raise exc_info[0](exc_info[1]).with_traceback(exc_info[2])

The exception raising syntax has changed; you can not re-raise an
exception using tuple notation any more.  The new syntax is far
clearer, but I'm unsure of back-compatibility or even if it is possible
to emulate it completely as a polygot (2.x and 3.x w/ same code).

        - Alice.


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Graham Dumpleton-2
In reply to this post by Graham Dumpleton-2
On 7 January 2011 17:13, Graham Dumpleton <[hidden email]> wrote:

> The version at:
>
> http://svn.python.org/projects/peps/trunk/pep-3333.txt
>
> still shows:
>
>        elif not headers_sent:
>             # Before the first output, send the stored headers
>             status, response_headers = headers_sent[:] = headers_set
>             sys.stdout.write('Status: %s\r\n' % status)
>             for header in response_headers:
>                 sys.stdout.write('%s: %s\r\n' % header)
>             sys.stdout.write('\r\n')
>
> so not using buffer there and also not converting strings written for
> headers to bytes.

So:

        elif not headers_sent:
             # Before the first output, send the stored headers
             status, response_headers = headers_sent[:] = headers_set
             sys.stdout.buffer.write(wsgi_header('Status: %s\r\n' % status))
             for header in response_headers:
                 sys.stdout.buffer.write(wsgi_header('%s: %s\r\n' % header))
             sys.stdout.buffer.write(wsgi_header('\r\n'))

where define up start of file:

def wsgi_header(u):
    return u.encode('iso-8859-1')

I am still seeing some issue with CRLF but is in my body and with
conversion of some StringIO in my test.

> Graham
>
> On 7 January 2011 17:00, Graham Dumpleton <[hidden email]> wrote:
>> Stupid question first. When running 2to3 on the example CGI code, why
>> would it throw back the following. Is this indicative of anything else
>> that needs to be changed to satisfy some Python 3 thing. The list()
>> bit seems redundant, but I don't know what the other stuff is about.
>>
>> --- xx.py (original)
>> +++ xx.py (refactored)
>> @@ -9,7 +9,7 @@
>>     return u.encode(enc, esc).decode('iso-8859-1')
>>
>>  def run_with_cgi(application):
>> -    environ = {k: wsgi_string(v) for k,v in os.environ.items()}
>> +    environ = {k: wsgi_string(v) for k,v in list(os.environ.items())}
>>     environ['wsgi.input']        = sys.stdin
>>     environ['wsgi.errors']       = sys.stderr
>>     environ['wsgi.version']      = (1, 0)
>> @@ -45,7 +45,7 @@
>>             try:
>>                 if headers_sent:
>>                     # Re-raise original exception if headers sent
>> -                    raise exc_info[0], exc_info[1], exc_info[2]
>> +                    raise exc_info[0](exc_info[1]).with_traceback(exc_info[2])
>>             finally:
>>                 exc_info = None     # avoid dangling circular ref
>>         elif headers_set:
>>
>>
>>
>>
>> On 7 January 2011 16:58, Guido van Rossum <[hidden email]> wrote:
>>> On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight <[hidden email]> wrote:
>>>> On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote:
>>>>> At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
>>>>>> Is that the last thing or do I need to go spend some time and write my
>>>>>> own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
>>>>>> lying around and just do some final validation checks with a parallel
>>>>>> implementation as a sanity check to make sure we got everything? This
>>>>>> might be a good idea anyway.
>>>>>
>>>>> It would.  In the meantime, though, I've checked in the two-line change to add .buffer in.  ;-)
>>>>
>>>> So does that mean PEP 3333 can be accepted now?
>>>
>>> TBH I've totally lost track. Hopefully PJE and Graham can tell you...
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>>
>>
>
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Graham Dumpleton-2
On 7 January 2011 17:22, Graham Dumpleton <[hidden email]> wrote:

> On 7 January 2011 17:13, Graham Dumpleton <[hidden email]> wrote:
>> The version at:
>>
>> http://svn.python.org/projects/peps/trunk/pep-3333.txt
>>
>> still shows:
>>
>>        elif not headers_sent:
>>             # Before the first output, send the stored headers
>>             status, response_headers = headers_sent[:] = headers_set
>>             sys.stdout.write('Status: %s\r\n' % status)
>>             for header in response_headers:
>>                 sys.stdout.write('%s: %s\r\n' % header)
>>             sys.stdout.write('\r\n')
>>
>> so not using buffer there and also not converting strings written for
>> headers to bytes.
>
> So:
>
>        elif not headers_sent:
>             # Before the first output, send the stored headers
>             status, response_headers = headers_sent[:] = headers_set
>             sys.stdout.buffer.write(wsgi_header('Status: %s\r\n' % status))
>             for header in response_headers:
>                 sys.stdout.buffer.write(wsgi_header('%s: %s\r\n' % header))
>             sys.stdout.buffer.write(wsgi_header('\r\n'))
>
> where define up start of file:
>
> def wsgi_header(u):
>    return u.encode('iso-8859-1')
>
> I am still seeing some issue with CRLF but is in my body and with
> conversion of some StringIO in my test.

Solved my CRLF issue. Was caused by what 2to3 did to my code.

Another thing though. For output changed to sys.stdout.buffer. For
input should we be using sys.stdin.buffer as well if want bytes?

Good thing I tried running this. Did we all assume that someone else
was actually running it to check it? :-)

Graham

>> Graham
>>
>> On 7 January 2011 17:00, Graham Dumpleton <[hidden email]> wrote:
>>> Stupid question first. When running 2to3 on the example CGI code, why
>>> would it throw back the following. Is this indicative of anything else
>>> that needs to be changed to satisfy some Python 3 thing. The list()
>>> bit seems redundant, but I don't know what the other stuff is about.
>>>
>>> --- xx.py (original)
>>> +++ xx.py (refactored)
>>> @@ -9,7 +9,7 @@
>>>     return u.encode(enc, esc).decode('iso-8859-1')
>>>
>>>  def run_with_cgi(application):
>>> -    environ = {k: wsgi_string(v) for k,v in os.environ.items()}
>>> +    environ = {k: wsgi_string(v) for k,v in list(os.environ.items())}
>>>     environ['wsgi.input']        = sys.stdin
>>>     environ['wsgi.errors']       = sys.stderr
>>>     environ['wsgi.version']      = (1, 0)
>>> @@ -45,7 +45,7 @@
>>>             try:
>>>                 if headers_sent:
>>>                     # Re-raise original exception if headers sent
>>> -                    raise exc_info[0], exc_info[1], exc_info[2]
>>> +                    raise exc_info[0](exc_info[1]).with_traceback(exc_info[2])
>>>             finally:
>>>                 exc_info = None     # avoid dangling circular ref
>>>         elif headers_set:
>>>
>>>
>>>
>>>
>>> On 7 January 2011 16:58, Guido van Rossum <[hidden email]> wrote:
>>>> On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight <[hidden email]> wrote:
>>>>> On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote:
>>>>>> At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
>>>>>>> Is that the last thing or do I need to go spend some time and write my
>>>>>>> own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
>>>>>>> lying around and just do some final validation checks with a parallel
>>>>>>> implementation as a sanity check to make sure we got everything? This
>>>>>>> might be a good idea anyway.
>>>>>>
>>>>>> It would.  In the meantime, though, I've checked in the two-line change to add .buffer in.  ;-)
>>>>>
>>>>> So does that mean PEP 3333 can be accepted now?
>>>>
>>>> TBH I've totally lost track. Hopefully PJE and Graham can tell you...
>>>>
>>>> --
>>>> --Guido van Rossum (python.org/~guido)
>>>>
>>>
>>
>
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Graham Dumpleton-2
In reply to this post by Alice Bevan–McGregor
On 7 January 2011 17:19, Alice Bevan–McGregor <[hidden email]> wrote:
>> -                    raise exc_info[0], exc_info[1], exc_info[2]
>> +                    raise
>> exc_info[0](exc_info[1]).with_traceback(exc_info[2])
>
> The exception raising syntax has changed; you can not re-raise an exception
> using tuple notation any more.  The new syntax is far clearer, but I'm
> unsure of back-compatibility or even if it is possible to emulate it
> completely as a polygot (2.x and 3.x w/ same code).

PJE already said that intent is that PEP will only have Python 3
compatible code in it. Not attempting to have examples that work for
both Python 2 and Python 3.

That sounds to me then that we should be using what 2to3 changed it to. Ie.,

                  if headers_sent:
                    # Re-raise original exception if headers sent
                    raise exc_info[0](exc_info[1]).with_traceback(exc_info[2])

Graham


Graham
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

PJ Eby
In reply to this post by Graham Dumpleton-2
At 05:00 PM 1/7/2011 +1100, Graham Dumpleton wrote:
>Stupid question first. When running 2to3 on the example CGI code,

Don't do that.  It's supposed to already be Python 3 code.  ;-)

It did, however, reveal a bug where I have not in fact done the
correct Python 3 thing:

>                  if headers_sent:
>                      # Re-raise original exception if headers sent
>-                    raise exc_info[0], exc_info[1], exc_info[2]
>+                    raise
>exc_info[0](exc_info[1]).with_traceback(exc_info[2])
>              finally:
>                  exc_info = None     # avoid dangling circular ref

Can somebody weigh in on what the correct translation here is?  The
only real Python 3 coding I've done to date has been experiments to
test changes to other aspects of WSGI.  ;-)


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

PJ Eby
In reply to this post by Graham Dumpleton-2
At 05:13 PM 1/7/2011 +1100, Graham Dumpleton wrote:

>The version at:
>
>http://svn.python.org/projects/peps/trunk/pep-3333.txt
>
>still shows:
>
>         elif not headers_sent:
>              # Before the first output, send the stored headers
>              status, response_headers = headers_sent[:] = headers_set
>              sys.stdout.write('Status: %s\r\n' % status)
>              for header in response_headers:
>                  sys.stdout.write('%s: %s\r\n' % header)
>              sys.stdout.write('\r\n')
>
>so not using buffer there and also not converting strings written for
>headers to bytes.

Fixed in SVN now.  The main issue now is that we need to fix the
re-raises and error handling for Python 3, in the text and examples.

I also found some references for with_traceback() and I think I've
got that sorted now, but if someone can check my work that'd be a good idea.

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

PJ Eby
In reply to this post by Graham Dumpleton-2
At 05:27 PM 1/7/2011 +1100, Graham Dumpleton wrote:
>Another thing though. For output changed to sys.stdout.buffer. For
>input should we be using sys.stdin.buffer as well if want bytes?

%&$*()&%!!!  Sorry, still getting used to this whole Python 3
thing.  (Honestly, I don't even use Python 2.6 for anything real yet.)


>Good thing I tried running this. Did we all assume that someone else
>was actually running it to check it? :-)

Well, I only recently started changing the examples to actual Python
3, vs being the old Python 2 examples.  Though, I'm not sure anybody
ever ran the Python 2 ones.  ;-)

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Guido van Rossum
In reply to this post by PJ Eby
On Fri, Jan 7, 2011 at 7:35 AM, P.J. Eby <[hidden email]> wrote:

> At 05:00 PM 1/7/2011 +1100, Graham Dumpleton wrote:
>>
>> Stupid question first. When running 2to3 on the example CGI code,
>
> Don't do that.  It's supposed to already be Python 3 code.  ;-)
>
> It did, however, reveal a bug where I have not in fact done the correct
> Python 3 thing:
>
>>                 if headers_sent:
>>                     # Re-raise original exception if headers sent
>> -                    raise exc_info[0], exc_info[1], exc_info[2]
>> +                    raise
>> exc_info[0](exc_info[1]).with_traceback(exc_info[2])
>>             finally:
>>                 exc_info = None     # avoid dangling circular ref
>
> Can somebody weigh in on what the correct translation here is?  The only
> real Python 3 coding I've done to date has been experiments to test changes
> to other aspects of WSGI.  ;-)

That translation works.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (CGI example)

Antoine Pitrou
In reply to this post by PJ Eby
Hello,

P.J. Eby <pje@...> writes:

>
> >                  if headers_sent:
> >                      # Re-raise original exception if headers sent
> >-                    raise exc_info[0], exc_info[1], exc_info[2]
> >+                    raise
> >exc_info[0](exc_info[1]).with_traceback(exc_info[2])
> >              finally:
> >                  exc_info = None     # avoid dangling circular ref
>
> Can somebody weigh in on what the correct translation here is?  The
> only real Python 3 coding I've done to date has been experiments to
> test changes to other aspects of WSGI.  

You don't need the "with_traceback". Just "raise exc_info[1]". The original
traceback is already attached to the exception instance (major difference from
Python 2).

Oh and by the way:

    headers_set = []
    headers_sent = []

This is really a recipe for disaster. Please give these two variables clearly
distinct names. Your example is very confusing to read because of this.

Regards

Antoine.


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Graham Dumpleton-2
In reply to this post by PJ Eby
On 8 January 2011 02:55, P.J. Eby <[hidden email]> wrote:

> At 05:27 PM 1/7/2011 +1100, Graham Dumpleton wrote:
>>
>> Another thing though. For output changed to sys.stdout.buffer. For
>> input should we be using sys.stdin.buffer as well if want bytes?
>
> %&$*()&%!!!  Sorry, still getting used to this whole Python 3 thing.
>  (Honestly, I don't even use Python 2.6 for anything real yet.)
>
>
>> Good thing I tried running this. Did we all assume that someone else
>> was actually running it to check it? :-)
>
> Well, I only recently started changing the examples to actual Python 3, vs
> being the old Python 2 examples.  Though, I'm not sure anybody ever ran the
> Python 2 ones.  ;-)

Latest CGI/WSGI bridge example extract from PEP 3333 seems to work
okay for my simple test.

So, if no more technical problems (vs cosmetic) that anyone else sees,
that is probably it and and we can toss this baby out the door.

Graham
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Guido van Rossum
Ok, now that we've had a week of back and forth about this, let me
repeat my "threat". Unless more concerns are brought up in the next 24
hours, can PEP 3333 be accepted? It seems a lot of people are waiting
for a decision that enables implementers to go ahead and claim PEP
333[3] compatibility. PEP 444 can take longer.

--Guido

On Fri, Jan 7, 2011 at 4:56 PM, Graham Dumpleton
<[hidden email]> wrote:

> On 8 January 2011 02:55, P.J. Eby <[hidden email]> wrote:
>> At 05:27 PM 1/7/2011 +1100, Graham Dumpleton wrote:
>>>
>>> Another thing though. For output changed to sys.stdout.buffer. For
>>> input should we be using sys.stdin.buffer as well if want bytes?
>>
>> %&$*()&%!!!  Sorry, still getting used to this whole Python 3 thing.
>>  (Honestly, I don't even use Python 2.6 for anything real yet.)
>>
>>
>>> Good thing I tried running this. Did we all assume that someone else
>>> was actually running it to check it? :-)
>>
>> Well, I only recently started changing the examples to actual Python 3, vs
>> being the old Python 2 examples.  Though, I'm not sure anybody ever ran the
>> Python 2 ones.  ;-)
>
> Latest CGI/WSGI bridge example extract from PEP 3333 seems to work
> okay for my simple test.
>
> So, if no more technical problems (vs cosmetic) that anyone else sees,
> that is probably it and and we can toss this baby out the door.
>
> Graham
>



--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Alice Bevan–McGregor
On 2011-01-10 13:12:57 -0800, Guido van Rossum said:

> Ok, now that we've had a week of back and forth about this, let me
> repeat my "threat". Unless more concerns are brought up in the next 24
> hours, can PEP 3333 be accepted?

+9001 (> 9000)

> It seems a lot of people are waiting for a decision that enables
> implementers to go ahead and claim PEP
> 333[3] compatibility.

Django, mod_wsgi, CherryPy, etc. all have solutions that would need
AFIK minor tweaking before going "live", which would make adoption of
PEP 3333 the fastest of any PEP I've ever seen. ;)

> PEP 444 can take longer.

Indeed it will!  :D

I have the conversion from Textile to ReST about half completed; I'll
continue to poke it now that mailing list traffic seems to have died
down and won't be consuming the majority of my Copious Spare Time™.  
ReST just doesn't jive with my neural net.  :/

        - Alice.


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Alice Bevan–McGregor
In reply to this post by Guido van Rossum
On 2011-01-10 13:12:57 -0800, Guido van Rossum said:

> Ok, now that we've had a week of back and forth about this, let me
> repeat my "threat". Unless more concerns are brought up in the next 24
> hours, can PEP 3333 be accepted? It seems a lot of people are waiting
> for a decision that enables implementers to go ahead and claim PEP
> 333[3] compatibility. PEP 444 can take longer.

Two hours to go...

        - Alice.


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Alice Bevan–McGregor
In reply to this post by Guido van Rossum
On 2011-01-10 13:12:57 -0800, Guido van Rossum said:
> Ok, now that we've had a week of back and forth about this, let me
> repeat my "threat". Unless more concerns are brought up in the next 24
> hours, can PEP 3333 be accepted? It seems a lot of people are waiting
> for a decision that enables implementers to go ahead and claim PEP
> 333[3] compatibility. PEP 444 can take longer.

With the lack of responses, can I assume this has been or will be
shortly marked as "accepted"?

I look forward to updating WebCore with compatibility.

        — Alice.


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Guido van Rossum
On Wed, Jan 12, 2011 at 2:34 PM, Alice Bevan–McGregor
<[hidden email]> wrote:

> On 2011-01-10 13:12:57 -0800, Guido van Rossum said:
>>
>> Ok, now that we've had a week of back and forth about this, let me repeat
>> my "threat". Unless more concerns are brought up in the next 24 hours, can
>> PEP 3333 be accepted? It seems a lot of people are waiting for a decision
>> that enables implementers to go ahead and claim PEP 333[3] compatibility.
>> PEP 444 can take longer.
>
> With the lack of responses, can I assume this has been or will be shortly
> marked as "accepted"?

Yep. Phillip, can you do the honors?

> I look forward to updating WebCore with compatibility.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
123