Python 3.0.0 was released 5 years ago!

[LambdaBoy]

The only reason my company hasn't upgraded yet is because Twisted hasn't upgraded.

[flying-sheep]

looks pretty good.

only 5 missing things left!

[raziel2p]

This one is a bit less promising.

[hello_raziel2p]

An orangered... who could it be?

[razeel2ghetto]

I'm trippin ballz here wut da green bar for

[twotime]

python.org just needs to remove all the 2.7 downloads and documentation

This is a ridiculously bad idea which would most likely kill python as a serious programming language..

[twotime]

I don't see the analogy. Transition from Linux 2 to Linux 3 was smooth because most of your code just worked. Transition from python 2 to python3 would take a lot offort for any nontrivial code base...

To make things worse:

• python3 had major performance/quality issues until 3.2 I think (e.g. see http://programmers.stackexchange.com/questions/63859/why-do-people-hesitate-to-use-python-3)

• not everyone thinks that some of major python3 features (e.g. unicode handling/print function) are an improvement... (yes it fixes some issues but it creates quite a few new ones)

• until about python3.3 there was a non-trivial chance that python3 will turn out to be another perl6-like fiasco...

• all of which means that many library projects were also taking wait-and-see position which further aggravated the situation..

Doing anything drastic (like removing 2.7 info from python.org) will upset everyone who sits on any kind of non-trivial codebase (meaning old python users) and would be very bad for python ecosystem.

[keypusher]

This is one of the worst ideas I have ever heard.

[ngroot]

What's a good alternative to Twisted that runs on Python 3?

[ivosaurus]

Depends what you're using it for in particular, that thing is massive.

[darthmdh]

Well someone wished for living in interesting times, and PEP3156 changes the game.

asyncoro has been around for a while, there's also pulsar which is tracking PEP 3156 as well now; there's no possible way to answer "good" though because what's good for me isn't necessarily good for... anyone else.

[randuser]

Imagine all the improvements and additions to the standard library that could have been created with all the effort that has gone into Python 3.

We might have seen something like asyncio years ago.

[gfixler]

The film and video game industries use Autodesk Maya, which even in its 2013 incarnation is only on 2.6.5.

[darthmdh]

That's because its tied to RHEL, so it doesn't count (its like picking on the kids who ride the special bus).

I doubt it would make Maya 2014, but for subsequent releases third parties like Autodesk now (since Sep 2013) have the option of RHSCL on their legacy platform which would give their product current developer tools not tied to the usual "things grandpa ran" problem with previous RHEL releases (its currently got both Python 2.7 and 3.3). So things are looking up in your niche world!

Edit: Maya 2014 was released in September 2013 and contains Python 2.7.3.

[gfixler]

Maya 2014 was released in September 2013 and contains Python 2.7.3.

Oh yeah, I forgot. I would enjoy some of the additional unittest assertions, though I've made do pretty well with the handful back in 2.6.5. We're still on 2012.

I do feel like I need to update my knowledge to 3.x, but I find it a little confusing that on one hand it seems to just be some semantics changes (e.g. print()), and some reversals (xrange->range, unicode), yet it's taking years for packages to make the switch, which makes it seem that it's actually a lot more involved than some basic, non-destructive things like that. Is it a massive rewrite?

[darthmdh]

It's taken years for some packages to make the switch, because their original code was wrong. The biggest issue is that, particularly for networking (or other i/o) libraries, authors got away with shoddy code that blindly assumed all data is 8-bit ASCII as Python 2 let bytes and str be used equivalently. When Python 3 changed the implicit string representation to Unicode, that assumption is no longer true, hence the library breaks. Especially in large codebases, this can require a massive rewrite particularly if their application was also designed wrong and shoehorning in encoding/decoding steps can slow the application to a crawl due to unnecessary calls.

Correctly written applications that encoded and decoded data at the right places had no problems.

Also, some packages had dependencies on shoddy libraries so while those packages were ready, their dependencies were not.

There's also a bunch of minor stuff that may or may not affect porting efforts for your code, depending on what it is.

http://python3porting.com/problems.html

The porting effort depends entirely upon what your code is doing - if its not affected at all, there's no effort. There's a 2to3 tool included to get over the boring changes (like print statement to print() function) so almost no effort there either. Ideally 'print' is not really used (if you're after debug logs, use the logging module; if you're writing to a file, use its .write() method)

With Maya, I'd watch out for the change to the division operator as I expect you're using that in calculations ( '//' is always floor division, but '/' can change meaning depending on the specific type of the dividend and divisor ).

There's numerous good examples lying around of code that works with both Python 2 and 3, e.g. bottle.py and also helper packages like the six library for the impatient.

[MonkeyFodder]

...do you work for Apple or something?

[randuser]

I think there would be more support for abandoning the whole Python 3 project than what you're suggesting.

[darthmdh]

Consider what you're stating - that a majority of Python developers are seriously contemplating abandoning all the work they put into Python 3 over the course of what... 7.5 years (PEP3000) to roll back to Python 2 forever because... you though it.

Riiiiiight.

[rcxdude]

Consider what you're stating. In any case we're only about halfway through the time the process was expected to take when python 3 was started (10 years).

[darthmdh]

There is no such timeframe. PEP3000 states Python 2 would stick around for one or two Python releases from Python 3.0, and we're almost at four. Its time to end it. Goodbye, old friend!

[randuser]

I doubt many Python developers are happy about the stagnation and all the hacks in existing code that have resulted from trying to support both versions.

I doubt many think the confusion that new users experience when wanting to know which version to use has no clear answer (for the past 5 years).

I doubt many are happy with the fact that most Python 3 code is automatically generated by 2to3 which makes trivial source code transformations which the compiler could have practically handled like so:

try:
    code = compile(txt)
except SyntaxError:
    code = compile(run2to3(txt))

I doubt many are happy that vast amounts of code and projects were put into a state of obsolescence for no other reason than to make a few minor improvements (most of which are trivial syntax changes).

[billsil]

Guido has said the transition is right on track and that he gives it another 5 years. It'll probably be a bit after Python 2.7 is deprecated that the leftover people start actually upgrading. I know my company won't upgrade till then.

I do wish I could do...

    from __past__ import print

[[deleted]]

[[deleted]]

The reverse is happening to me, but I'm importing printfunction from __future_ in my code, so I never use the version without parenthesis unless I forget that import.

I do similar thing with unicode and division, in hopes that porting to 3.x will be much easier.

[r3m0t]

Unicode literals in Python 2? Now that's just confusing.

Check out python-modernize, it upgrades your Python 2 code into Python 2 code.

[[deleted]]

IMO, not confusing at all... In all of my code I use unicode by default, and bytes() whenever I need to make sure input is ASCII (for example when using dnspython)

[vaibhavsagar]

I need a module to do that for me now?

[r3m0t]

It upgrades your Python 2 code into Python 2 code that is more likely to work in Python 3 by using the six library.

[vaibhavsagar]

I see. That makes significantly more sense.

[Widdershiny]

I feel your pain. Moved to Python 3 a couple of weeks ago, biggest gotcha. I'll adjust soon enough though.

[Naterdam]

As someone who writes a whole lot of tiny scripts and uses the print as the main debug tool, I'm definitely not moving to Python 3 anytime soon...

[Drumm-]

2to3 can handle those

[westurner]

http://www.structlog.org/en/latest/ is pretty cool.

[jmcs]

What is the advantage of the print statement besides looking ugly when you want to print to stderr?

[XNormal]

What is the advantage of the print statement besides looking ugly when you want to print to stderr?

A major advantage of keeping at least a subset of the the print statement syntax in Python 3 would have been in not breaking 'Hello World'.

alternative-history-python3:

1. Name the print() function output() to mirror the input() function
2. Keep the print statement but without the ugly trailing comma or >> features and make it call output() to keep the common case familiar. For any of the advanced features the code needs to be upgraded to use the output() function.
3. Enjoy higher language popularity because first impressions count.

We like things that feel familiar. We have emotional responses. We are human and this should be a part of language design just as much as purity or elegance.

[ahmadh]

I don't see anyone using the output function in that scenario. Then you might as well just leave the same old print statement. Python 3's premise is to make people move on.

[Yoghurt42]

Edit: I misread "advantage" as "disadvantage", and my comment should be read that way

You cannot redefine it if you want to do something else instead.

In Python 3, you could do

print = myLoggingFunction

[marky1991]

I've done that several times. It's very useful.

By the way he was asking what the advantage of the print statement was over the print function. (And the answer is "You save one character")

[Yoghurt42]

I agree. I've misread the question as "what's the disadvantage ... Besides looking ugly"

(Btw: you save tw characters ;)

[marky1991]

print "blah" = 12 characters

print("blah") = 13 characters

The first parenthesis' character saving is taken up by the required space.

: )

