Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Anyone using Python 3 in production?
44 points by iamelgringo on June 26, 2010 | hide | past | web | favorite | 28 comments
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?



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.


What are the benefits of print()?


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.


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.


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


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

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


Strictly 3.0, because of backwards compatibility.


  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)


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


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.


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


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


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


No Django support, no Python 3.


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


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


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


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.


Unladen swallow is still based on the 2.x series: 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.



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.


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.


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


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.


Personally I don't know anyone who's running on 3.0 yet - so I think it will be a while before I get left behind.


And that was always the plan. 3.0 adoption was supposed to take several years. So it's all good - the big thing which needs to occur before most people will is some of the big libs need to port over.


I also have the sneaking suspicion some of the cool VM work will end up being there around the same time (that said, I really like the Queue and Thread objects in 2.6 for most purposes, despite all the complaints people make about the GIL).


Eh, by "cool VM work" sure - if you mean unladen-swallows JIT. Anything else has a year+ lag time for inclusion to be seriously considered.

Also, the funny thing with the GIL (even as the maintainer of multiprocessing) is that it's never bothered me. I've used hundreds of threads working with Queues/etc all the time. I actually don't use multiprocessing as much as I use plain old python threads.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: