Live data from Hacker News

Python 3 Wall of Shame

python3wos.appspot.com

31–40 of 80 posts

Re: Python 3 Wall of Shame

#31
post #27

"Wall of Shame," sounds harsh. However I don't think it's entirely inappropriate. The premise is that it has been two years since py3k has been release and the community has little to show for it. One would think two whole years would be enough time to port a library. Especially if most of the fundamental challenges of doing so are matters of syntax (not in all cases I'm sure) and changing some names. OTOH, maybe the…

Guido should have stuck with his original plan - keep updating python 2.X till it's converged to python 3. Deprecate print statements, warn if you don't import division from __future__, and so on. Maybe even leave a 2.X compatibility mode: `from __past__ import print_statement`. I guess unicode is a sticky point though. I really don't know what can be done about except rant about how hard unicode is.

I am sure Guido realized one thing. Where would he get the resources to keep updating and do P3. I think he chose the right path. 5 year plan (half way there) to move everything to P3. That gives them a good time-frame to get things in P3 solid and stable (however you want to apply those terms).

Re: Python 3 Wall of Shame

#34
Pretty much inaccurate data. For example many project release under a new "3k" name, and leave the old ones. One of those is a backport of a stdlib module (multiprocessing), etc. So, it's bad data, and misleading, but I admire the idea.

Re: Python 3 Wall of Shame

#35

"Wall of Shame," sounds harsh. However I don't think it's entirely inappropriate. The premise is that it has been two years since py3k has been release and the community has little to show for it. One would think two whole years would be enough time to port a library. Especially if most of the fundamental challenges of doing so are matters of syntax (not in all cases I'm sure) and changing some names. OTOH, maybe the…

"Maybe py3k is viewed as "that bad," that no one wants to bother with it?"

I don't think anyone's viewing it that way. A lot of people want to switch and many are, but there's the non-zero cost of porting and also the generally low demand. No one wants to spend 3 days of initial work on a port that no one currently wants, then tack on the continued maintenance of two branches (or a single code base that works with both and requires twice the testing).

Part of the reason we have the PSF Sprints funding is to solve that problem. A group of 6-7 developers in Cape Town is taking advantage of the funding in early March and plans to complete more of the py3k port of matplotlib. matplotlib is a great one to work on in terms of community impact since it usually ranks highly in any poll of 3.x blockers.

Re: Python 3 Wall of Shame

#36
post #13

Funny to see zope.interface on that list. I remember back in 2005, when Zope 3 had just been launched, about how everyone who mattered in the Zope world would say things like "only stupid, retrograde people won't switch to Zope3". I guess the stupid people won, because 6 years on Zope is like the Cobol of Python web frameworks. I just hope the same thing won't happen to Python itself.

Let's just call Zope 2 the Common Lisp of Python frameworks... I guess it survives mostly because Plone needs it.

Zope 3 and Grok are pretty cool.

Re: Python 3 Wall of Shame

#38
post #33

Just picked one from the red list (pytz) and it looks like Py3.1 is supported...

And beaker too. Most projects i've clicked through only offer some source tarball or easy_install instructions but no mentioning of supported Python versions..

I am wondering how the list would really look...

Re: Python 3 Wall of Shame

#39

well, it's the same with php4 and php5. and php5 has been released in 2004 ...

What place is still running php4? The 4-series has been abandoned even for critical security patches some time ago, the move to 5 solidified a long time ago.

Maybe you're confusing PHP 5 and PHP 6; PHP 6 has been "just around the corner" now for a few years.

Re: Python 3 Wall of Shame

#40
post #16

well, it's the same with php4 and php5. and php5 has been released in 2004 ...

PHP 5 was still, as much as I can remember, compatible with PHP 4, wasn't it? Anything that worked in PHP 4 worked in PHP 5.

That's not true. If one used OOP in PHP4, running that code in PHP5 will produce lots of bugs related to the new object model.
Post reply on HN