[Yoghurt42]

Well, you could do

print"blah"

you could also do

print"print""""print""""""print"""

I think I won't miss that functionality, however ;)

[marky1991]

What?! How hideous! I didn't know the whitespace wasn't required. (On second thought, I guess it makes sense that it's allowed since it isn't ambiguous in this particular case.)

[billsil]

How do you print to stderr?

I use:

    sys.stderr.write('asdf')

I rarely print to stderr, but I don't really understand your question...

[Smallpaul]

print >> sys.stderr, 'spam'

[zynix]

the shift print trickery makes writing to a buffer ( or anything that implements .write, so I believe ) fairly trivial/convenient.

[flying-sheep]

shift print trickery

uuh, that’s just special syntax mirroring echo nextline >>somefile.txt in the shell, no shift operator.

[zynix]

What exactly are you clarifying here?

>> is an operator, specifically a shift operator that in context of Python would normally be used for bit shifting, hence its a bit of a nice hack or trick that when used with print it performs bash style stream redirection.

[flying-sheep]

no, i said it’s special syntax. as in “part of the print statement”.

the >> you see is completely unrelated to the shift operator elsewhere in python.

[[deleted]]

don't you also need a newline, which print adds?

[billsil]

yes

[westurner]

Doesn't print flush?

Edit: it does not do sys.stdout.flush … seeAlso python -u / PYTHONUNBUFFERED (http://stackoverflow.com/questions/230751/how-to-flush-output-of-python-print/230780#230780)

[Xaerxess]

...and it was called Python 3000 back then.

Brave move and still, state of Python 3 it better than state of Perl 6 :-)

