4 ms·

WSGI on Python 3

35 points by mattyb 16y ago

jnoller 16y ago
Standard library changes in Python 3 which make supporting WSGI and stacks like it (and protocols in general) more difficult or painful are bugs. Since the stdlib isn't set in stone, those bugs should be fixed by the interested parties. No one involved in core development is infallible, if a decision has been made which is fundamentally flawed, it can and should be changed.
- kingkilr 16y ago
  They're not all stdlib changes though. The lack of certain string methods on bytes makes implementing the stdlib changes unreasonably difficult.
  - jnoller 16y ago
    Agreed, this has come up more and more frequently and I'm beginning to see the light of allowing string methods on bytes more and more.
- ianb 16y ago
  But... if the standard library gets fixed, what then? Do we say "WSGI is only compatible with Python 3.3+"? That's just... crazy.
  - jnoller 16y ago
    Fair enough; but I'd rather see things fixed then see the constant drum beat of "this is broken and a piss-poor design decision". If it's broken, fix it. There's no excuse to not fix bugs, even in the name of backwards compatibility.
pilif 16y ago
I totally agree: The whole HTTP spec has the concept of ASCII implicitly embedded. Converting this to Unicode is, IMHO, the wrong approach. If the spec is talking bytes, then the libraries working with that spec should also be talking bytes. While latin1 can be converted to Unicode, this is not true for all encodings, so the current way how WSGI is handling requests might actually destroy some data in passing (some multibyte japanese encodings cannot be losslessly converted to Unicode). If the library doesn't provide easy methods to do something, it's IMHO totally the wrong approach to potentially destroy data just to have the convenience methods available. So the solution should be to either provide the needed library methods for bytes directly in python or to provide them as a third party library and have WSGI depend on that, though it's probably way easier to just have the internal string methods accept bytes too.
- randallsquared 16y ago
  some multibyte japanese encodings cannot be losslessly converted to Unicode I hadn't heard this... do you have a link or search terms that will produce more information about the issue ("convert CJK unicode" and "multibyte japanese encoding unicode" didn't)?
  - pilif 16y ago
    http://en.wikipedia.org/wiki/Han_unification http://en.wikipedia.org/wiki/Han_unification
  - wycats 16y ago
    Also, http://yehudakatz.com/2010/05/17/encodings-unabridged/ http://yehudakatz.com/2010/05/17/encodings-unabridged/ My post is mostly about the ramifications of Ruby 1.9's encoding support on Rails (a similar topic), but I go into some detail about the problems of Japanese encodings on the web.
    - pilif 16y ago
      see also the novel I posted here on Hacker News defending the way Ruby 1.9 decided to handle strings with: http://news.ycombinator.com/item?id=1163684 http://news.ycombinator.com/item?id=1163684
joubert 16y ago
Any one use PyPy in production? With Apache + WSGI?

35 points by mattyb 16y ago

Standard library changes in Python 3 which make supporting WSGI and stacks like it (and protocols in general) more difficult or painful are bugs. Since the stdlib isn't set in stone, those bugs should be fixed by the interested parties. No one involved in core development is infallible, if a decision has been made which is fundamentally flawed, it can and should be changed.

kingkilr 16y ago
They're not all stdlib changes though. The lack of certain string methods on bytes makes implementing the stdlib changes unreasonably difficult.
- jnoller 16y ago
  Agreed, this has come up more and more frequently and I'm beginning to see the light of allowing string methods on bytes more and more.
ianb 16y ago
But... if the standard library gets fixed, what then? Do we say "WSGI is only compatible with Python 3.3+"? That's just... crazy.
- jnoller 16y ago
  Fair enough; but I'd rather see things fixed then see the constant drum beat of "this is broken and a piss-poor design decision". If it's broken, fix it. There's no excuse to not fix bugs, even in the name of backwards compatibility.

pilif 16y ago

I totally agree: The whole HTTP spec has the concept of ASCII implicitly embedded. Converting this to Unicode is, IMHO, the wrong approach. If the spec is talking bytes, then the libraries working with that spec should also be talking bytes. While latin1 can be converted to Unicode, this is not true for all encodings, so the current way how WSGI is handling requests might actually destroy some data in passing (some multibyte japanese encodings cannot be losslessly converted to Unicode). If the library doesn't provide easy methods to do something, it's IMHO totally the wrong approach to potentially destroy data just to have the convenience methods available. So the solution should be to either provide the needed library methods for bytes directly in python or to provide them as a third party library and have WSGI depend on that, though it's probably way easier to just have the internal string methods accept bytes too.

randallsquared 16y ago
some multibyte japanese encodings cannot be losslessly converted to Unicode I hadn't heard this... do you have a link or search terms that will produce more information about the issue ("convert CJK unicode" and "multibyte japanese encoding unicode" didn't)?
- pilif 16y ago
  http://en.wikipedia.org/wiki/Han_unification http://en.wikipedia.org/wiki/Han_unification
- wycats 16y ago
  Also, http://yehudakatz.com/2010/05/17/encodings-unabridged/ http://yehudakatz.com/2010/05/17/encodings-unabridged/ My post is mostly about the ramifications of Ruby 1.9's encoding support on Rails (a similar topic), but I go into some detail about the problems of Japanese encodings on the web.
  - pilif 16y ago
    see also the novel I posted here on Hacker News defending the way Ruby 1.9 decided to handle strings with: http://news.ycombinator.com/item?id=1163684 http://news.ycombinator.com/item?id=1163684

joubert 16y ago

Any one use PyPy in production? With Apache + WSGI?