[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Phillip J. Eby added the comment: That change to the spec is fine, though you might also want to add something like, "Like all other WSGI specification types", since *all* types specified in WSGI are 'type()' not 'isinstance()'. -- ___ Python track

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Éric Araujo added the comment: Here’s my try at making the spec more explicit about str subclasses. -- keywords: +patch Added file: http://bugs.python.org/file22244/pep--no-subclasses.diff ___ Python tracker _

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Éric Araujo added the comment: FYI, #10977 has been opened to tackle the general subclasses problem. -- ___ Python tracker ___ ___ Py

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

R. David Murray added the comment: > 4. The explicit-vs-implicit is about the contract defined in the spec (making > explicit what, precisely, is required of both parties), not the type test. Perhaps a clarification in the () spec that 'type str' means "type(s) is str" would be in order,

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Phillip J. Eby added the comment: 1. WSGI is a *Python* spec, not a *CPython* spec, so CPython implementation details have little bearing on how the spec should work. Most non-CPython implementations have a native string type optimized for their runtime or VM (i.e. Jython and IronPython), and

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Antoine Pitrou added the comment: > Implicit knowledge in your own head about what might or might not be a > good idea to program is not the same thing as a specification. > "type(x) is str" is a good specification in this context, while > "string subclasses, but only if they're really str" does

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Phillip J. Eby added the comment: Implicit knowledge in your own head about what might or might not be a good idea to program is not the same thing as a specification. "type(x) is str" is a good specification in this context, while "string subclasses, but only if they're really str" does not

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Antoine Pitrou added the comment: > PyString_AsString() only "works on subclasses" if their internal > representation is the same as type str. So we can't say "subclass of > str" without *also* specifying that the subclass store its contents in > exactly the same way as an object of type str...

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Phillip J. Eby added the comment: PyString_AsString() only "works on subclasses" if their internal representation is the same as type str. So we can't say "subclass of str" without *also* specifying that the subclass store its contents in exactly the same way as an object of type str... whi

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Andrey Popp <8may...@gmail.com> added the comment: I've also sent message[1] to web-sig about this issue. [1]: http://mail.python.org/pipermail/web-sig/2011-January/004986.html -- ___ Python tracker __

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Antoine Pitrou added the comment: > Jean-Paul Calderone added the comment: > > > Phillip, your argument about interfacing with code written in C > doesn't work for built-in immutable types like str. > > Sure it does. Definitely-str is easier to handle in C than > maybe-str-subclass. Well, P

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Jean-Paul Calderone added the comment: > Phillip, your argument about interfacing with code written in C doesn't work > for built-in immutable types like str. Sure it does. Definitely-str is easier to handle in C than maybe-str-subclass. It doesn't matter that str.__new__ gets called. Othe

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Denis S. Otkidach added the comment: Phillip, your argument about interfacing with code written in C doesn't work for built-in immutable types like str. Any subclass of str must call str.__new__ thus keeping proper internal state. -- ___ Python tra

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Phillip J. Eby added the comment: One of the original reasons was to make it easier for server authors writing C code to interface with WSGI. C APIs that operate on lists and dicts often do not do what you would expect, when called on a subclass. Essentially, this could lead to an app that

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Andrey Popp <8may...@gmail.com> added the comment: > the spec says "an object of type str" he means 'type(x) is str' as opposed to > 'isinstance(x, str)' -1 Liskov substitution principle states, that every subtype S of type T can be used whenever type T is used. -- nosy: +andreypopp

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Antoine Pitrou added the comment: > OK. So he is saying that when the spec says "an object of type str" he > means 'type(x) is str' as opposed to 'isinstance(x, str)'. I would > naively have expected the latter, as other people clearly do as well. +1 with RDM here. > Doesn't matter how unpy

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Phillip J. Eby added the comment: Doesn't matter how unpythonic it is: the spec calls for exact types and has done so for six years already, so it's a bit late to do anything about it. (And any version of Python that allowed string subclasses was in violation of the spec and therefore buggy.

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Denis S. Otkidach added the comment: Current behavior is unpythonic: documentation explicitly mentions isinstance as preferred way to check type (see http://docs.python.org/library/types.html ). Also 2.7 is the last minor version with str as "main" string type. So I believe it should use isin

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

R. David Murray added the comment: OK. So he is saying that when the spec says "an object of type str" he means 'type(x) is str' as opposed to 'isinstance(x, str)'. I would naively have expected the latter, as other people clearly do as well. I didn't participate in any of the discussions

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Éric Araujo added the comment: See http://bugs.python.org/issue5800#msg121958 -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

R. David Murray added the comment: Eric, could you point out the part of the specification that requires exactly a string and makes a string subclass invalid? I did a quick scan and couldn't find it, and unfortunately don't have the time to re-read the whole spec right now. -- nosy:

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Tim Perevezentsev added the comment: str - immutable. So every str subclass object is normal string. I don't see any design violation here. -- ___ Python tracker ___ __

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

Éric Araujo added the comment: This is by design. PEP 333 and PEP contain more information about that. You’ll need to convert your objects to str before passing them to start_response. Sorry! -- nosy: +eric.araujo, pje resolution: -> invalid stage: -> committed/rejected stat

[issue10935] wsgiref.handlers.BaseHandler and subclasses of str

New submission from Tim Perevezentsev : This code: assert type(val) is StringType,"Header values must be strings" (from here http://svn.python.org/view/python/tags/r271/Lib/wsgiref/handlers.py?revision=86833&view=markup) from "start_response" method, is not allowing to use str subclasses