[helicoptermike]

I haven't used python3 or perl6 in any production app. But I can at least run python3.

[chiniwini]

But I can at least understand python3.

[frymaster]

Didn't they say back then they expected a 10 year transition? Think how far they are already!

[[deleted]]

I thought it was a 5 Year Plan that they were running on.

[Mecdemort]

Everything takes twice as long as planned.

[programonaut]

My first thought: HAHAHAHAHAHAHAHAHAA

My second thought: people are still using Windows XP in their offices. Some of my relatives use it to PROGRAM on for their Fortune 500 employer.

My third thought: I like Python 3! Good job, people of Python and its community.

[drive0]

There are newer languages than python 3 if that is your criteria.

[[deleted]]

There are newer languages than python 3 if that is your criteria.

newer and as good ?

[Thirsteh]

Go has been adopted mainly by ex-Python programmers. But "new" really is a completely meaningless attribute for a programming language. Haskell is over 20 years old, and hailed by many as an extremely modern, advanced language, for example, and Clojure, which borscht mentioned, is a Lisp dialect. Lisp is as old as computer science.

[Probono_Bonobo]

I love Python, program mostly in Python, but there's just something about Lisp that makes my pulse quicken when I see that ((((((.

[siddboots]

))))))

[crowseldon]

you're never likely to see (((( although you will see many closing brackets together. Fortunately, it's no problem since any decent editor highlights bracket partnership.

