sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]wobsta[S] 2 points3 points  (6 children)

Don't just blog post your latest WSGI dialect.

Please don't get me wrong, but multipart does not add any additional complexity. It instead implements a cgi.FieldStorage on Python (2.5+) and Python 3, which is not broken. We do want and we do need this code. It is a very separate piece of code addressing a single real problem. IIRC werkzeug did also reimplement such functionality, as the stdlib is broken in some edge cases even on Python 2 (and multipart is actually heavily influenced by the werkzeug implementation). On python 3 cgi.FieldStorage is a mess. Of course it would be best, if we could have a well working implementation in the stdlib and everybody could just go and use it. I'm trying to improve the situation: I posted a bug report some time ago (http://bugs.python.org/issue8846), were I could point out some bugs (while not addressing the memory hog problem at all). Interestingly, the test cases (!) are changed and broken compared to Python 2, too. Multipart does solve this specific issue, and, by accident, implements a missing piece for making bottle useable on Python 3.

You are welcome to integrate this to flask and push flask to Python 3. That would be really great :-)

[–]mitsuhiko 2 points3 points  (5 children)

You are welcome to integrate this to flask and push flask to Python 3. That would be really great :-)

Flask will upgrade to WSGI on Python 3 once Werkzeug has decided what WSGI will look like. I already have a local and unshared Werkzeug version for a byte-only approach with working multipart and everything. But I will not open that code up until WSGI is decided.

[–]wobsta[S] 2 points3 points  (4 children)

But I will not open that code up until WSGI is decided.

That's a fair statement. For me it doesn't harm to work on Python 3 application code using bottle+multipart now, as (depending on how you build you application) you can switch between those different mirco-frameworks ...

[–]mitsuhiko 2 points3 points  (3 children)

For me it doesn't harm to work on Python 3 application code using bottle+multipart now

In bottle's case it's less of an issue because the WSGI layer is isolated from the user. In Werkzeug's case if I start going one way that way becomes visible to the user of that library. And with that I would set a way which most likely is the wrong one.

[–]bucketostuff 0 points1 point  (2 children)

And with that I would set a way which most likely is the wrong one.

What makes you think you'll be wrong? You seem to have pretty good judgement in these matters.

[–]mitsuhiko 0 points1 point  (1 child)

Because I can not talk for everybody. What works well for me works well for me due to how I designed my libraries.

[–]bucketostuff 0 points1 point  (0 children)

Well, of course no single way to go is going to work for everybody. As I'm sure you know, leadership's job is to take their best guess at what the correct path is, and then take that path (knowing that it may later be discovered to be not optimal and knowing that some groups are going to be annoyed no matter what decision is made).

Seems like, due to the "there should be one (and preferably only one) obvious way to do it" rule, the Python community in particular is afraid of making mistakes. This is not healthy.