6 ms·

Ask HN: Anyone using Python 3 in production?

44 points by iamelgringo 16y ago

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 16y ago
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 16y ago
  What are the benefits of print()?
  - samdk 16y ago
    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 16y ago
      Being part of __future__, is print() slated for release in 2.7 or is it strictly a 3.x feature?
      - algorias 16y ago
        Strictly 3.0, because of backwards compatibility.
      - timf 16y ago
        In 2.7, print is still the print statement by default: http://docs.python.org/2.7/library/functions.html#print http://docs.python.org/2.7/library/functions.html#print
    - algorias 16y ago
      All that is just syntactic sugar. print "comma prevents a newline from being printed", print >> sys.stderr, "Any file object can be used" The change to a function is purely for consistency, not functionality.
  - babo 16y ago
    from __future__ import print_function map(print, [1,2,3]) def test(*a, **b): print(*a, **b) test(12) with open('t.out', 'w') as f: test(12,13, sep='--', file=f)
surething 16y ago
The big holdback for my outfit is the lack of NumPy support.
- jnoller 16y ago
  This is coming this year, as far as I have been told.
  - cdavid 16y ago
    it is kind of there if you use the trunk, actually
pquerna 16y ago
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 16y ago
  Unladen swallow is still based on the 2.x series: http://code.google.com/p/unladen-swallow/source/browse/trunk/Include/patchlevel.h http://code.google.com/p/unladen-swallow/source/browse/trunk... 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 16y ago
    http://www.python.org/dev/peps/pep-3146/ http://www.python.org/dev/peps/pep-3146/ http://svn.python.org/view/python/branches/py3k-jit/ http://svn.python.org/view/python/branches/py3k-jit/
kennethreitz 16y ago
No.
kennethreitz 16y ago
No.
tonetheman 16y ago
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 16y ago
  The syntax changed in some areas. For example, the print statement no longer exists; there is a print function to replace it.
Daishiman 16y ago
No Django support, no Python 3.
- barnaby 16y ago
  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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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/ 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.
jnoller 16y ago
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 http://wiki.python.org/moin/Python2orPython3
pilif 16y ago
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.

44 points by iamelgringo 16y ago

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 16y ago

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 16y ago
What are the benefits of print()?
- samdk 16y ago
  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 16y ago
    Being part of __future__, is print() slated for release in 2.7 or is it strictly a 3.x feature?
    - algorias 16y ago
      Strictly 3.0, because of backwards compatibility.
    - timf 16y ago
      In 2.7, print is still the print statement by default: http://docs.python.org/2.7/library/functions.html#print http://docs.python.org/2.7/library/functions.html#print
  - algorias 16y ago
    All that is just syntactic sugar. print "comma prevents a newline from being printed", print >> sys.stderr, "Any file object can be used" The change to a function is purely for consistency, not functionality.
- babo 16y ago
  from __future__ import print_function map(print, [1,2,3]) def test(*a, **b): print(*a, **b) test(12) with open('t.out', 'w') as f: test(12,13, sep='--', file=f)

surething 16y ago

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

jnoller 16y ago
This is coming this year, as far as I have been told.
- cdavid 16y ago
  it is kind of there if you use the trunk, actually

pquerna 16y ago

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 16y ago
Unladen swallow is still based on the 2.x series: http://code.google.com/p/unladen-swallow/source/browse/trunk/Include/patchlevel.h http://code.google.com/p/unladen-swallow/source/browse/trunk... 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 16y ago
  http://www.python.org/dev/peps/pep-3146/ http://www.python.org/dev/peps/pep-3146/ http://svn.python.org/view/python/branches/py3k-jit/ http://svn.python.org/view/python/branches/py3k-jit/

kennethreitz 16y ago

No.

kennethreitz 16y ago

No.

tonetheman 16y ago

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 16y ago
The syntax changed in some areas. For example, the print statement no longer exists; there is a print function to replace it.

Daishiman 16y ago

No Django support, no Python 3.

barnaby 16y ago
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 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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/ 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.

jnoller 16y ago

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 http://wiki.python.org/moin/Python2orPython3

pilif 16y ago

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.