12 ms·

Python 3 in 2016

184 points by jaxondu 11y ago

andrewstuart 11y ago
The PyPi download statistics are constantly being quoted as though the are some exact representation of the state of Python 3 takeup. I'm calling this as bullshit. How much of these downloads are computers auto updating their configurations? How, exactly, do these stats reflect the number of people developing current projects with Python 3? The number of legacy projects written in Python 2 will be vastly higher than the number of Python3 projects currently in development. Maybe that's what is being updated. When a statistician does an analysis of what these numbers really mean I will believe them but until then the numbers mean precisely nothing. Or more accurately, they seem to mean exactly what the Python 2 diehards want them to believe. My assertion is that Python 3 is very actively and healthy and the PyPi stats are just lies, damn lies and statistics.
- creshal 11y ago
  I get my python 2 and 3 dependencies from distribution packages (Arch, Debian), and so do all people using my software. PyPi impact: Zero.
- hynek 11y ago
  Hmm I’m not sure how to take this comment. The main point of the article is basically that those numbers don’t tell the whole story (even explicitly in footnote 1).
  - andrewstuart 11y ago
    Your post gives the stats some level of credit when really they tell absolutely nothing, or more precisely they tell a tale that is so open to interpretation as to mean nothing at all. There's no gloom around Python 3. Lots of people support it. The highest ever upvoted post on Reddit/r/Python was a post asking to remove training material that asserts that Python 3 is irrelevant. https://www.reddit.com/r/Python/top/ https://www.reddit.com/r/Python/top/ There must be alot of people who feel positively about Python 3 to vote it up that high, presumably at the same time that the Python 2 diehards are voting the post down. The appropriate message regarding the PyPi stats is not to give gentle credence to them but to condemn them as a completely irrelevant measure of the success or otherwise of Python 3.
    - hynek 11y ago
      Hm that’s unfortunate that it comes out that way. I thought I’m just acknowledging that people are agonizing over them and then explain why’s not a good metric.
      - mkesper 11y ago
        Footnotes are not very explicit, nobody reads the small print.
- DasIch 11y ago
  Somehow Python 3 projects don't require updates? PyPI stats are going to be massively inflated due to Continous Integration and such but I don't see why that would tip the scales in one direction or the other by any significant amount.
  - hynek 11y ago
    The newer a pip, the more likely it is that it caches things for example. There a more things, I had long discussions with dstufft about it in the past.
hathym 11y ago
can we please stop writing articles in twitter? https://twitter.com/hynek/status/699928792752594944 https://twitter.com/hynek/status/699928792752594944
amstocker 11y ago
I think this is a nice healthy view to have about Python 2 to 3. Can't wait until python 4!
- EvanPlaice 11y ago
  I seriously doubt 4 will include breaking changes, at least not to the semantics/syntax of the language itself. What python really needs in 4 is better unified package management and distribution support. They have a lot to learn from the Javascript and Ruby evosystems.
  - crdoconnor 11y ago
    >They have a lot to learn from the Javascript and Ruby evosystems. Such as? I really hope I'm not going to start needing 1,200 dependencies to build a simple app like I would in node.
    - EvanPlaice 11y ago
      Support for local, per-project installs without hacks like virtualenv. Per-project configurations to map things like external dependencies and project info. Setup.py + MANIFEST is not the answer. Better suport of versioned deps so multiple versions of the same dep 'just works' when its neessary. Better package publishing for library maintainers. Have you ever published a pckage to PYPI? It's a huge pain. Support for Markdown-based documentation on PYPI. ReStructuredText is cool and all but MD os the defacto standard Standard support for direct install from GitHub without weird hacks. Pick one unified standard and deprecate the rest. The current 3, distutils, distutils2 and setup.py all suck. Write some halfway decent docs on how to publish packages. I spend more time on Stack Overflow that the python docs every time I publish a package. Dependencies are used so heavily in the JS/Ruby ecosystem because it's extremely easy to publish a package and the package manager 'just works'.
      - crdoconnor 11y ago
        * Virtualenv isn't a hack. * Setup.py/MANIFEST.in seems like a pretty clear answer to me. * I've worked with python for about 10 years and only once have I come across two packages that required conflicting versions that I wanted to deploy in the same environment. * Yes, I do it pretty frequently. * "MD os the defacto standard" Huh? According to whom? ReST is fine. * "Standard support for direct install from GitHub without weird hacks." - stick "git+https://github.com/yourname/yourpackage" https://github.com/yourname/yourpackage" in your requirements.txt and off you go. * Yeah, they should really standardize on pip, but this is relatively minor. * Use one of the templates. * Yes, I hear somebody even published a package that checked if a number was negative. And it had a bug.
osullivj 11y ago
I code in both 2 & 3, and had been nervous about that. New stuff with low dependencies in 3, and older stuff with Python C API dependencies in 2 (eg spreadserve.com). I was worried that the move to 3 would force migration of my 2 based code, so I'm reassured rather than alarmed by this article. The cognitive load switching between two Python dialects isn't as bad as, for instance, switching between C++ with and without STL & Boost.
zzleeper 11y ago
I tried switching to 3 a few years ago and was burned by some libraries that didn't work or worked with bugs. Last year though I tried again and there were absolutely no problems. It's more natural, all non-dead libraries seem to support it, and in any case I was already using "from future import" for a while. That said, I don't really intend to port old stuff from 2.7 if I can avoid it, so I expect that 2 and 3 will coexist for a while even within the same firm
- hynek 11y ago
  That’s exactly the place I found myself in and that made me sum it up.
gloves 11y ago
Been thinking about learning to code, and a lot of people have recommended Python as a good language to begin with. Taking a look at this, should I be looking elsewhere?
- orf 11y ago
  Python is an excellent language to begin with, you're reading this article wrong if it puts you off Python. There is drama around Python 2 or Python 3, but the answer is clear. Use Python 3 for new projects, use Python 2 when you have to (legacy projects).
- agumonkey 11y ago
  It has nice features: - not large syntax - expressive overloaded keywords (in) - slice syntax that is easy on mind and eyes - nice set of builtin structure: lists, sets, dicts - with literals for all of them [], {}, {:} - lambda, generators, context (cute yet general way to ensure releasing resources, files, connections..) But as all languages, you can lose yourself, learn and write shitty code in it. Find idioms, https://duckduckgo.com/?q=raymond+hettinger+python&ia=videos https://duckduckgo.com/?q=raymond+hettinger+python&ia=videos <- hettinger likes to makes python code small and solid ps: I don't like it's oop syntax sometimes That said, I never learned so much about one language than by learning another one. All paradigms have at least one gem to discover.
- hodwik 11y ago
  If you decide to learn Python, I'd suggest going through the Learn Python the Hard Way book. It's excellent.
  - hodwik 11y ago
    Weirdest downvotes I've ever gotten.
baq 11y ago
Python 3 is worth it not for asyncio and unicode (though these are very good reasons if you care about them). It's worth it due to 21st century exception handling, which breaks down in Python 2 in a spectacular fashion the moment you raise in your except: clauses.
- hynek 11y ago
  Ah yeah the small nice things. `raise from`, `__traceback__` on all raised exceptions (instead of dicking with `sys.exc_info`), `nonlocal`, `super` …
wiz21c 11y ago
Since everyone gives anecdotal proofs that Python 3 is just fine, I'll give mine as well. I've migrated to Python3 a rather big project (for the unicode handling) and although it was not quite easy, it'just fine now. I'm active in Qt, web, json, sql domains and I've never needed a library that is Python 2 only. Thus from my own point of view, the Python 3 ecosystem is just complete now. Super.
- EvanPlaice 11y ago
  I think the biggest barrier to adoption right now is OS support. OSX still comes bundled with python2. There's no indication that Apple is working on a transition to 3. Ubuntu is actively working on the transition but the current LTS release (ie the one companies/enterprise will use) is still locked onto python2. The same can likely be said for other flavors of *nix. From a user's perspective, python3 has been ready for 'prime time' for a while. From an OS, systems, enterprise perspective python3 still is still a ways out.
  - emmelaich 11y ago
    I suspect that many Pythoners will install Python3 (with homebrew) or other on OSX (and whatever other platforms still come with just Python2)
    - hynek 11y ago
      I would recommend to even use pyenv (https://github.com/yyuu/pyenv https://github.com/yyuu/pyenv) that will allow you to install any Python version in your home directory (i.e. not fucking up your system installation). If you maintain many FOSS libs like I do, together with tox it's priceless.
      - obelisk_ 11y ago
        Homebrew installs software into /usr/local last time I checked so unless you are doing something really strange like manually overwriting system files, you'll be hard pressed to fuck up the whole system. Personally I'd install homebrew into /opt/homebrew.
srathi 11y ago
We are using Python LDAP library[1] at work, but it is not available for Python 3 yet. Is there an alternative? 1 https://pypi.python.org/pypi/python-ldap/ https://pypi.python.org/pypi/python-ldap/
- hynek 11y ago
  Yes! RedHat needed it too and forked the project: https://pypi.python.org/pypi/pyldap https://pypi.python.org/pypi/pyldap
- thristian 11y ago
  ldap3 is not API-compatible with python-ldap, but it's pure-Python (it doesn't need the OpenLDAP libraries installed) and you might find its API is a bit nicer to use: https://pypi.python.org/pypi/ldap3 https://pypi.python.org/pypi/ldap3
- perlgeek 11y ago
  I can second the recommendation for ldap3. It's very well-engineered, well-documented, works with python 2 and 3, and has (if I remember correctly) zero dependencies.
paulhallett 11y ago
We've been using Python 3 since we implemented a new service architecture and it's been an easy transition for our 50+ engineers.
deleted 11y ago
[deleted]
ivoras 11y ago
Since it's basically all anecdotal, I'll say my gazing-into-the-crystal-ball educated-guess feeling that Python 4 will make the entirety of Python about as popular as Perl is today if: it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3. The developers have dug themselves into this mess with frivolous differences ("print" a function, wanting to remove the "%" string operator, etc.), instead of spending the years on more productive features, now is the chance to dig themselves out again. It's a beautiful language, too bad the development choices were a bit sketchy.
- orf 11y ago
  Comments like this are so misguided and yet so common on HN. Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons. Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. Python 4 will just be the next release after Python 3.9.
  - ivoras 11y ago
    It may very well never happen, that's a completely possible outcome. We'll see what it does to Python's popularity.
  - bhaak 11y ago
    > Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. > > Python 4 will just be the next release after Python 3.9. Really? Why even change the major version then, when there are no breaking changes? Given that many Python programmers seem to be traumatized by the last major version switch, why even bother? Or is this just for setting up Python 5 can have breaking changes if the switch to 4 is painless?
    - orf 11y ago
      > Really? Why even change the major version then, when there are no breaking changes? Python releases don't follow semver. If Linus can bump the kernel to 4.0 because he felt like it so can Python.