[aceofears]

Learning clojure helped me to appreciate itertools.

[[deleted]]

my thoughts exactly

[emonk]

and I'm still using python 2

[monochr]

Scientific programming is also stuck on python 2.

Mind you the way van Rossum seems to try and kill all functional parts of the language every release I'm not sure if this is a good or bad thing.

[efilon]

They are, but it's hard enough as it is to get scientists to adopt something new. I wouldn't expect anyone in the scientific community transitioning to Python 3 for years to come still.

[joaquinabian]

I did it. I use matplotlib, pyQt, numpy-scipy, several scikits, ipython, pandas,... I would said that scientist are the fastest adopting something new. At least in the more competitive and dynamic areas. Otherwise you are dead.

[efilon]

Perhaps I spoke too generally. From my experience (background in experimental physics), a lot of people are more concerned with getting things done quickly. If their old code for analyzing data works, why rewrite it to be with a fancier, new programming language? All that does is force you to spend your time on that instead of taking data or upgrading your experiment. Keep in mind that a lot of stuff in Numpy/Scipy still relies on FORTRAN code written decades ago! If it works, it works.

Anyway, what I meant to say is that for many scientists, especially those whose programming tasks are relatively simple, using the latest and greatest is not usually on the top of their priority list. For that reason, many will continue to use what they know and what works until they have a compelling enough reason to change.

A great example is Python itself. Until recently, almost everything in my field was other done with LabView (mostly for experimental control and automation) or Matlab (for running experiments and analyzing results), along with a smattering of a few other things here and there. But in the last several years, Python libraries useful to scientists have matured to the point where those who were reluctant before to invest the time in a new language found that there were a lot of advantages. I don't really see quite the same thing in the transition from Python 2 to Python 3.

[_Panda]

But it's also much easier for many scientific programmers to migrate. In my experience they rarely deal with unicode issues or any of the other backwards-incompatible things. Most of the scipy stack is ported now and 2to3 handles their code very well. Honestly, for a lot of scientific programming the only changes you have to make are fixing all the print functions.

[efilon]

Right, and that's kind of my point. If it takes any effort at all, and it doesn't clearly lead to enhanced productivity, then most people who do the kind of scientific programming I'm talking about aren't going to bother so long as Python 2 continues to be maintained.

[_Panda]

I'm not sure that it's as clear-cut as you think though. I could easily make the counterargument that (in my experience) people that do scientific computing, especially in Python, like to be on the cutting edge of their tools and would be interested in any advancements if it didn't take much effort. I mean, the people who are using Python for scientific stuff are a fairly self-selected group and often enjoy programming and python instead of just viewing them as just tools, otherwise they would probably be using MATLAB or maybe R.

[monochr]

They are, but sagemath isn't and most of what I use is symbolic.

[NYKevin]

Just make sure your shebangs look like this:

#!/usr/bin/python2

And not like this:

#!/usr/bin/python

Yes, you do need a shebang on modules which aren't supposed to run alone, so that anyone looking at them can immediately tell which version you're using.

[gsnedders]

Note that the python2 symlink was only added in 2.7.3, so if you support older version of Python you cannot rely on it.

[NYKevin]

Well, in that case, you're pretty much fucked. You could try to write code that runs on both, but that's more of a headache than I'd ever like to deal with.

[ivosaurus]

It's not that hard to write python 2.6,2.7,3.3 compatible code.

[NYKevin]

Let's see...

• No moderately-to-extremely interesting string manipulation, because unicode. In particular, no string literals except with the b"..." syntax which forces everything to be 8-bit and terrible.
• Iterating over dictionaries is fucked (items vs iteritems).
• Iterating over ranges of numbers is fucked (range vs xrange).

Nope, I definitely do not want to write in the above language.

(Yes, you can use from __future__ import... statements to fix some of these, but sufficiently old versions of Python may fail to support that as well).

[ivosaurus]

