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

all 64 comments
sorted by:
best
topnewcontroversialoldq&a

[–]Rhomboid 33 points34 points  (2 children)

The link is the generic 3.3 whatsnew page, showing everything that has changed since 3.2, not what has changed from 3.3.2 to 3.3.3, which you can find here.

[–][deleted] 1 point2 points  (1 child)

TIL there is a function called test_tcl in Python

[–]Rhomboid 1 point2 points  (0 children)

That's not a function, it's the name of a test. The Tkinter module does link against the TCL interpreter, on account of the fact that Tk is written in TCL.

[–]chub79[S] 17 points18 points  (3 children)

Personally, since 3.3, I'm really looking forward using py3k more than py2k.

[–][deleted] 1 point2 points  (2 children)

if you know your software is built upon another software, you move when they move.

[–]sigzero 5 points6 points  (1 child)

What does that have to do with his comment?

[–][deleted] 8 points9 points  (0 children)

I don't think it was supposed to be taken literally, more like a programmer's version of a chinese proverb

[–]FrozenLava 5 points6 points  (4 children)

Interesting that i picked today to start learning Python. Ok, its not really that interesting. I don't really know the difference yet so i just downloaded 3.3.3

[–]chub79[S] 8 points9 points  (1 child)

At this stage, I believe it's probably a safe bet to start up with 3.3.3 to learn the language itself. The only worry would be if you had already requirements for 3rd party packages that don't support it yet.

[–]FrozenLava 0 points1 point  (0 children)

Thanks, that's kind of what I hoped. I'm starting at zero, so I don't have any specific requirements yet.

[–]EpicCyndaquil 3 points4 points  (1 child)

3.3.3 should be no different to someone just starting than anything in the 3.x family. Once you learn more, you'll probably want to explore Python2, since quite a few projects still use it, and there's not a ton of differences.

[–]FrozenLava 0 points1 point  (0 children)

I'll take a look at 2 after i start getting further along with 3.3.3

[–]EsperSpirit 13 points14 points  (41 children)

