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 Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