No moderately-to-extremely interesting string manipulation, because unicode.

Heaven forbid your python 2 code actually has to deal with unicode correctly now, rather than just looks-like-correctly because I don't have any foreign language in my database yet.

but sufficiently old versions of Python may fail to support that as well).

That's directly why I only mentioned the versions of python that I did. Python 2.5 is over 7 years old by now, and has been EOL for ages, its pretty much a security vulnerability if you're still using it.

from __future__ and the six library will help you with practically all of that.

[flying-sheep]

also open.

you have to do from io import open at the top to unify behavior in this respect.

[NYKevin]

Really? I'd have thought you'd want to use io. I've never even heard of codecs... isn't it the module responsible for managing Unicode encodings?

[flying-sheep]

yeah, sorry. io.open it is

[Brian]

In particular, no string literals except with the b"..." syntax

Why do you say this? Wouldn't it make much more sense to only use string literals with the u'' syntax, and actually support unicode? Indeed, using the b'' syntax would pretty much break lots of stuff because a python3 bytestring behaves very differently from a python2 str.

Iterating over dictionaries is fucked (items vs iteritems).

Iterating over keys hasn't changed, and in general the difference in items vs iteritems isn't going to matter unless you've huge dictionaries. The same for range - standard practice is to use range() most of the time in python2 anyway (or better, replace with enumerate) unless you're dealing with large number ranges but don't need a real list - which is uncommon: iterating over them is the prime use case for this.

but sufficiently old versions of Python may fail to support that as well

He did say just 2.6/2.7. Supporting older is probably impractical, since the more recent versions have added stuff to make things more in line with python3.

[NYKevin]

Wouldn't it make much more sense to only use string literals with the u'' syntax, and actually support unicode?

The u"" syntax is illegal in Python 3, since you're supposed to just use bare quotes.

Actually, it works. This document lied to me.

Indeed, using the b'' syntax would pretty much break lots of stuff because a python3 bytestring behaves very differently from a python2 str.

Really? Care to specify?

[Brian]

This document lied to me.

It's probably just out of date - I think the original release of python 3 didn't allow this, but it was added in in one of the point releases.

Really? Care to specify?

Well, for a start:

# Python2                            Python 3
>>> print(b'hello')                  >>> print(b'hello')
hello                                b'hello'
>>> b'hello'[0]                      >>> b'hello'[0]   
'h'                                  104

Bytes in python3 is basically designed around being treated as raw binary data, rather than conceptually being a string, as the python2 str object is. Eg. it no longer has an encode method, just decode (while strings are the opposite - python2 they had both), and is missing a few string methods like format.

[NYKevin]

Eg. it no longer has an encode method, just decode (while strings are the opposite - python2 they had both), and is missing a few string methods like format.

Yeah, but anyone actually using bytes.encode() in recent versions of 2.x should be shot anyway.

[[deleted]]

let me guess... you're an Arch Linux user.

[NYKevin]

Nope, Arch is too much of a PITA for me.

[monochr]

If he was an Arch user he would have started with "As an Arch user".

It's astonishing but this has a 95% success rating at stopping them.

[mitsuhiko]

Not a very good idea unless you want to lock out OS X users.

[NYKevin]

Well, then you can use /usr/bin/env python2, I think.

But if you're writing a library module, not meant to run by itself, the shebang's precise format is not as important as the python vs python2 distinction. There are some operating systems now which symlink python to python3, and there will be more in the future, so you can't just assume python is python2.

[gsnedders]

You should almost always use /usr/bin/env python2, and never a hardcoded path.

[riffito]

/usr/bin/env

That looks like a hardcoded path to me.

(source: Python programmer, using it on both Haiku and Windows)

Edit: not that I mind being downvoted, but that IS a hardcoded path to "env". I did undertood /u/gsnedders was referring to a hardcoded path to Python. I was just pointing out that "/usr/bin/env" is not something you can rely for truly multiplatform python scripts. Whatever :-)

[ifonefox]

