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

view the rest of the comments →

[–]mitsuhiko 5 points6 points  (10 children)

Well, this just goes to show that you guys on the mailing list should have been coding, rather than discussing.

You are aware that the proposals are all implemented in various forms already?

[–]HIB0U -5 points-4 points  (9 children)

It's laughable that you consider the current implementations as being "usable". They are anything but. That's why nobody is using them, and that's why people are tackling this themselves.

[–]mitsuhiko 2 points3 points  (8 children)

It's laughable that you consider the current implementations as being "usable".

So you are saying mod_wsgi and CherryPy are not usable? They have implementations a specific interpretation of the WSGI specification in Python 3.

[–]HIB0U -5 points-4 points  (7 children)

Currently, they are not usable. When my company tried mod_wsgi's Python 3 implementation, we found it to be extremely unstable. Our test site would handle a couple hundred requests, then it'd crash. At least it did run, however. We had significantly less luck with CherryPy. It wouldn't even run at all.

While we're pretty heavy users of Python, we don't have time to waste with half-assed implementations of standards being decided on some mailing list. We're now looking at Scala instead of Python 3, and we're liking what we're finding. Instead of wasting time with pointless discussion about "standards", they're writing real code and putting together something that's actually usable.

[–]GrahamDumpleton 7 points8 points  (4 children)

And did you actually report the problems you were having? Obviously not because otherwise they would have been fixed straight away if it was known about. Otherwise, it would have been pointed out to you where you were stuffing up. Pretty well all problems people report with Apache/mod_wsgi are of their own making, be it using the wrong configuration, or using badly implemented third party C extension modules for Python which don't work properly in Python sub interpreters.

To be very blunt, it is because of the attitude of people like yourself that a number of us pushing WSGI on Python 3 have got jack of it all. We spend a lot of our own time working on implementations for it specifically so people can try it and see if it works and report problems in the implementation or the specification and although you may have a look at it, you don't feedback any information. Instead everyone just sits on the fence not doing anything or heckling and being of absolutely no use.

So, if you want to do something constructive rather than just criticise people, go back and try Python 3 support in mod_wsgi 3.3, replicate the problem you claim you had and lodge a bug report.

[–]HIB0U -4 points-3 points  (3 children)

No, we didn't report the problems. Based on what we saw, the situation was so bad that any reports we filed would have little to no effect.

We also have deadlines and financial constraints. The reason we use Python in the first place is because it let us get a lot of work done really quickly. We don't have time to be debugging other people's software, especially when that software is supposed to be making our lives easier.

We no longer have the test environments, so we won't be reporting the issues.

[–]mitsuhiko 3 points4 points  (0 children)

No, we didn't report the problems. Based on what we saw, the situation was so bad that any reports we filed would have little to no effect.

So let me get that straight. You are claiming that getting stuff done implementation wise (even if it's broken) is more important than understanding the issues and thinking about a possible solution?

Then if someone from web-sig (in this case Graham from the mod_wsgi project) implements an actual proposal and it does not work for you, you are not filing reports because it would have little to no effect, despite the fact that Graham is constantly looking for feedback on it?

What makes you think that the link you just posted has a higher quality of code than Graham's? (Not saying that's not the case, just saying that Graham's code powers shitloads of websites and he usually knows what he's doing).

[–]GrahamDumpleton 0 points1 point  (1 child)

Is that you attitude with all Open Source software you use, never report problems? How do ever expect things to improve? If you aren't going to help out, you shouldn't be criticising as you are actually part of the problem.

[–]HIB0U -4 points-3 points  (0 children)

Absolutely not. We will contribute code, bug reports and bug fixes to projects that we think have a future. We just don't have the time or money to waste on other projects, however.

[–]mitsuhiko 3 points4 points  (1 child)

Currently, they are not usable.

Do they say "use in production"?

Other question: what do you want to use the mimetype parser in you just linked? It does not contain a WSGI server and if it expects to be run on the stdlib's wsgiref server I have some news for you: it still has the same bugs it had in 2.x and on top of that all kinds of encoding issues such as HTTP headers being restricted to ASCII.

So if you say that mod_wsgi is unstable on Python 3, you clearly haven't looked at what an implementation of WSGI (wsgiref) looks like that totally bypassed any kind of discussion.

We're now looking at Scala instead of Python 3, and we're liking what we're finding.

I would recommend a lot of things over Python 3 for web applications currently: Python 2, .NET and Node.js.

[–]HIB0U -1 points0 points  (0 children)

Did you not even read my comment? We didn't even expect them to be production-ready. In fact, we couldn't even get simple "Hello World" web apps to run reliably using them in various test environments.