I'm having the exact same experience! I just started using Python 3.4 (soon 3.5) for a new, major project and I'm pretty excited about it. I expected to find a bunch of roadblocks -- like being in a parallel universe or something. But, well, everything totally works!

The only package I found that didn't work with our Python 3 infrastructure was Fabric, but that's really easy to spin out (and will be fixed soon).

There's really no reason to not use Python 3 for (almost) all new projects at this point. It's exciting! I expect engineers who're used to developing in Python 3 will start to feel embarrassed that they're still running 2, and we'll port over all of those internal codebases (like at Dropbox :P).

How did you replace Fabric? I've hacked things together with some branches of Fabric + devs that just about work on Python 3, but it's not really satisfactory.

I replaced it with Ansible when I was doing a 2 to 3 transition about a year ago. It wasn't easy, but learning a real infrastructure automation tool (which Fabric is not) was worth it.

I thought Ansible wasn't ported to Python 3 [0] and actually had a lot of weird bugs when I last tried to use it. It is one of the few reasons I keep Python 2 installed on my laptop.

[0]: http://docs.ansible.com/ansible/faq.html#how-do-i-handle-pyt...

yes, but what ansible uses in the backend is easy to forget, as you never actually have any contact to python in your yml files.

You rarely have straight dependencies on fabric from your app though. Personally I simply treat it as a command line tool, and `pip install` it system wide. It just happened to have been written in Python 2, and to require script files written in Python 2, but it's orthogonal to the apps/scripts I write with Python 3. Maybe your use case is different.

When I switched to Python 3, I used Invoke to replace Fabric. The main developer of Fabric is working on Invoke as the replacement for Fabric.

Moved a rather big, produciton running, project (100000 LOC) recently. Was not easy but now I've this very warm, conforting feeling, that if something happens in the future, I'll be ready for it :-) (now considering the adoption rate of P3, I'd say the future is, well, rather distant :-))

For me unicode was the reason to switch to 3, not everybody lives in an english-only world :-)

"""When starting a new project from scratch, I see no reason NOT to use python 3. Maybe if a few libs you depend heavily on are still not ported."""

wxPython comes to mind... :-/ Also PyGame, although it seems that there are now development releases for 3.x.

wxPython largely[1] supports Python 3.

PyGame has worked on Python 3 for ages. Looking at [2] suggests it's from at least since the start of 2012.

[1]: http://wxpython.org/Phoenix/docs/html/classic_vs_phoenix.htm...

[2]: https://aur.archlinux.org/packages/python-pygame-hg/

Pygame supports Python 3 in development releases. If you try to grab releases from their site they're something like 6 years old.

There are efforts being made to port Pygame as you mention but there's also the option of not using Pygame. I've written small games and OpenGL demos using PySDL2 and PyOpenGL in Python 3. It works rather well.