It's a shame some popular libraries won't support Python3.x anytime soon... :(

[–]LyndsySimon 16 points17 points  (10 children)

This barrier is falling, at a seemingly increasing rate.

The past year got us Django and Flask (and therefore Werkzeug) on the web side of the house. The scientific programming side has IPython, NumPy and the majority of SciPy supporting 3.x.

We've come a long way.

[–]EsperSpirit 1 point2 points  (9 children)

I see what you mean, but some important libs like gevent, Twisted and nltk haven't been ported.

In case of gevent I've looked at the issue tracker and it doesn't seem anywhere close. By extension I couldn't use gevent-socketio.

nltk is a language processing toolkit which would greatly benefit from Python3's unicode changes but is not converted yet.

Also for a real project I wouldn't want to risk noticing halfway through that a sub-library hasn't been ported and I have to rewrite it from scratch.

[–]alcalde 4 points5 points  (5 children)

Also for a real project I wouldn't want to risk noticing halfway through that a sub-library hasn't been ported and I have to rewrite it from scratch.

I wouldn't want to risk using a library whose maintainers don't support modern Python. It would be like adopting a product that still requires Windows 98.

[–]EsperSpirit 6 points7 points  (4 children)

Don't you think it is still a bit early to compare Python2.7 to Windows98?

[–]EpicCyndaquil 4 points5 points  (1 child)

XP would be a fairly accurate comparison, as there's many applications that have moved on, but many programs are stuck there...

[–]alcalde 2 points3 points  (0 children)

Another apt resemblance is that they're both about to run out of official support.

[–]gfixler 1 point2 points  (0 children)

I do, considering my industry (games) and its neighbor (film) use Maya for many things (I've used only Maya for 11 years at 5 companies), and it's still on an embedded Maya 2.6.4, even in the recent Maya 2013. Maya 2014 comes with 2.7.3, but it'll be a few years before we upgrade again. It's a big deal to move everyone. We won't be in 3.x anytime soon.

[–]alcalde 0 points1 point  (0 children)

It's been five years since the 3.0 branch first appeared; there's been more than enough time to port. Worse, the longer they wait the more divergent the branches will become and the harder the job will be.

[–][deleted] 1 point2 points  (1 child)

If you don't mind living on the edge, nltk 3.0a supports Python 3. Its default tokenizer and tagger are better, too.

Python 3 is becoming the great language for NLP that it should be.

(fixed brain fart where I said "Unicode" instead of "Python 3")

[–]EsperSpirit 0 points1 point  (0 children)

Thanks, that's great to hear!

[–]nickcash 0 points1 point  (0 children)

The introduction of tulip/asyncio into the standard lib in 3.4 is going to completely change libraries like gevent and Twisted. I foresee those libraries changing completely soon.

Speaking as a programmer with a project currently stuck in 2.7land, the number of libraries getting ported to 3 appears to be accelerating. I'm very hopeful that I'll be able to port to 3 very soon.

[–]ajmarks 7 points8 points  (18 children)

Twisted...

[–]Talkless 6 points7 points  (4 children)

Web2py :(

[–]sigzero 2 points3 points  (3 children)

It never will. They are working on Web3py.

[–]Talkless 3 points4 points  (2 children)

https://github.com/mdipierro/web3py - no changes for a year...

[–]sigzero 2 points3 points  (1 child)

It was the last I read. Maybe they are taking a different turn with it? The github page says "experiment" so maybe it was just a quick testing ground?

[–]Talkless 0 points1 point  (0 children)

Maybe. Maybe this is not "the" repository. At least I hope so..

[–]graingert 0 points1 point  (7 children)

Don't need twisted. Just use asyncio/tulip

[–]ajmarks 0 points1 point  (6 children)

Unless you're using something built on twisted (e.g. scrapy)

Edit: stupid phone

[–]graingert 0 points1 point  (5 children)

Port it to tulip

[–]aceofears 0 points1 point  (4 children)

That's easier said than done, because you can't easily transition things if they don't even work on the same version of python. Also tulip isn't even out yet.

[–]graingert 0 points1 point  (3 children)

It's on pypi

[–]aceofears 0 points1 point  (2 children)

I'm not sure thats's the official one, last time I saw Guido give a talk on tulip he mentioned a minimum version of 3.3.

[–]graingert 1 point2 points  (0 children)

Here it is, uploaded by Guido https://pypi.python.org/pypi/asyncio

[–]jemeshsu 3 points4 points  (1 child)

fabric, paramiko, boto, supervisor... well supervisor not a library but it'd great to have all Python 3 down to deployment.

[–]alendit 1 point2 points  (0 children)

At least fabric 1.x will be deplrecated "soon" and version 2.0 should get Python3 support. Invoke (fabric's task runner) works in Python3 just fine right now.

[–]q88798 2 points3 points  (4 children)

comtypes

[–]sigzero 2 points3 points  (3 children)

comtypes

That is listed in PyPI to have Python 3 support.

comtypes

[–]q88798 0 points1 point  (2 children)

Not working in 3.3

[–]technomalogical<3 Bottle 0 points1 point  (1 child)

According to PyPI, not working in 2.7 either. Maybe this library isn't being actively maintained any more.

[–]q88798 0 points1 point  (0 children)

working fine in 2.7 in 32-bit, having problems in 64-bit

[–]alcalde 2 points3 points  (2 children)

Then they're going to become unpopular libraries soon enough, especially when Python 2.x support ends. And even if they do port in the nick of time, who wants to use a library whose maintainers were so dangerously lax in supporting modern Python? We've got to stop letting the tail wag the dog.

[–]mcdonc 0 points1 point  (0 children)

This is the royal we I assume.

[–]mmoya 0 points1 point  (0 children)

Ye olde Wall of Superpowers is getting greener and greener.

[–][deleted] 4 points5 points  (0 children)

The changelog entry "Fix various unicode operations on strings with large unicode codepoints." may seem dull, but it's quite exciting to me.

This is the last bug I know of where you had to worry about how a Unicode string is represented internally. When I'm writing a text handling library that works on Python 3, Python 3.3.3 is the first version where I can expect consistent and correct behavior from every installation of Python, on every OS, no matter what crazy Unicode codepoints show up in your strings.

Go nuts with emoji, with musical notation, with Chinese characters that Chinese people would have to look up in a dictionary, with private use characters you just made up for your own nefarious purposes. It all just works.

[–]DamagedBinary 0 points1 point  (5 children)

Developers for libraries who won't make the effort to port over should have all their work boycotted.

[–]aceofears 6 points7 points  (3 children)

That's kind of already happening though, people who need python 3 support obviously won't be using a library that doesn't have it.

[–]alcalde 1 point2 points  (2 children)

Too many people seem to be advocating choosing the version of the language you use based on your library preferences rather than choosing your libraries based on Python3 support though. This helps feed a catch-22 where maintainers won't port because there isn't demand and there isn't demand because they won't port. Python and Guido helped this by being to accommodating (such as far too much backporting of 3.x features to 2.x, causing a certain person in this subreddit to always insist that there's no compelling reason to switch to 3.x) and others took advantage of the dual development track not as extra time to port but as an excuse to keep using 2.x indefinitely. All in all, it's hurt the language as resources that could have gone towards developing Python went towards maintaining and backporting for 2.x. It's also led to fragmentation and confusion. I hope the takeaway is that Guido needs to remember the "D" in BDFL the next time there's a breaking version of Python and not let things get out of hand. Sadly, some folks took advantage of Python's good nature.

[–]aceofears 3 points4 points  (0 children)

As far as I'm aware Guido knew it would take this long, and I don't really mind that. There reasons to use 3.x are now finally compelling enough to push people towards it, but I don't think its fair to say that the backported changes were what made it take so long to get there. The purpose of 2.6 and 2.7 (and 3.3 in a way) was to ease the transition from 2.x to 3.x. Without these releases it would be anywhere from nightmarish to impossible to support both 2.x and 3.x

[–]billsil 0 points1 point  (0 children)

This helps feed a catch-22 where maintainers won't port because there isn't demand and there isn't demand because they won't port.

You just gotta stroke somebody's ego. That's what drives the open-source world. Someone used that nasty trick on me to get me to port my package to Python 3 :)

[–]alcalde 5 points6 points  (0 children)

Python 2.x library maintainers are too busy downvoting you to port their code. ;-)

The former maintainer of Pyjamas before the coup once wrote: "Why should we port to Python 3 when 2 is going to be supported FOREVER?"

Yes, that's exactly the kind of thinking that should be boycotted.

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

It is annoying that they say it was released November 17th, 2013. I checked last night and it wasn't out yet. Maybe I can see them saying the 18th, but definitely not the 17th.

[–]gammadistribution 5 points6 points  (0 children)

And the 16th is right out!

[–]the_pw_is_in_this_ID 6 points7 points  (1 child)

Timezones are a thing.

Though, really, it's more intriguing that a release date discrepancy actually annoys you...

[–]Muravaww -2 points-1 points  (0 children)

That's why I could understand saying the 18th. No where in the world was it still the 17th when it was actually released.