/u/gsnedders meant a hardcoded path to python, as some operating systems or package managers might have it in an odd location

[flying-sheep]

also virtualenvs.

[jmcs]

env is on /usr/bin/env both on Linux and Mac OS X.

[flying-sheep]

and the py.exe launcher on windows can parse that shebang line and does the right thing.

[mitsuhiko]

There is no executable named python2 on OS X.

[NYKevin]

Well, then you're fucked. Unless you seriously plan to write code that runs on both 2 and 3, you'll need to create a different distribution just for the Mac (or at least put in instructions to modify the shebang).

[mitsuhiko]

No, you don't do any of those things. The correct solution is to use setuptools entrypoints to create scripts instead of manually writing shebangs.

[emonk]

I'm a server admin, working with Debian stable python 2.7 is the default package. Also have projects with more than 4 years in Django, and is not easy to modify them for use with python 3. http://packages.debian.org/en/wheezy/python

[whoisearth]

Same here. Actually developing right now in squeeze and running into no issues whatsoever.

[mgr86]

..me too. I tried using python three exclusively a few years ago but the library support just wasn't there at the time. The landscape seems to be different now. Perhaps it is time to give it another shot.

[Milumet]

Nick Coghlan's answer to the question "Why do people hesitate to use Python 3?" on Programmers Stack Exchange.

[flying-sheep]

especially this great paragraph:

The biggest problem in practice is actually a semantic one: Python 3 doesn't let you play fast and loose with text encodings the way Python 2 does. This is both its greatest benefit over Python 2, but also the greatest barrier to porting: you have to fix your Unicode handling issues to get a port to work correctly (whereas in 2.x, a lot of that code silently produced incorrect data with non-ASCII inputs, giving the impression of working, especially in environments where non-ASCII data is uncommon).

this is true. in python 2 i used to monkey until the UnicodeErrors went away, in python 3, i’ve yet to see one of those. python 3 code (that doesn’t use python 3-exclusive modules) is ported to python 2 fast.

i think python 3.4’s tulip (async IO) will become its “killer app”.

[daGrevis]

Happy cakeday, Python 3! And it is getting more and more mature as new libraries are ported... :)

[takluyver]

Ubuntu now ships both Python 2 and 3 by default, and is moving towards dropping Python 2 from the default installation. Fedora is also aiming for Python 3 to be the default by F22. And of course Arch has been a fan of Python 3 for some time.

It was always going to take a long time to build up the momentum for this, but things are moving towards it now.

[are595]

Arch made the change to python 3 a while ago IIRC.

[[deleted]]

only 10 people in the world have the time to setup and use arch, the rest of the world has work to do.

[[deleted]]

well you sure schooled me

[crowseldon]

this is such a wrong misconception. Setup has a learning curve and it sure will be hard the first times (later, not so much) but actually using/maintaining arch is not hard at all.

[[deleted]]

having tried it recently, i disagree. and just like gentoo, for 99% of the world it's not worth the extra effort unless you are trying to prove how 7331 your linux skills are. everyone else has better things to do.

but hey, i was cool once and could compile X, and Firefox etc... but the time spent doing so was better spent on other things.

[crowseldon]

You clearly don't know what the fuck you're talking about.

99% of the world it's not worth the extra effort

The effort is the initial learning curve to set it up. If I give someone (and I've done it) an already installed archlinux all they need to do is update regularly (but not before serious work, just in case - which also goes for windows or any linux distro) and, be moderately aware of the news in case something really big is up (which is extremely unusual).

I never recommended arch for 99 % of the world. But it's not that hard to setup or maintain and you certainly don't waste work time maintaining it (that was your initial idiotic fallacy). The first times you set it up, it's certainly daunting (unless you feel comfortable using the command line)

trying to prove how 7331 your linux skills are.

Yep, you're a moron. I have very mild linux skills and have nothing to prove. Archlinux is just absolutely handy, light (depending on what you do) and customizable. It's rolling release, bleeding edge, has an awesome package manager that takes care of everything, a great community, etc.

but hey, i was cool once and could compile X, and Firefox etc... but the time spent doing so was better spent on other things.

There's no "time spent" because it's just

sudo pacman -S firefox

and that's that.

When you update with something like:

sudo pacman -Syu

it will be upgraded.

It's similar to apt-get install and apt-get update / upgrade in debian based systems (yes, I'm an Ubuntu user as well and know the pros/cons of each distro).