Project Phoenix (http://wiki.wxpython.org/ProjectPhoenix) seems promising. Have you tried it or do you know its status?

IIRC, I recall finding a post claiming it was stable enough for production use. Another post I found just now[1] suggests I am probably on the right lines.

[1]: http://comments.gmane.org/gmane.comp.python.wxpython/103221

Twisted too: https://twistedmatrix.com/trac/milestone/Python-3.x

Twisted and wxPython are a great combo and will keep me on 2.7 as long as they are not ported.

Isn't twisted largely superseded by asyncio?

https://docs.python.org/3/library/asyncio.html

I had to build a simple LDAP proxy recently, looked at twisted and asyncio and went with asyncio/python3. For that use-case, it was a perfect choice.

It's 2015 and you still rely on wxPython? You probably have bigger problems than the 3.x transition.

Which cross-platform native desktop GUI toolkit would you recommend instead?

I assume he's referring to Qt.

PyQT is GPL3+commercial.

PySide is Qt4.

GKT3 looks ugly outside Linux.

Tk looks obsolete everywhere.

wxPython is Python 2 and I think GTK2 on Linux.

Basically, there is no usable, modern cross-platform GUI toolkit for Python right now.

PyQt is very much usable. It's GPL3 but if you're using it in commercial projects, you shouldn't just pinch your nose because you have to get a commercial license.

Besides, PySide is porting to Qt5 too.

I'm not sure I'd pinch my nose over the cost of PyQt, but the cost of PyQt is pretty negligible.

The problem is the cost of Qt itself for commercial development - unless I'm misreading the Qt website I might choke and drown on the cost of a developer license for Qt ("1x Qt for Application Development ($350/Interval)") and (" This subscription is automatically invoiced at 1 months Intervals").

Maybe it's badly-written English confusing me, but that (and other info on their site) sounds suspiciously like "Developing commercially for Qt and being able to do maintenance releases requires a $350/month developer license." Oh, and their licensing FAQ specifically says that you CANNOT start on the LGPL version and change to the commercial license without prior permission from them.

Maybe it's just me, but if I'm going to be expected to spend $4200/year/developer (or "contact us" for a perpetual agreement), maybe I'd be better off spending a little money first checking out the other alternatives.

> PyQt is very much usable. It's GPL3 but if you're using it in commercial projects, you shouldn't just pinch your nose because you have to get a commercial license.

But I do and thousands of other people do as well. Today, the value-add is somewhere else, not in language bindings for GUI toolkits.

No offense to whatever it is you work on, but if you are a commercial project and:

- Can't comply with GPL3 and make your code compatible with the license

- Can't afford to pay for a commercial license

- Can't use a different language, such as C++, which has alternate offers

Then the problem is on your side, because either your business model is wrong or you're simply being cheap. You're not entitled to a free GUI toolkit for no good reason.

The measure is value for money.

For 350 GBP (=500 EUR), you can have Intellij Idea.

When you ask your boss for a budget for Nx500 (N=number of developers), it is a huge difference, if you ask that for language bindings for GUI toolkit, or IDE.

The language and GUI toolkits are both free, the glue between them is not, and that damages them both. How many commercial PyQt apps have you seen in the wild?

Exactly.

Imagine, if someone asked money for XAML for C#... or for JavaFX. What it would do with their adaptation in projects?

> How many commercial PyQt apps have you seen in the wild?

Not many because most people use Qt, not PyQt. It's just easier.

> Besides, PySide is porting to Qt5 too.

Is there any kind of concrete roadmap on this? All I've heard was basically "yeah, we want to move to Qt5 at some point in the future" back in 2013.

Yeah, activity picked up a week or two ago; someone has done most of the legwork to get the bindings auto-generated, and now there's the clean up to do.

That's very nice to hear. I was seriously beginning to fear that PySide was dead in the water.

I'd love to have a decent GUI toolkit for Python I could use with Apache or MIT code (without having to isolate the GPL bits), but I was nervous about being stuck on Qt4, so I was never terribly sure about PySide.

I assumed he was just trolling.

I can think of one reason for using Python 2 -- if you are creating a project that you want to share with others, there are a lot of enterprise systems that are still on Python 2.x. I've had the experience a number of times of finding a program that seems to do exactly what I want, but I can't deploy it on my production servers because they are all running RHEL 6 with Python 2.6.

Of course, it is possible to install multiple versions side-by-side, and edit the scripts so they all start with #!/usr/local/bin/python3 or something like that, but it is just another barrier of entry. Not to mention that then there are most likely a bunch of additional modules that have to be tracked down to get something to work.

(Actually, come to think of it, this really isn't a python specific issue, this is really a general plea that if you are making something that is geared toward sysadmins, make sure that there is an easy enough installation method available for at least the currently supported versions of RHEL/Centos, Ubuntu LTS, and Suse Enterprise).

The implication that you cannot use Python 3 "if you are creating a project that you want to share with others" is false. Python 3 code is routinely shared and used.

There are a lot of enterprise systems that are still on COBOL, but that wouldn't make it any less ridiculous to say that you can't use Python if you are creating a project that you want to share with others.

Knock yourself out: https://www.softwarecollections.org/en/scls/rhscl/rh-python3...

That's a really poor argument.

In addition to what others said, if you write code for python 3 making it compatible with python2.7 is relatively painless task (from my own experience) due to Python 2.7 having py3 functionality back ported.

Regarding python 2.6 this was discontinued back in 2013, as far as I know all redhat versions that used 2.6 are no longer supported unless you're paying for extended support. So I'm not convinced it is a good excuse.

Also if you use Java for example and you want to use JDK7 or JDK8 it doesn't matter that RH distro uses old version you'll find a proper RPM (or build one) to use it.

RHEL 6 uses python 2.6, and is supported till 2020 (not counting the extended support). Of course, if an app only needs a single host or two, its no problem to have an updated OS for that app. But certain app types, such as backup and monitoring apps, don't do any good unless they run on the majority of systems that a site has. In my case, I couldn't even try out several popular backup systems, as they either required Python 3, or had other library requirements that weren't available on the older enterprise systems.

Same here. It really wasn't that long ago that I was sticking with Python 2 and recommending to my managers that new projects be started with Python 2. (Yes, I know, I was part of the problem)

These days, I have few reservations about starting new projects with Python 3. It has become my new default.

I still use python 2 because I'm not the best programmer and most stack overflow answers are python 2 based (although more and more are for both now-a-days). I wouldn't be opposed to using python 3, but see no real reason to do so.

Man I hate this argument so much.

People make it look like those are two completely different languages, even though there are actually very minor differences. You'll realize it once you'll start using python 3. Also py3 is much easier to master for a novice because it is much more consistent and no longer has some special cases.

For example if you're dividing a number you no longer need to convert one variable to be float in order to get a decimal. There is no int and long types, just int etc.

That's valid, but I don't think there are many questions that don't apply to both languages. I'd bet most times you will just have to change range() and print(). The difference in the two versions isn't too extreme!

Can you give me an example of when you used async in Python? I haven't seen a good one. Thanks!