retrogradeorbit 11y ago
I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that would be fine. But when it comes to new projects, I struggle to find a compelling reason to use Python at all, when there are so many amazing languages now to choose from. With a new project you could choose Scala, Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less popular ones like Haxe and Dart. I've even been playing around with Elm. And I'm sure I've missed a bunch of others too. So the question for me, for new projects is: why choose Python 3 (over all the other non python options) at all? Not what's better about Python 3 than Python 2, but what's better about Python 3 than those other choices. These other choices all have certain areas where they have great strengths. What is Python 3's strength when compared to these other languages? It's a mutable, imperative, single CPU bound language that can't target the browser and is extremely difficult to distribute and deploy. Or have these issues been fixed? I don't mean to troll any Python fanboys. I use Python 2 every single day at work and I'm very happy with it. But what does Python 3 offer that other new languages don't? Because when you are starting a new project you can choose anything. Why should I choose Python 3 for my new projects?
- Odin78 11y ago
  Noob question: What's so difficult about deploying/distributing python?
  - hynek 11y ago
    ATM it takes work to create a deployable artifact. We package virtualenvs using fpm, others use Docker. But Go just spits out a single binary you can scp anywhere (the build process OTOH is more painful IMHO). That’s why I’m highly curious about https://us.pycon.org/2016/schedule/presentation/2122/ https://us.pycon.org/2016/schedule/presentation/2122/ .
  - retrogradeorbit 11y ago
    https://glyph.twistedmatrix.com/2015/09/software-you-can-use.html https://glyph.twistedmatrix.com/2015/09/software-you-can-use...
vegabook 11y ago
Three is (finally) likely to win, if only because of the constant nagging of the project leaders, and the fact that some distros will now move to it by default. But it will be a pyrrhic victory because it will have been a force-feed, not an enthusiastic, willing, adoption by the community. As a result of this mess, while Python's inertia is huge, its momentum is slowing. Its leadership, having lost credibility, cannot really lead effectively anymore. It will continue to be a massive, unavoidable language, but something of the magic of when I first learned it, has been snuffed out.
- hynek 11y ago
  That’s only true for people who are part of the community for a long time. Newcomers don’t understand what the fuss is about and why anyone would want to use Python 2. My own Python bubble is more like what you described (although the mood is improving IMHO) but talking to newcomers is eye opening.
  - deleted 11y ago
    [deleted]
emmelaich 11y ago
It's quite possible that someone will come up with a good enough automatic 2->3 converter which alleviate the situation.
- Spiritus 11y ago
  2to3 (comes bundled with Python) will do some of the work for you.
- ProblemFactory 11y ago
  There are converters, and it's not too difficult to even write code that runs in both Python 2 and 3. The main roadblock in upgrades is unicode text vs bytes handling. Python2 was lax about using bytes for text. You could do unicode and bytes properly if you really tried hard enough, but it took a conscious effort. So most people just used bytes for text, and hoped for the best (if the data is ASCII or UTF-8, it will work most of the time). Python3 is strict about the text vs bytes separation. Patching this into a program afterwards is a lot of work. But if your Python2 program already does unicode carefully in Python2 (unicode type internally everywhere, from __future__ import unicode_literals, explicit encode/decode when talking to external APIs), then you are 90% done with the upgrade to Python3.
- icebraining 11y ago
  python-modernize[1] tries to automatically make your codebase compatible with both Python 2 and 3, using 2to3 and six[2] underneath. I haven't tried it yet, though. [1] https://github.com/mitsuhiko/python-modernize https://github.com/mitsuhiko/python-modernize [2] https://pypi.python.org/pypi/six https://pypi.python.org/pypi/six
  - brettcannon 11y ago
    Armin handed over development and now Modernize is actively developed at https://github.com/python-modernize/python-modernize https://github.com/python-modernize/python-modernize
    - icebraining 11y ago
moistgorilla 11y ago
This is the ultimate HN circlejerk comment >Scala, Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less popular ones like Haxe and Dart Are you kidding me? Did you just list the languages you see threads on HN about? Scala and Go I could maybe understand if you needed the performance but the rest of the choices are just bad. Especially if you are trying to start a business instead of a functional programming bootcamp. Also there is nothing inherently more difficult about deploying and distributing python compared to any of the languages you chose.
- StavrosK 11y ago
  Eh, okay, Go is much easier to deploy because it's a single binary (also the same with Dart), but yeah, the rest of the comment makes no sense. Seriously? Dart? Not even Rust?
- dang 11y ago
  Please don't be rude in HN comments. We detached this subthread from https://news.ycombinator.com/item?id=11124822 https://news.ycombinator.com/item?id=11124822 and marked it off-topic.
libeclipse 11y ago
I started off python learning python 3, but a few months into it, I was forced do a project in python 2. It was a turning point, I immediately ported over all my python projects to python 2. To me, it just seemed more simple, elegant, and cleaner. It was the more pythonic version of python. And if I'm still working with python after 2020, I'll be using python 2.
- hepta 11y ago
  I don't understand this, what is more "pythonic" about 2?
  - hueving 11y ago
    Not typing 'encode' or 'decode' when dealing with strings. I know it sounds stupid, but it's really distracting compared to everything else in python that just flows easily.
    - mkesper 11y ago
      Then you're doing it wrong. Sorry but that's definitely better solved in Python3 than in 2. Always decode/encode when opening a file/stream/whatever and only use unicode internally.
    - Yaggo 11y ago
      Sounds like you are shooting yourself in the foot. Your code may work with ASCII but will immediately break in non-naïve cases.
angvp 11y ago
Not going to happen IMO, yet no advantages to do the transition.
- mrweasel 11y ago
  The Unicode support alone justify transitioning for us.
