

Ask HN:  Anyone using  Python 3 in production? - iamelgringo

I'd love to make the switch over to Python 3 before I get tons of code written on my startup.  Anyone using it in production?
======
justin_vanw
Nobody is switching to Python 3. If you go first you get all of the pain and
no advantages (plus switching later isn't very hard anwyay). I would import
unicode_literals, division, and the print() function from __future__ and stick
with 2.6.

~~~
endtime
What are the benefits of print()?

~~~
samdk
It has optional arguments which make certain things a lot easier and make it
much more consistent with the rest of the language.

 _sep_ is the separator between arguments, so you can do something like:

    
    
        >> print('a','b','c',sep='')
        abc
    

_end_ is the value at the end of the line (useful, for example, if you want to
print without a newline at the end).

 _file_ lets you specify a file to print to, so for example you can do
_file=sys.stderr_ to print to stderr instead of stdout.

~~~
gometro33
Being part of __future__, is print() slated for release in 2.7 or is it
strictly a 3.x feature?

~~~
timf
In 2.7, print is still the print statement by default:

<http://docs.python.org/2.7/library/functions.html#print>

------
jnoller
We in python-dev land have been working on discussing various help documents
and things associated with the website. For now, if you have lots of 2.x
dependencies - use 2.x - it's stable and well supported by the community.

If you're doing greenfield development, and don't plan on lots of external
dependencies, use 3. Personally, if I didn't have dependencies on a few
"really big" external libraries, I _would_ be running 3 in production.

This wiki page - a work in progress - should help you if you're thinking about
switching.

<http://wiki.python.org/moin/Python2orPython3>

------
pilif
We are running a web service (just the API no front end) written in Python 3
for a tiny bit less than one year.

Even under considerable load, the traditional Apache/mod_wsgi combination
never failed (though we had some encoding issues during development).

The reason to go p3 was for one the new string handling, which I personally
find absolutely beautiful and the idea of future proofing the application. We
are a small shop and certainly don't have the resources to rewrite the thing
in 3 years when all the cool stuff is happening in python 3 land.

This was also the reason to start development of another application in PHP5
just when 5.0.0 came out. There it paid off, though with p3 I'm not quite
sure. It looks as if we are stuck with 2.x maybe forever.

------
surething
The big holdback for my outfit is the lack of NumPy support.

~~~
jnoller
This is coming this year, as far as I have been told.

~~~
cdavid
it is kind of there if you use the trunk, actually

------
tonetheman
We are not switching anytime soon. I have not looked at what they did to the
syntax (hopefully nothing). There is really no advantage for us and most
likely it will break things.

If are starting from scratch it might be OK. I guess it depends on your needs
for library support.

IMO it was a bad idea to split development like they did. But I am just a user
and not in charge. :)

If it was me I would pick 2.6

~~~
For_Iconoclasm
The syntax changed in some areas. For example, the print statement no longer
exists; there is a print function to replace it.

------
pquerna
We aren't running Python 3 yet -- we are using Python 2.6.

The most impressive things that might push us to upgrade are the new VMs like
unladen swallow or PyPy, assuming they don't get backported support for 2.7ish
style python.

But right now, most libraries are made for 2.x only, and there isn't yet a
large enough performance or memory use gap to force us to take the porting
hit.

~~~
sapphirecat
Unladen swallow is still based on the 2.x series:
[http://code.google.com/p/unladen-
swallow/source/browse/trunk...](http://code.google.com/p/unladen-
swallow/source/browse/trunk/Include/patchlevel.h)

What I'm writing today to distribute is targeted at 2.x, where x>=5. If I
didn't want to distribute it, I'd be using 2.6 and writing as close to 3.x as
it allows.

~~~
sfk
<http://www.python.org/dev/peps/pep-3146/>

<http://svn.python.org/view/python/branches/py3k-jit/>

------
Daishiman
No Django support, no Python 3.

~~~
barnaby
Ditto. I do mostly Django development, so I'm tied to 2.6 for the moment, but
I'll upgrade the second that I can.

Also, Ubuntu ships with 2.6 and I'm too lazy to switch

------
nailer
There's no great benefit for the pain. The really cool work in the language -
new GIL-removal work, PyPy, pip and virtualenv, etc aren't yet included in
Python 3.

When I make the jump, it will probably be to the inevitable 3.5 or 4.0 that
includes all the juicy stuff.

~~~
jnoller
Why on earth would PyPy be included? If GIL-Removal, PyPy, pip and virtualenv
being included is your "must have" list, you're going to be waiting long after
everyone else has moved onward :)

For me, it's simply "I just need my dependencies" - which is a simple
statement, but an incredibly hard problem.

~~~
cdavid
I think the problem is that python 3 is just different, without much
improvements over 2 for many people. For example, the things which IMO were
worth fixing at backward incompatibility price (like the import system,
improved C API with ABI across minor versions, packaging) were not fixed.

I have (in small parts) contributed to the python 3 conversion for
numpy/scipy, and the only reason why I have done so is to be a good "python
citizen", and because numpy is a major library in the python ecosystem. But I
don't see any advantage in doing so. The cost is high, and the advantages near
inexistent for me

~~~
jnoller
You see - the reason your hit list of itches were not fixed were because no
one stepped in to do them - this isn't anyones fault, but it doesn't mean
important things were not fixed. Instead, the other itches (such as bytes vs.
strings/unicode) were fixed.

Function annotations, the standard library cleanup, and other things came
along for the really big ride, which was the bytes/unicode/etc ride. So,
there's lots of improvements that came with 3.0 - but the nice thing is is
that it continues to evolve.

We now have a New (more rational) GIL, we're probably going to have a futures
package (<http://www.python.org/dev/peps/pep-3148/>) and so on (heck, python3
is also getting a jit). And things will continue to be added. Everyone knows
and admits that the transition will take years, but now with 2.x being "done"
(meaning, no more releases past 2.7) and more great work being done in 3.x,
hopefully people in general will start to see the benefits.

