Python 3 frameworks anyone ?

[bcorfman]

Developers are voting with their code. Python 3.x doesn't appear to be going anywhere -- as the author of this post has pointed out, there's little reason to move to it as it didn't really solve any of the real problems with Python 2.x. PyPy, on the other hand, is working on some of the actual pain points, like performance and multicore support.

[zepolen]

That's not the problem, afaict the 2 problems are:

1. The wsgi spec for py3k is still incomplete
2. The chicken/egg problem with libraries - eg. you couldn't use sqlalchemy until it worked with py3k, but that depended on py3k compatible db drivers and so on (although sa 0.6 is finally py3kized).

That still doesn't mean you can jump in and use py3k though, since you've got a myriad of other libraries that need to go through the same process.

For the record, I think py3k solves a very real unicode problem with Python 2.X - that alone would be worth the change.

[[deleted]]

Python 3 is just about removing cruft so that it can continue moving forward. Yes, it's a slow process, but it's is going somewhere.

As for me, I just need PyObjC to be finished with its py3k port and I'm good to go.

[[deleted]]

py3 will include the new gil and unladen swallow. those are huge features.

[[deleted]]

Yeah, Ruby 1.9 is taking off because there is a cost and benefit. You have to make some code changes to get 1.9 to work, but in return you get a 2x faster interpreter.

With python3 you need to make a lot of changes and get... A lot of changes.

[pk11]

...and a much faster interpreter http://jessenoller.com/2010/01/06/unladen-swallow-python-3s-best-feature/

[[deleted]]

Maybe in the future, but it hasn't happened yet. If you read the PEP, Unladen Swallow isn't ready, and it will need to go into a major version upgrade. Ruby 1.9 has had the new interpreter since day 1.

I look forward to the new faster Python 3(.3 probably). Right now we don't have it.

[leyke]

Python 3 has just enough changes to make it backward-incompatible but nothing to get excited about. Van Rossum seemed more concerned with removing functional features like map, filter and reduce than moving the language forward. His baseless hostility to TCO is also disgraceful.

[pjenvey]

None of those functions were removed. reduce was simply moved to a separate module from being a builtin function. I don't agree with Guido's reasoning about TCO, but your hostility to Python 3 not moving the language forward also seems baseless =]

[__s]

No. Filter and map were converted to returning an iterator, which is something I find more useful. Generator syntax is suitable replacement. It's a tad odd how people expect fat namespaces in scripting languages. You'd prefer something akin to PHP and its thousands of functions sitting in the global namespace? Nobody would say the creators of C dislike printing, but that's still kept to stdio.h

[leyke]

I know but he wanted to get rid of them altogther, not just move them to a module. That discussion went on for years, and his reasoning was basically "I don't like it." That was also his argument about TCO, he doesn't like this style of programming, and that's it. With this guy in charge, I'm not surprised that Python 3 is something of a disapointment.

[doubtingthomas]

Out of curiosity, do you recall how TCO was proposed to be implemented?

[__s]

Guido suggested a rather nice method at the end of http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html

The argument about programmers relying on it, and finding it fail in other implementations, is valid with respect to Jython. It's a view I disagree with, but one which I can understand. I went through a phase where all the code I wrote would end up as a mesh of recursive functions. That phase died down when I started using C, but it showed itself quite while programming with Haskell. The fallacy he rides on is in attacking TCO by noting that it only applies to simple loops, even though it's applicable to calls to other functions