mangeletti 11y ago
For anyone hesitant because they're worried they will need to support 2.x installations at some point, there is 3to2[1]. You can write for 3.5 only, and then back port only if you need to. 1. https://pypi.python.org/pypi/3to2/1.1.1 https://pypi.python.org/pypi/3to2/1.1.1
czep 11y ago
I, for one, must admit to having almost completely ignored Python 3 until very recently. One thing I discovered that is way awesomer than you can imagine is Unicode handling: it just works! I'd say Unicode was a tricky issue in 50% of Python projects I've worked on in the past, but with Python 3, none of that matters anymore.
deleted 11y ago
[deleted]
dethos 11y ago
Unless it is explicitly necessary to use python 2 (like legacy stuff, that hasn't been upgraded yet), I've been using python 3 solely for almost 2 years, and there is no turning back. I have no reason to stick with the old version. The last piece that needs to change, to complete the transition, is the majority of OS makers to bundle python3 by default.
- collyw 11y ago
  I would be as well, but many jobs out there involve existing code on python 2.
draw_down 11y ago
The problem is not Python 3, the problem is keeping both languages in my head at the same time. I'm tired of caring whether "print" is supposed to be a function or not, I just want to print something.
- orpheansodality 11y ago
  Why not just always use print() as a function? That's only a single mental change, and works in both 2 and 3.
  - witty_username 11y ago
    print isn't a function (even though print("hello") works) in Python 2. But you can use __future__ to make it a function.
Walkman 11y ago
In practice: inheriting from "object" every time is not a big deal, but losing the possibility to use Pypy or Kivy is huge.
- MollyR 11y ago
  This is my problem as well. I love using Kivy instead of tkinter, and Pypy.
fideloper 11y ago
Python3 is still broken in some important ways (virtual environments) on Debian/Ubuntu, which make it a but of a pain to use both in development and production. Example: Ubuntu 14.04 (and later versions) come with Python 3.4, but pyvenv is unavailable (just try searching ubuntu 14.04 pyvenv to get an idea). This bug from 2014 is still relevant, although at least the "python3.4-venv" package is available to patch it enough to get going. https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847?comments=all https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/129...
cdnsteve 11y ago
On the web framework side of things, who is using aiohttp (web) and something like API-Hour? Seems like the performance is really great. Python 3 asyncio. It's hard to find people blogging about it, not sure why? It seems like a great combination. http://blog.gmludo.eu/2015/02/macro-benchmark-with-django-flask-and-asyncio.html http://blog.gmludo.eu/2015/02/macro-benchmark-with-django-fl...
agentgt 11y ago
I used to write a lot of personal Python scripts (ie ~/bin). I mainly did this because I seem to always screw up bash scripts and just can't remember all the conditional flags ie ([[-z ]] and error handling with bash for me has always been tricky. However in the last couple of years I have dropped Python in favor of Groovy in part because I know the JVM and its plethora of libraries so well. Groovy is a highly underrated language. Really my only complaint is the startup time is not nearly as fast as Python but it does seem faster than say Clojure scripts. Also one of the things that I have to say I sort of think Java got right is that it has always been backward compatible (I know this was sort of impossible with Python given its not really a byte code language). That is I really don't have to worry if I write Groovy in a pre Java 5 (ie without generics) where as with Python I wasn't sure if I should write new scripts in 3 or 2. The other annoying thing albeit far less than Ruby is dependencies with Python. Groovy has a complete bad ass way of just declaring dependencies in a script (@Grab) and they will automatically be downloaded. I have yet to see a scripting language that does this (ie dependency install on demand). BTW since apparently any time I mention Java-like-tech on any HN post I seem to get downvoted... I really really love Python. This was not to denigrate Python or that Groovy is better than Python.
- vorg 11y ago
  > I really don't have to worry if I write Groovy in a pre Java 5 (ie without generics) Groovy has many incompatible changes between versions, esp from 1.8 to 2.0 but also 1.7 to 1.8, 1.6 to 1.7, etc. Many sites provide Groovy 1.8 as the default because no-one there wants to bother with upgrading.
  - agentgt 11y ago
    Oh I guess its cause I only use it for personal scripts and only really started using it after Groovy 2 (although I used the language before I didn't switch from Python to Groovy till after Groovy 2). I am also not as Groovy as I could be (ie write like its Java at times) so maybe thats why I haven't ran into issues.
jorge-fundido 11y ago
I don't understand the python2 vs python3 fuss. Maybe I'm not doing anything interesting enough, but I find it fairly easy to write code that runs in python >= 2.7 and python >= 3.3. If I was working in a python2-only code base, I would just baby-step it towards python3 compatibility. It doesn't have to be a complicated, disruptive task.
- nas 11y ago
  Things are a lot easier with recent versions of Python 3. Not spending more time on supporting 2/3 compatible codebases was a big mistake in my opinion. I think Guido had the idea that everyone was eventually going to run 2to3 and then be done with the conversion. There is too much Python 2 code out there for that to work. Python 2 was too successful and businesses have no inventive to convert working apps. The %-formatting (printf style) for bytes is a big deal (introduced in 3.5). Putting a 'u' prefix in front of text strings and 'b' in front of byte strings will not go a long way in making things work.
  - ant6n 11y ago
    Next step: bring back print. For my code base, I'm mostly worried about division being different, which will introduce silent errors when integer types break down (or up?) into floats.
esaym 11y ago
I've debated jumping from perl only dev into the python world for a couple of years now. I've got a list of Django youtube vids queued up on my plex server right now. But I was thinking yesterday (while in the shower of course), perl has perl6 (which may or may not take off). But what does the future of python have? Python 4,5,6? Any real innovative changes or just more of kicking the can down the road (such as perl5)?
- ch4s3 11y ago
  I think the best case for moving to Python is for the tooling around math and data science. If you're build other types of web apps in Perl and looking to switch to something else. I'm not sure Django is going to offer you a ton of benefit for the switching cost, IMHO.
  - esaym 11y ago
    Well the benefit I initially see is more jobs and with a side note of hopefully a cleaner code base. There are not too many perl companies that have been founded in the last 10 years. And I am finding more and more that companies that are older than 10 years old and are using perl, that this usually means they haven't changed a dang thing in their architecture or web dev process since 1998. Which means I get to deal with CGI spaghetti, 6+ second page load times (so count ajax anything out), and the world's worse use of javascript. I've had good experiences with newer perl companies with short contract work, but these older ones are killing me and I'm pretty bummed about it as you can tell. I've worked hard to learn best practices and modern web dev styles, none of which I can use at the older places.
- StavrosK 11y ago
  What's the can here?
jdlyga 11y ago
My main gripe about Python 3 and Python in general is that it really needs a good method of distribution. Sure there's PyInstaller, but it's not straightforward enough and there's a lot of mystery problems that take a lot of time to figure out.
deleted 11y ago
[deleted]

Python 3 in 2016

184 points by jaxondu 11y ago

The PyPi download statistics are constantly being quoted as though the are some exact representation of the state of Python 3 takeup. I'm calling this as bullshit. How much of these downloads are computers auto updating their configurations? How, exactly, do these stats reflect the number of people developing current projects with Python 3? The number of legacy projects written in Python 2 will be vastly higher than the number of Python3 projects currently in development. Maybe that's what is being updated. When a statistician does an analysis of what these numbers really mean I will believe them but until then the numbers mean precisely nothing. Or more accurately, they seem to mean exactly what the Python 2 diehards want them to believe. My assertion is that Python 3 is very actively and healthy and the PyPi stats are just lies, damn lies and statistics.

creshal 11y ago
I get my python 2 and 3 dependencies from distribution packages (Arch, Debian), and so do all people using my software. PyPi impact: Zero.
hynek 11y ago
Hmm I’m not sure how to take this comment. The main point of the article is basically that those numbers don’t tell the whole story (even explicitly in footnote 1).
- andrewstuart 11y ago
  Your post gives the stats some level of credit when really they tell absolutely nothing, or more precisely they tell a tale that is so open to interpretation as to mean nothing at all. There's no gloom around Python 3. Lots of people support it. The highest ever upvoted post on Reddit/r/Python was a post asking to remove training material that asserts that Python 3 is irrelevant. https://www.reddit.com/r/Python/top/ https://www.reddit.com/r/Python/top/ There must be alot of people who feel positively about Python 3 to vote it up that high, presumably at the same time that the Python 2 diehards are voting the post down. The appropriate message regarding the PyPi stats is not to give gentle credence to them but to condemn them as a completely irrelevant measure of the success or otherwise of Python 3.
  - hynek 11y ago
    Hm that’s unfortunate that it comes out that way. I thought I’m just acknowledging that people are agonizing over them and then explain why’s not a good metric.
    - mkesper 11y ago
      Footnotes are not very explicit, nobody reads the small print.
DasIch 11y ago
Somehow Python 3 projects don't require updates? PyPI stats are going to be massively inflated due to Continous Integration and such but I don't see why that would tip the scales in one direction or the other by any significant amount.
- hynek 11y ago
  The newer a pip, the more likely it is that it caches things for example. There a more things, I had long discussions with dstufft about it in the past.

hathym 11y ago

can we please stop writing articles in twitter? https://twitter.com/hynek/status/699928792752594944 https://twitter.com/hynek/status/699928792752594944

amstocker 11y ago

I think this is a nice healthy view to have about Python 2 to 3. Can't wait until python 4!

EvanPlaice 11y ago
I seriously doubt 4 will include breaking changes, at least not to the semantics/syntax of the language itself. What python really needs in 4 is better unified package management and distribution support. They have a lot to learn from the Javascript and Ruby evosystems.
- crdoconnor 11y ago
  >They have a lot to learn from the Javascript and Ruby evosystems. Such as? I really hope I'm not going to start needing 1,200 dependencies to build a simple app like I would in node.
  - EvanPlaice 11y ago
    Support for local, per-project installs without hacks like virtualenv. Per-project configurations to map things like external dependencies and project info. Setup.py + MANIFEST is not the answer. Better suport of versioned deps so multiple versions of the same dep 'just works' when its neessary. Better package publishing for library maintainers. Have you ever published a pckage to PYPI? It's a huge pain. Support for Markdown-based documentation on PYPI. ReStructuredText is cool and all but MD os the defacto standard Standard support for direct install from GitHub without weird hacks. Pick one unified standard and deprecate the rest. The current 3, distutils, distutils2 and setup.py all suck. Write some halfway decent docs on how to publish packages. I spend more time on Stack Overflow that the python docs every time I publish a package. Dependencies are used so heavily in the JS/Ruby ecosystem because it's extremely easy to publish a package and the package manager 'just works'.
    - crdoconnor 11y ago
      * Virtualenv isn't a hack. * Setup.py/MANIFEST.in seems like a pretty clear answer to me. * I've worked with python for about 10 years and only once have I come across two packages that required conflicting versions that I wanted to deploy in the same environment. * Yes, I do it pretty frequently. * "MD os the defacto standard" Huh? According to whom? ReST is fine. * "Standard support for direct install from GitHub without weird hacks." - stick "git+https://github.com/yourname/yourpackage" https://github.com/yourname/yourpackage" in your requirements.txt and off you go. * Yeah, they should really standardize on pip, but this is relatively minor. * Use one of the templates. * Yes, I hear somebody even published a package that checked if a number was negative. And it had a bug.

osullivj 11y ago

I code in both 2 & 3, and had been nervous about that. New stuff with low dependencies in 3, and older stuff with Python C API dependencies in 2 (eg spreadserve.com). I was worried that the move to 3 would force migration of my 2 based code, so I'm reassured rather than alarmed by this article. The cognitive load switching between two Python dialects isn't as bad as, for instance, switching between C++ with and without STL & Boost.

zzleeper 11y ago

I tried switching to 3 a few years ago and was burned by some libraries that didn't work or worked with bugs. Last year though I tried again and there were absolutely no problems. It's more natural, all non-dead libraries seem to support it, and in any case I was already using "from future import" for a while. That said, I don't really intend to port old stuff from 2.7 if I can avoid it, so I expect that 2 and 3 will coexist for a while even within the same firm

hynek 11y ago
That’s exactly the place I found myself in and that made me sum it up.

gloves 11y ago

Been thinking about learning to code, and a lot of people have recommended Python as a good language to begin with. Taking a look at this, should I be looking elsewhere?

orf 11y ago
Python is an excellent language to begin with, you're reading this article wrong if it puts you off Python. There is drama around Python 2 or Python 3, but the answer is clear. Use Python 3 for new projects, use Python 2 when you have to (legacy projects).
agumonkey 11y ago
It has nice features: - not large syntax - expressive overloaded keywords (in) - slice syntax that is easy on mind and eyes - nice set of builtin structure: lists, sets, dicts - with literals for all of them [], {}, {:} - lambda, generators, context (cute yet general way to ensure releasing resources, files, connections..) But as all languages, you can lose yourself, learn and write shitty code in it. Find idioms, https://duckduckgo.com/?q=raymond+hettinger+python&ia=videos https://duckduckgo.com/?q=raymond+hettinger+python&ia=videos <- hettinger likes to makes python code small and solid ps: I don't like it's oop syntax sometimes That said, I never learned so much about one language than by learning another one. All paradigms have at least one gem to discover.
hodwik 11y ago
If you decide to learn Python, I'd suggest going through the Learn Python the Hard Way book. It's excellent.
- hodwik 11y ago
  Weirdest downvotes I've ever gotten.

baq 11y ago

Python 3 is worth it not for asyncio and unicode (though these are very good reasons if you care about them). It's worth it due to 21st century exception handling, which breaks down in Python 2 in a spectacular fashion the moment you raise in your except: clauses.

hynek 11y ago
Ah yeah the small nice things. `raise from`, `__traceback__` on all raised exceptions (instead of dicking with `sys.exc_info`), `nonlocal`, `super` …

wiz21c 11y ago

Since everyone gives anecdotal proofs that Python 3 is just fine, I'll give mine as well. I've migrated to Python3 a rather big project (for the unicode handling) and although it was not quite easy, it'just fine now. I'm active in Qt, web, json, sql domains and I've never needed a library that is Python 2 only. Thus from my own point of view, the Python 3 ecosystem is just complete now. Super.

EvanPlaice 11y ago
I think the biggest barrier to adoption right now is OS support. OSX still comes bundled with python2. There's no indication that Apple is working on a transition to 3. Ubuntu is actively working on the transition but the current LTS release (ie the one companies/enterprise will use) is still locked onto python2. The same can likely be said for other flavors of *nix. From a user's perspective, python3 has been ready for 'prime time' for a while. From an OS, systems, enterprise perspective python3 still is still a ways out.
- emmelaich 11y ago
  I suspect that many Pythoners will install Python3 (with homebrew) or other on OSX (and whatever other platforms still come with just Python2)
  - hynek 11y ago
    I would recommend to even use pyenv (https://github.com/yyuu/pyenv https://github.com/yyuu/pyenv) that will allow you to install any Python version in your home directory (i.e. not fucking up your system installation). If you maintain many FOSS libs like I do, together with tox it's priceless.
    - obelisk_ 11y ago
      Homebrew installs software into /usr/local last time I checked so unless you are doing something really strange like manually overwriting system files, you'll be hard pressed to fuck up the whole system. Personally I'd install homebrew into /opt/homebrew.

srathi 11y ago

We are using Python LDAP library[1] at work, but it is not available for Python 3 yet. Is there an alternative? 1 https://pypi.python.org/pypi/python-ldap/ https://pypi.python.org/pypi/python-ldap/

hynek 11y ago
Yes! RedHat needed it too and forked the project: https://pypi.python.org/pypi/pyldap https://pypi.python.org/pypi/pyldap
thristian 11y ago
ldap3 is not API-compatible with python-ldap, but it's pure-Python (it doesn't need the OpenLDAP libraries installed) and you might find its API is a bit nicer to use: https://pypi.python.org/pypi/ldap3 https://pypi.python.org/pypi/ldap3
perlgeek 11y ago
I can second the recommendation for ldap3. It's very well-engineered, well-documented, works with python 2 and 3, and has (if I remember correctly) zero dependencies.

paulhallett 11y ago

We've been using Python 3 since we implemented a new service architecture and it's been an easy transition for our 50+ engineers.

deleted 11y ago

[deleted]

ivoras 11y ago

Since it's basically all anecdotal, I'll say my gazing-into-the-crystal-ball educated-guess feeling that Python 4 will make the entirety of Python about as popular as Perl is today if: it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3. The developers have dug themselves into this mess with frivolous differences ("print" a function, wanting to remove the "%" string operator, etc.), instead of spending the years on more productive features, now is the chance to dig themselves out again. It's a beautiful language, too bad the development choices were a bit sketchy.

orf 11y ago
Comments like this are so misguided and yet so common on HN. Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons. Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. Python 4 will just be the next release after Python 3.9.
- ivoras 11y ago
  It may very well never happen, that's a completely possible outcome. We'll see what it does to Python's popularity.
- bhaak 11y ago
  > Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. > > Python 4 will just be the next release after Python 3.9. Really? Why even change the major version then, when there are no breaking changes? Given that many Python programmers seem to be traumatized by the last major version switch, why even bother? Or is this just for setting up Python 5 can have breaking changes if the switch to 4 is painless?
  - orf 11y ago
    > Really? Why even change the major version then, when there are no breaking changes? Python releases don't follow semver. If Linus can bump the kernel to 4.0 because he felt like it so can Python.

retrogradeorbit 11y ago

I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that would be fine. But when it comes to new projects, I struggle to find a compelling reason to use Python at all, when there are so many amazing languages now to choose from. With a new project you could choose Scala, Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less popular ones like Haxe and Dart. I've even been playing around with Elm. And I'm sure I've missed a bunch of others too. So the question for me, for new projects is: why choose Python 3 (over all the other non python options) at all? Not what's better about Python 3 than Python 2, but what's better about Python 3 than those other choices. These other choices all have certain areas where they have great strengths. What is Python 3's strength when compared to these other languages? It's a mutable, imperative, single CPU bound language that can't target the browser and is extremely difficult to distribute and deploy. Or have these issues been fixed? I don't mean to troll any Python fanboys. I use Python 2 every single day at work and I'm very happy with it. But what does Python 3 offer that other new languages don't? Because when you are starting a new project you can choose anything. Why should I choose Python 3 for my new projects?

Odin78 11y ago
Noob question: What's so difficult about deploying/distributing python?
- hynek 11y ago
  ATM it takes work to create a deployable artifact. We package virtualenvs using fpm, others use Docker. But Go just spits out a single binary you can scp anywhere (the build process OTOH is more painful IMHO). That’s why I’m highly curious about https://us.pycon.org/2016/schedule/presentation/2122/ https://us.pycon.org/2016/schedule/presentation/2122/ .
- retrogradeorbit 11y ago
  https://glyph.twistedmatrix.com/2015/09/software-you-can-use.html https://glyph.twistedmatrix.com/2015/09/software-you-can-use...

vegabook 11y ago

Three is (finally) likely to win, if only because of the constant nagging of the project leaders, and the fact that some distros will now move to it by default. But it will be a pyrrhic victory because it will have been a force-feed, not an enthusiastic, willing, adoption by the community. As a result of this mess, while Python's inertia is huge, its momentum is slowing. Its leadership, having lost credibility, cannot really lead effectively anymore. It will continue to be a massive, unavoidable language, but something of the magic of when I first learned it, has been snuffed out.

hynek 11y ago
That’s only true for people who are part of the community for a long time. Newcomers don’t understand what the fuss is about and why anyone would want to use Python 2. My own Python bubble is more like what you described (although the mood is improving IMHO) but talking to newcomers is eye opening.
- deleted 11y ago
  [deleted]

emmelaich 11y ago

It's quite possible that someone will come up with a good enough automatic 2->3 converter which alleviate the situation.

Spiritus 11y ago
2to3 (comes bundled with Python) will do some of the work for you.
ProblemFactory 11y ago
There are converters, and it's not too difficult to even write code that runs in both Python 2 and 3. The main roadblock in upgrades is unicode text vs bytes handling. Python2 was lax about using bytes for text. You could do unicode and bytes properly if you really tried hard enough, but it took a conscious effort. So most people just used bytes for text, and hoped for the best (if the data is ASCII or UTF-8, it will work most of the time). Python3 is strict about the text vs bytes separation. Patching this into a program afterwards is a lot of work. But if your Python2 program already does unicode carefully in Python2 (unicode type internally everywhere, from __future__ import unicode_literals, explicit encode/decode when talking to external APIs), then you are 90% done with the upgrade to Python3.
icebraining 11y ago
python-modernize[1] tries to automatically make your codebase compatible with both Python 2 and 3, using 2to3 and six[2] underneath. I haven't tried it yet, though. [1] https://github.com/mitsuhiko/python-modernize https://github.com/mitsuhiko/python-modernize [2] https://pypi.python.org/pypi/six https://pypi.python.org/pypi/six
- brettcannon 11y ago
  Armin handed over development and now Modernize is actively developed at https://github.com/python-modernize/python-modernize https://github.com/python-modernize/python-modernize
  - icebraining 11y ago

moistgorilla 11y ago

This is the ultimate HN circlejerk comment >Scala, Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less popular ones like Haxe and Dart Are you kidding me? Did you just list the languages you see threads on HN about? Scala and Go I could maybe understand if you needed the performance but the rest of the choices are just bad. Especially if you are trying to start a business instead of a functional programming bootcamp. Also there is nothing inherently more difficult about deploying and distributing python compared to any of the languages you chose.

StavrosK 11y ago
Eh, okay, Go is much easier to deploy because it's a single binary (also the same with Dart), but yeah, the rest of the comment makes no sense. Seriously? Dart? Not even Rust?
dang 11y ago
Please don't be rude in HN comments. We detached this subthread from https://news.ycombinator.com/item?id=11124822 https://news.ycombinator.com/item?id=11124822 and marked it off-topic.

libeclipse 11y ago

I started off python learning python 3, but a few months into it, I was forced do a project in python 2. It was a turning point, I immediately ported over all my python projects to python 2. To me, it just seemed more simple, elegant, and cleaner. It was the more pythonic version of python. And if I'm still working with python after 2020, I'll be using python 2.

hepta 11y ago
I don't understand this, what is more "pythonic" about 2?
- hueving 11y ago
  Not typing 'encode' or 'decode' when dealing with strings. I know it sounds stupid, but it's really distracting compared to everything else in python that just flows easily.
  - mkesper 11y ago
    Then you're doing it wrong. Sorry but that's definitely better solved in Python3 than in 2. Always decode/encode when opening a file/stream/whatever and only use unicode internally.
  - Yaggo 11y ago
    Sounds like you are shooting yourself in the foot. Your code may work with ASCII but will immediately break in non-naïve cases.

angvp 11y ago

Not going to happen IMO, yet no advantages to do the transition.

mrweasel 11y ago
The Unicode support alone justify transitioning for us.

mangeletti 11y ago

For anyone hesitant because they're worried they will need to support 2.x installations at some point, there is 3to2[1]. You can write for 3.5 only, and then back port only if you need to. 1. https://pypi.python.org/pypi/3to2/1.1.1 https://pypi.python.org/pypi/3to2/1.1.1

czep 11y ago

I, for one, must admit to having almost completely ignored Python 3 until very recently. One thing I discovered that is way awesomer than you can imagine is Unicode handling: it just works! I'd say Unicode was a tricky issue in 50% of Python projects I've worked on in the past, but with Python 3, none of that matters anymore.

deleted 11y ago

[deleted]

dethos 11y ago

Unless it is explicitly necessary to use python 2 (like legacy stuff, that hasn't been upgraded yet), I've been using python 3 solely for almost 2 years, and there is no turning back. I have no reason to stick with the old version. The last piece that needs to change, to complete the transition, is the majority of OS makers to bundle python3 by default.

collyw 11y ago
I would be as well, but many jobs out there involve existing code on python 2.

draw_down 11y ago

The problem is not Python 3, the problem is keeping both languages in my head at the same time. I'm tired of caring whether "print" is supposed to be a function or not, I just want to print something.

orpheansodality 11y ago
Why not just always use print() as a function? That's only a single mental change, and works in both 2 and 3.
- witty_username 11y ago
  print isn't a function (even though print("hello") works) in Python 2. But you can use __future__ to make it a function.

Walkman 11y ago

In practice: inheriting from "object" every time is not a big deal, but losing the possibility to use Pypy or Kivy is huge.

MollyR 11y ago
This is my problem as well. I love using Kivy instead of tkinter, and Pypy.

fideloper 11y ago

Python3 is still broken in some important ways (virtual environments) on Debian/Ubuntu, which make it a but of a pain to use both in development and production. Example: Ubuntu 14.04 (and later versions) come with Python 3.4, but pyvenv is unavailable (just try searching ubuntu 14.04 pyvenv to get an idea). This bug from 2014 is still relevant, although at least the "python3.4-venv" package is available to patch it enough to get going. https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847?comments=all https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/129...

cdnsteve 11y ago

On the web framework side of things, who is using aiohttp (web) and something like API-Hour? Seems like the performance is really great. Python 3 asyncio. It's hard to find people blogging about it, not sure why? It seems like a great combination. http://blog.gmludo.eu/2015/02/macro-benchmark-with-django-flask-and-asyncio.html http://blog.gmludo.eu/2015/02/macro-benchmark-with-django-fl...

agentgt 11y ago

I used to write a lot of personal Python scripts (ie ~/bin). I mainly did this because I seem to always screw up bash scripts and just can't remember all the conditional flags ie ([[-z ]] and error handling with bash for me has always been tricky. However in the last couple of years I have dropped Python in favor of Groovy in part because I know the JVM and its plethora of libraries so well. Groovy is a highly underrated language. Really my only complaint is the startup time is not nearly as fast as Python but it does seem faster than say Clojure scripts. Also one of the things that I have to say I sort of think Java got right is that it has always been backward compatible (I know this was sort of impossible with Python given its not really a byte code language). That is I really don't have to worry if I write Groovy in a pre Java 5 (ie without generics) where as with Python I wasn't sure if I should write new scripts in 3 or 2. The other annoying thing albeit far less than Ruby is dependencies with Python. Groovy has a complete bad ass way of just declaring dependencies in a script (@Grab) and they will automatically be downloaded. I have yet to see a scripting language that does this (ie dependency install on demand). BTW since apparently any time I mention Java-like-tech on any HN post I seem to get downvoted... I really really love Python. This was not to denigrate Python or that Groovy is better than Python.

vorg 11y ago
> I really don't have to worry if I write Groovy in a pre Java 5 (ie without generics) Groovy has many incompatible changes between versions, esp from 1.8 to 2.0 but also 1.7 to 1.8, 1.6 to 1.7, etc. Many sites provide Groovy 1.8 as the default because no-one there wants to bother with upgrading.
- agentgt 11y ago
  Oh I guess its cause I only use it for personal scripts and only really started using it after Groovy 2 (although I used the language before I didn't switch from Python to Groovy till after Groovy 2). I am also not as Groovy as I could be (ie write like its Java at times) so maybe thats why I haven't ran into issues.

jorge-fundido 11y ago

I don't understand the python2 vs python3 fuss. Maybe I'm not doing anything interesting enough, but I find it fairly easy to write code that runs in python >= 2.7 and python >= 3.3. If I was working in a python2-only code base, I would just baby-step it towards python3 compatibility. It doesn't have to be a complicated, disruptive task.

nas 11y ago
Things are a lot easier with recent versions of Python 3. Not spending more time on supporting 2/3 compatible codebases was a big mistake in my opinion. I think Guido had the idea that everyone was eventually going to run 2to3 and then be done with the conversion. There is too much Python 2 code out there for that to work. Python 2 was too successful and businesses have no inventive to convert working apps. The %-formatting (printf style) for bytes is a big deal (introduced in 3.5). Putting a 'u' prefix in front of text strings and 'b' in front of byte strings will not go a long way in making things work.
- ant6n 11y ago
  Next step: bring back print. For my code base, I'm mostly worried about division being different, which will introduce silent errors when integer types break down (or up?) into floats.

esaym 11y ago

I've debated jumping from perl only dev into the python world for a couple of years now. I've got a list of Django youtube vids queued up on my plex server right now. But I was thinking yesterday (while in the shower of course), perl has perl6 (which may or may not take off). But what does the future of python have? Python 4,5,6? Any real innovative changes or just more of kicking the can down the road (such as perl5)?

ch4s3 11y ago
I think the best case for moving to Python is for the tooling around math and data science. If you're build other types of web apps in Perl and looking to switch to something else. I'm not sure Django is going to offer you a ton of benefit for the switching cost, IMHO.
- esaym 11y ago
  Well the benefit I initially see is more jobs and with a side note of hopefully a cleaner code base. There are not too many perl companies that have been founded in the last 10 years. And I am finding more and more that companies that are older than 10 years old and are using perl, that this usually means they haven't changed a dang thing in their architecture or web dev process since 1998. Which means I get to deal with CGI spaghetti, 6+ second page load times (so count ajax anything out), and the world's worse use of javascript. I've had good experiences with newer perl companies with short contract work, but these older ones are killing me and I'm pretty bummed about it as you can tell. I've worked hard to learn best practices and modern web dev styles, none of which I can use at the older places.
StavrosK 11y ago
What's the can here?

jdlyga 11y ago

My main gripe about Python 3 and Python in general is that it really needs a good method of distribution. Sure there's PyInstaller, but it's not straightforward enough and there's a lot of mystery problems that take a lot of time to figure out.

deleted 11y ago

[deleted]