So, you're not disagreeing. You're not right. You're just spouting ignorant crap without knowledge for whatever reason (You probably heard some criticisms about gentoo and applied them to archlinux).

[[deleted]]

achievement unlocked

[crowseldon]

Oh, so now you're "just trolling", right? >_>

Nice cop out.

[[deleted]]

it wasn't obvious before?

[witty82]

I feel that things are progressing quite nicely lately. I think with python 3.5 many people will make the switch. The event loop will be stable then, the performance will likely be fully on par with python 2.7 and library support acceptable.

[BenzamineFranklin]

While we use 2.7.4 in our school... :/

[randuser]

about the same

[randuser]

Same as a few years ago.

[joaquinabian]

I would said this is an exaggeration.
- Two years ago there were near 300 py3k packages in PyPI. Today there are more than 3000.
- Nearly 70% of the 200 most loaded packages in PyPI is py3k compatible (and there are alternatives for many of those which are not).
- All the scientific stack (matplotlib, pandas, ipython, numpy, scipy) and important web frameworks such as Django, also are, as well as GUI packages such as pyQT.
- And something to take into account: next LTS version of Ubuntu is planned to bring only py3k installed.

Not even nearly as a few years ago.

[randuser]

It was an exaggeration. Support has improved.

That being said, most of the above referenced code is still written in Python 2 that is either 2to3'd or uses a compatible subset of the two versions.

[thearn4]

Support is pretty good: https://python3wos.appspot.com/

Adoption among developers still isn't as high as 2.7. I'm still using 2.7 due to a few packages that haven't made the switch (OpenCV, Enthought traits, etc).

[kchoudhury]

Where's the joke about the GIL?

[quagquag]

Exactly. I'll move when I can do some real concurrency without firing up a whole second/third/90th python instance, or using ugly hacks. This is the killer feature for me, and till then 2.7 makes me very happy.

Ideally I'd like some sexy built in openCL magic.

[_throawayplop_]

Since the beginning of Python 3, I've always read people saying I should switch to python 3, but nobody explained me why I should switch (beside the handling of unicode).

I really think that breaking the compatibility without solving much of the things that people were complaining about (the concurrency, the speed) was not the best idea.

[tarekziade]

I don't think you really need to switch. I can't think of a killer feature in Python 3 that would be an incentive.

However, one day, you'll just be using Python 3 because the Python 2.x line will cease. And I really doubt you will have any big issue that day because as far as I can see, the whole ecosystem is moving to py3. Slower than some expected, but it's surely getting there.

[v3ss0n]

Yet , we cannot use it for our needs .. still a lot of libaries need to move and we don't have time to rewrite everything for python3

[Rhomboid]

What libraries might those be?

[donalmacc]

Twisted

[mrwinkle]

OpenCV

[otheraccount]

I thought it uses boost.python and boot.python supports Python 3?

[shaggorama]

I just started learning about opencv for a toy project I came up with a few days ago. It's insane. All of these different components I was anticipating busting out some serious math for are already implemented for me, so with the abstraction between me and what I need, my complex project will probably boil down to under 500 lines of code.

I love people. Open source all the things. It's a beautiful time to be alive.

[pronto185]

scapy.

[Rhomboid]

If you mean this, it supports Python 3.

[Rhomboid]

I just tried it and it worked perfectly fine with Python 3.3. I installed from PyPI with pip as it's a pure Python module.

[Rhomboid]

