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 02:52 PM 1/12/2011 -0800, Guido van Rossum wrote:

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

Apparently not -- I went to check it in and found Raymond had already
marked it "Final".  ;-)

(I'm not clear on whether there's a difference between "Final" and
"Accepted" heredifference, but I assume that if we find some sort of
actual error we can still fix it.)


_______________________________________________
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 13 January 2011 12:02, P.J. Eby <[hidden email]> wrote:

> At 02:52 PM 1/12/2011 -0800, Guido van Rossum wrote:
>>
>> 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?
>
> Apparently not -- I went to check it in and found Raymond had already marked
> it "Final".  ;-)
>
> (I'm not clear on whether there's a difference between "Final" and
> "Accepted" heredifference, but I assume that if we find some sort of actual
> error we can still fix it.)

You can partly blame me for that. They were talking about WSGI and
Python 3 on #python-dev and I mentioned that Guido had just blessed it
and made mistake of mentioning the word 'final' in the sentence not
knowing anything about what next status would be. Anyway, Raymond
decided to take it on themselves to update even though I said to leave
it to you. There response since is 'IIRC, informational peps go
straight to final upon acceptance.'. So, they seem to think that the
final status is correct.

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)

Andrey Popp
Hello,

while PEP-3333 declared as "final" (not sure if it means the same as "accepted"), I would like to draw your attention at this bug report[1].

Personally, I'd like to fix PEP in the way it resolves mentioned bug. But if you disagree with me, I'd like at least to add note about statements like:

  "object A should be of type TA"

It's not common behavior for Python objects, and in some meaning it just breaks OOP in Python (see Liskov substitution principle[2]). Isn't this looks like unpythonic or at least as leaking abstraction?

[1]: http://bugs.python.org/issue10935
[2]: http://en.wikipedia.org/wiki/Liskov_substitution_principle

_______________________________________________
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 20, 2011, at 6:17 AM, Andrey Popp wrote:
> Hello,
>
> while PEP-3333 declared as "final" (not sure if it means the same as "accepted"), I would like to draw your attention at this bug report[1].
>
> Personally, I'd like to fix PEP in the way it resolves mentioned bug.

-1. I think the restriction to exact types is useful. It avoids the need to worry about running arbitrary unexpected user code in *Python* contexts. (as you pointed out, the C API ignores any overrides done in subclasses of str, and just accesses it as if it was the base class anyways...)

Furthermore, even were it not the case, the bug report is not timely: PEP 3333 is a minimal modification over PEP 333, which has been final for years.

> But if you disagree with me, I'd like at least to add note about statements like:
>
>  "object A should be of type TA"
>
> It's not common behavior for Python objects, and in some meaning it just breaks OOP in Python (see Liskov substitution principle[2]). Isn't this looks like unpythonic or at least as leaking abstraction?

It already states that for response_headers: "i.e. type(response_headers) is ListType".

But I agree, a clarification could be added to the statement '''all objects referred to in this specification as "strings" must be of type str or StringType''' and '''For values referred to in this specification as "bytestrings" [...] the value must be of type bytes under Python 3, and str in earlier versions of Python'''. It's not 100% obvious that it really does mean "type(obj) is str/bytes".

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)

PJ Eby
At 09:45 AM 1/20/2011 -0500, James Y Knight wrote:
>But I agree, a clarification could be added to the statement '''all
>objects referred to in this specification as "strings" must be of
>type str or StringType''' and '''For values referred to in this
>specification as "bytestrings" [...] the value must be of type bytes
>under Python 3, and str in earlier versions of Python'''. It's not
>100% obvious that it really does mean "type(obj) is str/bytes".

Feel free to write said clarification, check it in, and add glowing
praise for your efforts to the acknowledgements section.  I will
indeed appreciate it, so you won't even be lying.   ;-)

Or, you can just send me a patch, and receive slightly less
praise.  Either way works for me, though.  ;-)

_______________________________________________
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