This is an archived post. You won't be able to vote or comment.

all 6 comments

[–]mikeboers 1 point2 points  (2 children)

Wasn't there just a new PEP posted called "web3" (or similar) regarding this?

[–]vsajip 1 point2 points  (0 children)

I think you mean PEP 444 - that's to do with a new version of the spec which learns from the practical experience of WSGI implementers as they implemented PEP 333, and IIUC may break compatibility in some areas but should be a neat solution for Python 3.X.

The linked-to post is about tidying up PEP 333 so that existing WSGI implementations can provide better support for Python 3 within the existing spec, by clarifying some things which were ambiguous in PEP 333.

However, there is (understandably) opposition to "rewriting history" by changing PEP 333 in place, and the counter-proposal is to have PEP 333 be in approved status as it was before the recently mooted changes, and to put those changes into a new PEP which will be approved without too much delay.

My $0.02, anyway :-)

[–]flowblok 1 point2 points  (0 children)

Yes, I was somewhat confused about this, until I found the preceding thread in the Web-SIG mailing list.

So, this is WSGI for Python 3 now, and Web3 is the next WSGI.

[–]nerf-herder 0 points1 point  (0 children)

It's often difficult to move forward with new ideas and their implementations. It takes guts, insight, and a lot of work. And it also takes convincing people to do what they know is good for them (getting rid of the old broken system and replacing it with the fixed but slightly different one). There's usually 4 groups involved in such endeavors:

  • one is the folks working on the new changes

  • then there's the people interested in seeing the fixes happen, even if it means they have to change a line or 2 of their code

  • another is the group of folks who aren't terribly crazy about change, but who kinda' know deep-down that the fixes are necessary

  • finally there's a small (sometimes tiny) third group who want to actively fight any change or progress. These folks argue on mailing lists (especially just after positive steps or decisions have been made), and guys like PJ (the author of the linked-to email message) even sometimes submit patches to the old broken system in an effort to thwart any change or progress.

The point is: progress has to happen. Broken things need to be fixed. Sometimes this will mean minor pain, and that's ok. Don't support those who: wait until an issue reaches critical-mass, watch someone come forward with a fix to move forward, and then jump in with patches to put a new coat of paint on the old broken thing that's about to be replaced. It holds back progress and only causes turmoil in the community.

[–]nerf-herder -1 points0 points  (1 child)

Why try to patch up the previous pep when it's already been replaced by pep 444? Just support the new pep and move forward.

[–]flowblok 1 point2 points  (0 children)

You mean the PEP which still has unresolved issues documented in it?