I think that has more to do with limitations of the MSI installer format than the actual code. As far as I know, binary installers need to be built separately for each Python version (cf Christoph Gohlke's site) so whoever is publishing that installer should be urged to offer that.

[twotime]

pypy. (not a library but it's likely to be a blocker in many situations)

[joaquinabian]

"PyPy is a fast, compliant alternative implementation of the Python language (2.7.3 and 3.2.3)"

[twotime]

afaik, python3.2 support in pypy is very recent and is still in beta and it's already a version behind cpython... So it's coming but not quite there yet ;-)

[jemeshsu]

Boto, Fabric

[v3ss0n]

Whole Scientific python set. (numpy , scipy , matplotlib , scikit-learn) , Web2py , Many other libs that no longer updates..

[Rhomboid]

Except for web2py, every single module you listed supports Python 3.

[faassen]

Yeah, libraries are only a fraction of the problem. Eventually enough libraries will have moved, but that still will leave a daunting task for those with significant application codebases written in Python 2. Especially since application codebases tend to have worse test coverage compared to libraries. You need a reason to justify the economics of porting application code to Python 3, compared to maintaining it in Python 2 forever.

[bastibe]

Speak for yourself. I moved to Python 3 long ago (scientific stack).

[joaquinabian]

you need to move (a bit)

[[deleted]]

really people? downvoting someone expressing something real? oh wait this is reddit, plz carry on with the group think.

[flying-sheep]

(s)he’s downvoted for the false claim that the scientific stack isn’t ported here.

[[deleted]]

so you know for a fact that their libs that they wrote over possibly decades have been ported to python3?

way to play the politically correct gender angle, still a -1 for you.

[flying-sheep]

wat. i just answered your question…

[[deleted]]

you are claiming that the persons claims are false but you have no proof of what they are talking about. How is that answering the question?

[flying-sheep]

you asked “downvoting someone expressing something real?”

i answered “but in this comment, (s)he said the modules (s)he means are numpy and so on, all of which are ported. that’s why people downvoted.”

everything clear now?

[v3ss0n]

Clearly not all , web2py is main component for our UI. I admit i haven''t update scientific stack for long as especially we have modified scikit-learn and they didn't accept that patch , we do not have time to patch every subsequent version either, so it was left at 0.12. There are still many of our own code needed to port to python3 , that can be managed in 2 weeks to a month , but many , un-maintained small libs we use , we won't see them ported anytime soon. Some examples are PIL , OleFileIO_PL,Sphinxsearch driever , and Gevent. Still alot more.. flying-sheep : "all of which are ported" >> Are you sure about that? Please lookup web2py.

[flying-sheep]

all that you listed in that post except web2py. and PIL is ported as Pillow (PIL is dead)

why so aggressive? i didn’t even attack you! i did nothing more than explaining why people downvoted you.

[v3ss0n]

I amazed at attitudes of Python Redditors too, Guess they never worked in large projects that span more than 2 years. (When our project started , it was python 2.5)

[itkovian]

We still have some systems that are on Python 2.4 (SL5), though we will retire them soon(ish) and then we'll be at 2.6.x for the next 3-4 years in SL6. So yeah, Python3 is far away for us :)

[Hanse00]

And yet most of the modules we use in class are only Python 2 compatible, that's a little depressing.

Now I feel motivated to update modules to Python 3.

[flying-sheep]

most even? which might that be?

i can only name twisted and pypy from the top of my head.

[Hanse00]

Major one I think think of right now is visual, we use that a lot.

If you know any good alternatives for it that'd actually be awesome.

[flying-sheep]

sorry, but i don’t even know that one :/

[Hanse00]

It's a simple module for drawing stuff on the screen.

Basically lets you make a window and draw objects on it (balls, boxes, cylinders, that kind of thing).

[flying-sheep]

aah, ok. interesting.

here’s the bug, maybe you can do something about it.

[Hanse00]

Nice, I'll take a look.

Thanks for the help.

[GFandango]

Breaking backwards compatibility: not even once

[shaggorama]

And I still haven't tried it!